From nobody Wed Apr 1 07:35:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0C1AC400 for ; Wed, 1 Apr 2015 07:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 v5hJBpKNdxpO for ; Wed, 1 Apr 2015 07:35:29 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9269A1AC3FD for ; Wed, 1 Apr 2015 07:35:29 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t31EZSqW021395 for ; Wed, 1 Apr 2015 10:35:28 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t31EZSPn032353 for ; Wed, 1 Apr 2015 10:35:28 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Tue, 31 Mar 2015 19:40:20 +0200 References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Wed, 01 Apr 2015 10:35:28 -0400 Message-ID: <32352.1427898928@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-01 10:35:28 EDT Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:35:31 -0000 J. Gomez writes: > a "technically appropriate" technical solution yes there is: > "Every resender[ *] who invalidates the original Author's DKIM > signature must take ownership of the Header-From and re-sign > the message". Simple. Easy. But socially unacceptable (for > now, at least) because of the expectations of several legacy > mail usages. If by "expectations of several legacy mail usages" you mean "reasonable expectations of well-established mail usages", and not "unreasonable expectations of nearly-obsolete mail usages", then sure. :-) So having granted that the above proposed solution is unacceptable, how can we move on to find an acceptable solution? Some days ago I tentatively suggested signing only part of some message parts, in particular part of the Subject header (excluding any future additions of "[list-identification]"), assuming that such an approach had doubtless already been suggested elsewhere. I was expecting to hear either "been there, tried that, won't work", or (a polite version of) "that's a dumb idea because...", but I've heard nothing. I can't quite make myself believe that you're all rendered speechless by my sheer genius, so... why *won't* something like that work? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Wed Apr 1 07:41:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B651AC427 for ; Wed, 1 Apr 2015 07:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 7Uxmvi-DNHwv for ; Wed, 1 Apr 2015 07:41:04 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCADB1A1B6A for ; Wed, 1 Apr 2015 07:41:01 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 10:40:57 -0400 From: "MH Michael Hammer (5304)" To: Anne Bennett , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Third Party Sender DMARC Adaptations Thread-Index: AQHQaxhBJX2wYZ5+W0+S6Sz7l8l0CZ02vneAgABSl4D//8xOiIABXq2qgAAA17A= Date: Wed, 1 Apr 2015 14:40:57 +0000 Message-ID: References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> In-Reply-To: <32352.1427898928@vindemiatrix.encs.concordia.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:41:06 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Anne Bennett > Sent: Wednesday, April 01, 2015 10:35 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations >=20 >=20 > J. Gomez writes: >=20 > > a "technically appropriate" technical solution yes there is: > > "Every resender[ *] who invalidates the original Author's DKIM > > signature must take ownership of the Header-From and re-sign the > > message". Simple. Easy. But socially unacceptable (for now, at least) > > because of the expectations of several legacy mail usages. >=20 > If by "expectations of several legacy mail usages" you mean "reasonable > expectations of well-established mail usages", and not "unreasonable > expectations of nearly-obsolete mail usages", then sure. :-) >=20 This will be extremely difficult. > So having granted that the above proposed solution is unacceptable, how > can we move on to find an acceptable solution? >=20 > Some days ago I tentatively suggested signing only part of some message > parts, in particular part of the Subject header (excluding any future add= itions > of "[list-identification]"), assuming that such an approach had doubtless > already been suggested elsewhere. I was expecting to hear either "been > there, tried that, won't work", or (a polite version of) "that's a dumb i= dea > because...", but I've heard nothing. I can't quite make myself believe t= hat > you're all rendered speechless by my sheer genius, so... why *won't* > something like that work? >=20 Signing only part of a message (whether body or only part of headers such a= s subject) invites abuse through replay attacks. This is one of the reasons= that "l=3D" pretty much went by the wayside. >=20 > Anne. > -- > Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal > H3G 1M8 > anne@encs.concordia.ca +1 514 848-2424= x2285 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Apr 1 07:53:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031F01ACD2A for ; Wed, 1 Apr 2015 07:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 3eYK2-HwbqG5 for ; Wed, 1 Apr 2015 07:53:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE901A1A67 for ; Wed, 1 Apr 2015 07:53:27 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t31ErOJa029416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 07:53:27 -0700 Message-ID: <551C0660.8030900@dcrocker.net> Date: Wed, 01 Apr 2015 07:53:20 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Steve Atkins , "dmarc@ietf.org" References: <8161668.HfpJrFpWJf@kitterma-e6430> <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> In-Reply-To: <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 01 Apr 2015 07:53:27 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:53:47 -0000 On 3/30/2015 12:01 PM, Steve Atkins wrote: > It's not particularly difficult to make DKIM and SPF work if you have full > control over the domain name you're sending from (and some control > over the delivery path). Forgive my focusing on precise wording, but 'sending from' can have enough different, valid meanings to permit some confusion, so I suggest language that is a bit more cumbersome but precise: It's not particularly difficult to make DKIM and SPF work if you have full control over the domain name that is used in the rfc5322.from (author) field in the message header (and some control over the delivery path). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 1 08:20:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C51ACD80 for ; Wed, 1 Apr 2015 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9-SeTHAPeokL for ; Wed, 1 Apr 2015 08:20:38 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id CB2CE1ACDA6 for ; Wed, 1 Apr 2015 08:20:37 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id BC3558B7E for ; Wed, 1 Apr 2015 17:20:36 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 1 Apr 2015 17:20:36 +0200 Message-ID: <8DC147BAA9DD4141A56051E342FDABC3@fgsr.local> From: "J. Gomez" To: References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> Date: Wed, 1 Apr 2015 17:20:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:20:41 -0000 On Wednesday, April 01, 2015 4:35 PM [GMT+1=3DCET], Anne Bennett wrote: > J. Gomez writes: >=20 > > a "technically appropriate" technical solution yes there is: > > "Every resender[ *] who invalidates the original Author's DKIM > > signature must take ownership of the Header-From and re-sign > > the message". Simple. Easy. But socially unacceptable (for > > now, at least) because of the expectations of several legacy > > mail usages. >=20 > If by "expectations of several legacy mail usages" you mean > "reasonable expectations of well-established mail usages", > and not "unreasonable expectations of nearly-obsolete mail > usages", then sure. :-) >=20 > So having granted that the above proposed solution is > unacceptable, how can we move on to find an acceptable solution? It is an "unacceptable" solution, for now at least because of the = incumbency said legacy mail usages still hold. If no better "solution" is found now when formalizing DMARC, I guess the = slow but unstoppable dynamics of reality will decide the matter for us = in about 10 or 15 years (much as SPF needed a lot of time to be = generally used and nowadays more and more people are publishing "-all"). Regards, J.Gomez From nobody Wed Apr 1 08:27:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E3A1ACD63 for ; Wed, 1 Apr 2015 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 A9lQ6HM4dpop for ; Wed, 1 Apr 2015 08:27:15 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 117D61ACD7A for ; Wed, 1 Apr 2015 08:27:09 -0700 (PDT) Received: from [10.247.19.251] (mobile-166-171-251-124.mycingular.net [166.171.251.124]) by mail.wordtothewise.com (Postfix) with ESMTPSA id D179F8005A for ; Wed, 1 Apr 2015 08:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1427902028; bh=RZcigC/9N1KJmS/Tmq9r9c4jsU/NYyDG29Pbf85U+n0=; h=From:Subject:Date:References:In-Reply-To:To:From; b=heCUFsqZ28sbPG7D51tdsVj3LH7nuQDKMu60Nsbh/vRRrnBaSqAH5mtGhgzwIDnW/ LbqUd8wQtWjnAjBSO5W3SeHCXbiKgLhWF/ZjSBXYiY6nJX+R9sZNsho417JTOJFwWh /TYEDR3+9RkDudVxOtLtIlYzTdQ9oxz8J/A6cgZQ= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <26EAE921-357D-44AE-8716-9D00A71CDB85@wordtothewise.com> Date: Wed, 1 Apr 2015 08:27:07 -0700 References: <8161668.HfpJrFpWJf@kitterma-e6430> <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> <551C0660.8030900@dcrocker.net> In-Reply-To: <551C0660.8030900@dcrocker.net> To: "dmarc@ietf.org" X-Mailer: iPhone Mail (12B466) Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:27:16 -0000 > On Apr 1, 2015, at 07:53, Dave Crocker wrote: >=20 >> On 3/30/2015 12:01 PM, Steve Atkins wrote: >> It's not particularly difficult to make DKIM and SPF work if you have ful= l >> control over the domain name you're sending from (and some control >> over the delivery path). >=20 > Forgive my focusing on precise wording, but 'sending from' can have > enough different, valid meanings to permit some confusion, so I suggest > language that is a bit more cumbersome but precise: >=20 > It's not particularly difficult to make DKIM and SPF work if you > have full control over the domain name that is used in the rfc5322.from > (author) field in the message header (and some control over the delivery > path). In the context of reduced SPF and DKIM functionality as required for use wit= h DMARC, sure. Cheers, Steve= From nobody Wed Apr 1 08:31:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08B1ACD63 for ; Wed, 1 Apr 2015 08:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 FwwY4p-gcPqv for ; Wed, 1 Apr 2015 08:31:21 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 A48921ACE02 for ; Wed, 1 Apr 2015 08:31:21 -0700 (PDT) Received: by wgdm6 with SMTP id m6so57498739wgd.2 for ; Wed, 01 Apr 2015 08:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVQaHSMcBteOZfULaRL6kYz0cp/MPfLBy0vZCyN1eo0=; b=zOxeZXJNd+drQnc08thUl07SDmUxXYRnUzFtaRGHSmy0z9isWbunvbaWXDTh2Wb+W/ I02mewJOqHPsyBvJtqGkIOgvz8VT1e/GM2VIJKg7WV1aSvC1YKeCuEA4EX4ChfgjA46X Xt7OboRHnuDJ+0Ad6SYcxo7rgGKsMhw3yaxPAIm3DiksisjCGDaelWQe9RE4uUnoHIis R3mVXV9uH/xF81eITPx2ymUICz8PCgIyrJ1IecJTLTxxA0/T81QrJM8qGRJS+0NH/lGr Qqh1RO8shG+ZM04k1oCeklEfj9v5jqSM9L58koRbMuyGPpi+MIg38PcYIW334NBOnCkT 1psA== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr86188886wjc.135.1427902280259; Wed, 01 Apr 2015 08:31:20 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 1 Apr 2015 08:31:20 -0700 (PDT) In-Reply-To: <32352.1427898928@vindemiatrix.encs.concordia.ca> References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> Date: Wed, 1 Apr 2015 08:31:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=047d7bd6adce305e5b0512ab687c Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:31:26 -0000 --047d7bd6adce305e5b0512ab687c Content-Type: text/plain; charset=UTF-8 On Wed, Apr 1, 2015 at 7:35 AM, Anne Bennett wrote: > Some days ago I tentatively suggested signing only part of > some message parts, in particular part of the Subject header > (excluding any future additions of "[list-identification]"), > assuming that such an approach had doubtless already been > suggested elsewhere. I was expecting to hear either "been > there, tried that, won't work", or (a polite version of) "that's > a dumb idea because...", but I've heard nothing. I can't quite > make myself believe that you're all rendered speechless by my > sheer genius, so... why *won't* something like that work? I missed the earlier suggestion. As I recall this was considered during the development of DKIM originally, exactly for this reason. We rejected it because we couldn't come up with a safe description of what a tag should look like. If arbitrary text is allowed in there, then one could "tag" a spam URL at the front of a legitimate message's Subject field and the signature would still pass. If you assert a length limit on the size of a tag, then lists out there that use some longer mnemonic to identify the list are excluded. If you assert no special characters are allowed, you exclude international list names. Not all list tags use the square brackets at the front as delimiters. Et cetera. Short of introducing legislation about what constitutes a "standard" set of list modifications, which would be highly controversial and consensus firmly disliked, there wasn't a good path forward there, so the working group dropped the idea. -MSK --047d7bd6adce305e5b0512ab687c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 1, 2015 at 7:35 AM, Anne Bennett <anne@e= ncs.concordia.ca> wrote:
Some days ago I tentati= vely suggested signing only part of
some message parts, in particular part of the Subject header
(excluding any future additions of "[list-identification]"),
assuming that such an approach had doubtless already been
suggested elsewhere.=C2=A0 I was expecting to hear either "been
there, tried that, won't work", or (a polite version of) "tha= t's
a dumb idea because...", but I've heard nothing.=C2=A0 I can't= quite
make myself believe that you're all rendered speechless by my
sheer genius, so... why *won't* something like that work?
<= div>
I missed the earlier suggestion.

As I = recall this was considered during the development of DKIM originally, exact= ly for this reason.=C2=A0 We rejected it because we couldn't come up wi= th a safe description of what a tag should look like.=C2=A0 If arbitrary te= xt is allowed in there, then one could "tag" a spam URL at the fr= ont of a legitimate message's Subject field and the signature would sti= ll pass.=C2=A0 If you assert a length limit on the size of a tag, then list= s out there that use some longer mnemonic to identify the list are excluded= .=C2=A0 If you assert no special characters are allowed, you exclude intern= ational list names.=C2=A0 Not all list tags use the square brackets at the = front as delimiters.=C2=A0 Et cetera.

Short of introducin= g legislation about what constitutes a "standard" set of list mod= ifications, which would be highly controversial and consensus firmly dislik= ed, there wasn't a good path forward there, so the working group droppe= d the idea.

-MSK
--047d7bd6adce305e5b0512ab687c-- From nobody Wed Apr 1 08:31:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09AB1ACE1F for ; Wed, 1 Apr 2015 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 wzRtSEYtqYhK for ; Wed, 1 Apr 2015 08:31:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF191ACDD6 for ; Wed, 1 Apr 2015 08:31:34 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t31FVU0k031024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 08:31:34 -0700 Message-ID: <551C0F4F.7030007@dcrocker.net> Date: Wed, 01 Apr 2015 08:31:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Steve Atkins , "dmarc@ietf.org" References: <8161668.HfpJrFpWJf@kitterma-e6430> <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> <551C0660.8030900@dcrocker.net> <26EAE921-357D-44AE-8716-9D00A71CDB85@wordtothewise.com> In-Reply-To: <26EAE921-357D-44AE-8716-9D00A71CDB85@wordtothewise.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 01 Apr 2015 08:31:34 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:31:38 -0000 On 4/1/2015 8:27 AM, Steve Atkins wrote: > n the context of reduced SPF and DKIM functionality as required for use with DMARC, sure. Wasn't that that was the context of the thread? And one of the useful things about the wording I suggested is that it doesn't rely on context. It's always accurate and precise and clear. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 1 08:56:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BA81ACE9E for ; Wed, 1 Apr 2015 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GbBQNEKGh8Xy for ; Wed, 1 Apr 2015 08:56:34 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5A11ACE8E for ; Wed, 1 Apr 2015 08:56:34 -0700 (PDT) Received: from [10.247.19.251] (mobile-166-171-251-124.mycingular.net [166.171.251.124]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 692528005A for ; Wed, 1 Apr 2015 08:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1427903794; bh=s/j2+WqZ6E+KDEc8CbBXEPH+D28wqUVVTUcGIXU3S20=; h=From:Subject:Date:References:In-Reply-To:To:From; b=SHD+kg/BjyuCPgej7Inq8Vyc+V03Vnj65Fyz4Plt4xKRf0uG5OLR/JElhIAXnI0Nk UlXCrCzjTDSSMderL0UGYigpRf7XVXx/DkJUs6e4EUCipG86HHJdTgIuZL2BpgeHzb zJnPHMuTZ8wZx2fBFPxHnQoGwKDihkFS0ZuvSAis= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: Date: Wed, 1 Apr 2015 08:56:30 -0700 References: <8161668.HfpJrFpWJf@kitterma-e6430> <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> <551C0660.8030900@dcrocker.net> <26EAE921-357D-44AE-8716-9D00A71CDB85@wordtothewise.com> <551C0F4F.7030007@dcrocker.net> In-Reply-To: <551C0F4F.7030007@dcrocker.net> To: "dmarc@ietf.org" X-Mailer: iPhone Mail (12B466) Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:56:39 -0000 > On Apr 1, 2015, at 08:31, Dave Crocker wrote: >=20 >> On 4/1/2015 8:27 AM, Steve Atkins wrote: >> n the context of reduced SPF and DKIM functionality as required for use w= ith DMARC, sure. >=20 > Wasn't that that was the context of the thread? The message being discussed wasn't from a domain that was using DMARC, thoug= h that's usually an implicit context on a dmarc mailing list. >=20 > And one of the useful things about the wording I suggested is that it > doesn't rely on context. It's always accurate and precise and clear. It's clear, but I don't think it's accurate unless you include the context o= f DMARC alignment. Controlling the domain used in the 5322.from doesn't allow me to do SPF or d= kim authentication, as they don't key off that domain. To be able to authenticate I need to control the domain used in the return p= ath or dkim d=3D - just controlling the 5322.from itself doesn't allow me to= send authenticated mail using that domain. As a concrete example, if I send mail with a 5322.from of steve@blighty.com t= hrough a typical small esp that uses a bounce.esp.com return path and signs w= ith d=3Desp.com then I cannot authenticate that email, despite having full c= ontrol over the domain used in the 5322.from. Cheers, Steve= From nobody Wed Apr 1 09:15:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7E81AC3FB for ; Wed, 1 Apr 2015 09:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 28OajJ8HY77n for ; Wed, 1 Apr 2015 09:15:53 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573D01A1A64 for ; Wed, 1 Apr 2015 09:15:53 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 12:15:51 -0400 From: "MH Michael Hammer (5304)" To: Steve Atkins , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Third Party Sender DMARC Adaptations Thread-Index: AQHQaxhBJX2wYZ5+W0+S6Sz7l8l0CZ01pJ6AgALfbwCAAAlwgIAAATaAgAAHAAD//8FjsA== Date: Wed, 1 Apr 2015 16:15:50 +0000 Message-ID: References: <8161668.HfpJrFpWJf@kitterma-e6430> <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> <551C0660.8030900@dcrocker.net> <26EAE921-357D-44AE-8716-9D00A71CDB85@wordtothewise.com> <551C0F4F.7030007@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:15:55 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Steve Atkins > Sent: Wednesday, April 01, 2015 11:56 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations >=20 >=20 >=20 > > On Apr 1, 2015, at 08:31, Dave Crocker wrote: > > > >> On 4/1/2015 8:27 AM, Steve Atkins wrote: > >> n the context of reduced SPF and DKIM functionality as required for us= e > with DMARC, sure. > > > > Wasn't that that was the context of the thread? >=20 > The message being discussed wasn't from a domain that was using DMARC, > though that's usually an implicit context on a dmarc mailing list. >=20 > > > > And one of the useful things about the wording I suggested is that it > > doesn't rely on context. It's always accurate and precise and clear. >=20 > It's clear, but I don't think it's accurate unless you include the contex= t of > DMARC alignment. >=20 > Controlling the domain used in the 5322.from doesn't allow me to do SPF o= r > dkim authentication, as they don't key off that domain. >=20 > To be able to authenticate I need to control the domain used in the retur= n > path or dkim d=3D - just controlling the 5322.from itself doesn't allow m= e to > send authenticated mail using that domain. >=20 > As a concrete example, if I send mail with a 5322.from of steve@blighty.c= om > through a typical small esp that uses a bounce.esp.com return path and si= gns > with d=3Desp.com then I cannot authenticate that email, despite having fu= ll > control over the domain used in the 5322.from. >=20 That's an operational choice Steve. You could provide them a private DKIM k= ey so they could sign d=3D with your 5322.from domain signature. If they ar= en't willing to do that and you are concerned about abuse of your domain th= en you find another vendor. Places you have a contractual relationship with= are much easier to resolve than random 3rd parties. Mike From nobody Wed Apr 1 09:50:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDC51A905E for ; Wed, 1 Apr 2015 09:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nHrdA_N020x7 for ; Wed, 1 Apr 2015 09:50:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70201A8939 for ; Wed, 1 Apr 2015 09:50:41 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D49F4C40021 for ; Wed, 1 Apr 2015 11:50:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427907040; bh=3OVXLhdw80LmIMesgihRoT1IhSuRwqeWvN4hCvOFzE0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VvQxVkmjLVhZEG7MSpseNOr4J5uI7Gb9jdanb8rH1lolO1LyKBdiTSw0aBnczuOWd XU0daqpC0oxMR9RRBzKTli3S9xgzbMhmK2TO+Mu1Eo7h+wCkRx5K6iDzvPUG7mU3/1 kerxQ+QZM2skntYY0zV6DulF6zYRnbvu6mVo5fIc= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 01 Apr 2015 12:50:40 -0400 Message-ID: <2490793.3lDNzc1A5U@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-48-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <8161668.HfpJrFpWJf@kitterma-e6430> <32352.1427898928@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:50:43 -0000 On Wednesday, April 01, 2015 08:31:20 AM Murray S. Kucherawy wrote: > On Wed, Apr 1, 2015 at 7:35 AM, Anne Bennett wrote: > > Some days ago I tentatively suggested signing only part of > > some message parts, in particular part of the Subject header > > (excluding any future additions of "[list-identification]"), > > assuming that such an approach had doubtless already been > > suggested elsewhere. I was expecting to hear either "been > > there, tried that, won't work", or (a polite version of) "that's > > a dumb idea because...", but I've heard nothing. I can't quite > > make myself believe that you're all rendered speechless by my > > sheer genius, so... why *won't* something like that work? > > I missed the earlier suggestion. > > As I recall this was considered during the development of DKIM originally, > exactly for this reason. We rejected it because we couldn't come up with a > safe description of what a tag should look like. If arbitrary text is > allowed in there, then one could "tag" a spam URL at the front of a > legitimate message's Subject field and the signature would still pass. If > you assert a length limit on the size of a tag, then lists out there that > use some longer mnemonic to identify the list are excluded. If you assert > no special characters are allowed, you exclude international list names. > Not all list tags use the square brackets at the front as delimiters. Et > cetera. > > Short of introducing legislation about what constitutes a "standard" set of > list modifications, which would be highly controversial and consensus > firmly disliked, there wasn't a good path forward there, so the working > group dropped the idea. That matches my recollection. Scott K From nobody Wed Apr 1 11:11:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980911A87C7 for ; Wed, 1 Apr 2015 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=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 solQnjAyEvii for ; Wed, 1 Apr 2015 11:11:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4B41A19F6 for ; Wed, 1 Apr 2015 11:11:38 -0700 (PDT) Received: (qmail 84190 invoked from network); 1 Apr 2015 18:11:36 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Apr 2015 18:11:36 -0000 Date: 1 Apr 2015 18:11:14 -0000 Message-ID: <20150401181114.966.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:11:39 -0000 >As I recall this was considered during the development of DKIM originally, >exactly for this reason. We rejected it because we couldn't come up with a >safe description of what a tag should look like. Yeah, that's what I recall, we couldn't figure out a way to allow benign modifications without also allowing spammy ones. Has anyone looked at my double signing draft? The idea is the the original sender (which we'll call, oh, Yahoo) puts on a very weak signature probably only on From, Date, and Message-ID, with l=0 and a new tag that says the signature is only valid if the message is also signed by a specific other domain, call it ietf.org. It probably also puts on an ordinary strong signature, too, and sends the message to a list forwarder such as dmarc@ietf.org. The list does what it does, and signs the message normally with d=ietf.org. That breaks the strong yahoo signature, but the weak one is now valid in combination with the normal ietf.org signature, so there's a valid d=yahoo signature and DMARC is happy. The forwarder could of course do naughty things, but only the specific forwarder to whom the message was sent, which greatly limits the scope of damage. It's even more limited in the common case that the original sender has a reasonably good idea who are likely to be the well behaved forwarders and only puts the weak signatures on mail sent to them. R's, John From nobody Wed Apr 1 11:11:55 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E502E1A8A1F for ; Wed, 1 Apr 2015 11:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 5TBQkdBQvEOL for ; Wed, 1 Apr 2015 11:11:52 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (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 12DEA1A8A1A for ; Wed, 1 Apr 2015 11:11:52 -0700 (PDT) Received: by qcay5 with SMTP id y5so48124431qca.1 for ; Wed, 01 Apr 2015 11:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VCKkDXZ9phgBc/uBT1LbXMf9hkoQ3e3XEUNRLNzKKBo=; b=DJxDHoeF1MESmhnHfVoevcrxIHy/q9udEfc1lHOSswviVdoE3sYWnMvQLWBVTwhX4Q IRpukAMpiYTqzFZsr77g+FUjSQoJ3B0klrPmcavN7BYJwrJ4AUhY1/pXCuRN8UbuO0fx MMQ9ExDkCpSTymMU9wBRVu3DA4Z4V8UhlDlVCTsMeaBQm2LAQM/n/KG546I6hk5xwbtA go9F+WynHF+IpW0gRRKVTTB20TEsNqCyB2af/qvH+niwNrkiDjcHZWSHJ8MsxQYqIuGK iZEDnn0xMuPpSGSU8IozEqJ40FodQU+G8SwHdu02OTRbZJSIWWShUoWD45VJHiRHooVU 6Trg== X-Received: by 10.140.16.162 with SMTP id 31mr28068367qgb.31.1427911911354; Wed, 01 Apr 2015 11:11:51 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 131sm1745983qhh.48.2015.04.01.11.11.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 11:11:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: Date: Wed, 1 Apr 2015 11:11:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8161668.HfpJrFpWJf@kitterma-e6430> <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> <551C0660.8030900@dcrocker.net> <26EAE921-357D-44AE-8716-9D00A71CDB85@wordtothewise.com> <551C0F4F.7030007@dcrocker.net> To: Michael Hammer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dmarc@ietf.org" , Steve Atkins Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:11:54 -0000 > On Apr 1, 2015, at 9:15 AM, MH Michael Hammer (5304) = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Steve Atkins >> Sent: Wednesday, April 01, 2015 11:56 AM >> To: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations >>=20 >>=20 >>=20 >>> On Apr 1, 2015, at 08:31, Dave Crocker wrote: >>>=20 >>>> On 4/1/2015 8:27 AM, Steve Atkins wrote: >>>> n the context of reduced SPF and DKIM functionality as required for = use >> with DMARC, sure. >>>=20 >>> Wasn't that that was the context of the thread? >>=20 >> The message being discussed wasn't from a domain that was using = DMARC, >> though that's usually an implicit context on a dmarc mailing list. >>=20 >>>=20 >>> And one of the useful things about the wording I suggested is that = it >>> doesn't rely on context. It's always accurate and precise and = clear. >>=20 >> It's clear, but I don't think it's accurate unless you include the = context of >> DMARC alignment. >>=20 >> Controlling the domain used in the 5322.from doesn't allow me to do = SPF or >> dkim authentication, as they don't key off that domain. >>=20 >> To be able to authenticate I need to control the domain used in the = return >> path or dkim d=3D - just controlling the 5322.from itself doesn't = allow me to >> send authenticated mail using that domain. >>=20 >> As a concrete example, if I send mail with a 5322.from of = steve@blighty.com >> through a typical small esp that uses a bounce.esp.com return path = and signs >> with d=3Desp.com then I cannot authenticate that email, despite = having full >> control over the domain used in the 5322.from. >=20 > That's an operational choice Steve. You could provide them a private = DKIM key so they could sign d=3D with your 5322.from domain signature. = If they aren't willing to do that and you are concerned about abuse of = your domain then you find another vendor. Places you have a contractual = relationship with are much easier to resolve than random 3rd parties. Dear Mike, View this issue from the perspective of those offering forums=20 and who provide recipients a means to identify authors and to=20 sort messages. Most individuals do not own their =46rom domain=20 and instead rely on services offered by their broadband provider. =20 It is fairly unlikely either organizations or individuals will=20 offer private keys or authorize all source IP addresses to=20 support all possible forums on a large scale. Neither DKIM nor=20 SPF accommodate such use based on current DMARC constructs, even=20 assuming contractual issues are not imposed on behalf of clients=20 or providers.=20 In that sense, DMARC (ab)use can not be remedied by practical=20 operational choices, which DMARC should be able to support. I-D to follow. Regards, Douglas Otis= From nobody Wed Apr 1 11:20:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19341A1C03 for ; Wed, 1 Apr 2015 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=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 eIWTN_AHMdCU for ; Wed, 1 Apr 2015 11:20:52 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 2264F1A889D for ; Wed, 1 Apr 2015 11:20:52 -0700 (PDT) Received: by wgra20 with SMTP id a20so62273618wgr.3 for ; Wed, 01 Apr 2015 11:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xJYI6FVG/vuGGHB0v9hrXOP1GL+l+8wRZWcSpdrPZzY=; b=TZFtzMPA/j/ONx2EXE7Lv6kvJWoQvtcQVqHtgkjAjmum642Zc/Y57/bjnZK08hix+B mK6hnPg7DOCPHiIlU0ZnepgArR6P5lXx7KbdSWJjfcDt2xTzn5ZfIS6WBn+otmnMjZ+A RKcDyNrfovtJQ6Dn/hdP9qaJjEYXshDn2wNVYLZYxgklYrA1H7JQHwg4apOdWgargoo5 aKVQEckZbyZKPmuya0iaPR4YqUaxugqi3X3k3ZlpCTYJcz09qvet9xZ6qBsso/In7nTj A9UtQisvOV+OpZS9vM1vZpvSB47HvEmNKwUzkWBeagI9lVxAVZKie7ZGzjF2jDBK4N4U FWzw== MIME-Version: 1.0 X-Received: by 10.180.187.67 with SMTP id fq3mr17542064wic.59.1427912450882; Wed, 01 Apr 2015 11:20:50 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 1 Apr 2015 11:20:50 -0700 (PDT) In-Reply-To: <20150401181114.966.qmail@ary.lan> References: <20150401181114.966.qmail@ary.lan> Date: Wed, 1 Apr 2015 11:20:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c3807067c29f0512adc6b7 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:20:53 -0000 --001a11c3807067c29f0512adc6b7 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 1, 2015 at 11:11 AM, John Levine wrote: > Has anyone looked at my double signing draft? The idea is the the > original sender (which we'll call, oh, Yahoo) puts on a very weak > signature probably only on From, Date, and Message-ID, with l=0 and a > new tag that says the signature is only valid if the message is also > signed by a specific other domain, call it ietf.org. It probably also > puts on an ordinary strong signature, too, and sends the message to a > list forwarder such as dmarc@ietf.org. The list does what it does, > and signs the message normally with d=ietf.org. That breaks the > strong yahoo signature, but the weak one is now valid in combination > with the normal ietf.org signature, so there's a valid d=yahoo > signature and DMARC is happy. > > The forwarder could of course do naughty things, but only the specific > forwarder to whom the message was sent, which greatly limits the scope > of damage. It's even more limited in the common case that the original > sender has a reasonably good idea who are likely to be the well > behaved forwarders and only puts the weak signatures on mail sent to > them. > Didn't we stalemate on the question of whether this has to be a whole new header field, or a "v=" increase? I seem to recall someone (Dave?) thinking both were horrible. -MSK --001a11c3807067c29f0512adc6b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 1, 2015 at 11:11 AM, John Levine <johnl@taugh.c= om> wrote:
Has anyone looked at my double signin= g draft?=C2=A0 The idea is the the
original sender (which we'll call, oh, Yahoo) puts on a very weak
signature probably only on From, Date, and Message-ID, with l=3D0 and a
new tag that says the signature is only valid if the message is also
signed by a specific other domain, call it ietf.org.=C2=A0 It probably also
puts on an ordinary strong signature, too, and sends the message to a
list forwarder such as dmarc@ietf.org= .=C2=A0 The list does what it does,
and signs the message normally with d=3Dietf.org.=C2=A0 That breaks the
strong yahoo signature, but the weak one is now valid in combination
with the normal ietf.org = signature, so there's a valid d=3Dyahoo
signature and DMARC is happy.

The forwarder could of course do naughty things, but only the specific
forwarder to whom the message was sent, which greatly limits the scope
of damage. It's even more limited in the common case that the original<= br> sender has a reasonably good idea who are likely to be the well
behaved forwarders and only puts the weak signatures on mail sent to
them.

Didn't we stalemate on the qu= estion of whether this has to be a whole new header field, or a "v=3D&= quot; increase?=C2=A0 I seem to recall someone (Dave?) thinking both were h= orrible.

-MSK
--001a11c3807067c29f0512adc6b7-- From nobody Wed Apr 1 11:36:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E701A7025 for ; Wed, 1 Apr 2015 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 foQFf-jK-PBo for ; Wed, 1 Apr 2015 11:36:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69A51A86FC for ; Wed, 1 Apr 2015 11:36:33 -0700 (PDT) Received: (qmail 89194 invoked from network); 1 Apr 2015 18:36:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15c69.551c3ab0.k1504; bh=F9ZuL/RtkeqDkfMOF9Dnz0owl5SeOhalsh7LThD60wk=; b=eip4Ig18vhVPaWwChLMd77I+qQiK6DA3b35arZQCEjIROCElYj7mmtsy+i4YlGsaFxRwq3ohboMQ3L/COHhIwzqHkwah4fxio6GdWFxpLae4lAeU/OkSS42GjTJSHYeQLhAYdx4BMge4j/XsR/pGg2vmtVgtYq1NfVYLi9wy6lG3UD3rYGhM9qyqb2AwntKmm016VQK5lmPGZvONywn4TnniFCr5jMigJ+wg54Y5ipoHoOsAYHts7t7u8jxqgCHw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15c69.551c3ab0.k1504; bh=F9ZuL/RtkeqDkfMOF9Dnz0owl5SeOhalsh7LThD60wk=; b=2Qx5/80TqSi0FBEZ1zq1AGOOM0S4D6ltOtMMHYgqEhCgyD5fqiDtHZzQ3I19rdkUdVYw9qjBVwJHHHckatKLxDhFXvWEcHOwMt+O6hY6oa6PPjwULl7LcoPYrLjWRGQI6xQTcjMkvbBRJa6LMKSdctZu8KlzzmXF40yxKnF/6To+oa2iyeoRdYG4V9HRn0ZA+J8xwOtFhJPMaftg+CzRZFQSoI1c+o4FW63q5y4P4vkPuT3fQt6NW0+EBASLoeUC Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2015 18:36:32 -0000 Date: 1 Apr 2015 14:36:31 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150401181114.966.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:36:39 -0000 > Didn't we stalemate on the question of whether this has to be a whole new > header field, or a "v=" increase? I seem to recall someone (Dave?) > thinking both were horrible. That was certainly a question, but I don't recall any consensus on realtive horribility. I like v=2, that's what version bumps are for. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 18:00:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CD31AD061 for ; Wed, 1 Apr 2015 18:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 e3vLGYLseSEK for ; Wed, 1 Apr 2015 18:00:22 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 737F21AD062 for ; Wed, 1 Apr 2015 18:00:22 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3210KBc018507; Wed, 1 Apr 2015 21:00:20 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3210J0l025104; Wed, 1 Apr 2015 21:00:19 -0400 Message-Id: <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Murray S. Kucherawy" From: Michael Jack Assels In-reply-to: References: <20150401181114.966.qmail@ary.lan> Comments: In-reply-to "Murray S. Kucherawy" message dated "Wed, 01 Apr 2015 11:20:50 -0700." Date: Wed, 01 Apr 2015 21:00:19 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-01 21:00:20 EDT Archived-At: Cc: "dmarc@ietf.org" , John Levine , mjassels@encs.concordia.ca Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 01:00:24 -0000 On Wed, 01 Apr 2015 11:20:50 PDT, "Murray S. Kucherawy" wrote: > On Wed, Apr 1, 2015 at 11:11 AM, John Levine wrote: > > > Has anyone looked at my double signing draft? The idea is the the > > original sender (which we'll call, oh, Yahoo) puts on a very weak > > signature probably only on From, Date, and Message-ID, with l=0 and a > > new tag that says the signature is only valid if the message is also > > signed by a specific other domain, call it ietf.org. It probably also > > puts on an ordinary strong signature, too, and sends the message to a > > list forwarder such as dmarc@ietf.org. The list does what it does, > > and signs the message normally with d=ietf.org. That breaks the > > strong yahoo signature, but the weak one is now valid in combination > > with the normal ietf.org signature, so there's a valid d=yahoo > > signature and DMARC is happy. > > > > The forwarder could of course do naughty things, but only the specific > > forwarder to whom the message was sent, which greatly limits the scope > > of damage. It's even more limited in the common case that the original > > sender has a reasonably good idea who are likely to be the well > > behaved forwarders and only puts the weak signatures on mail sent to > > them. > > > > Didn't we stalemate on the question of whether this has to be a whole new > header field, or a "v=" increase? I seem to recall someone (Dave?) > thinking both were horrible. > > -MSK To avoid a new header field or a "v=" increase, to make DMARC failure a really reliable indication of genuine invalidity, at least where mailing lists are concerned, why not focus on the fact that RFC5322.From headers clearly allow multiple addresses, and invite Mediators such as mailing list to take responsibility for their changes by adding an address in their own domain to the RFC5322.From header and adding their own DKIM-Signature? RFC7489 seems to hem and haw a bit about multiple From addresses (in a single From header). E.g., in Section 6.6.1: o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format; and a little later in the same section: The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. (The word "fail" leaves me confused. Shouldn't that be "pass"?) At any rate, it seems to me that if DMARC would be satisfied by a Mediator making substantial modifications to my message, changing the RFC5322.From to From: "Michael Jack Assels" and signing appropriately, it ought to be similarly happy with From: "Michael Jack Assels" , "dmarc" Sender: "dmarc" signed by IETF's sending MTA. Assuming that the usual change is made to the Subject line and the usual trailer is appended to the message body, only the "ietf.org" identity ought to align with "the" RFC5322.From domain, and I can't see a reason why DMARC wouldn't be happy. Yes, someone could have spoofed my address, but IETF's receiver will have had an opportunity to check that, so it's either IETF's fault for accepting the original message or my MTA's fault for not being DMARC compliant. In this case, the mailing list would be doing what's asked of it by DMARC, but keeping (most of) it's time honoured values intact. MJA From nobody Wed Apr 1 19:05:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0B1A8824 for ; Wed, 1 Apr 2015 19:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 pDpHTrieVvHk for ; Wed, 1 Apr 2015 19:04:59 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81111AC401 for ; Wed, 1 Apr 2015 19:04:57 -0700 (PDT) Received: (qmail 47993 invoked from network); 2 Apr 2015 02:04:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=bb78.551ca3c8.k1504; bh=5eElWyYgZTHmgCwRVkZSXpPBZfj/eqfQKLP1GzrhzGs=; b=R+pMqpDcRidzde+debr4Mijqn2vZCc9XtddWdWSUQv8elj131sXS/SJ5FnYojAQ1HToF8edNK4pgiftiSeirsFHj4l+KIbEMrwGhpwZNRhygS1smshc8+Rz59r08CmPpTlc1Zqan24WvQpzco3UetEYCOXjyWqNAseuR0qSJ5jJyZDbLnPHPz6h6tMd6r/E//Z8dXNguaohbP1n5b9qYCeAbyTvuc40a6XVxUEt9potQ7AjRBMema/nkZtZLb7i8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=bb78.551ca3c8.k1504; bh=5eElWyYgZTHmgCwRVkZSXpPBZfj/eqfQKLP1GzrhzGs=; b=OMQKPFgDBrCOh6OsJRr69Zwnq1WSQYpIpPayG5kSDJjYA5OT+izqn3zSw4BJZE+uCNXGkpXVksiD+ljZBssWL5d2YI6TgUQAhIYbRN/+7uYJb73r0ZTe+rMTSYtzRqUfUqtnfMmtduqxTdn7K2iFFRt31Te3lNWD/H6xZwXOmTBDx4Bf4eJfpIQWsBS11KKngp3fO3dMoJNR1FiHClqazsjrVkUamE4LXC581iquB+YwKpXt+9Mg8pUrAcoHWGdr Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Apr 2015 02:04:56 -0000 Date: 1 Apr 2015 22:04:56 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> References: <20150401181114.966.qmail@ary.lan> <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 02:05:00 -0000 > To avoid a new header field or a "v=" increase, to make DMARC failure a really > reliable indication of genuine invalidity, at least where mailing lists > are concerned, why not focus on the fact that RFC5322.From headers clearly > allow multiple addresses, and invite Mediators such as mailing list to take > responsibility for their changes by adding an address in their own domain > to the RFC5322.From header and adding their own DKIM-Signature? I believe we looked at that and decided it wasn't promising. The problem is that bad guys can do whatever good guys can do: From: security@paypal.com, igor@rbn.ru Subject: Urgent security alert about your Paypal account! DKIM-Signature: ... d=rbn.ru Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 19:25:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D11A6F39 for ; Wed, 1 Apr 2015 19:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 uocHzUOjiScv for ; Wed, 1 Apr 2015 19:25:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997271A1B28 for ; Wed, 1 Apr 2015 19:25:00 -0700 (PDT) Received: from [192.168.1.141] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t322Ou1H021319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Apr 2015 19:25:00 -0700 Message-ID: <551CA875.9080206@dcrocker.net> Date: Wed, 01 Apr 2015 19:24:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150401181114.966.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 01 Apr 2015 19:25:00 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 02:25:02 -0000 On 4/1/2015 11:36 AM, John R Levine wrote: >> Didn't we stalemate on the question of whether this has to be a whole new >> header field, or a "v=" increase? I seem to recall someone (Dave?) >> thinking both were horrible. > > That was certainly a question, but I don't recall any consensus on > realtive horribility. I like v=2, that's what version bumps are for. Version numbers are superfluous or inappropriate overhead. That is, they are either useless or else the wrong solution to demultiplexing amongst alternate protocols. When a protocol is revised, there are two possibilities: Upward Compatible: The old version of the protocol interworks with the new version. So the new protocol is a superset of the old. In this case, the enhancements typically self-identify, as new parameters or new values for existing parameters. Incompatible: The old and new don't interwork. In the first case, the version field is literally useless. It is wholly redundant or worse insufficient, given that the receiver of the protocol data unit sees the new stuff in other ways than the version field. In the latter case, it's really an entirely new protocol, which should be identified by the next-lower protocol, rather than by using the version field as an in-bred demultiplexing field. And yes, IPv4 and IPv6 are distinguished by different demultiplexing values in the Ethernet frame: http://en.wikipedia.org/wiki/EtherType d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 1 19:59:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CF41A01BA for ; Wed, 1 Apr 2015 19:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JIFohV0BwsQf for ; Wed, 1 Apr 2015 19:59:19 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 2060B1A0248 for ; Wed, 1 Apr 2015 19:59:18 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so71937632wgb.1 for ; Wed, 01 Apr 2015 19:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pBnS70+EIuZM3tvFuDnOdk/W/ENklWePGr0EnWva5Uw=; b=skgt+zcQ+oTdQCDE2ZjjzIMXziXkMEoaSpen93GF8tcD1ZTdnIgf5kmzeFq7N2WLaP BEuGEsPfdwFN1v1x4N4v5sA3786v1hiSwLF+mBg6BxKrhkOdsNQMAaaQV5gX1HD9fTVE MadY5Gn1/G3tv4fNQDUsGS0xb8Bk/97jol8OzG3/6IWBl1Ung1ex3zbirKEy6pFM/BzV dnBYjlqnlQEM3WAh9N4z2k3UoOkDsPGFG8xRsaJcqoVa1/UYVWzBrX+SBB2H3uDq5EUt sDg6A0D6YgwqTsKpkzK1ltU4fI/9TY3u00dknlRP9ykFFHRqtBhAznhhAwN6SqCLVSBu ZcXw== MIME-Version: 1.0 X-Received: by 10.180.187.67 with SMTP id fq3mr20328875wic.59.1427943556727; Wed, 01 Apr 2015 19:59:16 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 1 Apr 2015 19:59:16 -0700 (PDT) In-Reply-To: <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> References: <20150401181114.966.qmail@ary.lan> <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> Date: Wed, 1 Apr 2015 19:59:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Michael Jack Assels Content-Type: multipart/alternative; boundary=001a11c38070754b550512b50466 Archived-At: Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 02:59:21 -0000 --001a11c38070754b550512b50466 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 1, 2015 at 6:00 PM, Michael Jack Assels < mjassels@encs.concordia.ca> wrote: > > The case of a syntactically valid multi-valued RFC5322.From field > presents a particular challenge. The process in this case is to > apply the DMARC check using each of those domains found in the > RFC5322.From field as the Author Domain and apply the most strict > policy selected among the checks that fail. > > (The word "fail" leaves me confused. Shouldn't that be "pass"?) > DMARC's "p=" describes the action to take when the evaluation mechanism fails. There is no policy to apply (other than, I suppose, an implicit "accept" action) when DMARC passes. > > At any rate, it seems to me that if DMARC would be satisfied by a Mediator > making substantial modifications to my message, changing the RFC5322.From > to > > From: "Michael Jack Assels" > > and signing appropriately, it ought to be similarly happy with > > From: "Michael Jack Assels" , > "dmarc" > Sender: "dmarc" > > signed by IETF's sending MTA. Assuming that the usual change is made to > the Subject line and the usual trailer is appended to the message body, > only the "ietf.org" identity ought to align with "the" RFC5322.From > domain, > and I can't see a reason why DMARC wouldn't be happy. Yes, someone could > have spoofed my address, but IETF's receiver will have had an opportunity > to check that, so it's either IETF's fault for accepting the original > message > or my MTA's fault for not being DMARC compliant. > > In this case, the mailing list would be doing what's asked of it by DMARC, > but keeping (most of) it's time honoured values intact. This could work, except that if this yields favorable treatment by the receiver, then that's all an attacker needs to do to get to your inbox (i.e., double up the From: using an arbitrary domain name, and make sure the message satisfies the DMARC test for the latter). The exception to that is some expression, which the receiver can confirm, that domain2 and domain1 have some kind of relationship that's interesting to this process. -MSK --001a11c38070754b550512b50466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 1, 2015 at 6:00 PM, Michael Jack Assels <mjassels@encs.concordia.ca> wrote:

=C2=A0 =C2=A0The case of a syntactically valid multi-valued RFC5322.From fi= eld
=C2=A0 =C2=A0presents a particular challenge.=C2=A0 The process in this cas= e is to
=C2=A0 =C2=A0apply the DMARC check using each of those domains found in the=
=C2=A0 =C2=A0RFC5322.From field as the Author Domain and apply the most str= ict
=C2=A0 =C2=A0policy selected among the checks that fail.

(The word "fail" leaves me confused.=C2=A0 Shouldn't that be = "pass"?)

DMARC's "p= =3D" describes the action to take when the evaluation mechanism fails.= =C2=A0 There is no policy to apply (other than, I suppose, an implicit &quo= t;accept" action) when DMARC passes.
=C2=A0

At any rate, it seems to me that if DMARC would be satisfied by a Mediator<= br> making substantial modifications to my message, changing the RFC5322.From to

=C2=A0 =C2=A0From: "Michael Jack Assels" <mjassels@porn-list.e= xample.xxx>

and signing appropriately, it ought to be similarly happy with

=C2=A0 =C2=A0From: "Michael Jack Assels" <mjassels@encs.concordia.ca>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"dmarc" <no-reply@ietf.org>
=C2=A0 =C2=A0Sender: "dmarc" <dmarc-bounces@ietf.org>

signed by IETF's sending MTA.=C2=A0 Assuming that the usual change is m= ade to
the Subject line and the usual trailer is appended to the message body,
only the "ietf.org&q= uot; identity ought to align with "the" RFC5322.From domain,
and I can't see a reason why DMARC wouldn't be happy.=C2=A0 Yes, so= meone could
have spoofed my address, but IETF's receiver will have had an opportuni= ty
to check that, so it's either IETF's fault for accepting the origin= al message
or my MTA's fault for not being DMARC compliant.

In this case, the mailing list would be doing what's asked of it by DMA= RC,
but keeping (most of) it's time honoured values intact.

This could work, except that if this yields favorable trea= tment by the receiver, then that's all an attacker needs to do to get t= o your inbox (i.e., double up the From: using an arbitrary domain name, and= make sure the message satisfies the DMARC test for the latter).

The exception to that is some expression, which the receiver can co= nfirm, that domain2 and domain1 have some kind of relationship that's i= nteresting to this process.

-MSK
--001a11c38070754b550512b50466-- From nobody Wed Apr 1 20:02:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682E1A0363 for ; Wed, 1 Apr 2015 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 snjfcqnfRjOh for ; Wed, 1 Apr 2015 20:02:06 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFE91A033A for ; Wed, 1 Apr 2015 20:02:06 -0700 (PDT) Received: (qmail 57104 invoked from network); 2 Apr 2015 03:02:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=df0f.551cb12d.k1504; bh=1tYWdXmxnNWJ9anZW3mIkfnnoJJLBfndQZpH1SkbhQI=; b=sb7kjQ9kiHrNhg6ET93G/4lgxkeP73KghfCj3CUI1aytn6AEuiZhX0Wm31qovY+PDl322bdRyLYheuTLLtTJPOFfi84nxlG6k0ZmCU1Z58INSj15hT61iBKtV+wE7tXG+KoPN1MyubX539uBLCUBJI9ntnKkB5400BmDHZOZ6gwARd0+gKQSf7dnoF3YuMzsByQJTFE+j7V/XQVWbvFVTlKNRBWTvC9hOlJyoowpPNL6ikAwdHKQrh2hMfahdfDI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=df0f.551cb12d.k1504; bh=1tYWdXmxnNWJ9anZW3mIkfnnoJJLBfndQZpH1SkbhQI=; b=FXrRoeK/N7dR33KHxQbSlsnKKYK5LWAvwRInv2OGu3enklp5OKpCcZdEFHklugkp6ZseTOldDNY42m7XDfgPhBYFzxSrKxps9xO02FHzrFUAUqRedSdaVW+qFb4ahe1v0suOzpDHvuAC3uWNCu9nK6iU8rOgur81HyE/05KWhRxFeOTzAW4hTIww99tNY0l7wUZLynaFPSoVeuoc7gejv9tTd3uSb2pS0ppPsMU1dkTBzsL31s2wS7P5Nb6/fKSW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Apr 2015 03:02:05 -0000 Date: 1 Apr 2015 23:02:04 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150401181114.966.qmail@ary.lan> <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:02:07 -0000 > The exception to that is some expression, which the receiver can confirm, > that domain2 and domain1 have some kind of relationship that's interesting > to this process. Right, which brings us back to my double signing approach. It's looking like the worst option except for all of the others. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 20:03:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F20B1A0122 for ; Wed, 1 Apr 2015 20:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 O_b0R9nnt_Bn for ; Wed, 1 Apr 2015 20:03:08 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 876F01A00C7 for ; Wed, 1 Apr 2015 20:03:08 -0700 (PDT) Received: by wiaa2 with SMTP id a2so88936428wia.0 for ; Wed, 01 Apr 2015 20:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhgnBzAaHBt4xfQBhCdQD+qfcidI52X0L+z/ZP07lJQ=; b=fALWkZzygDXAYjk2PXx99OZu5ICDZRxx4H67Zm0P2m4gSeWJY5fs/gbCatxFoQlltj ZIkBfX91suUfvQJu7MI/hpd3+SW3lk0KdGHLvguPvhO7S9dQmdKpSd8sAKDE7RpQAf02 qieqQOFl9HVLU4XpXXaGikebRa6UweUa8MFPROwn7AK03ELF7bbNAhxkkj3mO0Xk5mGq R7BUVNQT7JKL3MvDyuMK7DsO8mH3IUbgunPUNsGteg5ifS0b5qPnUlGpTw8ZrVaqNXhU jg9WSRQl+wfma0dvPqD+FGxRP4nczN7owgxZeH1Vd7NXGDjIu2Kv62Aq7j4pkITKDVOp YOsg== MIME-Version: 1.0 X-Received: by 10.180.77.166 with SMTP id t6mr20758377wiw.52.1427943787336; Wed, 01 Apr 2015 20:03:07 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 1 Apr 2015 20:03:07 -0700 (PDT) In-Reply-To: <551CA875.9080206@dcrocker.net> References: <20150401181114.966.qmail@ary.lan> <551CA875.9080206@dcrocker.net> Date: Wed, 1 Apr 2015 20:03:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d043d645f341a6c0512b5127f Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:03:10 -0000 --f46d043d645f341a6c0512b5127f Content-Type: text/plain; charset=UTF-8 On Wed, Apr 1, 2015 at 7:24 PM, Dave Crocker wrote: > In the first case, the version field is literally useless. It is wholly > redundant or worse insufficient, given that the receiver of the protocol > data unit sees the new stuff in other ways than the version field. > > In the latter case, it's really an entirely new protocol, which should > be identified by the next-lower protocol, rather than by using the > version field as an in-bred demultiplexing field. > > And yes, IPv4 and IPv6 are distinguished by different demultiplexing > values in the Ethernet frame: > > http://en.wikipedia.org/wiki/EtherType > This argues for creating a new thing that looks almost identical to DKIM, using a new header field name, that has this one extra property. That forces demultiplexing one pseudo-layer down. I think John produced a draft about that as well. I can't get my head around the "entirely new" part of that assertion though. -MSK --f46d043d645f341a6c0512b5127f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 1, 2015 at 7:24 PM, Dave Crocker <dhc@dcrocker= .net> wrote:
In the first case, the version fiel= d is literally useless.=C2=A0 It is wholly
redundant or worse insufficient, given that the receiver of the protocol data unit sees the new stuff in other ways than the version field.

In the latter case, it's really an entirely new protocol, which should<= br> be identified by the next-lower protocol, rather than by using the
version field as an in-bred demultiplexing field.

And yes, IPv4 and IPv6 are distinguished by different demultiplexing
values in the Ethernet frame:

=C2=A0 =C2=A0 =C2=A0http://en.wikipedia.org/wiki/EtherType

This argu= es for creating a new thing that looks almost identical to DKIM, using a ne= w header field name, that has this one extra property.=C2=A0 That forces de= multiplexing one pseudo-layer down.=C2=A0 I think John produced a draft abo= ut that as well.

I can't get my head around the "= ;entirely new" part of that assertion though.

-MSK
--f46d043d645f341a6c0512b5127f-- From nobody Wed Apr 1 20:22:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE71A1A00BE for ; Wed, 1 Apr 2015 20:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 7j2hIOd2HAX3 for ; Wed, 1 Apr 2015 20:22:54 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73721A1B5C for ; Wed, 1 Apr 2015 20:22:50 -0700 (PDT) Received: (qmail 61825 invoked from network); 2 Apr 2015 03:22:49 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 2 Apr 2015 03:22:49 -0000 Date: 2 Apr 2015 03:22:27 -0000 Message-ID: <20150402032227.2479.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <551CA875.9080206@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:22:54 -0000 >In the latter case, it's really an entirely new protocol, which should >be identified by the next-lower protocol, rather than by using the >version field as an in-bred demultiplexing field. I suppose, but if the two procols are 99% the same, and the new one is upward compatible with the old one, and anything that understands the new one also has to understand the old one, and the goal is to have everything puts semantics on the old one put the same semantics on the new one, I'm having trouble seeing why one of these is vastly preferable to the other: DKIM-Signature: v=2; d=example.com; ... DaveKIM-Signature: v=1; d=example.com; ... In this particular case, the incompatibility is a new kind of "must handle" tag suggested by Ned Freed with the new rule that if a verifier doesn't understand it, the verification fails. The first of them would be must-re-sign, which means that the message has to be re-signed by another domain, e.g.: DKIM-Signature: v=2; d=yahoo.com; @mr=ietf.org; ... which would say this signature is only good if there is also a DKIM signature with d=ietf.org. You could chain these things which might deal with the educational forwarding issue that Elizabeth Z. described. Once you have the syntax for must handle tags (I used @ here) then we can add more of them as needed without another version bump. R's, John From nobody Wed Apr 1 21:08:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3E51B2A82 for ; Wed, 1 Apr 2015 21:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 LmvDHPhl4ayd for ; Wed, 1 Apr 2015 21:08:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6661B2A64 for ; Wed, 1 Apr 2015 21:08:04 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3247vcW024014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 21:08:01 -0700 Message-ID: <551CC09A.1020903@dcrocker.net> Date: Wed, 01 Apr 2015 21:07:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Dave Crocker References: <20150401181114.966.qmail@ary.lan> <551CA875.9080206@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 01 Apr 2015 21:08:01 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] New protocol (was Re: Third Party Sender DMARC Adaptations) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 04:08:07 -0000 On 4/1/2015 8:03 PM, Murray S. Kucherawy wrote: > > In the latter case, it's really an entirely new protocol, which should > be identified by the next-lower protocol, rather than by using the > version field as an in-bred demultiplexing field. ... > I can't get my head around the "entirely new" part of that assertion though. Absolutely trivial idea: If two networking implementations are properly conforming to mature and debugged specifications, but the implementations cannot interoperate, then the specifications are for different protocols. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 1 21:22:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7C1B2A98 for ; Wed, 1 Apr 2015 21:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 RcEKesiZ5tdj for ; Wed, 1 Apr 2015 21:22:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84301AD34C for ; Wed, 1 Apr 2015 21:22:29 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t324MP8d024194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 21:22:28 -0700 Message-ID: <551CC3FE.10702@dcrocker.net> Date: Wed, 01 Apr 2015 21:22:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20150402032227.2479.qmail@ary.lan> In-Reply-To: <20150402032227.2479.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 01 Apr 2015 21:22:29 -0700 (PDT) Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 04:22:31 -0000 On 4/1/2015 8:22 PM, John Levine wrote: >> In the latter case, it's really an entirely new protocol, which should >> be identified by the next-lower protocol, rather than by using the >> version field as an in-bred demultiplexing field. > > I suppose, but if the two procols are 99% the same, and the new one is > upward compatible with the old one, and anything that understands the 'Upward compatible' was carefully distinguished from 'different protocol'. Upward compatible says that the new one is a superset of the old one. That is, all the old stuff is the same, but there's some /additional/ stuff. The pattern is that the new stuff self-distinguishes. In which case the version field provides no useful information. Worse, the usual model of enhancement is a series of increments, where the increments often need to be used in different combinations. Each bit of increment needs to self-identify so that the receiver knows which enhancements are being used. Version fields don't support combinatorials like that. > new one also has to understand the old one, and the goal is to have > everything puts semantics on the old one put the same semantics on the > new one, I'm having trouble seeing why one of these is vastly > preferable to the other: > > DKIM-Signature: v=2; d=example.com; ... > DaveKIM-Signature: v=1; d=example.com; ... Nice example of useless version info. The fieldname provides all the distinguishing information that's needed, for the differential syntax and/or semantics. The reason it is better to use fieldname is because the engine that decides how to dispatch to code that understand the contents of a field only needs to look at the fieldname, rather than the fieldname and the version field. > In this particular case, the incompatibility is a new kind of "must > handle" tag suggested by Ned Freed with the new rule that if a > verifier doesn't understand it, the verification fails. The first of Right. So an older implementation sending to a newer one is trying to talk a different semantic than the newer one requires. Hence, they do not interoperate. Hence the demultiplexing between them should be in the lower-layer dispatcher. In the case of a DKIM-bis-ish change, that means a different header field name. It really is a different protocol. > them would be must-re-sign, which means that the message has to be > re-signed by another domain, e.g.: > > DKIM-Signature: v=2; d=yahoo.com; @mr=ietf.org; ... > > which would say this signature is only good if there is also a DKIM > signature with d=ietf.org. You could chain these things which might > deal with the educational forwarding issue that Elizabeth Z. described. What you have described is an overlay protocol. It logically sits above DKIM, since in additional to doing it's own thing, it "uses" DKIM. The fact that it looks quite a bit like DKIM is a distraction. It has an essentially different semantic. Remember that chimpanzees have almost all the same genes as humans. But they aren't human. Or perhaps we aren't chimpanzees. (Well, most of us aren't.) > Once you have the syntax for must handle tags (I used @ here) then we > can add more of them as needed without another version bump. Changing the must-implement set changes the basic protocol into a new protocol. Adding optional ones doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 2 04:50:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C191B2C7D for ; Thu, 2 Apr 2015 04:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 oZo9_Gs6M4Ad for ; Thu, 2 Apr 2015 04:50:10 -0700 (PDT) Received: from catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CEE261B2C7C for ; Thu, 2 Apr 2015 04:50:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2354; t=1427975396; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=3R1daD1O7kepeU+c5FOS528Aw0E=; b=KHKU6EWgvYkBCb//Vth5 szMDsnFP7vI8S6yT3BHiqtqoiTejYrwacrUCla0XaSl9TB/JD97fS6nPBIuum6Lv 96WnfGEvxanv2xoAiVEnHyVzvy2iOKwJDbNHsoWDpDgAJG3G5xXsrDUqYilr0huh KmSH7dQkQu7/0H0RPKgsJj8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 02 Apr 2015 06:49:56 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1685423423.29642.2860; Thu, 02 Apr 2015 06:49:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2354; t=1427975183; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=5hymjdV L0BPUXeGZnk8Vv0TeQup7f4eqRZ4mRh+ICTM=; b=HoGZH3Tl+UsLdSUyYzTjiSr 1QdUyPKSEJL87APrCrOcTVc8ru/7S596i7UzkCNDPYBksjaHiJwoDIPYqbDc+7mN TRfavIoI18sjZHufY/vTOUz8x/hnYAYAeBYdZ7CvJMkRsyyx62XOqdB4qfS/mhYd nyW0xu2FdYCEWVfluZMM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 02 Apr 2015 07:46:23 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 277718082.9.7284; Thu, 02 Apr 2015 07:46:21 -0400 Message-ID: <551D2CDA.1050803@isdg.net> Date: Thu, 02 Apr 2015 07:49:46 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <20150401181114.966.qmail@ary.lan> <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> In-Reply-To: <201504020100.t3210J0l025104@shadrach.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 11:50:12 -0000 On 4/1/2015 9:00 PM, Michael Jack Assels wrote: > To avoid a new header field or a "v=" increase, to make DMARC failure a really > reliable indication of genuine invalidity, at least where mailing lists > are concerned, why not focus on the fact that RFC5322.From headers clearly > allow multiple addresses, and invite Mediators such as mailing list to take > responsibility for their changes by adding an address in their own domain > to the RFC5322.From header and adding their own DKIM-Signature? Which address would be first? The 3rd party or the first party? Will the 3rd party first do a POLICY check to determine is this is allowed? Maybe the first party doesn't want or expect any 3rd party signature? I think the MLS/MLM needs to first respect the wishes of the 1st party before trying to circumvent the security by modifying the 5322.From. > RFC7489 seems to hem and haw a bit about multiple From addresses (in a > single From header). E.g., in Section 6.6.1: > > o Messages bearing a single RFC5322.From field containing multiple > addresses (and, thus, multiple domain names to be evaluated) are > typically rejected because the sorts of mail normally protected by > DMARC do not use this format; > > and a little later in the same section: > > The case of a syntactically valid multi-valued RFC5322.From field > presents a particular challenge. The process in this case is to > apply the DMARC check using each of those domains found in the > RFC5322.From field as the Author Domain and apply the most strict > policy selected among the checks that fail. While it is technically allowed by 5322. I have yet to see this in the wild and many software components simply are not ready for such multiple From field, especially at gateways and transformations or online hosting systems or MUAs where only one from is expected. > (The word "fail" leaves me confused. Shouldn't that be "pass"?) > > At any rate, it seems to me that if DMARC would be satisfied by a Mediator > making substantial modifications to my message, changing the RFC5322.From > to .... Its far easier to just a DNS lookup of the 1st party to determine if the 3rd party is a trusted, authorized resigner, "mediator." YesNo = Is_Signer_Authorized(Author, Signer) Far easier and least expensive solution. -- HLS From nobody Thu Apr 2 07:00:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C201A905D for ; Thu, 2 Apr 2015 06:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Cq5hSV8Ulkpn for ; Thu, 2 Apr 2015 06:59:57 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id BC1621A9057 for ; Thu, 2 Apr 2015 06:59:57 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t32DxthK017254 for ; Thu, 2 Apr 2015 09:59:56 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t32DxtOT010443 for ; Thu, 2 Apr 2015 09:59:55 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Wed, 01 Apr 2015 08:31:20 PDT References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Thu, 02 Apr 2015 09:59:55 -0400 Message-ID: <10442.1427983195@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-02 09:59:56 EDT Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 13:59:59 -0000 Murray S. Kucherawy responds to my (not-so-new) suggestion: >> Some days ago I tentatively suggested signing only part of >> some message parts, in particular part of the Subject header >> (excluding any future additions of "[list-identification]"), > As I recall this was considered during the development of DKIM originally, > exactly for this reason. We rejected it because we couldn't come up with a > safe description of what a tag should look like. If arbitrary text is > allowed in there, then one could "tag" a spam URL at the front of a > legitimate message's Subject field and the signature would still pass. Right, but if that tag were explicitly deemed to be excluded from the signature, it could be handled differently. Hmm, but if this resulted in (for example) the tag not being displayed, then we would have gained nothing in the case of mailing lists. > Short of introducing legislation about what constitutes a "standard" set of > list modifications, which would be highly controversial Unlike, say, having mailing lists munge the "From:" header. ;-) > and consensus > firmly disliked, there wasn't a good path forward there, so the working > group dropped the idea. ... but okay, in view of the fact that this idea ends up not really gaining us much in terms of allowing mailing lists to tag their messages, I'll drop it. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Thu Apr 2 07:49:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCCE1A9147 for ; Thu, 2 Apr 2015 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 e_e5AR4fW4mK for ; Thu, 2 Apr 2015 07:49:13 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873541A9138 for ; Thu, 2 Apr 2015 07:49:13 -0700 (PDT) Received: (qmail 52536 invoked from network); 2 Apr 2015 14:49:12 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 2 Apr 2015 14:49:12 -0000 Date: 2 Apr 2015 14:48:50 -0000 Message-ID: <20150402144850.5325.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <551CC3FE.10702@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:49:14 -0000 In article <551CC3FE.10702@dcrocker.net> you write: >On 4/1/2015 8:22 PM, John Levine wrote: >>> In the latter case, it's really an entirely new protocol, which should >>> be identified by the next-lower protocol, rather than by using the >>> version field as an in-bred demultiplexing field. >> >> I suppose, but if the two procols are 99% the same, and the new one is >> upward compatible with the old one, and anything that understands the > >'Upward compatible' was carefully distinguished from 'different protocol'. It occurs to me why this is still DKIM -- the external interface is the same. You call a DKIM verifier by, roughly, giving it a mail message, and it tells you what the d= was on the valid signatures. That doesn't change. Anything that uses DKIM v1, whether it's DMARC or a Spamassassin plugin, uses v2 the same way. On the signing side, the signer has the new option of adding a conditional signature, but all of the old options still work. R's, John From nobody Thu Apr 2 08:06:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0948E1B2CD6 for ; Thu, 2 Apr 2015 08:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 UXsrHoMkzkL9 for ; Thu, 2 Apr 2015 08:06:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3451B2CEC for ; Thu, 2 Apr 2015 08:06:01 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t32F5vO2013311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 08:06:00 -0700 Message-ID: <551D5AD2.4040605@dcrocker.net> Date: Thu, 02 Apr 2015 08:05:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20150402144850.5325.qmail@ary.lan> In-Reply-To: <20150402144850.5325.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 02 Apr 2015 08:06:00 -0700 (PDT) Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:06:29 -0000 On 4/2/2015 7:48 AM, John Levine wrote: > It occurs to me why this is still DKIM -- the external interface is > the same. You call a DKIM verifier by, roughly, giving it a mail > message, and it tells you what the d= was on the valid signatures. > That doesn't change. Anything that uses DKIM v1, whether it's DMARC > or a Spamassassin plugin, uses v2 the same way. > > On the signing side, the signer has the new option of adding a conditional > signature, but all of the old options still work. Protocols are defined by bits over the wire, not APIs. The most striking example of this point that I had to deal with was NetBIOS. IBM published the API but not the protocol. A few different LAN companies each created their own proprietary protocols that conformed to the API, but which were wildly different from IBM's and each other's. The fact that the new ones all ran over TCP didn't matter: They Did Not Interoperate. Eventually there was market pressure to interoperate and we were forced to collaborate on the development of RFC 1001/1002.(*) FWIW this confusion about the nature of 'upgrades' is a relatively consistent pattern over the years. It plagued some of the recent internationalized email work, which bogged down in trying to define both a new mode and the shared operation with new and old modes. And it plagued IPv4/IPv6, although in the reverse direction: v6 could have been an almost-compatible upgrade, which would have made gatewaying trivial and deployment probably 15 years earlier... d/ * It was also my introduction to the difference between skills in implementing a protocol specification, versus skills in designing one. Being quite good in the former was no prediction of competence in the latter... -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 2 08:14:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873331B2CF5 for ; Thu, 2 Apr 2015 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 iiZjDUuFILzC for ; Thu, 2 Apr 2015 08:14:06 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7269D1B2CD4 for ; Thu, 2 Apr 2015 08:14:06 -0700 (PDT) Received: (qmail 56605 invoked from network); 2 Apr 2015 15:14:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=dd1c.551d5cbc.k1504; bh=OX+DBYgLaLetkF2e+mXKBXjs0YPZhdT9WRKG6Klqwbs=; b=dnLRaSzTONzDX+dZTYALx7zxfHzcCRxFDU6z3BYaxouthsdzTbhjrrlG9p72/z9eh9AWowkPelXR3VAzH/yXWOAg6CJiohMKMcY9IsFnlsYF3B3puSHahHZmoRmMTXFMZ83iFvOCJtCi4pHCaOxgcipuM7Hl2VHjCKyzFA0UE2sh5dwrfr4zjv6v1eEw+/pgbXLsEQZDUnrv/56TFrI1w1RgnC6DCaKJ9vn9FG4QTXnaGNr9rouyM9/JX8i9bhI/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=dd1c.551d5cbc.k1504; bh=OX+DBYgLaLetkF2e+mXKBXjs0YPZhdT9WRKG6Klqwbs=; b=X3G1VyQwGcRTO1HGn+V7qoMRQpuAiqYtCCZ8k2bCxyhNLFUnKOzd3qCACjoXculWlg7akrXfDADXldWWRYDev4S1iWTVYyHcXn3SVN5uBFR9BCepxOOO/rR4RSK+iBdxfEPn7ofqjzv5uFJrOezduy2YXXFXPoA9f16p7w2uMkvLZxsyNAt7q1QpwkfLDDhfCNhJLMjbgk3xDONUmLJdwKxna6XZJadkTMLiaMUhSZyT1FkYiUtm2QWrvJu0MA6I Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Apr 2015 15:14:04 -0000 Date: 2 Apr 2015 11:14:03 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <551D5AD2.4040605@dcrocker.net> References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:14:10 -0000 >> On the signing side, the signer has the new option of adding a conditional >> signature, but all of the old options still work. > > Protocols are defined by bits over the wire, not APIs. They're defined by both. The main reason we published RFC 5672 was to clarify that the API returns the value of the d= tag, not the i= tag, even though the bits on the wire didn't change. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Apr 2 08:43:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42281ACD4A for ; Thu, 2 Apr 2015 08:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 iSRW37E2vxCz for ; Thu, 2 Apr 2015 08:42:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708CF1ACD81 for ; Thu, 2 Apr 2015 08:42:43 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t32FgdIf014227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 08:42:42 -0700 Message-ID: <551D636C.2080408@dcrocker.net> Date: Thu, 02 Apr 2015 08:42:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John R Levine References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 02 Apr 2015 08:42:43 -0700 (PDT) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:42:54 -0000 On 4/2/2015 8:14 AM, John R Levine wrote: >>> On the signing side, the signer has the new option of adding a >>> conditional >>> signature, but all of the old options still work. >> >> Protocols are defined by bits over the wire, not APIs. > > They're defined by both. Sorry, no. Or rather, while it is common to link them together, that's not required. Just as the same API can be satisfied by many different protocols, the same protocol can be accessed through many different APIs. Historically the IETF has tried to focus only on protocols (bits over the wire), in order to stay away from API wars and the differences needed by different platforms. In recent years, this has been relaxed somewhat, mostly serving to add to the confusion about the difference between APIs and protocols (IMO). I haven't done a careful audit, but the IETF typically does not put API specs on standards track, though I note that the Kerberos GSS-API comes close. Except that it is specified as... a protocol. > The main reason we published RFC 5672 was to > clarify that the API returns the value of the d= tag, not the i= tag, > even though the bits on the wire didn't change. That's not why I initially raised the issue that led to the creation of the update. I cast it in terms of overhead vs. payload, the same as I'm distinguishing here and alas, the same as I was taught, 40 years ago. "DomainKeys Identified Mail (DKIM) ... permit[s] a signing domain to claim responsibility for the introduction of a message into the mail stream. " That is, the 'payload' of DKIM is the delivery of a validated domain name. In the original specification, we failed to properly specify which of the two delivered identifiers (d= and s=) was that promised payload. In the Update, here too we see the confusion caused by having the document even reference the construct of an API. Frankly I conceded the reference in that document as a means of trying to get past people's confusion about the difference between the parts of a protocol that are overhead, versus that part that is payload, delivered outside of the protocol. Given this exchange now, I regret that concession. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 2 09:02:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B65D1A8AA7 for ; Thu, 2 Apr 2015 09:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 Abre2pXHOKew for ; Thu, 2 Apr 2015 09:02:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0061ACD57 for ; Thu, 2 Apr 2015 09:02:21 -0700 (PDT) Received: (qmail 62341 invoked from network); 2 Apr 2015 16:02:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f384.551d680c.k1504; bh=2e9dumC0l7Obguj4kBAskizn7nBwENxB8os9HUYqlhY=; b=ODXUXL27U7UKyiQ4/EMuyOfM6+P6uUcebvwv/G+dj7ZohqFEncQIL+8r1Zvtu0TFs4PuuXHXCXrntWor84reef14u9q4tbJ1VfLwcbSVYo7++s5EY1Dg6uF+UbkvZV23abhNnVGz62XjFBbdWZUEtHNANwpj+3PcmekT0BXuahptLJ8smOKNXucC70nrtsgJ10vOz7TGtNW+8rwfzMfG1p8cVauGKtY4xp0EfzsJgIwWK75b1ZDZ9DMDveO7y5Qk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f384.551d680c.k1504; bh=2e9dumC0l7Obguj4kBAskizn7nBwENxB8os9HUYqlhY=; b=IxUJFf2A9KaCC6ssD0Q+76p5E4pgpnX8cMt4AnG1hwAG0tGk22dHjaxbqQHtS6qMNTPknid9zGnGzGdcLResrMQiIa+PB0L+ROwdJ3AJedB0g6JmC6BsUTNHl53UzCWHuK4Lo88W5Ier1SiSGZq+BEesiqOUScztOWastRgQk372jrvSuVyh9lJSKjBXoYm3SXDQH8s7eCYwIlctMIxfaDu0yWG8LzWQvNSLLz0SHZl66Hw+ah0fyA0TsSytW8lF Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Apr 2015 16:02:19 -0000 Date: 2 Apr 2015 12:02:19 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <551D636C.2080408@dcrocker.net> References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> <551D636C.2080408@dcrocker.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:02:22 -0000 > That is, the 'payload' of DKIM is the delivery of a validated domain > name. In the original specification, we failed to properly specify > which of the two delivered identifiers (d= and s=) was that promised > payload. These hairs are split too finely for me to understand. The DKIM validator takes the message and the not-API returns a possibly empty list of identifiers. In v2 or whatever we call it, the validator does exactly the same thing. The main difference I see is that if we call v2 something else, we now have a tedious administrative exercise of finding every place something refers to DKIM and change it to "DKIM or DKIM-plus." This does not strike me as a good use of anyone's time. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Apr 2 09:18:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD40A1B2D30 for ; Thu, 2 Apr 2015 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 pwJXBg5PZeUG for ; Thu, 2 Apr 2015 09:18:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3EE1ACEE4 for ; Thu, 2 Apr 2015 09:18:34 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t32GIUaq015643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 09:18:34 -0700 Message-ID: <551D6BD1.6050809@dcrocker.net> Date: Thu, 02 Apr 2015 09:18:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John R Levine References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> <551D636C.2080408@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 02 Apr 2015 09:18:34 -0700 (PDT) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:18:35 -0000 On 4/2/2015 9:02 AM, John R Levine wrote: >> That is, the 'payload' of DKIM is the delivery of a validated domain >> name. In the original specification, we failed to properly specify >> which of the two delivered identifiers (d= and s=) was that promised >> payload. > > These hairs are split too finely for me to understand. You mean like the difference between a driver and a passenger? Really, there's nothing subtle or fine about it. In fact is a clean and essential distinction, if the protocol is to be cleanly defined. In classic networking architecture hierarchies, an exchange is characterized by defining provider and a consumer. The former wants to supply some information to the latter. That information is the payload. They use a protocol to do that. The protocol is a set of rules and formats for effecting that transfer of the payload. Any part of the protocol that is not payload is overhead. > The DKIM > validator takes the message and the not-API returns a possibly empty > list of identifiers. In v2 or whatever we call it, the validator does > exactly the same thing. Ahh, I see. American English and British English and Malaysian English are all identical, since they satisfy the same, generic functional description. For that matter, English and Russian are the same because the do too. Again: The required semantics differ and... The Protocols Do Not Interoperate. To make this fundamental point irrelevant, one of us first needs to be able to mate with an orang utan. > The main difference I see is that if we call v2 something else, we now > have a tedious administrative exercise of finding every place something > refers to DKIM and change it to "DKIM or DKIM-plus." This does not > strike me as a good use of anyone's time. That task you characterize as tedious is, in fact, the discipline of making sure the documentation is careful to distinguish between the two different (ie, non-interoperable) protocols. Efforts to do that with a single specification wind up confusing things and confusing readers and implementers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 2 10:59:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6A1A005B for ; Thu, 2 Apr 2015 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 L-dh8mAPnY8v for ; Thu, 2 Apr 2015 10:59:38 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 9BEE41A002D for ; Thu, 2 Apr 2015 10:59:37 -0700 (PDT) Received: by widjs5 with SMTP id js5so14045807wid.1 for ; Thu, 02 Apr 2015 10:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sV7B9kkf62ugYAhgCDutMyyNhQL5jqWkoifm9AQy+M8=; b=STgap+BLWyJ1vJ+wSVZKpcegNZuYSwzRan9teewjSc8d4rF1S9JFmG4+JusuM/kEGU eTNmvQ99bPFJQzI2/wtTHmDvQuoyW/ldCp5MSkyja3s6WminJbbhWkXsrwVgZq0FmGVd Jc7WnT77T4cn0p+AmXHM8mpcaHFJ8KeMVdCcvMgKhuWgeNERHBD1z1EU1U2XGbsyl++v BM9T7aiGICqPaIQXDKP7NVS5qhwAgLO/N72maQt4DFEAg+vw0/ga+9UmZEOFZ5KBfGal 17oFfgwahHYiWrHV+pQNNbbbbntiyjnpZZ+0ZI3RfdWTNvHo3q7ikn4I0gB8hika/M+u trRw== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr27904207wjc.4.1427997576403; Thu, 02 Apr 2015 10:59:36 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 2 Apr 2015 10:59:36 -0700 (PDT) In-Reply-To: <10442.1427983195@vindemiatrix.encs.concordia.ca> References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> <10442.1427983195@vindemiatrix.encs.concordia.ca> Date: Thu, 2 Apr 2015 10:59:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=089e01419d1c4820170512c198e4 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 17:59:39 -0000 --089e01419d1c4820170512c198e4 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett wrote: > > As I recall this was considered during the development of DKIM > originally, > > exactly for this reason. We rejected it because we couldn't come up > with a > > safe description of what a tag should look like. If arbitrary text is > > allowed in there, then one could "tag" a spam URL at the front of a > > legitimate message's Subject field and the signature would still pass. > > Right, but if that tag were explicitly deemed to be excluded > from the signature, it could be handled differently. Hmm, but > if this resulted in (for example) the tag not being displayed, > then we would have gained nothing in the case of mailing lists. > Handled by whom? If we're talking about telling MUAs "Don't render the unsigned part of the content the same way as the signed content", then a bunch of additional complexities begin to appear: - MUAs now need to know how to do DKIM themselves, so that they know what parts were signed and what parts were not; alternatively, we need a way to signal between the DKIM verifier and the MUA what parts are safe to render, beyond what Authentication-Results already provides - We're wandering into conversations about how MUAs should interact with users, which this community typically avoids like a terrible allergy - Even if the above aren't problems, we're relying on MUAs to adapt to this change in a relatively short period of time Here be dragons. -MSK --089e01419d1c4820170512c198e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett <anne@e= ncs.concordia.ca> wrote:
> A= s I recall this was considered during the development of DKIM originally, > exactly for this reason.=C2=A0 We rejected it because we couldn't = come up with a
> safe description of what a tag should look like.=C2=A0 If arbitrary te= xt is
> allowed in there, then one could "tag" a spam URL at the fro= nt of a
> legitimate message's Subject field and the signature would still p= ass.

Right, but if that tag were explicitly deemed to be excluded
from the signature, it could be handled differently.=C2=A0 Hmm, but
if this resulted in (for example) the tag not being displayed,
then we would have gained nothing in the case of mailing lists.

Handled by whom?=C2=A0 If we're talking about = telling MUAs "Don't render the unsigned part of the content the sa= me way as the signed content", then a bunch of additional complexities= begin to appear:

- MUAs now need to know how to do DKIM = themselves, so that they know what parts were signed and what parts were no= t; alternatively, we need a way to signal between the DKIM verifier and the= MUA what parts are safe to render, beyond what Authentication-Results alre= ady provides

- We're wandering into conversations abo= ut how MUAs should interact with users, which this community typically avoi= ds like a terrible allergy

- Even if the above aren't= problems, we're relying on MUAs to adapt to this change in a relativel= y short period of time

Here be dragons.

-MSK
--089e01419d1c4820170512c198e4-- From nobody Thu Apr 2 11:08:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16D31A0039 for ; Thu, 2 Apr 2015 11:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 x_AkOUTiQU9o for ; Thu, 2 Apr 2015 11:08:32 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3C11A0030 for ; Thu, 2 Apr 2015 11:08:30 -0700 (PDT) Received: (qmail 79807 invoked from network); 2 Apr 2015 18:08:29 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 2 Apr 2015 18:08:29 -0000 Date: 2 Apr 2015 18:08:07 -0000 Message-ID: <20150402180807.5793.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 18:08:33 -0000 >Handled by whom? If we're talking about telling MUAs "Don't render the >unsigned part of the content the same way as the signed content", then a >bunch of additional complexities begin to appear: We went over all of this ages ago when DKIM was young. It should all be in the DKIM WG archives. >- We're wandering into conversations about how MUAs should interact with >users, which this community typically avoids like a terrible allergy No kidding. I see no reason to expect that mail recipients would do anything useful with differently colored parts of the message. Punting security decisions to users usually seems to train the users to push whatever button makes the warning go away. Also, when we went down this rathole before, we noted that MIME provides an enormous range of ways to make both malicious and benign changes to a message body, and l= doesn't begin to scratch the mites on the dust on the surface. R's, John From nobody Thu Apr 2 11:42:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8BF1A0191 for ; Thu, 2 Apr 2015 11:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4Wp6C6fX0yC7 for ; Thu, 2 Apr 2015 11:42:48 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 F15721A1AB3 for ; Thu, 2 Apr 2015 11:42:44 -0700 (PDT) Received: by wgra20 with SMTP id a20so93715331wgr.3 for ; Thu, 02 Apr 2015 11:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rFEnEeuPqfbC3GD9GpGdbZLLJJFIeoDTULjnq7Pu0A4=; b=tx/WHe7MGelN0r4ThHgKH80urCDEJLoaKxidMunfomz9ve60oYjbgYvJM19gHzEXa0 awInHZXj0Gc2nfpFWNaKVKEddyLQS/GEiIsYjQFNvFrpoysIIi8KhvjOCj2FtsDB9bwb XXP/Bi3aBAmDbEy1aNrJ72mN3R7qUK6QJBJ6wjHLBSrpMHrJLXG7CuCB3Rx2zXipWcu3 mbsTeWc8WVAB/5e/bXqs1DpAAGDv7fn0WF2BE+N6JvUIprLksoIzFw55FN1/HWmZAGJ8 fRJw9BrdEbL5knDKGBh4y0bHP0oKivJvsIwmjp89ou3UPpHCexqkPw4ixdvLaezlWmPz DfIA== MIME-Version: 1.0 X-Received: by 10.180.75.40 with SMTP id z8mr27229196wiv.59.1428000163731; Thu, 02 Apr 2015 11:42:43 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 2 Apr 2015 11:42:43 -0700 (PDT) In-Reply-To: <551D6BD1.6050809@dcrocker.net> References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> <551D636C.2080408@dcrocker.net> <551D6BD1.6050809@dcrocker.net> Date: Thu, 2 Apr 2015 11:42:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d0438956d7f9dcb0512c23275 Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 18:42:50 -0000 --f46d0438956d7f9dcb0512c23275 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker wrote: > > The main difference I see is that if we call v2 something else, we now > > have a tedious administrative exercise of finding every place something > > refers to DKIM and change it to "DKIM or DKIM-plus." This does not > > strike me as a good use of anyone's time. > > That task you characterize as tedious is, in fact, the discipline of > making sure the documentation is careful to distinguish between the two > different (ie, non-interoperable) protocols. > > Efforts to do that with a single specification wind up confusing things > and confusing readers and implementers. I'm using API terminology here but I think the comment generalizes to the protocol: If the input is "the message" and the output is "a set of zero or more SDIDs representing domains whose signatures validated", then I don't think it matters if we go the "v=2" route or the "new header field name" route, because the multiplexing happens on the inside of the processing machine thus described. However, and perhaps unfortunately, RFC5672 changed it so that the output of DKIM is a single SDID. That means either (a) RFC5672 got it wrong, because this doesn't allow for the whole message to be the input and multiple domain names (for passing signatures) to be the output, or (b) the above definition is wrong, because it means a single DKIM signature _plus_ the whole message is the input, and the algorithm picks apart the message as needed to complete the verification and thus produce the single SDID (or an error). OpenDKIM certainly implements the first definition I've used above at its API level, though I could argue that it satisfies either of the two definitions and just happens to do the latter one in a parallel way. -MSK --f46d0438956d7f9dcb0512c23275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker <dhc@dcrocker= .net> wrote:
> The main diff= erence I see is that if we call v2 something else, we now
> have a tedious administrative exercise of finding every place somethin= g
> refers to DKIM and change it to "DKIM or DKIM-plus."=C2=A0 T= his does not
> strike me as a good use of anyone's time.

That task you characterize as tedious is, in fact, the discipline of=
making sure the documentation is careful to distinguish between the two
different (ie, non-interoperable) protocols.

Efforts to do that with a single specification wind up confusing things
and confusing readers and implementers.

I'm = using API terminology here but I think the comment generalizes to the proto= col:

If the input is "the message" and the= output is "a set of zero or more SDIDs representing domains whose sig= natures validated", then I don't think it matters if we go the &qu= ot;v=3D2" route or the "new header field name" route, becaus= e the multiplexing happens on the inside of the processing machine thus des= cribed.

However, and perhaps unfortunately, RFC5672 chang= ed it so that the output of DKIM is a single SDID.=C2=A0 That means either = (a) RFC5672 got it wrong, because this doesn't allow for the whole mess= age to be the input and multiple domain names (for passing signatures) to b= e the output, or (b) the above definition is wrong, because it means a sing= le DKIM signature _plus_ the whole message is the input, and the algorithm = picks apart the message as needed to complete the verification and thus pro= duce the single SDID (or an error).

OpenDKIM certainly im= plements the first definition I've used above at its API level, though = I could argue that it satisfies either of the two definitions and just happ= ens to do the latter one in a parallel way.

-MSK
--f46d0438956d7f9dcb0512c23275-- From nobody Thu Apr 2 12:23:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197E31A1BBE for ; Thu, 2 Apr 2015 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 2aVxkcRVNPwG for ; Thu, 2 Apr 2015 12:23:13 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 F25C21A1AB5 for ; Thu, 2 Apr 2015 12:23:12 -0700 (PDT) Received: by widdi4 with SMTP id di4so89013986wid.0 for ; Thu, 02 Apr 2015 12:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F6oRMNAbyJ9hEvuNCAe4zKYlCGzXQNdTwfuZT3mYG+I=; b=vsrC9/z+IUuK9kaCSt2fsS31B8ih8V7t7ofcmIFs5bl/F3SEbFMpg/Bi9Syp+y44Kr NQrhabzuIuuUAohgOXsA/QktwuG9CE1Rpw5zo/3HtjJzI0i03i4FRUouKCg1EoWEVdlh QVovmuYuxss93ha4jKaLjq8q6XASiwuVd3zIaL1jKLHbveFCt5R7ZOszFDNNxKlY9CDc cDHTvzBuoaFjWOs+n9wEFS3n/3tHCEqPkQiYgKE1Dr3Am5Sb+XflnKzKIlA0Mldzh/6q MGBJXLkPcK0bpXoZiOeRiQ/dX6ZKgo70TLwBORAZbmzhBYurNOwEVhBTyrv8gRQfxuqs +jhg== MIME-Version: 1.0 X-Received: by 10.180.75.243 with SMTP id f19mr27178656wiw.94.1428002591785; Thu, 02 Apr 2015 12:23:11 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 2 Apr 2015 12:23:11 -0700 (PDT) In-Reply-To: References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> <551D636C.2080408@dcrocker.net> <551D6BD1.6050809@dcrocker.net> Date: Thu, 2 Apr 2015 12:23:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d0438951b38c9830512c2c375 Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:23:16 -0000 --f46d0438951b38c9830512c2c375 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy wrote: > If the input is "the message" and the output is "a set of zero or more > SDIDs representing domains whose signatures validated", then I don't think > it matters if we go the "v=2" route or the "new header field name" route, > because the multiplexing happens on the inside of the processing machine > thus described. > As I read RFC6376 sections 3.8 and 3.9, this is a valid perspective. (I may be biased.) -MSK --f46d0438951b38c9830512c2c375 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
If the input is "the message" and the output = is "a set of zero or more SDIDs representing domains whose signatures = validated", then I don't think it matters if we go the "v=3D2= " route or the "new header field name" route, because the mu= ltiplexing happens on the inside of the processing machine thus described.<= br>

As I read RFC6376 sections 3.8 an= d 3.9, this is a valid perspective.=C2=A0 (I may be biased.)

<= div>-MSK
--f46d0438951b38c9830512c2c375-- From nobody Thu Apr 2 12:42:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C201A0118 for ; Thu, 2 Apr 2015 12:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 O9M_Mpn5DYFI for ; Thu, 2 Apr 2015 12:42:14 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D84A61A0111 for ; Thu, 2 Apr 2015 12:42:13 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lHvtC3wBsz1L8n8; Thu, 2 Apr 2015 21:42:11 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lHvtC2jlFz5Mgff; Thu, 2 Apr 2015 21:42:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 2E07F12341F; Thu, 2 Apr 2015 21:42:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3Hnr2V7LdYRw; Thu, 2 Apr 2015 21:42:05 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 74CA1123398; Thu, 2 Apr 2015 21:42:05 +0200 (CEST) Message-ID: <551D9B8D.2060104@sonnection.nl> Date: Thu, 02 Apr 2015 21:42:05 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Anne Bennett References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> <10442.1427983195@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040900050006040406010607" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1428003731; bh=xNcxA7QLqG8DgJIOunqMFFBTXByP7uvmKQpt4jtd++E=; h=Message-ID:Date:From:To:Subject:From; b=J6mUAPQoy1gEcC4/JGy5YDwmLgySqMLRHYOORzR9+zZxyFPFNZrmehttkyQVPvR1o RSSliOYD20QeheBTJc+6VYvzAcgaWnn7x/DGeckAyiRQKQvVpkpTL91HYWvN09J/6E CppZN0WOxpqRRuLL5uR0PYtsoC9pvIGdGGnXnhME= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lHvtC3wBsz1L8n8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:42:20 -0000 This is a multi-part message in MIME format. --------------040900050006040406010607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/02/2015 07:59 PM, Murray S. Kucherawy wrote: > On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett > wrote: > > > As I recall this was considered during the development of DKIM originally, > > exactly for this reason. We rejected it because we couldn't > come up with a > > safe description of what a tag should look like. If arbitrary > text is > > allowed in there, then one could "tag" a spam URL at the front of a > > legitimate message's Subject field and the signature would still > pass. > > Right, but if that tag were explicitly deemed to be excluded > from the signature, it could be handled differently. Hmm, but > if this resulted in (for example) the tag not being displayed, > then we would have gained nothing in the case of mailing lists. > > > Handled by whom? If we're talking about telling MUAs "Don't render > the unsigned part of the content the same way as the signed content", > then a bunch of additional complexities begin to appear: > > - MUAs now need to know how to do DKIM themselves, so that they know > what parts were signed and what parts were not; alternatively, we need > a way to signal between the DKIM verifier and the MUA what parts are > safe to render, beyond what Authentication-Results already provides > > - We're wandering into conversations about how MUAs should interact > with users, which this community typically avoids like a terrible allergy > > - Even if the above aren't problems, we're relying on MUAs to adapt to > this change in a relatively short period of time > > Here be dragons. if DMARC is really the succes that dmarc.org claims it is [1] and with so many of the big ESPs around here [2] I fail to see why it would be so difficult to involve the MUA developers of these same ESPs? /rolf P.S. I only noticed today the significant organizational change of dmarc.org [3] and the fact that this 'new' dmarc.org has only two founding sponsors. [1] http://dmarc.org/2015/02/dmarc-is-a-proven-tool-in-the-fight-against-fraudulent-email/ [2] http://dmarc.org/about/history/ [3] http://dmarc.org/about/ --------------040900050006040406010607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 04/02/2015 07:59 PM, Murray S. Kucherawy wrote:
On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett <anne= @encs.concordia.ca> wrote:
> As I recall this was considered during th= e development of DKIM originally,
> exactly for this reason.=A0 We rejected it because w= e couldn't come up with a
> safe description of what a tag should look like.=A0 If arbitrary text is
> allowed in there, then one could "tag" a spam URL at the front of a
> legitimate message's Subject field and the signature would still pass.

Right, but if that tag were explicitly deemed to be excluded
from the signature, it could be handled differently.=A0 Hmm= , but
if this resulted in (for example) the tag not being displayed,
then we would have gained nothing in the case of mailing lists.

Handled by whom?=A0 If we're talking about telling MUAs "Don't render the unsigned part of the content the same way as the signed content", then a bunch of additional complexities begin to appear:

- MUAs now need to know how to do DKIM themselves, so that they know what parts were signed and what parts were not; alternatively, we need a way to signal between the DKIM verifier and the MUA what parts are safe to render, beyond what Authentication-Results already provides

- We're wandering into conversations about how MUAs should interact with users, which this community typically avoids like a terrible allergy

- Even if the above aren't problems, we're relying on MUAs to adapt to this change in a relatively short period of time

Here be dragons.

if DMARC is really the succes that dmarc.org claims it is [1] and with so many of the big ESPs around here [2] I fail to see why it would be so difficult to involve the MUA developers of these same ESPs?

/rolf

P.S. I only noticed today the significant organizational change of dmarc.org [3] and the fact that this 'new' dmarc.org has only two founding sponsors.

[1] http://dmarc.or= g/2015/02/dmarc-is-a-proven-tool-in-the-fight-against-fraudulent-email/
[2] http://dmarc.org/about/history/
[3] http://dmarc.org/about/

--------------040900050006040406010607-- From nobody Thu Apr 2 12:51:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE60C1A023E for ; Thu, 2 Apr 2015 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 LUBzCvBimMUA for ; Thu, 2 Apr 2015 12:51:32 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 E77AA1A0235 for ; Thu, 2 Apr 2015 12:51:31 -0700 (PDT) Received: by wgin8 with SMTP id n8so5883022wgi.0 for ; Thu, 02 Apr 2015 12:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FzvxqrcjQ3c1hZ9XYDgEBEN+qXLI5Mw0It51RDFn9aY=; b=s9Bc0tw364NH+DAIrSv/Ef///99yoLt3KXcdvSWVcS5xH0K4ymTruyryab3ATd6lU2 N9B48ikx5TDqHyMtXo5HwMDitet0Qnti+dGI3QwDDu3/6fB5777VVKE3E6D6KHiJ0kao hLIQXClZbdFjgZVMX1LIMyu4VQGBGpSgqql8NIeOXevUUHmWkgorlptGUn4vsXapxFWp 2662MkU+M3B8dfJIEVbQ2fD1Ou2sWZw/lkjxLxAroJZJvkARwnL4YugMhDsE+z455Cqi 5yvGlbebaIso0uHFvQ06bSr9XNCtEcrDJi0+92giT/j8FdGValV/PhgD3O5hgQssl2S/ nZwQ== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr98507072wjc.135.1428004290647; Thu, 02 Apr 2015 12:51:30 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 2 Apr 2015 12:51:30 -0700 (PDT) In-Reply-To: <551D9B8D.2060104@sonnection.nl> References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> <10442.1427983195@vindemiatrix.encs.concordia.ca> <551D9B8D.2060104@sonnection.nl> Date: Thu, 2 Apr 2015 12:51:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=047d7bd6adce7b5d3c0512c32852 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:51:34 -0000 --047d7bd6adce7b5d3c0512c32852 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > if DMARC is really the succes that dmarc.org claims it is [1] and with so > many of the big ESPs around here [2] I fail to see why it would be so > difficult to involve the MUA developers of these same ESPs? > Several of them are here. If they have better experience understanding what actually gets through to users in terms of message safety that doesn't reduce to, as John Levine put it, "Where do I click to make this warning go away?", they have yet to say so. :-) -MSK --047d7bd6adce7b5d3c0512c32852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
=20 =20 =20
if DMARC is really the succes t= hat dmarc.org claims it = is [1] and with so many of the big ESPs around here [2] I fail to see why it would be so difficult to involve the MUA developers of these same ESPs?

Several of them are her= e.=C2=A0 If they have better experience understanding what actually gets th= rough to users in terms of message safety that doesn't reduce to, as Jo= hn Levine put it, "Where do I click to make this warning go away?"= ;, they have yet to say so.=C2=A0 :-)

-MSK
--047d7bd6adce7b5d3c0512c32852-- From nobody Thu Apr 2 14:25:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3B11A6EE8 for ; Thu, 2 Apr 2015 14:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 LfVynz_yoy_Z for ; Thu, 2 Apr 2015 14:25:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAC61A6EDC for ; Thu, 2 Apr 2015 14:25:12 -0700 (PDT) Received: from [192.168.1.141] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t32LP5HO024803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 14:25:08 -0700 Message-ID: <551DB3AD.8030803@dcrocker.net> Date: Thu, 02 Apr 2015 14:25:01 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Dave Crocker References: <20150402144850.5325.qmail@ary.lan> <551D5AD2.4040605@dcrocker.net> <551D636C.2080408@dcrocker.net> <551D6BD1.6050809@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 02 Apr 2015 14:25:08 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 21:25:13 -0000 On 4/2/2015 11:42 AM, Murray S. Kucherawy wrote: > On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker > wrote: > If the input is "the message" and the output is "a set of zero or more > SDIDs representing domains whose signatures validated", then I don't Except that that does not describe the DKIM protocol. A protocol is not (necessarily) and input/output engine. It is an interaction engine that delivers things. DKIM delivers a single validated identifier. With respect to the specific DKIM function, the message is overhead, not payload. It is part of what service to enable the payload, not be part of it. > However, and perhaps unfortunately, RFC5672 changed it so that the > output of DKIM is a single SDID. Sorry, no. It wasn't changed, although the precise spec language did change. RFC 478: "permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. " RFC 6376: "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use." In both cases, it refers to a single domain name. Not multiple. If you want to validate multiple domain names, you do multiple (independent) signatures. The substantive change was to clarify an ambiguity in the original spec, about /which/ of the two possible domain names that are in the DKIM-Signature field constitutes the promised one. > That means either (a) RFC5672 got it > wrong, because this doesn't allow for the whole message to be the input huh? > and multiple domain names (for passing signatures) to be the output, or > (b) the above definition is wrong, because it means a single DKIM > signature _plus_ the whole message is the input, and the algorithm picks > apart the message as needed to complete the verification and thus > produce the single SDID (or an error). Or (c) the whole message isn't part of DKIM payload. The answer is (c). > OpenDKIM certainly implements the first definition I've used above at > its API level, though I could argue that it satisfies either of the two > definitions and just happens to do the latter one in a parallel way. I suspect what you've just said is that OpenDKIM can process multiple signatures and deliver a list of validated domain names. This is one more demonstration of the difference between a protocol and an API... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 2 14:31:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA30E1A6F33 for ; Thu, 2 Apr 2015 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8exu1c7bd2ig for ; Thu, 2 Apr 2015 14:31:38 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5BD1A6EF4 for ; Thu, 2 Apr 2015 14:31:37 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([10.255.109.167]) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com ([10.255.109.166]) with Microsoft SMTP Server (TLS) id 15.1.136.3; Thu, 2 Apr 2015 21:31:36 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.010; Thu, 2 Apr 2015 21:31:35 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Third Party Sender DMARC Adaptations Thread-Index: AQHQaxhCh5XUTZXzyUSIPfUlL/hyLp02e2mAgABSl4CAAA9gXYABXqzOgAAPkQCAAXjcj4AAQuYAgAAcooCAAAKhAIAAGnhw Date: Thu, 2 Apr 2015 21:31:35 +0000 Message-ID: References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> <10442.1427983195@vindemiatrix.encs.concordia.ca> <551D9B8D.2060104@sonnection.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.145] x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(199003)(24454002)(377454003)(189002)(102836002)(15975445007)(19625215002)(19609705001)(2351001)(107886001)(19580395003)(16236675004)(19617315012)(101416001)(68736005)(33656002)(87936001)(2656002)(110136001)(46102003)(19300405004)(19580405001)(93886004)(105586002)(106356001)(97736003)(5890100001)(92566002)(450100001)(77156002)(62966003)(16601075003)(66066001)(54356999)(50986999)(76176999)(86362001)(64706001)(2501003)(2950100001)(2900100001)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0534947130 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB605B65C288778125A947F0596F20BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 21:31:35.5152 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 21:31:40 -0000 --_000_BL2SR01MB605B65C288778125A947F0596F20BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBzb3J0cyBvZiB0aGluZ3MgZG8geW91IHdhbnQgdG8gc2VlIGluIGFuIE1VQT8NCg0KLSBH bWFpbCBzYXlzLCBvZiBtZXNzYWdlcyBpbiB0aGUgc3BhbSBmb2xkZXIsIOKAnFRoaXMgbWVzc2Fn ZSBpcyBoZXJlIGJlY2F1c2Ugb3RoZXJzIG1hcmtlZCBpdCBhcyBzcGFtLuKAnQ0KLSBJZiB5b3Ug ZW5hYmxlIGl0IGluIEdtYWlsLCB0aGV5IGFsc28gcHV0IGEga2V5IGJlc2lkZSBhdXRoZW50aWNh dGVkIG1lc3NhZ2VzDQotIE91dGxvb2suY29tL0hvdG1haWwgaGFzIGEgR3JlZW4gU2hpZWxkIGlu IHRoZSBMaXN0IHZpZXcgbmV4dCB0byBtZXNzYWdlcyB0aGF0IGFyZSBvbiB0aGUgR3JlZW4gU2hp ZWxkIGxpc3QgKGxhcmdlIGJyYW5kIHN1c2NlcHRpYmxlIHRvIHNwb29maW5nLCBtYW51YWxseSBt YWludGFpbmVkKSBhbmQgcGFzcyBhdXRoZW50aWNhdGlvbg0KLSBPdXRsb29rIGRlc2t0b3Agc2F5 cyDigJxUaGlzIG1lc3NhZ2Ugd2FzIG1hcmtlZCBhcyBzcGFtIGJ5IGEgZmlsdGVyIG90aGVyIHRo YW4gdGhlIE91dGxvb2sganVuayBjbGllbnTigJ0NCi0gT3V0bG9vayBkZXNrdG9wIGFsc28gZGlz YWJsZXMgTGlua3MsIFJlcGx5LCBSZXBseSBBbGwsIGFuZCBBdHRhY2htZW50cyBmb3IgbWVzc2Fn ZXMgaW4gSnVuaywgYW5kIGFueSBtZXNzYWdlIG1hcmtlZCBhcyBQaGlzaCByZWdhcmRsZXNzIG9m IHdoZXRoZXIgb3Igbm90IGl0IGlzIGluIHRoZSBpbmJveA0KDQpXaXRoaW4gTWljcm9zb2Z0LCB3 ZeKAmXJlIGxvb2tpbmcgYXQgaG93IHRvIGluY2x1ZGUgc29tZSBvZiB0aGUgdGhpbmdzIGluIG91 dGxvb2suY29tL0hvdG1haWwgaW50byBPdXRsb29rIGFuZCBob3cgYmVzdCB0byBpbnRlZ3JhdGUg c2FmZXR5IGludG8gdGhlIG92ZXJhbGwgdXNlciBleHBlcmllbmNlIGluIG1haWwgY2xpZW50cyBN aWNyb3NvZnQgY29udHJvbHMuIFdoaWxlIHRyYWRpdGlvbmFsbHkgdGhlcmUgaGFzbuKAmXQgYmVl biBhIGxvdCBvZiBNVEEtdG8tTVVBIGNvbW11bmljYXRpb24gKG90aGVyIHRoYW4gRXhjaGFuZ2Ug YW5kIE91dGxvb2spLCB0aGF0IGRvZXNu4oCZdCBuZWVkIHRvIGJlIHRoZSBjYXNlIGdvaW5nIGZv cndhcmQuDQoNCi0tIFRlcnJ5DQoNCkZyb206IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11cnJheSBTLiBLdWNoZXJhd3kNClNlbnQ6IFRodXJzZGF5 LCBBcHJpbCAyLCAyMDE1IDEyOjUyIFBNDQpUbzogPFIuRS5Tb25uZXZlbGRAc29ubmVjdGlvbi5u bD4NCkNjOiBkbWFyY0BpZXRmLm9yZzsgQW5uZSBCZW5uZXR0DQpTdWJqZWN0OiBSZTogW2RtYXJj LWlldGZdIFRoaXJkIFBhcnR5IFNlbmRlciBETUFSQyBBZGFwdGF0aW9ucw0KDQpPbiBUaHUsIEFw ciAyLCAyMDE1IGF0IDEyOjQyIFBNLCBSb2xmIEUuIFNvbm5ldmVsZCA8Ui5FLlNvbm5ldmVsZEBz b25uZWN0aW9uLm5sPG1haWx0bzpSLkUuU29ubmV2ZWxkQHNvbm5lY3Rpb24ubmw+PiB3cm90ZToN CmlmIERNQVJDIGlzIHJlYWxseSB0aGUgc3VjY2VzIHRoYXQgZG1hcmMub3JnPGh0dHA6Ly9kbWFy Yy5vcmc+IGNsYWltcyBpdCBpcyBbMV0gYW5kIHdpdGggc28gbWFueSBvZiB0aGUgYmlnIEVTUHMg YXJvdW5kIGhlcmUgWzJdIEkgZmFpbCB0byBzZWUgd2h5IGl0IHdvdWxkIGJlIHNvIGRpZmZpY3Vs dCB0byBpbnZvbHZlIHRoZSBNVUEgZGV2ZWxvcGVycyBvZiB0aGVzZSBzYW1lIEVTUHM/DQoNClNl dmVyYWwgb2YgdGhlbSBhcmUgaGVyZS4gIElmIHRoZXkgaGF2ZSBiZXR0ZXIgZXhwZXJpZW5jZSB1 bmRlcnN0YW5kaW5nIHdoYXQgYWN0dWFsbHkgZ2V0cyB0aHJvdWdoIHRvIHVzZXJzIGluIHRlcm1z IG9mIG1lc3NhZ2Ugc2FmZXR5IHRoYXQgZG9lc24ndCByZWR1Y2UgdG8sIGFzIEpvaG4gTGV2aW5l IHB1dCBpdCwgIldoZXJlIGRvIEkgY2xpY2sgdG8gbWFrZSB0aGlzIHdhcm5pbmcgZ28gYXdheT8i LCB0aGV5IGhhdmUgeWV0IHRvIHNheSBzby4gIDotKQ0KLU1TSw0K --_000_BL2SR01MB605B65C288778125A947F0596F20BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGF0IHNvcnRzIG9mIHRo aW5ncyBkbyB5b3Ugd2FudCB0byBzZWUgaW4gYW4gTVVBPzxvOnA+PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSBHbWFpbCBzYXlz LCBvZiBtZXNzYWdlcyBpbiB0aGUgc3BhbSBmb2xkZXIsIOKAnFRoaXMgbWVzc2FnZSBpcyBoZXJl IGJlY2F1c2Ugb3RoZXJzIG1hcmtlZCBpdCBhcyBzcGFtLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+LSBJZiB5b3UgZW5hYmxlIGl0IGluIEdtYWlsLCB0aGV5IGFsc28gcHV0IGEga2V5 IGJlc2lkZSBhdXRoZW50aWNhdGVkIG1lc3NhZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4tIE91dGxvb2suY29tL0hvdG1haWwgaGFzIGEgR3JlZW4gU2hpZWxkIGluIHRoZSBMaXN0IHZp ZXcgbmV4dCB0byBtZXNzYWdlcyB0aGF0IGFyZSBvbiB0aGUgR3JlZW4gU2hpZWxkIGxpc3QgKGxh cmdlIGJyYW5kIHN1c2NlcHRpYmxlIHRvIHNwb29maW5nLCBtYW51YWxseSBtYWludGFpbmVkKQ0K IGFuZCBwYXNzIGF1dGhlbnRpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tIE91 dGxvb2sgZGVza3RvcCBzYXlzIOKAnFRoaXMgbWVzc2FnZSB3YXMgbWFya2VkIGFzIHNwYW0gYnkg YSBmaWx0ZXIgb3RoZXIgdGhhbiB0aGUgT3V0bG9vayBqdW5rIGNsaWVudOKAnTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+LSBPdXRsb29rIGRlc2t0b3AgYWxzbyBkaXNhYmxlcyBMaW5rcywg UmVwbHksIFJlcGx5IEFsbCwgYW5kIEF0dGFjaG1lbnRzIGZvciBtZXNzYWdlcyBpbiBKdW5rLCBh bmQgYW55IG1lc3NhZ2UgbWFya2VkIGFzIFBoaXNoIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBu b3QgaXQNCiBpcyBpbiB0aGUgaW5ib3g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2l0aGluIE1pY3Jvc29mdCwgd2XigJlyZSBs b29raW5nIGF0IGhvdyB0byBpbmNsdWRlIHNvbWUgb2YgdGhlIHRoaW5ncyBpbiBvdXRsb29rLmNv bS9Ib3RtYWlsIGludG8gT3V0bG9vayBhbmQgaG93IGJlc3QgdG8gaW50ZWdyYXRlIHNhZmV0eSBp bnRvIHRoZSBvdmVyYWxsIHVzZXINCiBleHBlcmllbmNlIGluIG1haWwgY2xpZW50cyBNaWNyb3Nv ZnQgY29udHJvbHMuIFdoaWxlIHRyYWRpdGlvbmFsbHkgdGhlcmUgaGFzbuKAmXQgYmVlbiBhIGxv dCBvZiBNVEEtdG8tTVVBIGNvbW11bmljYXRpb24gKG90aGVyIHRoYW4gRXhjaGFuZ2UgYW5kIE91 dGxvb2spLCB0aGF0IGRvZXNu4oCZdCBuZWVkIHRvIGJlIHRoZSBjYXNlIGdvaW5nIGZvcndhcmQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPi0tIFRlcnJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmls IDIsIDIwMTUgMTI6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+ICZsdDtSLkUuU29ubmV2ZWxkQHNvbm5l Y3Rpb24ubmwmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkbWFyY0BpZXRmLm9yZzsgQW5uZSBCZW5uZXR0 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZG1hcmMtaWV0Zl0gVGhpcmQgUGFydHkgU2VuZGVy IERNQVJDIEFkYXB0YXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVGh1LCBBcHIgMiwgMjAxNSBhdCAxMjo0MiBQTSwgUm9sZiBFLiBTb25uZXZlbGQgJmx0Ozxh IGhyZWY9Im1haWx0bzpSLkUuU29ubmV2ZWxkQHNvbm5lY3Rpb24ubmwiIHRhcmdldD0iX2JsYW5r Ij5SLkUuU29ubmV2ZWxkQHNvbm5lY3Rpb24ubmw8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5pZiBETUFSQyBpcyByZWFsbHkgdGhlIHN1Y2NlcyB0aGF0IDxhIGhyZWY9Imh0dHA6Ly9kbWFy Yy5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRtYXJjLm9yZzwvYT4gY2xhaW1zIGl0IGlzIFsxXSBh bmQgd2l0aCBzbyBtYW55IG9mIHRoZSBiaWcgRVNQcyBhcm91bmQgaGVyZSBbMl0gSSBmYWlsIHRv IHNlZSB3aHkgaXQgd291bGQgYmUgc28gZGlmZmljdWx0IHRvIGludm9sdmUgdGhlIE1VQSBkZXZl bG9wZXJzIG9mIHRoZXNlIHNhbWUgRVNQcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5TZXZlcmFsIG9mIHRoZW0gYXJlIGhlcmUuJm5ic3A7IElmIHRoZXkgaGF2ZSBi ZXR0ZXIgZXhwZXJpZW5jZSB1bmRlcnN0YW5kaW5nIHdoYXQgYWN0dWFsbHkgZ2V0cyB0aHJvdWdo IHRvIHVzZXJzIGluIHRlcm1zIG9mIG1lc3NhZ2Ugc2FmZXR5IHRoYXQgZG9lc24ndCByZWR1Y2Ug dG8sIGFzIEpvaG4gTGV2aW5lIHB1dCBpdCwgJnF1b3Q7V2hlcmUgZG8gSSBjbGljayB0byBtYWtl DQogdGhpcyB3YXJuaW5nIGdvIGF3YXk/JnF1b3Q7LCB0aGV5IGhhdmUgeWV0IHRvIHNheSBzby4m bmJzcDsgOi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tTVNLIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL2SR01MB605B65C288778125A947F0596F20BL2SR01MB605namsdf_-- From nobody Thu Apr 2 14:32:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966791A1B5D for ; Thu, 2 Apr 2015 14:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 NAlGnQBgPbKd for ; Thu, 2 Apr 2015 14:32:11 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (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 E7A2C1A1EE8 for ; Thu, 2 Apr 2015 14:32:10 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so55136710qcb.2 for ; Thu, 02 Apr 2015 14:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OVm7dns5Y5eCSaWIijMELa0Zoy6evLKyqqWQLmJ+YTQ=; b=mVVfwZBIiTAhNpB5Cjbi1fFqNMlSshL+ytkKCiZUs4rpousdYM9/wqQWsZ5itbuj7O TfrBVMLPLQPulIXdZ72IlCzALVn0DRILFEtFQUBHw8CYaL49WsoCZmAVUTRjfott+gsF jrF7HvmuIzlwwGExZ3zV6NTXxPGiSZze34TQhU7LRPnivWTd6Pn0VfdR1bmI+y9C65fE z8v0Fno8o9Q37whj1XvhmZTFxJq1oTvARdzwIWIDmnFvz4CO6JJng6z2iCxwcVvygLwE 9l9Jl2k/OQ1LFUbRJhpMpNpXfafWZTuFHsubBieQ1Tk0JIVuRutyc/epMpjnKkaNmNpq mNJA== X-Received: by 10.140.19.237 with SMTP id 100mr5337112qgh.24.1428010330192; Thu, 02 Apr 2015 14:32:10 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id y17sm4325346qky.8.2015.04.02.14.32.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 14:32:09 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <20150402180807.5793.qmail@ary.lan> Date: Thu, 2 Apr 2015 14:30:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46AAA894-2D4C-4A1B-9016-AA3C0AFF4F8A@gmail.com> References: <20150402180807.5793.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 21:32:12 -0000 > On Apr 2, 2015, at 11:08 AM, John Levine wrote: >=20 >> Handled by whom? If we're talking about telling MUAs "Don't render = the >> unsigned part of the content the same way as the signed content", = then a >> bunch of additional complexities begin to appear: >=20 > We went over all of this ages ago when DKIM was young. It should all = be > in the DKIM WG archives. >=20 >> - We're wandering into conversations about how MUAs should interact = with >> users, which this community typically avoids like a terrible allergy >=20 > No kidding. I see no reason to expect that mail recipients would do > anything useful with differently colored parts of the message. > Punting security decisions to users usually seems to train the users > to push whatever button makes the warning go away. >=20 > Also, when we went down this rathole before, we noted that MIME > provides an enormous range of ways to make both malicious and benign > changes to a message body, and l=3D doesn't begin to scratch the mites > on the dust on the surface. Dear John, The goal is to prevent recipients from seeing non-aligned Froms = signifying a domain seeking DMARC protection. This may significantly = affect third-partys causing DMARC alignment failures. In such cases, a = remedy likely requires modification of =46rom domains. The TPA-Label scheme envisioned a DMARC extension to assert domains = seeking protection will separately authorize various third-partys = confirmed by various methods. It is now clear, ESPs (ab)using DMARC = have no interest in managing exceptions, with their lack of interest = likely remaining true when expecting them to add provisions for the = destinations of their user's messages.=20 I'll attempt to put together an I-D that includes provisions for = supporting both mailing-lists and SMTP gateways without changing DKIM or = SPF, or expecting ESP cooperation. The work is to be done by those = affected by DMARC and not rightfully the (ab)using ESP, acquiescing to = the view might makes right. Regards, Douglas Otis From nobody Thu Apr 2 16:22:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DCA1A87ED for ; Thu, 2 Apr 2015 16:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 n2_bEwc1AsjR for ; Thu, 2 Apr 2015 16:22:32 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFC21A87EC for ; Thu, 2 Apr 2015 16:22:32 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id EAFCE1C38CF; Fri, 3 Apr 2015 08:22:30 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CDD7B120EC9; Fri, 3 Apr 2015 08:22:30 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> <10442.1427983195@vindemiatrix.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 03 Apr 2015 08:22:30 +0900 Message-ID: <87zj6qglop.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 23:22:34 -0000 Murray S. Kucherawy writes: > On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett wrote: > > Right, but if that tag were explicitly deemed to be excluded > > from the signature, it could be handled differently. Hmm, but > > if this resulted in (for example) the tag not being displayed, > > then we would have gained nothing in the case of mailing lists. > > > > Handled by whom? If we're talking about telling MUAs "Don't render the > unsigned part of the content the same way as the signed content", then a > bunch of additional complexities begin to appear: How about substituting s/U/T/? Unpacking that rather obscure expression, if you have a well-defined protocol (as opposed to, say, the quoting convention for replies :-), the M*T*A (or spam-fighting milter) could remove the parts signed only by 3rd parties, and add a message/rfc822 subpart of the whole original message as an attachment which the reader *could* look at, if they want to, in most M*U*As. Really paranoid sites like A** and Y****! could just remove on receipt. > - We're wandering into conversations about how MUAs should interact > with users, which this community typically avoids like a terrible > allergy Note that although this does rely on the MUA to havec certain capabilities, most MUAs *do* have them, and I hope that users will accept the inconvenience because they get the original message without the third-party decorations. I suspect this line of thought is beneficial only to MLs, unfortunately. From nobody Thu Apr 2 17:00:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B311A88C4 for ; Thu, 2 Apr 2015 17:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BRYYRrkpHVFM for ; Thu, 2 Apr 2015 17:00:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAF441A88BD for ; Thu, 2 Apr 2015 17:00:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKCBK6SW1S00G9IV@mauve.mrochek.com> for dmarc@ietf.org; Thu, 2 Apr 2015 16:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1428018948; bh=CIgI7bX5iGstczt3Rede95OwPb19nNHsR7mbsU2PLkk=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=DqlTUu/V8jYvO9ztYP9LnzokCZvtHTIL7pVERFD2bsCSYRaYOVyM10dETMyFJMk7t xNwBl7Ei+MMbbIIA5vo9csXla1CSXwtSC8fOXyVZnVBoAHkNmKbrhwFsz2v900JKhA xOckANs/qrnrtvMjteIFYPFgJ/s3G+3XjcGKo5js= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKC9H3DBZK00GZDS@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 02 Apr 2015 16:55:45 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PKCBK57P6I00GZDS@mauve.mrochek.com> Date: Thu, 02 Apr 2015 16:49:42 -0700 (PDT) In-reply-to: "Your message dated Thu, 02 Apr 2015 03:22:27 +0000" <20150402032227.2479.qmail@ary.lan> References: <551CA875.9080206@dcrocker.net> <20150402032227.2479.qmail@ary.lan> To: John Levine Archived-At: Cc: dmarc@ietf.org, dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 00:00:51 -0000 > >In the latter case, it's really an entirely new protocol, which should > >be identified by the next-lower protocol, rather than by using the > >version field as an in-bred demultiplexing field. > I suppose, but if the two procols are 99% the same, and the new one is > upward compatible with the old one, and anything that understands the > new one also has to understand the old one, and the goal is to have > everything puts semantics on the old one put the same semantics on the > new one, I'm having trouble seeing why one of these is vastly > preferable to the other: > DKIM-Signature: v=2; d=example.com; ... > DaveKIM-Signature: v=1; d=example.com; ... Without getting into the desirability/utility of any sort of v2, I'll note that the latter of these has one small advantage: It avoids any issues with broken DKIM handlers that fail to correctly interpret the v= field. Having said that, I think the version bump approach is a pretty significant aesthetic win, especially if the change is, as noted below, to implement the "must handle" tag. And aesthetics in protocols do matter to some extent. Ned > In this particular case, the incompatibility is a new kind of "must > handle" tag suggested by Ned Freed with the new rule that if a > verifier doesn't understand it, the verification fails. The first of > them would be must-re-sign, which means that the message has to be > re-signed by another domain, e.g.: > DKIM-Signature: v=2; d=yahoo.com; @mr=ietf.org; ... > which would say this signature is only good if there is also a DKIM > signature with d=ietf.org. You could chain these things which might > deal with the educational forwarding issue that Elizabeth Z. described. > Once you have the syntax for must handle tags (I used @ here) then we > can add more of them as needed without another version bump. > R's, > John > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 2 17:35:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250B21A898F for ; Thu, 2 Apr 2015 17:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 u5n6VECz2ADX for ; Thu, 2 Apr 2015 17:35:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C981A898C for ; Thu, 2 Apr 2015 17:35:37 -0700 (PDT) Received: from [192.168.1.141] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t330ZUDm028410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 17:35:33 -0700 Message-ID: <551DE04D.6030907@dcrocker.net> Date: Thu, 02 Apr 2015 17:35:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20150402032227.2479.qmail@ary.lan> In-Reply-To: <20150402032227.2479.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 02 Apr 2015 17:35:34 -0700 (PDT) Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 00:35:39 -0000 On 4/1/2015 8:22 PM, John Levine wrote: > DKIM-Signature: v=2; d=example.com; ... > DaveKIM-Signature: v=1; d=example.com; ... > > In this particular case, the incompatibility is a new kind of "must > handle" tag suggested by Ned Freed with the new rule that if a > verifier doesn't understand it, the verification fails. This handling of unrecognized tags is another change from existing DKIM: "3.6.1. Textual Representation ... The current valid tags are described below. Other tags MAY be present and MUST be ignored by any implementation that does not understand them." So receipt of a message signed in the new form will likely produce an incorrect signature validation, since (1) the new tag's semantics won't be applied and (2) the new rule for unrecognized tags won't be applied. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 2 18:31:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E4F1A90B3 for ; Thu, 2 Apr 2015 18:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 xCsaAdxV-Fj6 for ; Thu, 2 Apr 2015 18:31:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8754F1ACD55 for ; Thu, 2 Apr 2015 18:26:00 -0700 (PDT) Received: (qmail 40308 invoked from network); 3 Apr 2015 01:25:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9d73.551dec27.k1504; bh=wh1UB7o9bIh8iA9RFI7EaYgljjEZocFuUojZfb+9ftU=; b=FjnWauIKLfTH/eXkVMKp9qHHfiE5yNtkMP5OVUCcfsMmo/84+ocuetClygqS5V+6BvqUBzesFAs7sVYlxgCuh4UX1HeMDXR32NMgVrpGnnawZEkcFUT6CRiMthi7SiFhg1RKQOdRvpa2CWrwiGv8Ad0+bijoHrVH9v8psu0LYDiYSWQwLCu0T3c2I4YTGT71va79v26nxlI/iCgpdKCIh8Zbxd/celEdRDE6UwHNKU5Xd4sTkQrAEm2OjV21721i DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9d73.551dec27.k1504; bh=wh1UB7o9bIh8iA9RFI7EaYgljjEZocFuUojZfb+9ftU=; b=LDOmcUretrZzRtnbH6Pe+U4PbT7ji08xo2Uw750my6GC1EapBm/kO6GjzCPD0C2Y0La6wLYw9XR1G1KkiPoKVUU5+Fu+um+WgMoHWr6RzWLVIfHCobqf94jdPG4fvIp1Bf94Cg2e5U4VFeqQhlQfNnWgYrlNP5GEz8k8PxIHZysxRH6dl9zInDcxav/aeGzyU9bd6/EIYHiu65rMaYLA7M6/LwFa6xTXPL3D4M3P4oG5N4sMovRFKwDEbDd0N+iM Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 03 Apr 2015 01:25:58 -0000 Date: 2 Apr 2015 21:25:58 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <551DE04D.6030907@dcrocker.net> References: <20150402032227.2479.qmail@ary.lan> <551DE04D.6030907@dcrocker.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 01:31:40 -0000 > So receipt of a message signed in the new form will likely produce an > incorrect signature validation, ... I wondered about that, too, so before I proposed a version bump, I took a look at the code that people use: * Murray's opendkim C library: checks that the version is 0.5 or 1, fails otherwise. That's the code in the milters that sendmail and postfix use, and I believe it's the library that everyone else with custom C code (including me) uses or adapts. It replaces the older libdkim. * Jason Long's perl Mail::DKIM: checks that the version is 0.5 or 1, will accept no v= at all for backward compatibility with DK but not other v= values. This is what spamassassin uses. * Scott K's dkimpy: checks that the version is 0.5 or 1. A version bump appears unlikely to produce an incorrect signature validation unless there are other libraries in active use that ignored the spec that says to check the version number. I suppose I could try sending v=2 signatures to my Yahoo and Gmail and Hotmail accounts to see what their trace headers say, but I'd be pretty surprised if they got it wrong. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Apr 2 20:13:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8531A008B for ; Thu, 2 Apr 2015 20:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 iJtkI48vFkrI for ; Thu, 2 Apr 2015 20:13:23 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (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 710A21A007C for ; Thu, 2 Apr 2015 20:13:23 -0700 (PDT) Received: by wgra20 with SMTP id a20so101224338wgr.3 for ; Thu, 02 Apr 2015 20:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fX9b+dEcA2zu/HZqy9z0p6nimpg8c8QQM73xlmdVvSU=; b=EQypJPYGcWDJ6KfrzD29iQf7hc4YEJytRfk0m3sWBRDQRrtplcsTi+tBBgUXyOAwfm D5vrfCtx3P3Nrr0sd3bjfFPVSqLpseUL4ycSUdbKakv6X16j1Jqc6LTTS4hMHmqU7YZk S/n7iJXD7XDIuBtlVehyadKgIJf8ZqTjbOXgqQGi9YxSI/oaCheWlXMyN6R7+Dk+PO4c LLHa+Y10FZDR5sTf/K6LbHfYPvo4sDO+XxQxx/jAyWmFMV6u4+hUPcli8Dd0SxVfq2Kl d9oVDi0VpX05RhjJiIENASzf0TP3W3y8iBXHCk08SjUdQW+kwnBvlOvq/ABchAF5URcR gBbg== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr1582831wix.52.1428030802270; Thu, 02 Apr 2015 20:13:22 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 2 Apr 2015 20:13:22 -0700 (PDT) In-Reply-To: References: <20150402032227.2479.qmail@ary.lan> <551DE04D.6030907@dcrocker.net> Date: Thu, 2 Apr 2015 20:13:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d044289e8b29ca30512c9543d Archived-At: Cc: "dmarc@ietf.org" , Dave Crocker Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 03:13:25 -0000 --f46d044289e8b29ca30512c9543d Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 6:25 PM, John R Levine wrote: > So receipt of a message signed in the new form will likely produce an >> incorrect signature validation, ... >> > > I wondered about that, too, so before I proposed a version bump, I took a > look at the code that people use: > > * Murray's opendkim C library: checks that the version is 0.5 or 1, fails > otherwise. That's the code in the milters that sendmail and postfix use, > and I believe it's the library that everyone else with custom C code > (including me) uses or adapts. It replaces the older libdkim. > It won't accept 0.5 unless configured to do so, and that's off by default. -MSK --f46d044289e8b29ca30512c9543d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2015 at 6:25 PM, John R Levine <johnl@taugh.= com> wrote:
So receipt of a message signed in the new form will likely produce an
incorrect signature validation, ...

I wondered about that, too, so before I proposed a version bump, I took a l= ook at the code that people use:

* Murray's opendkim C library: checks that the version is 0.5 or 1, fai= ls otherwise.=C2=A0 That's the code in the milters that sendmail and po= stfix use, and I believe it's the library that everyone else with custo= m C code (including me) uses or adapts.=C2=A0 It replaces the older libdkim= .

It won't accept 0.5 unless config= ured to do so, and that's off by default.

-MSK
--f46d044289e8b29ca30512c9543d-- From nobody Fri Apr 3 11:40:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ABA1ACF19 for ; Fri, 3 Apr 2015 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 u2EzZONA3vf8 for ; Fri, 3 Apr 2015 11:40:29 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 41F4C1ACF1B for ; Fri, 3 Apr 2015 11:40:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1209; t=1428086419; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=OGUGgbOmJcAxjxfm53kg9/7okrA=; b=NHdDQyTvAM8n/Bw9xdJs pr79VF991ucdGUBPq8BMFFLWPk3ashMIyQef2CDC0cqBtjHCHvON83ispV/GQ567 T8v9HrTnqiWq5L6penvOxiR1hmDwe867M8BSOv/asXF68GXgsDzQbqjA3tqCndTp pbpPCsBlA4xT/4CPdfj7Hnw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 03 Apr 2015 13:40:19 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1796444764.36165.3676; Fri, 03 Apr 2015 13:40:18 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1209; t=1428086204; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=DXONN/m 3myF5ry37SVxzfRZsNaG6/ORz3RoT03fmv5k=; b=Ebx5B+OzPdPmsd6/J3CStos xPdnNdiXZhcXEoG0G5t+cdLKEQBU7Sp1mPOBobWQI2WqaazqUQlRjNgrOFbaSvqq LF8hL8Oij5Oc4i890Ozd3gBNPz5wkoDUAANq1t529FBtv/p60zVzdGZBEBn3jdP1 1u7VrYXPGMAX43rXClS0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 03 Apr 2015 14:36:44 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 388739348.9.7324; Fri, 03 Apr 2015 14:36:42 -0400 Message-ID: <551EDE8C.6000905@isdg.net> Date: Fri, 03 Apr 2015 14:40:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: dmarc@ietf.org References: <20150402032227.2479.qmail@ary.lan> <551DE04D.6030907@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 18:40:34 -0000 On 4/2/2015 9:25 PM, John R Levine wrote: >> So receipt of a message signed in the new form will likely produce an >> incorrect signature validation, ... > > I wondered about that, too, so before I proposed a version bump, I > took a look at the code that people use: > > * Murray's opendkim C library: checks that the version is 0.5 or 1, > fails otherwise. That's the code in the milters that sendmail and > postfix use, and I believe it's the library that everyone else with > custom C code (including me) uses or adapts. It replaces the older > libdkim. At least 8-10 years ago, it wasn't the library "everyone else" used. It wasn't quite portable to Windows (without changes). It might be different today. Alt-N's open source DKIM/ADSP library was a pure C/C++ portable package and it was used. In this API, if "v=" exist, it checks for the string match of either: "1" "0.5" "0.4" "0.3" "0.2" and returns a DKIM_SIG_VERSION_02_PLUS version otherwise DKIM_STAT_INCOMPAT. If "v=" did not exist, it returns a DKIM_SIG_VERSION_PRE_02 version. None of this was made optional to operators. So a "version bump" would return DKIM_STAT_INCOMPAT (unknown version). -- HLS From nobody Fri Apr 3 15:48:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAAD1A7001 for ; Fri, 3 Apr 2015 15:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 O3IuuqzIovHJ for ; Fri, 3 Apr 2015 15:48:16 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 33EF31A6FFF for ; Fri, 3 Apr 2015 15:48:16 -0700 (PDT) Received: by ierf6 with SMTP id f6so99152268ier.2 for ; Fri, 03 Apr 2015 15:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J6kPjbexLFHX7fjS3yprU+gONOP+4xQWvQYBUqfe8ps=; b=HoOl5FFCFXV8RAdBmC3nEcQwtGiLlwzTQmwlQcIeKwKS1iwisZWh3hDDgB/OKxLoZr Hx3CdCXDvKDtH5N70aa83p+kyuLBjQgIJgaq+2HLOz0bcD0ufIIebOIzH82tNJ2b4Zrk QYFo9s550BV5ppNmfogBEV9ukdAspxqnr911wp1qr64XcPjccqJWRLTIew76Vqjq61hK SuJqc4smPnce/55D5V5iAJ6PqZvvKzrEIANApn4ytQcY/Btp+S3Lzj+8p1kPO83jgowz rRaSWMOEMcOm2uPXAPnLKMLBbmDtpMqAB0vgXe3BchgKLcD8w0CLLqYNJy7WtC0dJHjz ZxOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J6kPjbexLFHX7fjS3yprU+gONOP+4xQWvQYBUqfe8ps=; b=EJp1fAK2cVNF6gBQVmrnnsboMaoF9prIcL9dgkt0kDTkOnVRkd7CWqPXz4TnCtPzCX quceJFzDh+U+02C4df5fKhX1tl8W5sHi27EPO9RVb0w+dUHgmkMKrOU/v6fkXnWF356d 7jzbUz8WZ+kD1Gf16QYHt383FnHS0pXRo5Zk+Q9T+lQ8Li6j85mbr92h0ArKp+YSJ8uW X80FXeFIFopsDYBGv0SA5/r33GTGscdQv0J3rb97UNFc7zpfP7kv8JGtWPQ0/4aJW2As lG4nWF74XtuuYVFot6m23ioboD45vLmg76J+w7q3gehSfxDybkxQMVvCc5rYBRICFTRL 3YPA== X-Gm-Message-State: ALoCoQn6XpWsoNggeZzWJOb16Kbp7WCPBRXWlY9ujcyF79KlJFmpnD++WlWEw5lUIaMTJ08IlNrm MIME-Version: 1.0 X-Received: by 10.50.73.168 with SMTP id m8mr24386439igv.32.1428101295487; Fri, 03 Apr 2015 15:48:15 -0700 (PDT) Received: by 10.64.86.7 with HTTP; Fri, 3 Apr 2015 15:48:15 -0700 (PDT) In-Reply-To: <551EDE8C.6000905@isdg.net> References: <20150402032227.2479.qmail@ary.lan> <551DE04D.6030907@dcrocker.net> <551EDE8C.6000905@isdg.net> Date: Fri, 3 Apr 2015 15:48:15 -0700 Message-ID: From: Brandon Long To: Hector Santos Content-Type: multipart/alternative; boundary=089e013a239c6bfe8a0512d9bea6 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 22:48:17 -0000 --089e013a239c6bfe8a0512d9bea6 Content-Type: text/plain; charset=UTF-8 Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll get a "bad format" or "bad version" in the AuthRes header. Wonder how old the DKIM1 is and whether we should remove that now... Brandon On Fri, Apr 3, 2015 at 11:40 AM, Hector Santos wrote: > On 4/2/2015 9:25 PM, John R Levine wrote: > >> So receipt of a message signed in the new form will likely produce an >>> incorrect signature validation, ... >>> >> >> I wondered about that, too, so before I proposed a version bump, I >> took a look at the code that people use: >> >> * Murray's opendkim C library: checks that the version is 0.5 or 1, >> fails otherwise. That's the code in the milters that sendmail and >> postfix use, and I believe it's the library that everyone else with >> custom C code (including me) uses or adapts. It replaces the older >> libdkim. >> > > At least 8-10 years ago, it wasn't the library "everyone else" used. It > wasn't quite portable to Windows (without changes). It might be different > today. Alt-N's open source DKIM/ADSP library was a pure C/C++ portable > package and it was used. In this API, if "v=" exist, it checks for the > string match of either: > > "1" > "0.5" > "0.4" > "0.3" > "0.2" > > and returns a DKIM_SIG_VERSION_02_PLUS version otherwise > DKIM_STAT_INCOMPAT. If "v=" did not exist, it returns a > DKIM_SIG_VERSION_PRE_02 version. None of this was made > optional to operators. So a "version bump" would return > DKIM_STAT_INCOMPAT (unknown version). > > -- > HLS > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e013a239c6bfe8a0512d9bea6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks like we require v to exist and be either 1 or DKIM1,= otherwise you'll get a "bad format" or "bad version&quo= t; in the AuthRes header.=C2=A0 Wonder how old the DKIM1 is and whether we = should remove that now...

Brandon

On Fri, Apr 3, 2015 at 11:4= 0 AM, Hector Santos <hsantos@isdg.net> wrote:
On 4/2/2015 9:25 PM, John R Levine wrot= e:
So receipt of a message signed in the new form will likely produce an
incorrect signature validation, ...

I wondered about that, too, so before I proposed a version bump, I
took a look at the code that people use:

* Murray's opendkim C library: checks that the version is 0.5 or 1,
fails otherwise.=C2=A0 That's the code in the milters that sendmail and=
postfix use, and I believe it's the library that everyone else with
custom C code (including me) uses or adapts.=C2=A0 It replaces the older libdkim.

 At least 8-10 years ago, it wasn't the library "everyone else"= ; used. It wasn't quite portable to Windows (without changes).=C2=A0 It= might be different today.=C2=A0 Alt-N's open source DKIM/ADSP library = was a pure C/C++ portable package and it was used.=C2=A0 In this API, if &q= uot;v=3D" exist, it checks for the string match of either:

=C2=A0 =C2=A0"1"
=C2=A0 =C2=A0"0.5"
=C2=A0 =C2=A0"0.4"
=C2=A0 =C2=A0"0.3"
=C2=A0 =C2=A0"0.2"

and returns a DKIM_SIG_VERSION_02_PLUS version otherwise DKIM_STAT_INCOMPAT= . If "v=3D" did not exist, it returns a DKIM_SIG_VERSION_PRE_02 v= ersion.=C2=A0 =C2=A0None of this was made
optional to operators.=C2=A0 So a "version bump"=C2=A0 would retu= rn DKIM_STAT_INCOMPAT (unknown version).

--
HLS



_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--089e013a239c6bfe8a0512d9bea6-- From nobody Fri Apr 3 16:08:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0431A887B for ; Fri, 3 Apr 2015 16:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dLFw0aiN_Hvu for ; Fri, 3 Apr 2015 16:08:13 -0700 (PDT) Received: from articuno.alameth.org (articuno.alameth.org [IPv6:2600:3c01::f03c:91ff:fe70:755c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDC41A874C for ; Fri, 3 Apr 2015 16:08:13 -0700 (PDT) Received: from rapidash.eng.sonicwall.com (unknown [IPv6:2620:9f:12:cc51::2d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by articuno.alameth.org (Postfix) with ESMTPS id 6337184E8; Fri, 3 Apr 2015 23:09:02 +0000 (UTC) Message-ID: <551F1D48.9060805@alameth.org> Date: Fri, 03 Apr 2015 16:07:52 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150402032227.2479.qmail@ary.lan> <551DE04D.6030907@dcrocker.net> <551EDE8C.6000905@isdg.net> In-Reply-To: <551EDE8C.6000905@isdg.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Hector Santos Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 23:08:15 -0000 >> >> * Murray's opendkim C library... the code in the milters that >> sendmail and postfix use, and I believe it's the library that >> everyone else with custom C code (including me) uses or adapts. It >> replaces the older libdkim. > > ... Alt-N's open source DKIM/ADSP library was a pure C/C++ portable > package and it was used. In this API, if "v=" exist, it checks for > the string match of either: > > "1" > "0.5" > "0.4" > "0.3" > "0.2" Dell also uses the Alt-N library (which I think is the same thing as "libdkim"). From nobody Fri Apr 3 19:42:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697231A88EA for ; Fri, 3 Apr 2015 19:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 V8o3PhEfd4ok for ; Fri, 3 Apr 2015 19:42:52 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3CA1A88E9 for ; Fri, 3 Apr 2015 19:42:52 -0700 (PDT) Received: (qmail 51557 invoked from network); 4 Apr 2015 02:42:51 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Apr 2015 02:42:51 -0000 Date: 4 Apr 2015 02:42:29 -0000 Message-ID: <20150404024229.8836.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: blong@google.com Subject: Re: [dmarc-ietf] DKIM libraries, was Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 02:42:54 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll >get a "bad format" or "bad version" in the AuthRes header. Wonder how old >the DKIM1 is and whether we should remove that now... The DNS key record has to say v=DKIM1 while the signature says v=1 In answer to someone else's question, libdkim is inded the Alt-N library which as far as I can tell hasn't been touched since 2008. It still seems to work OK, and it checks the v= in the signature to be "1" or some old 0.x test versions. R's, John From nobody Fri Apr 3 21:18:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769FD1A8987 for ; Fri, 3 Apr 2015 21:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8Eh5VyTqx6_y for ; Fri, 3 Apr 2015 21:18:25 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 F1E811A8983 for ; Fri, 3 Apr 2015 21:18:24 -0700 (PDT) Received: by wixm2 with SMTP id m2so82297560wix.0 for ; Fri, 03 Apr 2015 21:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8HOtOuLtO06A8FV7fg8zIvgMXs8ChfOEbtQRvsXupVI=; b=lGzgUMEMOT/8B8Jj5q9en14vE+AA3fuF1FpQK88JWD+pt/kHqvG8oUsQFhgZftv6g8 /QXQjd6pYx5VmRPhGYlk5QmexnDkS3nFcHA4pA4QgJHcJ0WmPKaKSwdCWew5CaMGNn4T utrT4RWSYeBW2Seq/AXnrIPk3UCL8TlaMV+jm074W+dzj8wujCXIdhQQA89m6xOymWtP tiu5k9vBG+5DpFYHLiLAAW0FOgiyoxOshTm2oVWfS6ncGNtb/DMmrg7B9zOXM5vNh6Ru vJIdyNdndScFT6nerpXTcicLO+8sTaaCe3HyBqGCfZjvoFJxkZd64+o6ZrNKSUzKG+6Z xCGw== MIME-Version: 1.0 X-Received: by 10.180.75.40 with SMTP id z8mr10999505wiv.59.1428121103771; Fri, 03 Apr 2015 21:18:23 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Fri, 3 Apr 2015 21:18:23 -0700 (PDT) In-Reply-To: <20150404024229.8836.qmail@ary.lan> References: <20150404024229.8836.qmail@ary.lan> Date: Fri, 3 Apr 2015 21:18:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d0438956d162cf70512de5ba6 Archived-At: Cc: Brandon Long , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM libraries, was Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 04:18:26 -0000 --f46d0438956d162cf70512de5ba6 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 7:42 PM, John Levine wrote: > In answer to someone else's question, libdkim is inded the Alt-N > library which as far as I can tell hasn't been touched since 2008. > It still seems to work OK, and it checks the v= in the signature > to be "1" or some old 0.x test versions. > Unfortunately the dkim-milter package (the predecessor to OpenDKIM) also called its library "libdkim". -MSK --f46d0438956d162cf70512de5ba6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 3, 2015 at 7:42 PM, John Levine <johnl@taugh.co= m> wrote:
In answer to someone else's questi= on, libdkim is inded the Alt-N
library which as far as I can tell hasn't been touched since 2008.
It still seems to work OK, and it checks the v=3D in the signature
to be "1" or some old 0.x test versions.
Unfortunately the dkim-milter package (the predecessor to OpenD= KIM) also called its library "libdkim".

-MSK
--f46d0438956d162cf70512de5ba6-- From nobody Sun Apr 5 18:34:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559FC1A1B3F for ; Sun, 5 Apr 2015 18:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 IRMEvGAU_3wp for ; Sun, 5 Apr 2015 18:34:06 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 6A9501A1B2A for ; Sun, 5 Apr 2015 18:33:54 -0700 (PDT) Received: by wiun10 with SMTP id n10so21195410wiu.1 for ; Sun, 05 Apr 2015 18:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KqntENL4Ob32ool+u/HQD+mPK395x7x30msWHR8s8xI=; b=m5ndV30PqwVE96c12zVcgAAHlYmGBUsDI6rq1low+raE4/Tuk4xD3FsG0W4J18c6C7 P51R8VgpQw6ADJ3NFG1+28nKc4HISZ5ISt4tiK/x0t9FWOqbW0l83LLa3g1Fqt8l2oor 1rJHoDtE5UFkXONvfAcoCiiMT7nBCfEE9TaFh0+chUK/EepSjTx+BxX1V3N4U7FMqNv+ NePdoqf5JDvPvxGKaSEzksGK6x8McuZRhfxIEjW7UqkqZMY6pyldY0sYvXH2e8sJXLid gIxbEqTRWUt3Dczsjoxoo2KJoxDJIWYyMmV2ziTwIldUSwStTtOLGyIqsxor2panxacE lEig== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr53758408wic.94.1428284032978; Sun, 05 Apr 2015 18:33:52 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Sun, 5 Apr 2015 18:33:52 -0700 (PDT) Date: Sun, 5 Apr 2015 18:33:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c381ce6c96b90513044af6 Archived-At: Subject: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 01:34:17 -0000 --001a11c381ce6c96b90513044af6 Content-Type: text/plain; charset=UTF-8 Colleagues, I've posted a new version of draft-kucherawy-dkim-list-canon, which had expired. It was one of several we were considering a while back as a way of dealing with some indirect mail flows. https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ Also, I've posted a new one that proposes a way to include in the signature some information about message transformations that happened at a Mediator, allowing the Verifier to undo said changes and re-try the author signature. Something else to consider: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Comments on either or both are welcome. -MSK --001a11c381ce6c96b90513044af6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

I've posted a = new version of draft-kucherawy-dkim-list-canon, which had expired.=C2=A0 It= was one of several we were considering a while back as a way of dealing wi= th some indirect mail flows.

https://datatracker.ietf.org/doc/dra= ft-kucherawy-dkim-list-canon/

Also, I've posted a new = one that proposes a way to include in the signature some information about = message transformations that happened at a Mediator, allowing the Verifier = to undo said changes and re-try the author signature.=C2=A0 Something else = to consider:

https://datatracker.ietf.org/doc/draft-kucherawy-dkim= -transform/

Comments on either or both are welcome.
-MSK
--001a11c381ce6c96b90513044af6-- From nobody Mon Apr 6 08:25:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8D1A897D for ; Mon, 6 Apr 2015 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Cge1lDc-BwNp for ; Mon, 6 Apr 2015 08:25:20 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 99E541A892C for ; Mon, 6 Apr 2015 08:25:20 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t36FPIGQ016726; Mon, 6 Apr 2015 11:25:18 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t36FPHLT029899; Mon, 6 Apr 2015 11:25:17 -0400 Message-Id: <201504061525.t36FPHLT029899@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Murray S. Kucherawy" From: Michael Jack Assels In-reply-to: References: Comments: In-reply-to "Murray S. Kucherawy" message dated "Sun, 05 Apr 2015 18:33:52 -0700." Date: Mon, 06 Apr 2015 11:25:17 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-06 11:25:18 EDT Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 15:25:22 -0000 On Sun, 05 Apr 2015 18:33:52 PDT, "Murray S. Kucherawy" wrote: > I've posted a new version of draft-kucherawy-dkim-list-canon, which had > expired. It was one of several we were considering a while back as a way > of dealing with some indirect mail flows. > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ > > Also, I've posted a new one that proposes a way to include in the signature > some information about message transformations that happened at a Mediator, > allowing the Verifier to undo said changes and re-try the author > signature. Something else to consider: > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ > > Comments on either or both are welcome. Thanks for both of these. They significantly enhance the ability of compliant list mail surviving DKIM verification. Tiny spelling nits: In draft-kucherawy-dkim-list-canon, Appendix A, just before figure 1: "descendents" should be "descendants" (The former is becoming obsolete.) In draft-kucherawy-dkim-transform, Section 6, first paragraph: "additonal" should be "additional". A small nit: In draft-kucherawy-dkim-list-canon, Section 4, item 3, asks for "An integer expression of the number of children at that node." Just in case there are more than nine children, it might be helpful to specify "The decimal number of children at that node." A slightly larger nit: In draft-kucherawy-dkim-list-canon, Section 6.2, I can't make the last sentence parse: Operators that might grant preferential handling based on valid DKIM signatures from favorable domains; assuming that appended content in the presence of such signatures does not mean the appended content is necessarily safe. If I understand what you're trying to communicate, I'd suggest: Operators that might grant preferential handling based on valid DKIM signatures from favored domains should not assume that the added content is necessarily safe, despite the presence of a valid DKIM signature. In both documents, there's a conspicuously missing item that would make list subscribers -- and owners -- a lot happier: A mechanism for changing the RFC5322.Subject header. Since most lists nowadays add something like "[list-name] " immediately after "Subject: " in the originating Author's message, they still won't pass DKIM validation even after complying with the proposed body modification rules. Would it not be fairly easy to add an easily reversible "change-subject" transformation to draft-kucherawy-dkim-transform document, along with a corresponding "cs" DKIM-Signature tag? Assuming that the mediated RFC5322.From header is unchanged, this would make it fairly simple for the originating Author's message to be reconstructed from the message delivered to list members. But perhaps it might be better to put header transformations in a separate draft. Of course, none of this touches the issue of From-munging, but that's a DMARC alignment problem, not a DKIM problem, so these drafts aren't the place to address it. Thanks again, MJA From nobody Mon Apr 6 10:06:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC31A8F3A for ; Mon, 6 Apr 2015 10:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 A3s77vpAbS0k for ; Mon, 6 Apr 2015 10:06:48 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 099531A8F44 for ; Mon, 6 Apr 2015 10:06:47 -0700 (PDT) Received: by wgin8 with SMTP id n8so32253920wgi.0 for ; Mon, 06 Apr 2015 10:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8nbuyU076OInlGfiM/HrZeqyoPhaY+znOpiK2zcQy1w=; b=qUVZAAQ+yvT5vAao6ObVdJv0anAm+KkqtFpdwvXCIfEuihZmW7enYXG0OShY3TKdV/ Y9Ye2etbAl075aLBaTNKCmZUoJhI2VDqkR4mMJYBeXOKsiHS4TYYQVM2ezCzGFCBw+TK Q9QF+yg+dAxcVCaRkLofdnEr6gDr8ldbpwuoSOZHQIDihAYzfY1LJpTvJYC2wtXJWMWa +R7xozsIZaD73ITLHKpmXq5+UDdDsYp7MJvJi0JKqkwX+kqhGvUmDEDXs1bcF5l+1yg8 j/oTMnytaargz/EVcO6NY+wSNSWHXHJ3sCWgsv7DPv7JuBVX1S01TDgVz5jm5K/T8XHb N12w== MIME-Version: 1.0 X-Received: by 10.180.187.67 with SMTP id fq3mr60073253wic.59.1428340004644; Mon, 06 Apr 2015 10:06:44 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Mon, 6 Apr 2015 10:06:44 -0700 (PDT) In-Reply-To: <201504061525.t36FPHLT029899@shadrach.encs.concordia.ca> References: <201504061525.t36FPHLT029899@shadrach.encs.concordia.ca> Date: Mon, 6 Apr 2015 10:06:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Michael Jack Assels Content-Type: multipart/alternative; boundary=001a11c38070986fc8051311521a Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 17:06:50 -0000 --001a11c38070986fc8051311521a Content-Type: text/plain; charset=UTF-8 On Mon, Apr 6, 2015 at 8:25 AM, Michael Jack Assels < mjassels@encs.concordia.ca> wrote: > In both documents, there's a conspicuously missing item that would make > list subscribers -- and owners -- a lot happier: A mechanism for changing > the RFC5322.Subject header. Since most lists nowadays add something like > "[list-name] " immediately after "Subject: " in the originating Author's > message, they still won't pass DKIM validation even after complying > with the proposed body modification rules. Would it not be fairly > easy to add an easily reversible "change-subject" transformation to > draft-kucherawy-dkim-transform document, along with a corresponding "cs" > DKIM-Signature tag? Assuming that the mediated RFC5322.From header is > unchanged, this would make it fairly simple for the originating Author's > message to be reconstructed from the message delivered to list members. > But perhaps it might be better to put header transformations in a > separate draft. > It's conspicuously missing mainly because of the thread from last week that talks about why we avoided dealing with Subject: tagging during the original development of DKIM. However, if consensus is that this general approach is viable, then yes, it would be possible to have a second set of additional reversible mutations such as this. The difference in this case is that the list is taking responsibility for the mutations by signing the mutated form. The advantage of this method over the CDKIM or "v=2" method is that it's purely incremental to DKIM, so we don't have to touch RFC6376. -MSK --001a11c38070986fc8051311521a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 6, 2015 at 8:25 AM, Michael Jack Assels <mjassels@encs.concordia.ca> wrote:
In both documents, there's a conspicuously missing item that= would make
list subscribers -- and owners -- a lot happier:=C2=A0 A mechanism for chan= ging
the RFC5322.Subject header.=C2=A0 Since most lists nowadays add something l= ike
"[list-name] " immediately after "Subject: " in the ori= ginating Author's
message, they still won't pass DKIM validation even after complying
with the proposed body modification rules.=C2=A0 Would it not be fairly
easy to add an easily reversible "change-subject" transformation = to
draft-kucherawy-dkim-transform document, along with a corresponding "c= s"
DKIM-Signature tag?=C2=A0 Assuming that the mediated RFC5322.From header is=
unchanged, this would make it fairly simple for the originating Author'= s
message to be reconstructed from the message delivered to list members.
But perhaps it might be better to put header transformations in a
separate draft.

It's conspicuously = missing mainly because of the thread from last week that talks about why we= avoided dealing with Subject: tagging during the original development of D= KIM.=C2=A0 However, if consensus is that this general approach is viable, t= hen yes, it would be possible to have a second set of additional reversible= mutations such as this.

The difference in this case is t= hat the list is taking responsibility for the mutations by signing the muta= ted form.

The advantage of this method over the CDKIM or = "v=3D2" method is that it's purely incremental to DKIM, so we= don't have to touch RFC6376.

-MSK
--001a11c38070986fc8051311521a-- From nobody Mon Apr 6 13:48:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701021A9176 for ; Mon, 6 Apr 2015 13:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kOmfQgz7Nc4W for ; Mon, 6 Apr 2015 13:48:14 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB1D1A9165 for ; Mon, 6 Apr 2015 13:48:14 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id t36Km6sH048893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 6 Apr 2015 13:48:11 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com t36Km6sH048893 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1428353291; bh=K/riZnNI2hkK1g2zj2psxTIylqo/riJsAyWy8VXlrhM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lcjBYzqSIGIsY+XioxPiy4bNG9cXqRGcwuagyuc9YUeq+VYm/EgtlchwGCDULnD6n XQ0Mw1JZ6Ih0KMZzLD2eAO+SEcl+A6KZIrnIK/rqdKXk2wbogpLIKMA9zlRMKJsKZN +r3KIcq7PrbDFFcUI11tabkxfCIyJdSEKq7ICVMs= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <5522F107.9040606@crash.com> Date: Mon, 06 Apr 2015 13:48:07 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> <4D62F546336B4732A7B1CE73590A9450@fgsr.local> <32352.1427898928@vindemiatrix.encs.concordia.ca> <10442.1427983195@vindemiatrix.encs.concordia.ca> <551D9B8D.2060104@sonnection.nl> In-Reply-To: <551D9B8D.2060104@sonnection.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Mon, 06 Apr 2015 13:48:11 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] DMARC.org, was Re: Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 20:48:21 -0000 On 04/02/2015 12:42 PM, Rolf E. Sonneveld wrote: > > P.S. I only noticed today the significant organizational change of > dmarc.org [3] and the fact that this 'new' dmarc.org has only two > founding sponsors. While the change to the organization is significant - for instance, there is now a formal organization - there was actually not as significant a change in support as you seem to be implying. But with a formal organization replacing the loose collection of cooperating companies, the term "sponsor" takes on a different - or at least an additional - meaning. There are in fact three more founding sponsors whose logos have not made it to that page for purely administrative reasons. However DMARC.org continues to be advised by and collaborate with most of the members of the preceding group, and other organizations not part of that original group. > [2] http://dmarc.org/about/history/ > [3] http://dmarc.org/about/ --Steve. From nobody Tue Apr 7 10:26:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BC61B38A3 for ; Tue, 7 Apr 2015 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ClT38TnGCNtv for ; Tue, 7 Apr 2015 10:26:34 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 786AA1B389C for ; Tue, 7 Apr 2015 10:26:34 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t37HQVWA026560; Tue, 7 Apr 2015 13:26:31 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t37HQVjt006476; Tue, 7 Apr 2015 13:26:31 -0400 Message-Id: <201504071726.t37HQVjt006476@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Murray S. Kucherawy" From: Michael Jack Assels In-reply-to: References: <201504061525.t36FPHLT029899@shadrach.encs.concordia.ca> Comments: In-reply-to "Murray S. Kucherawy" message dated "Mon, 06 Apr 2015 10:06:44 -0700." Date: Tue, 07 Apr 2015 13:26:31 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-07 13:26:31 EDT Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 17:26:36 -0000 On Mon, 06 Apr 2015 10:06:44 PDT, "Murray S. Kucherawy" wrote: > On Mon, Apr 6, 2015 at 8:25 AM, Michael Jack Assels > wrote: > > > In both documents, there's a conspicuously missing item that would make > > list subscribers -- and owners -- a lot happier: A mechanism for changing > > the RFC5322.Subject header. [...] > > It's conspicuously missing mainly because of the thread from last week that > talks about why we avoided dealing with Subject: tagging during the > original development of DKIM. Sorry. It wasn't my intention to raise a question that had already been settled. I did read last week's thread. However, since your drafts appear to have done so much to address other issues that bother mailing list people, I thought it would be useful to handle subject tags in essentially the same way, the only significant difference being that they appear in headers rather than in the message body. > However, if consensus is that this general approach is viable, then yes, > it would be possible to have a second set of additional reversible > mutations such as this. The consensus is deafening. :-) MJA From nobody Wed Apr 8 09:19:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7681B33CC for ; Wed, 8 Apr 2015 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 saH0DkaCbKZl for ; Wed, 8 Apr 2015 09:19:31 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157961B33BD for ; Wed, 8 Apr 2015 09:19:28 -0700 (PDT) Received: (qmail 6222 invoked from network); 8 Apr 2015 16:19:28 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Apr 2015 16:19:28 -0000 Date: 8 Apr 2015 16:19:06 -0000 Message-ID: <20150408161906.32839.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:19:32 -0000 >Comments on either or both are welcome. They both have the same problem: the list says: Here's what I did. Whadda ya think? Every recipient system has to come up with its own heuristics to decide what combinations of changes are or are not acceptable, which means that the exact same message will be accepted by one 100% conformant implementation and rejected by another. This does not seem to me to be a major improvement over the current situation. R's, John From nobody Wed Apr 8 10:26:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF881B34DD for ; Wed, 8 Apr 2015 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 KCtzqtmkDjvd for ; Wed, 8 Apr 2015 10:26:32 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 6317D1B34DC for ; Wed, 8 Apr 2015 10:26:32 -0700 (PDT) Received: by wizk4 with SMTP id k4so63494125wiz.1 for ; Wed, 08 Apr 2015 10:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Iwj62QveqzugTtqSxN2cJvTNeBGtzQk7WkHh+hAqbF8=; b=vsk/GZOxCDYZHOkCVjnDjkvghEGDGZVj6wk+dFDF7C2tqffCMDIYfcniT1fL+ltbiK PfCDl5zWBiIW8yNeYJk1Sf5UsH3EboZDokOjCtI2z/26ZNZcGqLl0PKmNgJlGcVNTb3m fffZnLqU/vG8qssvxvTiHAS/UUxDkT56Os5Iey4oymL5ASd4WPgN0DTT4/FWjcMCUIUB Yyeyf3UklwU228G4w6INX2Uso0zk6+RvdKhupxSjZcLvWkmUJld3b78AMSk0nDslJCrG qjY+jagnLM6rOP8x6zORZkLDuSGVfvVKY5O1QjlvNXe0qdoc2hQXndwh1q9GrybF2TYi hefg== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr16749381wix.52.1428513990968; Wed, 08 Apr 2015 10:26:30 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 8 Apr 2015 10:26:30 -0700 (PDT) In-Reply-To: <20150408161906.32839.qmail@ary.lan> References: <20150408161906.32839.qmail@ary.lan> Date: Wed, 8 Apr 2015 10:26:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d044289e8fd0b92051339d4a6 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:26:34 -0000 --f46d044289e8fd0b92051339d4a6 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 9:19 AM, John Levine wrote: > >Comments on either or both are welcome. > > They both have the same problem: the list says: > > Here's what I did. Whadda ya think? > > Every recipient system has to come up with its own heuristics to > decide what combinations of changes are or are not acceptable, which > means that the exact same message will be accepted by one 100% > conformant implementation and rejected by another. This does not > seem to me to be a major improvement over the current situation. > But I think that's true of every protocol we have now. For example, independent of DMARC, a valid DKIM-signed message might be rejected by "A" and not by "B" because of its content based on local policy and filtering. Local heuristics about acceptable content will always be there regardless of what we do. The goal here is not acceptance, but deterministic results from the authentication layer. Or, more generally, we need to be able to recover a validated identifer that aligns in a way that doesn't degrade the integrity of that validation. Being able to have the author signature cover the original content and the list signature cover any changes seems like a win to me. -MSK --f46d044289e8fd0b92051339d4a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 8, 2015 at 9:19 AM, John Levine <johnl@taugh.co= m> wrote:
>Comments on eithe= r or both are welcome.

They both have the same problem: the list says:

=C2=A0Here's what I did.=C2=A0 Whadda ya think?

Every recipient system has to come up with its own heuristics to
decide what combinations of changes are or are not acceptable, which
means that the exact same message will be accepted by one 100%
conformant implementation and rejected by another.=C2=A0 This does not
seem to me to be a major improvement over the current situation.

But I think that's true of every protocol we have = now.=C2=A0 For example, independent of DMARC, a valid DKIM-signed message m= ight be rejected by "A" and not by "B" because of its c= ontent based on local policy and filtering.=C2=A0 Local heuristics about ac= ceptable content will always be there regardless of what we do.

The = goal here is not acceptance, but deterministic results from the authenticat= ion layer.=C2=A0 Or, more generally, we need to be able to recover a valida= ted identifer that aligns in a way that doesn't degrade the integrity o= f that validation.

Being able to ha= ve the author signature cover the original content and the list signature c= over any changes seems like a win to me.

-MSK
--f46d044289e8fd0b92051339d4a6-- From nobody Wed Apr 8 11:06:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424561A892C for ; Wed, 8 Apr 2015 11:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 O4vQlJYSUZ1V for ; Wed, 8 Apr 2015 11:06:56 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCD51A0066 for ; Wed, 8 Apr 2015 11:06:55 -0700 (PDT) Received: (qmail 25634 invoked from network); 8 Apr 2015 18:06:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6421.55256e3f.k1504; bh=uUjBu/VTT8qwDJjANVmaINgd/dHhJbW96fynXBqODzM=; b=E90le459Qa6Wi+DAh3/DOkhVor6detmxqXg7slIWB41VRCCJAcTnpZj3TlaRnIuogi5ToEb9r4LDZY3FmSuZ/2sf4F+/4Dt1lvNNJpzb54h4ZGbAUkhJ+FA/vgS+cYU+OdzRqVA87bdSIfDtAex+FSRaMtzOJnTo7WvcQeRa+ioWE4J+vuMYrDN+tHtgbyXM2gtsR4yps1dXb2ZtGk0yps6c2wGGP51lSWns9cefCqMdpY513LC1kryOeJgc/ant DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6421.55256e3f.k1504; bh=uUjBu/VTT8qwDJjANVmaINgd/dHhJbW96fynXBqODzM=; b=cvQ29Hw+uG3EiyKcx/FjDAIDgmX7Jh+QMnYeCwcav+gQrOADkW8ihxuaYgNc4HXuRalpvPM0oLupc3odOEX28wBazpIUt+5Y/0qXo1Xi/PaAof1I4lKyJcs5oZBS4xWsFDRJq+FP1PLB+IRlTG7M63nCJ3ocv+UuOHD1r8ND/Zm+DTihV0b7skjSrYUSDhZEdK4YtFplWMdOdVLMni3YmayhulQx8akX+qr6gBxLI7OtDa+8+dYXLPqJ03edYJOq Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 08 Apr 2015 18:06:55 -0000 Date: 8 Apr 2015 14:06:54 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:06:57 -0000 >> Here's what I did. Whadda ya think? > The goal here is not acceptance, but deterministic results from the > authentication layer. Well, that's the problem. The current spec has a well defined rule that a verifier uses on the headers and body and the key from the DNS. Either the signature's valid or it isn't. The recipient can certainly decide to do whatever it wants with that bit, but it's one well defined bit. Unless I'm misreading these drafts, the signature now says "I took the message, and then I deleted this part, and then I added that part" or the like. While it's likely possible for the recipient to say, yes, that's what you did, the recipient still has to make up its own rules about what transformations it likes, probably including body filtering of new parts. That seems too squishy to have much hope of interoperating. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 8 14:14:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEE81B3697 for ; Wed, 8 Apr 2015 14:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DV8717CfpMaj for ; Wed, 8 Apr 2015 14:14:07 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 BD01E1B3696 for ; Wed, 8 Apr 2015 14:14:06 -0700 (PDT) Received: by wizk4 with SMTP id k4so70111121wiz.1 for ; Wed, 08 Apr 2015 14:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tvD4ZDXyq4RDp8txTKox3QNbwAKo0G0igDn8Rm1W3tg=; b=0UNZV9hKEBx2CV+BopPmbsct6eQYdNRsaezgT+4M++KmaD8/r752BL/N1IDTZO5AfN gEuSnWVqXnsSWpPS3UTDn1qjAcxIOveZd2OJAw0VMhmhslMoQJhI2sFCoSRZXpN979YV ENDCQkjTO/f0JRLJi8/1NHxmDR/JEHM1Q8tzJyRxj33LuDc6jlSlEx1hzkb2O8A4bYUc py9Sg/WcJGjeMx+5IZ5zz90IsPl248++hxqWa8VSVGUSqCGODi0NteP/LBQk4PbXpSTM TC6OAvXj2Xv+F+HPnHizL/IR7a27JiE+HW2uk84P3CtSPYM4ykJux9COChrQxhDFN2pA 26/A== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr53070552wjc.4.1428527645590; Wed, 08 Apr 2015 14:14:05 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 8 Apr 2015 14:14:05 -0700 (PDT) In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> Date: Wed, 8 Apr 2015 14:14:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=089e01419d1cde096805133d024d Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:14:09 -0000 --089e01419d1cde096805133d024d Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 11:06 AM, John R Levine wrote: > Well, that's the problem. The current spec has a well defined rule that a > verifier uses on the headers and body and the key from the DNS. Either the > signature's valid or it isn't. The recipient can certainly decide to do > whatever it wants with that bit, but it's one well defined bit. > > Unless I'm misreading these drafts, the signature now says "I took the > message, and then I deleted this part, and then I added that part" or the > like. While it's likely possible for the recipient to say, yes, that's > what you did, the recipient still has to make up its own rules about what > transformations it likes, probably including body filtering of new parts. > Are these not well-defined rules, in the same vein that canonicalizations are? That's certainly the intent here. The existing "relaxed" canonicalizations spell out a bunch of things you do to the content before you compute the hashes. That's all these do as well. It's more involved, to be sure, but in the end you're just trying to figure out if the "d=" domain took responsibility for the content. -MSK --089e01419d1cde096805133d024d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 8, 2015 at 11:06 AM, John R Levine <johnl@tau= gh.com> wrote:
Well, tha= t's the problem.=C2=A0 The current spec has a well defined rule that a = verifier uses on the headers and body and the key from the DNS.=C2=A0 Eithe= r the signature's valid or it isn't.=C2=A0 The recipient can certai= nly decide to do whatever it wants with that bit, but it's one well def= ined bit.

Unless I'm misreading these drafts, the signature now says "I took= the message, and then I deleted this part, and then I added that part"= ; or the like.=C2=A0 While it's likely possible for the recipient to sa= y, yes, that's what you did, the recipient still has to make up its own= rules about what transformations it likes, probably including body filteri= ng of new parts.

Are these not well-def= ined rules, in the same vein that canonicalizations are?=C2=A0 That's c= ertainly the intent here.

The existing "relaxed"= ; canonicalizations spell out a bunch of things you do to the content befor= e you compute the hashes.=C2=A0 That's all these do as well.=C2=A0 It&#= 39;s more involved, to be sure, but in the end you're just trying to fi= gure out if the "d=3D" domain took responsibility for the content= .

-MSK
--089e01419d1cde096805133d024d-- From nobody Wed Apr 8 14:21:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518AC1B36BA for ; Wed, 8 Apr 2015 14:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 gdIYzfJCa8bj for ; Wed, 8 Apr 2015 14:21:15 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4281B36B8 for ; Wed, 8 Apr 2015 14:21:15 -0700 (PDT) Received: (qmail 56062 invoked from network); 8 Apr 2015 21:21:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=dafd.55259bc9.k1504; bh=SF05LCum8WweBLr4b8+dpERCm6Iz/gGQzwjOz2E0dzk=; b=lcA/D/3j8O8A7+ApzikSBS7GjjnZldJZZrQZyykut/Akg71NOZMZBwchZ3xn2nn20eSx5cDO9iBc3TanmJPJxLwKZWz8KAkzTfZDCmTX34Xm72Grr3BWDXpx5CLoliGgQyWgPXbW5FrnFDYu6a1fIgJtqSdFiWS30raWUnq0umxZ9wEyf+FhIYFriYwNNIVw7K+8IYJVat6bH8HGNbaug4kyk+T25MoeVa00aCvvZzZlLHv+S5gL9UrUe8qhuv8I DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=dafd.55259bc9.k1504; bh=SF05LCum8WweBLr4b8+dpERCm6Iz/gGQzwjOz2E0dzk=; b=FhDms2n0NvZlB+AbjDa0o9o/RquKP0eL0vxJsjjKitaoKnIxgWayqu14YNXm5prN64ksGPkealFw12fGGw0jKm3mYvNiwrWs78cgy+G62FacoRsn0toSWN0iR4D/OAAUh2jv+yRhgkI6K4duQ+64phkTk1sDZVxBcpLk3jVO5haG7zZIKHDBlq/0p5HzobEShzcGG9LshyeSDT11rIKBH/qEdEr7/CcXTzejbbkpqHrYmn/JCFXaM0m6tCP2hfL4 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 08 Apr 2015 21:21:13 -0000 Date: 8 Apr 2015 17:21:12 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:21:16 -0000 > Are these not well-defined rules, in the same vein that canonicalizations > are? That's certainly the intent here. They are, but they're not useful in the way that the existing ones are. The existing ones are strict enough that everyone appears to agree that if the signature validates, it's the same message for a pretty strict version of "same". These say that it's a message somewhat related to the original, but "somewhat related" isn't useful in the same binary way that "same" is. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 8 15:04:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4B1A9026 for ; Wed, 8 Apr 2015 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_PROFILE2=1.981, SPF_PASS=-0.001] autolearn=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 zVq5Yu3bDCXX for ; Wed, 8 Apr 2015 15:04:16 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 3B4D01A901F for ; Wed, 8 Apr 2015 15:04:15 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so129549278pdb.0 for ; Wed, 08 Apr 2015 15:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BqP3xjKY9osHi0MpF6XNwLsEBvAJ+jdU2nLYRqzrqwg=; b=MbjpIvedq2RGGzf5xfKEis6Aj2PvFY2BSII7LZ5uuaELdcgtIaAaJHpOu8zxll2blM bFWgw0fKaka6WYBe0tKz4/t3FLQFsF8jTA/B+CLeVpO6cr0qv07wCpM1Mp51zJZltiZJ 3z70kzRJmg7LZNbuT04x6pkcVDbD+xpHr+YvWUlL4AHyuf7jcrNlSWJnNNTIhnN14nJg PLOKdTDhHh0glukjlZ+l7CaQtPDpUIVjTpY9P2Ya0MQBq/Q7QZ0oJ4tnWQM4qNzkV3qT 9oJNFhUXohGSl0Mvg9s2XKclYup4WIsnjbfJQ43Wlv//K5xN0zC/E6c6cdO7IwWEmuRh JK7A== X-Received: by 10.68.221.102 with SMTP id qd6mr49068751pbc.119.1428530654873; Wed, 08 Apr 2015 15:04:14 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ae9sm377175pac.25.2015.04.08.15.04.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 15:04:13 -0700 (PDT) Message-ID: <5525A5D9.5080607@gmail.com> Date: Wed, 08 Apr 2015 15:04:09 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150408161906.32839.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:04:17 -0000 On 4/8/15 2:14 PM, Murray S. Kucherawy wrote: > The existing "relaxed" canonicalizations spell out a bunch of things you do > to the content before you compute the hashes. That's all these do as > well. It's more involved, to be sure, but in the end you're just trying to > figure out if the "d=" domain took responsibility for the content. Dear Murray, You seem to presume DKIM redefinition is able to override DMARC assumption based policies. DMARC makes questionable assumptions of From header fields playing the role of Sender. An assumption especially unlikely when there is a different signed Sender header field which undermines an assertion of figuring out if the "d=" domain took responsibility for the content. DMARC was promoted by bulk senders who continue to ignore broadband provider's (ab)use of DMARC now affecting millions who must routinely examine their spam folder for errant message placement. DMARC also continues a mistake made by DKIM that non-negotiated message structure is somehow assured validated by a store-and-forward transport. A mistake still leveraged in phishing attacks; perhaps even fine tuned with use of DMARC feedback, since Botnets have automated DMARC deployment. DMARC does indeed discourage phishing abuse of transactional messages. When (ab)used elsewhere, it exposes mailing-list member privacy without those so exposed ever sending a single message. Malefactors can subscribe to mailing-lists and subsequently toggle their DMARC assertions. DMARC feedback given to these malefactors allows gleaning of otherwise private subscription information. While not all feedback is returned, malefactors can easily differentiate local policy results based on DMARC count offsets, offering malefactors far better insight into their proficiencies. The sheer might of broadband providers undermines Author roles of the From header field when incorrectly assumed also playing the role of Sender. The only sure escape for non-transactional services is to abandon From header field's assured role of Author and to seek headers so defined but not (ab)used by transactional services. Rather than using a complex encapsulation scheme not needed when the mailing-list is well managed, defining a different header should offer a less complex and more immediate solution without broadband provider cooperation. DMARC with DKIM does not determine whether a domain took responsibility. DMARC with DKIM forces an errant role of Sender on the From header field while deprecating the role of Author. Regards, Douglas Otis From nobody Wed Apr 8 16:08:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35941A9241 for ; Wed, 8 Apr 2015 16:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xxhiLaR1Ayfq for ; Wed, 8 Apr 2015 16:08:31 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 904BA1A924C for ; Wed, 8 Apr 2015 16:08:30 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t38N8RY1018261; Wed, 8 Apr 2015 19:08:27 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t38N8Riw016536; Wed, 8 Apr 2015 19:08:27 -0400 Message-Id: <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John R Levine" From: Michael Jack Assels In-reply-to: References: <20150408161906.32839.qmail@ary.lan> Comments: In-reply-to "John R Levine" message dated "08 Apr 2015 17:21:12 -0400." Date: Wed, 08 Apr 2015 19:08:27 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-08 19:08:27 EDT Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:08:33 -0000 On 08 Apr 2015 17:21:12 EDT, "John R Levine" wrote: > > Are these not well-defined rules, in the same vein that canonicalizations > > are? That's certainly the intent here. > > They are, but they're not useful in the way that the existing ones are. > > The existing ones are strict enough that everyone appears to agree that if > the signature validates, it's the same message for a pretty strict version > of "same". These say that it's a message somewhat related to the > original, but "somewhat related" isn't useful in the same binary way that > "same" is. These new well-defined rules provide a mechanical procedure for determining whether the encapsulated message body is the "same", provided that the full message is DKIM-verified. It's arguably more the "same" than a normal mailing list posting with a list trailer added, because the list trailer under these rules will belong to the list's part of the composite message. Only the headers are different, and they were going to be different anyway, given DMARC's strict requirements on the From header. MJA From nobody Wed Apr 8 16:18:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7D71A9308 for ; Wed, 8 Apr 2015 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 6wCEOG7nUjXf for ; Wed, 8 Apr 2015 16:18:44 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AF21A92FC for ; Wed, 8 Apr 2015 16:18:44 -0700 (PDT) Received: (qmail 70986 invoked from network); 8 Apr 2015 23:18:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11549.5525b753.k1504; bh=TRaVbw3WYdXKbhPoYJelRs6vctJ+QZU/0GIILuU1D4g=; b=LsUmuyQHFmuNVNRawWX309vNev9rPeDh7AZGJdtNngtvIGs1/X2l38ZKnDYh6y/sn++UXxEn5QLk6ldOGqlbM/6D5/Jr3Pniz83CFxXHUgZlZuocPV0lrnPZBnaW7mAL3FCN9xghd88r8FJS9+hjkgRR43Tdj8M/lMJCdoPNl74G2f1FsBcA11a2X2D2fuweqCs9hptzCG8QI3IIn08rw2fhW7Fj4G6lYLL3lPIUCZR2AKX5VHrJCJLcUsfjTEBJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11549.5525b753.k1504; bh=TRaVbw3WYdXKbhPoYJelRs6vctJ+QZU/0GIILuU1D4g=; b=O/2xKW440lkAtBtucHrJXOaavrZUJyTlKviS3QLgdn+PDYxzP7Pub+ksgWswhu62p1tR1JNSjDV9tK3l4gAtUbPrb6wXXPpiVNDWEAKrfrkr/o4Mm/f8Ym+O6Pv9qSVI9eabH1O5u+7QY/96ZFwm68aUVMnKJvLacGUNnXQLvYjOLpS2cPi7okyxlQ80hmZGiCEmdtWR04YmiNBO5Y7gHqKJCyOs/aQ3h0J7duxaOsVhEwYO+92vk2Q7+vTfparI Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 08 Apr 2015 23:18:42 -0000 Date: 8 Apr 2015 19:18:42 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:18:46 -0000 > These new well-defined rules provide a mechanical procedure for determining > whether the encapsulated message body is the "same", provided that the full > message is DKIM-verified. Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll DKIM verify. Can someone explain in detail how a verifier is supposed to use this new hack. Consider these two messages: a) has a one line trailer part saying "for more information about foo list see http://foolist.org" b) has a 50 line trailer explaining that my credit card has been cancelled and I need to click on this malware link immediately. Both have a valid list-whatever signature. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 8 16:35:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524991B3085 for ; Wed, 8 Apr 2015 16:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JdSpXN7FWVje for ; Wed, 8 Apr 2015 16:35:46 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 3DDD51ACD74 for ; Wed, 8 Apr 2015 16:35:46 -0700 (PDT) Received: by wgyo15 with SMTP id o15so92906108wgy.2 for ; Wed, 08 Apr 2015 16:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GArXsh/jpBPwHywJ57cIN2uUV7fGKl7xlZng5vPOB1w=; b=AfL7Bz9OsZvfQfBJxB0parG67xBDLeF9lP8jPkCrfjnMhFsA3wUHC5jvPxWnL8eaSI 2/wimryXibzHWpPPEJaMGJZgmVQqXfHxSrnNeIkrI5xdpCOP1y1LBfh9oGufuCu9P22Q 05wtvtmlwDtkQUHFBZuxZdzcv9AjHLe6zFIb4YvKx/9K35a1kuRIbIMayD1r7Rh329I5 rh5E68Lt9o8fbMp1sWdhw2W+AlZxeLo4XfjPZkOqkBsgB26jomLPFwWFlGeeRU600gW+ ZlGsJKjX1qYeym+efWekk7XoDjhIItc7+CLv02fXPbl1wnAudjKoFNm0Bka/1Z5iX0Ak dBWA== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr1112834wic.94.1428536145045; Wed, 08 Apr 2015 16:35:45 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 8 Apr 2015 16:35:44 -0700 (PDT) In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> Date: Wed, 8 Apr 2015 16:35:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=001a11c381ce796db505133efd99 Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:35:48 -0000 --001a11c381ce796db505133efd99 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 4:18 PM, John R Levine wrote: > Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll > DKIM verify. Can someone explain in detail how a verifier is supposed to > use this new hack. Consider these two messages: > > a) has a one line trailer part saying > "for more information about foo list see http://foolist.org" > > b) has a 50 line trailer explaining that my credit card has been cancelled > and I need to click on this malware link immediately. > > Both have a valid list-whatever signature. Aren't you going to run them through your spam filter regardless, so the nasty stuff will get caught anyway? Assuming the schemes in those drafts worked, both cases have a valid list-whatever signature AND a valid author signature, AND you know the (a) or (b) added bit is solely the responsibility of the list (and, conversely, you also know where the original content starts and ends). Nobody's saying it's safe in any case, but you do know who did what, and that's more than we know today. -MSK --001a11c381ce796db505133efd99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 8, 2015 at 4:18 PM, John R Levine <johnl@taugh.= com> wrote:
Yeah, I can add a= giant new MIME part of arbitrary spamminess and it'll DKIM verify.=C2= =A0 Can someone explain in detail how a verifier is supposed to use this ne= w hack.=C2=A0 Consider these two messages:

a) has a one line trailer part saying
"for more information about foo list see http://foolist.org"

b) has a 50 line trailer explaining that my credit card has been cancelled = and I need to click on this malware link immediately.

Both have a valid list-whatever signature.

Aren't you going to run them through your spa= m filter regardless, so the nasty stuff will get caught anyway?

Assu= ming the schemes in those drafts worked, both cases have a valid list-whate= ver signature AND a valid author signature, AND you know the (a) or (b) add= ed bit is solely the responsibility of the list (and, conversely, you also = know where the original content starts and ends).=C2=A0 Nobody's saying= it's safe in any case, but you do know who did what, and that's mo= re than we know today.

-MSK
--001a11c381ce796db505133efd99-- From nobody Wed Apr 8 17:12:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200171A1B72 for ; Wed, 8 Apr 2015 17:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 hFskBT2zgv2k for ; Wed, 8 Apr 2015 17:12:49 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030E71A1B6D for ; Wed, 8 Apr 2015 17:12:48 -0700 (PDT) Received: (qmail 76365 invoked from network); 9 Apr 2015 00:12:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12a4c.5525c3ff.k1504; bh=jza4UXuLUdNtnU/+USbYmLAnKyvije4Vz+YFwmiuSp8=; b=spZXCspxe4HXw+5JomfyT99oQ+HjpAYBZcBPdTK+KX/7arWylFky6FeBMSKEBjLRIpnP9xg6F8vOolAe5p+kOR/8PWewVGtu5x+b1yMu7QtoFsj2d6v8OONmIfFpTrf2ye9PTm2uIVw/JxPX7NR6X0tJInY6lVaG0xcQCB1mCpOTV/Sl7SfHREk4ySct5HX6LsgFJifsw11VQsXheCc04bSecBesr5wwX/d6QNvgl2TVwtin+A6xCKzo5S0DgT7L DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12a4c.5525c3ff.k1504; bh=jza4UXuLUdNtnU/+USbYmLAnKyvije4Vz+YFwmiuSp8=; b=etVtvLoxIHbRUxU+GbsVzK943HB1Hl7naKgwnq/VO1KBCDPdDLX8NrotjfMpEziepjE7V0IURyzvtoBH7HeH2uHEcY0+rZU1Sspot7/iei78I0cOavscGaYv1E3X01QKL64DiNQ12Yvps7D+mW9CIGupKPXBqB3LhDxKYnuhS9x14X33NJK96nmf3ErrjmhDSZ1ReqFklLV8pFmprJhEuFJthLjNc0Em9mG8khEaNgQ6OvIUqOUHMCrTMzlsVQOq Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 09 Apr 2015 00:12:47 -0000 Date: 8 Apr 2015 20:12:46 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:12:50 -0000 > Assuming the schemes in those drafts worked, both cases have a valid > list-whatever signature AND a valid author signature, AND you know the (a) > or (b) added bit is solely the responsibility of the list (and, conversely, > you also know where the original content starts and ends). Nobody's saying > it's safe in any case, but you do know who did what, and that's more than > we know today. Indeed, but I don't see why it's useful. If you're going to run stuff through content filters anyway, what's the point? This sounds like it's going to reduce to mostly whitelisting well behaved remailers, which is an approach we know large systems aren't likely to use. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 8 17:29:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121DF1A913E for ; Wed, 8 Apr 2015 17:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 W5gE8S-GcA_j for ; Wed, 8 Apr 2015 17:29:20 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id E158C1A9131 for ; Wed, 8 Apr 2015 17:29:19 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t390TJf6026266; Wed, 8 Apr 2015 20:29:19 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t390TJtx016935; Wed, 8 Apr 2015 20:29:19 -0400 Message-Id: <201504090029.t390TJtx016935@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John R Levine" From: Michael Jack Assels In-reply-to: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> Comments: In-reply-to "John R Levine" message dated "08 Apr 2015 20:12:46 -0400." Date: Wed, 08 Apr 2015 20:29:19 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-08 20:29:19 EDT Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:29:21 -0000 On 08 Apr 2015 20:12:46 EDT, "John R Levine" wrote: > > Assuming the schemes in those drafts worked, both cases have a valid > > list-whatever signature AND a valid author signature, AND you know the (a) > > or (b) added bit is solely the responsibility of the list (and, conversely, > > you also know where the original content starts and ends). Nobody's saying > > it's safe in any case, but you do know who did what, and that's more than > > we know today. > > Indeed, but I don't see why it's useful. If you're going to run stuff > through content filters anyway, what's the point? This sounds like it's > going to reduce to mostly whitelisting well behaved remailers, which is an > approach we know large systems aren't likely to use. But surely you're going to run all DMARC-OKed mail through content filters, too. The person in charge of your domain's DNS servers can't really assure me of anything except that the message I'm receiving came from your domain. Almost all the phishing and spam I see comes from compromised, legitimate, DMARC-certifiable sources. Maybe I'm safe rejecting unmediated mail that fails DMARC with p=reject, but everything else goes through content filters. So why is DMARC any more useful than these "hacks"? MJA From nobody Wed Apr 8 17:33:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3751A702C for ; Wed, 8 Apr 2015 17:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 vlf6SbwAMaTb for ; Wed, 8 Apr 2015 17:33:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD79E1A92EA for ; Wed, 8 Apr 2015 17:32:58 -0700 (PDT) Received: (qmail 78853 invoked from network); 9 Apr 2015 00:32:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13404.5525c8ba.k1504; bh=mP9XfhmB6HgSVs9fVLIEHIl1xAhGK7pbzc0RAgqWJko=; b=Uc+z/SakKdV+mt82bbTI3ob7r7TUyXQBaFn0OT7VQ1Jee8bzlNKjstz6nWOvv/Ml4CSMbjOYJEBwIQS57JTbcdw70cT9N0h4q3iyB2rTyTMHn3dpS8JVMPJRmueoVlMoFmN1FYaIua0tRgc3cOD7BKlEa6dtTwcxfmJUuSPOKoBSphJrGwrSvM/eqSjps6pGD+4Ag2ohTIvyfdBKdNIfFpe74YEGKmwrog+nUSoywNG02Vt1KQf5aF3/sMzFsgIp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13404.5525c8ba.k1504; bh=mP9XfhmB6HgSVs9fVLIEHIl1xAhGK7pbzc0RAgqWJko=; b=XB/lE7527oSdoEq9wYf2aDJim/y2vM+IvgMBCG/2XvqhVQEhG+TWvvh/NDxPMN7qzOZbbbp4GPCR3aVF03WTBtD+HggNwHNtCDBgtTXh4pjfX8/fhKCPXi7PIRpqkrjeLNTMoih5XGsS4qgEFca/GPUO6y0Yf9Zf5Xrpt0Rnib1S3bGCIW0amu6hJ4efLLmH2K+8C9KPCOOU4mnkP6r/QyTo9jMSk7Z2k/Y5w6/vvVMXXD+khr8sCFxL8DxVbQPo Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 09 Apr 2015 00:32:57 -0000 Date: 8 Apr 2015 20:32:57 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504090029.t390TJtx016935@shadrach.encs.concordia.ca> References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <201504090029.t390TJtx016935@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:33:02 -0000 > So why is DMARC any more useful than these "hacks"? Good question. As originally intended, DMARC was for mail from sources where a failure reliably meant phish. Then AOL and Yahoo repurposed it to push their support costs onto other people, and its value has been under debate ever since. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 8 18:45:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8349A1ACDD7 for ; Wed, 8 Apr 2015 18:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 8DsPWPZ-4ZpF for ; Wed, 8 Apr 2015 18:45:42 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (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 EA4721ACDD6 for ; Wed, 8 Apr 2015 18:45:41 -0700 (PDT) Received: by pdea3 with SMTP id a3so134879108pde.3 for ; Wed, 08 Apr 2015 18:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WrWudu3jMOpQZkSCfTBctw5T20+kMzqXnhDjm3Vjulw=; b=KoMLBEXnK0aOf1iqhvJ5RkrcavADnIrzz+GNrXQ+VIzjL2yIKcdfPUW7wJTd7mn7El tfiDXopQLVSjC1TuuSCuAnCEknhcUmLH1Sx0/A39L9LBboNfT4VYXhspSS1xEtNekNXf p+uhPdvN+e0WlD69lQ68amv28WxFzu4lGkc030a8Uy3u70xeo2d66YlwY2Ua/fBglRuc eJvM2n0MxpBe3hoVmOO7YKz9MXNChTxx22+eUMxC77DgYZ3AcYcbLNRD9pntWh8r8Lbm gK5P1+AhVlH2PJ+qXSEBNiaedAgTH3m8DNlXJdpIk/0rtXfZR+uqjO4eH8dDhZ24DJRK EK7Q== X-Received: by 10.68.164.161 with SMTP id yr1mr51761731pbb.22.1428543941495; Wed, 08 Apr 2015 18:45:41 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id pb2sm12591598pdb.33.2015.04.08.18.45.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 18:45:40 -0700 (PDT) Message-ID: <5525D9C0.4080007@gmail.com> Date: Wed, 08 Apr 2015 18:45:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:45:43 -0000 On 4/8/15 4:35 PM, Murray S. Kucherawy wrote: > On Wed, Apr 8, 2015 at 4:18 PM, John R Levine wrote: > >> > Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll >> > DKIM verify. Can someone explain in detail how a verifier is supposed to >> > use this new hack. Consider these two messages: >> > >> > a) has a one line trailer part saying >> > "for more information about foo list see http://foolist.org" >> > >> > b) has a 50 line trailer explaining that my credit card has been cancelled >> > and I need to click on this malware link immediately. >> > >> > Both have a valid list-whatever signature. > Aren't you going to run them through your spam filter regardless, so the > nasty stuff will get caught anyway? > > Assuming the schemes in those drafts worked, both cases have a valid > list-whatever signature AND a valid author signature, AND you know the (a) > or (b) added bit is solely the responsibility of the list (and, conversely, > you also know where the original content starts and ends). Nobody's saying > it's safe in any case, but you do know who did what, and that's more than > we know today. > > -MSK Dear Murray, What will knowing more about mailing-lists hope to solve? Why not define minimum recommendations for third-party services for avoiding mistaken assumptions made by DMARC which may result in valid messages being disrupted by reject or quarantine DMARC handling. Frankly, redefining DKIM will not solve DMARC's basic problem of confusing Author with Sender roles. The only reasonable course of action is to cede From Header field role redefinitions to DMARC based on pragmatic principles and find another header field less likely (ab)used by transactional messaging. Regards, Douglas Otis From nobody Wed Apr 8 18:47:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843B1ACDDC for ; Wed, 8 Apr 2015 18:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 d52JAtnWMW7G for ; Wed, 8 Apr 2015 18:47:41 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5CD1ACDDA for ; Wed, 8 Apr 2015 18:47:41 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id D19E6804EF for ; Wed, 8 Apr 2015 18:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1428544060; bh=gxo5dKshYfHgX5ZiDCjRfqwrd8tihHks5tlvYIw/9n4=; h=Subject:From:In-Reply-To:Date:References:To:From; b=jQyHcOY0VqHQ5XgNtkawFelvPmlKhKff94ZbcDkDE7jgMrkRORj89rcyX4iKZFMzH AE8K/C3Z9y+dQWoqb8QcnSVVZm1fdd9amiPHsA8nOOyyVW6zUrG8JzMKce48hCdrmP Zr272CU3krUFhsAfOfSHYfsh7eaV7DlG7Tfew+bw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: Date: Wed, 8 Apr 2015 18:47:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <201504090029.t390TJtx016935@shadrach.encs.concordia.ca> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:47:42 -0000 On Apr 8, 2015, at 5:32 PM, John R Levine wrote: >> So why is DMARC any more useful than these "hacks"? >=20 > Good question. As originally intended, DMARC was for mail from = sources where a failure reliably meant phish. Then AOL and Yahoo = repurposed it to push their support costs onto other people, and its = value has been under debate ever since. Also a major reason that people who were dubious about SPF policy and = extremely dubious about ADSP supported DMARC was that it has reporting = and dry run functionality. Run it in p=3Dnone mode; use the reports to = make sure that nothing breaks; if nothing breaks switch to p=3Dreject. I didn't think that anyone significant would skip the testing, reporting = and decision making steps and leap directly to intentionally breaking = email for their users their users' correspondents. Cheers, Steve From nobody Wed Apr 8 19:07:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98AE1ACE18 for ; Wed, 8 Apr 2015 19:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 2hyZqyAZewY5 for ; Wed, 8 Apr 2015 19:07:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8C61ACE16 for ; Wed, 8 Apr 2015 19:07:00 -0700 (PDT) Received: (qmail 91234 invoked from network); 9 Apr 2015 02:06:59 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Apr 2015 02:06:59 -0000 Date: 9 Apr 2015 02:06:37 -0000 Message-ID: <20150409020637.34444.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:07:02 -0000 I updated my conditional signature draft, which is now (thanks to a suggestion from Ned Freed) the mandatory tag draft. https://tools.ietf.org/html/draft-levine-dkim-conditional-01 The idea is that you have a weak signature on To, From, Date, Message-ID but not subject or body, with a new tag that says the signature is only valid if it's also signed by a specified other party, who would be the entity that you expect to forward the message. So I send a message signed like this: From: johnl@taugh.com To: dmarc@ietf.org DKIM-Signature: ...; d=taugh.com; ... ordinary good strong signature DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ... weak signature, not good yet The list does what it does to the message, and now it's signed like this: From: johnl@taugh.com To: dmarc@ietf.org DKIM-Signature: ...; d=taugh.com; ... broken strong signature DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ... weak signature, good because it's also signed by ietf.org DKIM-Signature: ...; d=ietf.org; ... new good strong signature It seems to me that this addresses the same issues that the list mutation stuff does with a lot less complication, and without having to enumerate all of the ways that a list might change the message. It only assumes that the list won't change To, From, Date, or Message-ID, which matches my list experience. The list can make arbitrary changes to the message body, but if it does, you know who to blame. As a lazy list operator, I also like the fact that it doesn't require lists to do anything different from what they should be doing now, sign their outgoing mail. Senders put additional weak signatures on mail sent to addresses that might be mailing lists, verifiers have to upgrade to understand new signatures. Note that smelling like a mailing list is not the same as whitelisting mailing lists. R's, John PS: The spec uses DKIM-Signature v=2 since mandatory tags aren't backward compatible, but can we please not go down that rathole again, at least not until we consider whether double signing is useful. From nobody Wed Apr 8 19:57:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05451B3754 for ; Wed, 8 Apr 2015 19:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 JNbYy9E6Bla4 for ; Wed, 8 Apr 2015 19:57:00 -0700 (PDT) Received: from listserv.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFC61B3751 for ; Wed, 8 Apr 2015 19:57:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3119; t=1428548215; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gDigRgimRIdvZ0MFIbJavKqpdNA=; b=kWCa4PK3KwkJA1GAmxVj IGZPYkWxVwHEGUwdN17ixQtcvdy3RwUIDqt/vD7NyVhhwftmAYMSTq4puujEcXm2 AcxRT8BbQrti4hjqbMikQYRJuEEtFGu/FrxgLJ+eToWhozYAnlT1oHiSICRQSiqZ f7i2AKuGfRXsYpHNi2A/j6A= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 08 Apr 2015 22:56:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2258235210.603.3428; Wed, 08 Apr 2015 22:56:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3119; t=1428547991; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yoycYtG lb69u6YC0acJwiPx4l3XAAJtz+6Qtuy0IBOg=; b=Vn4uBQnKApB9U0wqEgyqsGt ihpX7hg0rR4qGIgZchGWgsCXn++/puLZ/g6VKb0gxPiqwgR9HiofDHEIxWtk0bwu A4Rsa1bGtSYtKeKDKqIj/UOTmFd38N6C2F9JcDqgOBklSGdGhL4vJX1IygFcbLth QKfI7Am7QsmM79qx3O0I= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 08 Apr 2015 22:53:11 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 850526848.9.6956; Wed, 08 Apr 2015 22:53:10 -0400 Message-ID: <5525EA77.7070303@isdg.net> Date: Wed, 08 Apr 2015 22:56:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150409020637.34444.qmail@ary.lan> In-Reply-To: <20150409020637.34444.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:57:03 -0000 On 4/8/2015 10:06 PM, John Levine wrote: > I updated my conditional signature draft, which is now (thanks to a > suggestion from Ned Freed) the mandatory tag draft. > > https://tools.ietf.org/html/draft-levine-dkim-conditional-01 > > The idea is that you have a weak signature on To, From, Date, > Message-ID but not subject or body, with a new tag that says the > signature is only valid if it's also signed by a specified other > party, who would be the entity that you expect to forward the message. > > So I send a message signed like this: > > From: johnl@taugh.com > To: dmarc@ietf.org > DKIM-Signature: ...; d=taugh.com; ... ordinary good strong signature > DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ... weak signature, not good yet > > The list does what it does to the message, and now it's signed like this: > > From: johnl@taugh.com > To: dmarc@ietf.org > DKIM-Signature: ...; d=taugh.com; ... broken strong signature > DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ... weak signature, good because it's also signed by ietf.org > DKIM-Signature: ...; d=ietf.org; ... new good strong signature Good idea. The outbound signer will create two signatures; a weak 1st party to satisfy the DMARC alignment, and the 2nd signature has a "@fs=" tag identifying the PENDING authorized 3rd party signer. The 3rd party signer will do its natural thing and sign the mail as a 3rd party signer. However, it MUST KEEP the other signatures. Do not remove the previous signatures, in particular the weak 1st party signature. The receiver will now have two signatures: - 1st party signature with @fs pointing to the 3rd party signature. - 3rd party signature New DMARC receivers following this idea will check for a two signatures requirement in order to pass this test. The 1st party authorizes the 3rd party with the @fs= tag. Old DMARC receivers SHOULD NOT fail because it sees a valid WEAK first party signature. However, depending on the implementation it COULD see a 3rd party signature as an violation of the exclusive DKIM 1st party only signing requirement. In other words, there should be no "Indirect" indicators in the mail. Having a 3rd party signature MAY/CAN BE leveraged for bad mail, unexpected "indirect" mail filtering. Across the board, unlike ATPS, this idea has more change requirements at signers, receivers and also MLS software to make sure they do not strip the weak 1st party signature. For the signers, like ATPS, there is still a scale problem here for the big guys with thousands of list domains. How will the signing machines determine which messages are for list domains? Overall, its a good idea, but its still a lot of work, more so than ATPS requires. This idea requires the signers, receiver and the MLS to adapt to new rules. I still think it is easier for the domain to publish a 3rd party authorization record and for any receiver to do 3rd party signature DNS authorization checks w/o 1st party records. No overhead and complexity in DKIM signing and receiver machine change required. -- HLS From nobody Wed Apr 8 20:14:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD981B2BA6 for ; Wed, 8 Apr 2015 20:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.602 X-Spam-Level: X-Spam-Status: No, score=-99.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 NI5HGPpzoKH9 for ; Wed, 8 Apr 2015 20:14:30 -0700 (PDT) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF01B2BA5 for ; Wed, 8 Apr 2015 20:14:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2195; t=1428549260; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=AS9QQp+habQ7HaxT+Uwc/yFszEQ=; b=AsheDNh73JFD+xMBeszc hYZOdKqU0HaFvus9o4nR0eSk4H4phY/13YwZU3j9qOfgq3FzmXYYq02AsP21+wBL /L9b+f+eG357Oo+wVTBRonlIbXVDHhfxTLo657UKaJFbacZV0ZxrR9Ev1PSIonov +3YYV9gG0UHWqo/sLOrtD8E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 08 Apr 2015 23:14:20 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2259280214.603.5032; Wed, 08 Apr 2015 23:14:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2195; t=1428549034; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FKpCWeC 1gTPZCW7J+wjYwXgPXmeyx94fF0yxODIaZiM=; b=r2m2rgXsgc1L+1T9nsHhQRN bm0IVY7CCmKfSZWUhEq0taWDDcb6pNesu0AJ0IuxqV/zRZySCosMYTBrL0GAuL1D VqIatqmyMcMjiS3z5cRLZ6uyXzKIo37P67Z0vYw0rgGEimS9vh3ruW5+Hds/Ps/7 TYpOyQq6x1VCZlA/UuuA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 08 Apr 2015 23:10:34 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 851570207.9.9892; Wed, 08 Apr 2015 23:10:33 -0400 Message-ID: <5525EE8B.9090405@isdg.net> Date: Wed, 08 Apr 2015 23:14:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <201504090029.t390TJtx016935@shadrach.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 03:14:31 -0000 On 4/8/2015 9:47 PM, Steve Atkins wrote: > > On Apr 8, 2015, at 5:32 PM, John R Levine wrote: > >>> So why is DMARC any more useful than these "hacks"? >> >> Good question. As originally intended, DMARC was for mail from sources where a failure reliably meant phish. Then AOL and Yahoo repurposed it to push their support costs onto other people, and its value has been under debate ever since. > > Also a major reason that people who were dubious about SPF policy and extremely dubious about ADSP supported DMARC was that it has reporting and dry run functionality. Run it in p=none mode; use the reports to make sure that nothing breaks; if nothing breaks switch to p=reject. > > I didn't think that anyone significant would skip the testing, reporting and decision making steps and leap directly to intentionally breaking email for their users their users' correspondents. > I don't think this is a fair assessment. Obviously for many, it was expected for a DKIM+POLICY to prevail in the market place where publishers will expose strong rejection policies and receivers will begin to honor it. DKIM+POLICY (ADSP) was a standard track IETF WG work item with many RFC documents produced. Investments were done. APIs were written. After all, Yahoo invented the idea with Domainkeys with its built-in "o=" policy tag, so we should not be surprise Yahoo was also the first to finally enable it abeit after 10 years evolution to DKIM+DMARC. What ADSP did not have was a reporting feature. It might had changed its fate. DMARC is fundamentally no different than ADSP otherwise. DKIM+ATPS should not be a problem for most domains. Not everyone is a YAHOO and even then, I don't think they should have a problem managing "50,000" list domain records, if that is their maximum exposure to this. If you look at the ideas, ATPS is the least expensive. All the others have the same scale issue for the domain needing to authorize a larger list of domains. And they also have a higher change requirement at three locations; signers, receivers and middle ware. In Levine's idea, the middle ware MUST NOT remove the weak 1st party signature. -- HLS From nobody Wed Apr 8 21:54:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5181AC415 for ; Wed, 8 Apr 2015 21:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ppS1p9uaT5yL for ; Wed, 8 Apr 2015 21:54:29 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (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 79F841A1B2A for ; Wed, 8 Apr 2015 21:52:30 -0700 (PDT) Received: by wgsk9 with SMTP id k9so85404072wgs.3 for ; Wed, 08 Apr 2015 21:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j3fUQ1Z78gf9A0Ev9Scj8CBL1tHTY85Skm/lBm4XwXE=; b=p5OmvnxlfUetUxFrGL6VphGdBzcdAOU292Zfhkg+mCNc5l7LaaIU1ofwu7BNO8IqPy Xk6rSynESo9fd9v+5rR6atcS4XR/eRYACwNv248SBYzjXnVUKLdMbc5kNBCkVNtSsDaI I/15yWr1OgPTsBbiF8w5KUH82p3SNQendWeX4AxO4xUk0jLvpBvCNMdvIlppWaE26wFl NSYR494++KziYfjIb+mjWtcXlp+8dTTrA2oQyIc3FL4vynW8GR4IC/fdeqcL9trkK8Fp pu2LQqxKN1kPEykE9YW9/lUzh9iezCh9IVsViCxGb89jzKj3O+r5vqBrWoGfdu2s4o6r tZJQ== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr55132938wjc.111.1428555149219; Wed, 08 Apr 2015 21:52:29 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 8 Apr 2015 21:52:29 -0700 (PDT) In-Reply-To: <20150409020637.34444.qmail@ary.lan> References: <20150409020637.34444.qmail@ary.lan> Date: Wed, 8 Apr 2015 21:52:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7bacb11e361d3b0513436a88 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 04:54:30 -0000 --047d7bacb11e361d3b0513436a88 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: > I updated my conditional signature draft, which is now (thanks to a > suggestion from Ned Freed) the mandatory tag draft. > > https://tools.ietf.org/html/draft-levine-dkim-conditional-01 > > [...] > Well, I'm game to try. Adjustments to the parsing engine should be fairly simple, and a couple of extra steps to notice and resolve the forward reference will be needed. And maybe some extra return codes. I'd use "!" instead of "@", I think, as an indication of their importance when observed visually, but that's rather a minor point. The first thing that hits me: Do we have to be specific about what's meant by "weak"? How does the verifier decide if it's "weak enough" or perhaps "too weak"? -MSK --047d7bacb11e361d3b0513436a88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 8, 2015 at 7:06 PM, John Levine <johnl@taugh.co= m> wrote:
I updated my conditional signature dra= ft, which is now (thanks to a
suggestion from Ned Freed) the mandatory tag draft.

https://tools.ietf.org/html/draft-levine-dkim-conditional-0= 1

[...]

Well, I'm game to try.=C2= =A0 Adjustments to the parsing engine should be fairly simple, and a couple= of extra steps to notice and resolve the forward reference will be needed.= =C2=A0 And maybe some extra return codes.=C2=A0 I'd use "!" i= nstead of "@", I think, as an indication of their importance when= observed visually, but that's rather a minor point.

= The first thing that hits me: Do we have to be specific about what's me= ant by "weak"?=C2=A0 How does the verifier decide if it's &qu= ot;weak enough" or perhaps "too weak"?

-MS= K
--047d7bacb11e361d3b0513436a88-- From nobody Thu Apr 9 05:10:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DDE1A19F4 for ; Thu, 9 Apr 2015 05:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 BXOAjSSp-ki2 for ; Thu, 9 Apr 2015 05:10:26 -0700 (PDT) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D30B91A19EC for ; Thu, 9 Apr 2015 05:10:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3442; t=1428581415; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=5dhAK3SsCsLeeOfQyiW+gcDn5Cs=; b=OgEsqX3BbRCeaxQHHOzj k9cwFtF4auPicgxmqb53CVnY9gqWWyf7W9EvWxJtbaed6krwAOmmrWx1Q3POKpsx OrPw7pzz34KHto2Q25npI805Z90zLrATi7NmAzrbmhmQEfhNnXlX3WEF0K6Z0gvB 4XyM9+n/e9zITHTyqTCruGg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 08:10:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2291435562.3150.4264; Thu, 09 Apr 2015 08:10:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3442; t=1428581193; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=X1kFwC3 SyXmvYPuxQAEO3ULLr04Rm6+8FlQX4rFtCFI=; b=rHJTgXzYLZlzKBU+y/bk/Eu wfVV6JA+n6uvogJtrSV5YWwU4WF6fwf/GF7izMAhFJrLMCIpv3ORWB895I8xnQOk 3bv/OBWl0dm98b6Tp9hu4FkqlmG0G+1MfZba+7sjr2L8cjHIgfDHK4gY0KisUYJM I3RKtd/78pirEUEK7O5Q= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 08:06:33 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 883728941.9.5816; Thu, 09 Apr 2015 08:06:32 -0400 Message-ID: <55266C2B.4040708@isdg.net> Date: Thu, 09 Apr 2015 08:10:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <20150409020637.34444.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 12:10:32 -0000 Fairly simple? I'm not sure about that. 1) The signer engine needs to do two signatures now. This will be a major code change, more outbound signing overhead. There is still that so called scalability, "big data" problem. How will the "YAHOOs" scale this? A database is still needed of which domains will have an outbound mail stream with two signatures. Some how the list domains will still need to register with the Yahoos and tell the Yahoos, "Please send us two signatures authorizing out list domain." I would like to call this a "registration" problem because thats seems to be the area of disagreement as a real problem. 2) Two (actually all) receivers now have to comply; the MLM MDA receiver (middle ware) and the final User MDA receivers. All middle ware MUST NOT strip the weak 1st party signature. All this is not fairly simple changes. The idea has the same end result for 3rd party authorization with more complex calculations at all points; signers, middle ware and receivers. This is far more complex than a simple DNS lookup of the ADID/SDID at the receivers satisfying the same end result question -- "Does the ADID authorize the SDID as a signer?" Are we trying to skip the DNS part from the solution of all this? I would like to ask the chairs, if the Indirect Mail Interop report including further explorations into ATPS and TPA, then why is that not happening, and who will do it? Obviously, Murray is showing his disinterest in completing the DKIM ATPS work. The IETF should present all the solutions in this complicated project. Compared to what being proposed with this idea and Murray's other two ideas, the DNS lookup method is still a viable option, if only, to be included in the total solution pack: DKIM+DMARC+ATPS as a faster, optimized, least change approach, more proven in the market place with APIs already set to do the ADID lookup. DKIM+DMARC "In-band" method, such as Levine's @FS= idea for, I guess, for the customers out there that, for some reason, want a more complex DKIM engine in signing and verifying in order to do the same thing, perhaps because they have problems interacting with their DNS administration requirements? Even if this dual signature @FS= approach goes forward, the software change requirements will allow for an optimized DNS authorization lookup method to be included. -- HLS On 4/9/2015 12:52 AM, Murray S. Kucherawy wrote: > On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: > >> I updated my conditional signature draft, which is now (thanks to a >> suggestion from Ned Freed) the mandatory tag draft. >> >> https://tools.ietf.org/html/draft-levine-dkim-conditional-01 >> >> [...] >> > > Well, I'm game to try. Adjustments to the parsing engine should be fairly > simple, and a couple of extra steps to notice and resolve the forward > reference will be needed. And maybe some extra return codes. I'd use "!" > instead of "@", I think, as an indication of their importance when observed > visually, but that's rather a minor point. > > The first thing that hits me: Do we have to be specific about what's meant > by "weak"? How does the verifier decide if it's "weak enough" or perhaps > "too weak"? > > -MSK > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Thu Apr 9 05:28:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F971A89FF for ; Thu, 9 Apr 2015 05:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GL1LuNKir4Hg for ; Thu, 9 Apr 2015 05:28:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 2F3D11A899B for ; Thu, 9 Apr 2015 05:28:41 -0700 (PDT) Received: by wizk4 with SMTP id k4so90324887wiz.1 for ; Thu, 09 Apr 2015 05:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=29S1i6SILhXlz/hcGohht4+Mz4pDMpunGp291FzItOg=; b=QbWeCzNBu4SpsbHiA6JO/cuzr0ptDrxTfKcrGhgNGDEeC4FkomCOIpJGygkW4wtTOU 9tkF2BJcDsPAu3ERm8f+MS224P9tAsTv+OTAjHaYshIz60e5FhkgkAF9R9ZyWio9AF8G YPwXZeYvXHeMN1x0VuboeoKe3+ZGWTRqW2BmB3NQlUwecJKfUTfVYVOC6EHo39GsYxxm Uzc1NUsHw67PiKOkkrO7CwJU77cYDtreoBaagTrgUJD52pGwIEW3mhEZCLR+GqoP6WA4 WTda5Mm/i/Giov6Ut3pwFMn2jiVfk7BvZPfw0J1LdsE1tydbLjrsUz9l0m2+3xuNGymk /6MA== MIME-Version: 1.0 X-Received: by 10.180.77.166 with SMTP id t6mr6010083wiw.52.1428582519962; Thu, 09 Apr 2015 05:28:39 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 9 Apr 2015 05:28:39 -0700 (PDT) In-Reply-To: <20150409020637.34444.qmail@ary.lan> References: <20150409020637.34444.qmail@ary.lan> Date: Thu, 9 Apr 2015 05:28:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d043d645fa28229051349c9f5 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 12:28:43 -0000 --f46d043d645fa28229051349c9f5 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: > It seems to me that this addresses the same issues that the list > mutation stuff does with a lot less complication, and without having > to enumerate all of the ways that a list might change the message. It > only assumes that the list won't change To, From, Date, or Message-ID, > which matches my list experience. The list can make arbitrary changes > to the message body, but if it does, you know who to blame. > That last sentence is basically what I said about both of my drafts, and that logic was shot down. Once you've decided you don't like the arbitrary changes, you know who to blame, but you still have to decide what you like and what you don't. > As a lazy list operator, I also like the fact that it doesn't require > lists to do anything different from what they should be doing now, > sign their outgoing mail. Senders put additional weak signatures on > mail sent to addresses that might be mailing lists, verifiers have to > upgrade to understand new signatures. Note that smelling like a > mailing list is not the same as whitelisting mailing lists. > "might be mailing lists" sounds like a place for heuristics. How would you identify an address that might be a list, or content that's likely destined for a list? The "-l" suffix isn't that common these days. -MSK --f46d043d645fa28229051349c9f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 8, 2015 at 7:06 PM, John Levine <johnl@taugh.co= m> wrote:
It seems to me that this addresses the= same issues that the list
mutation stuff does with a lot less complication, and without having
to enumerate all of the ways that a list might change the message.=C2=A0 It=
only assumes that the list won't change To, From, Date, or Message-ID,<= br> which matches my list experience.=C2=A0 The list can make arbitrary changes=
to the message body, but if it does, you know who to blame.

That last sentence is basically what I said about both= of my drafts, and that logic was shot down.=C2=A0 Once you've decided = you don't like the arbitrary changes, you know who to blame, but you st= ill have to decide what you like and what you don't.
=C2=A0
As a lazy list operator, I also like the fact that it doesn't require lists to do anything different from what they should be doing now,
sign their outgoing mail.=C2=A0 Senders put additional weak signatures on mail sent to addresses that might be mailing lists, verifiers have to
upgrade to understand new signatures.=C2=A0 Note that smelling like a
mailing list is not the same as whitelisting mailing lists.

"might be mailing lists" sounds like a place= for heuristics.=C2=A0 How would you identify an address that might be a li= st, or content that's likely destined for a list?=C2=A0 The "-l&qu= ot; suffix isn't that common these days.

-MSK
--f46d043d645fa28229051349c9f5-- From nobody Thu Apr 9 06:24:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A321C1A1AC6 for ; Thu, 9 Apr 2015 06:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HKO47YRXYTdJ for ; Thu, 9 Apr 2015 06:24:46 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 785281A1A7C for ; Thu, 9 Apr 2015 06:24:46 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t39DOiMu012602 for ; Thu, 9 Apr 2015 09:24:45 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t39DOi15020560 for ; Thu, 9 Apr 2015 09:24:44 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: "dmarc@ietf.org" In-reply-to: Your message of Thu, 09 Apr 2015 08:10:19 EDT References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Thu, 09 Apr 2015 09:24:44 -0400 Message-ID: <20559.1428585884@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-09 09:24:45 EDT Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:24:50 -0000 Hector Santos writes: > A database is still needed of which domains will have an > outbound mail stream with two signatures. Some how the list domains > will still need to register with the Yahoos and tell the Yahoos, > "Please send us two signatures authorizing out list domain." I > would like to call this a "registration" problem because thats seems > to be the area of disagreement as a real problem. I have to agree; if this is the case, to me, it is a show-stopper. The genius of the DKIM and SPF and DMARC approaches is that they are DNS-based, and thus completely decentralized. The idea that lists would have to register with the e-mail providers of all of their contributors, or that I as a (very small!) e-mail provider would have to figure out what is and isn't a list, doesn't scale. I have not yet taken the time to fully understand the "weak and strong signatures" idea, but if I may be forgiven for commenting anyway: could the above problem be solved by having "original" signers always supply various forms of signature (without needing to figure out if the receiver address is a list), and having "intermediate" signers (such as mailing lists) add more signatures as described in the draft? A message that arrives with only the "original" signatures would be checked against the strong one, and a message that arrives with "additional" signatures would be checked as per the draft. Of course, if the idea of specifically setting up a third-party trust is crucial to the proposal, then my suggestion is useless, and the "registration problem" is not solvable. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Thu Apr 9 07:17:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7901A6EDC for ; Thu, 9 Apr 2015 07:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 lIuLCTDEN-8p for ; Thu, 9 Apr 2015 07:17:24 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 526F41A3B9B for ; Thu, 9 Apr 2015 07:17:23 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3lN4L91GQgz5Mgff; Thu, 9 Apr 2015 16:17:21 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3lN4L86Rmyz1LBMt; Thu, 9 Apr 2015 16:17:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 85DEC12341F; Thu, 9 Apr 2015 16:17:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5dKoCa5Yw7kE; Thu, 9 Apr 2015 16:17:18 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 4C8CC123408; Thu, 9 Apr 2015 16:17:18 +0200 (CEST) Message-ID: <552689EE.4090408@sonnection.nl> Date: Thu, 09 Apr 2015 16:17:18 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anne Bennett , "dmarc@ietf.org" References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> In-Reply-To: <20559.1428585884@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1428589041; bh=blGmCcIW8XTH9FbvPWFJTHqpOkAuIUl3XODVa9Nis3s=; h=Message-ID:Date:From:To:Subject:From; b=R/MOpcyck+KANC2J8b2u7oypMvo/2cWeGe2USXd7JLVzLtcmhlEAZ5bkxKBQ9ElcR wDR4GkjIALTpCcAe5CjuRMqbQwarE3tjeDjh22YyFCMLfTQv/oGOR/9LrKotzxkg3F VbQnoL5zGzGfQa1NN5meU7/PBXsNpecpb2U7W8Hk= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3lN4L91GQgz5Mgff Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:17:27 -0000 On 04/09/2015 03:24 PM, Anne Bennett wrote: > Hector Santos writes: > >> A database is still needed of which domains will have an >> outbound mail stream with two signatures. Some how the list domains >> will still need to register with the Yahoos and tell the Yahoos, >> "Please send us two signatures authorizing out list domain." I >> would like to call this a "registration" problem because thats seems >> to be the area of disagreement as a real problem. > I have to agree; if this is the case, to me, it is a > show-stopper. The genius of the DKIM and SPF and DMARC > approaches is that they are DNS-based, and thus completely > decentralized. The idea that lists would have to register with > the e-mail providers of all of their contributors, or that I > as a (very small!) e-mail provider would have to figure out > what is and isn't a list, doesn't scale. This can be solved by having the owners of mailing lists publish a yet-to-be-defined DNS record in which they proclaim the presence of a mailing list within that domain. I'm contemplating to write a draft for this, as more than one of the suggested solutions to the mailing list problem might benefit from this. Having said that, I don't like the idea of designing all sorts of auxilliary technologies to solve the problems introduced by DMARC, or better said: if we'd come up with such helper technologies we should try to address as many use cases, presented in [1], as possible. If we do not, at the the end of the day we'll have created a myriad of new technologies, considerably increased the complexity of the e-mail ecosystem worldwide with a net result of zero as long as senders still treat p=reject as p=none/quarantine. /rolf [1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt From nobody Thu Apr 9 07:52:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0121A90B0 for ; Thu, 9 Apr 2015 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 LlGXUr-Y0a_b for ; Thu, 9 Apr 2015 07:52:10 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A281B2D80 for ; Thu, 9 Apr 2015 07:51:38 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 10:51:37 -0400 From: "MH Michael Hammer (5304)" To: "R.E.Sonneveld@sonnection.nl" , Anne Bennett , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Updated mandatory tag/conditional signature draft Thread-Index: AQHQcmngFWtiSiGFV0WBjoxSq49yw51EYDCAgAB6VYD//9HI0oAAUbIA///FTbA= Date: Thu, 9 Apr 2015 14:51:37 +0000 Message-ID: References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> In-Reply-To: <552689EE.4090408@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.220] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:52:16 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Rolf E. > Sonneveld > Sent: Thursday, April 09, 2015 10:17 AM > To: Anne Bennett; dmarc@ietf.org > Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature dra= ft >=20 > On 04/09/2015 03:24 PM, Anne Bennett wrote: > > Hector Santos writes: > > > >> A database is still needed of which domains will have an outbound > >> mail stream with two signatures. Some how the list domains will > >> still need to register with the Yahoos and tell the Yahoos, > >> "Please send us two signatures authorizing out list domain." I > >> would like to call this a "registration" problem because thats seems > >> to be the area of disagreement as a real problem. > > I have to agree; if this is the case, to me, it is a show-stopper. > > The genius of the DKIM and SPF and DMARC approaches is that they are > > DNS-based, and thus completely decentralized. The idea that lists > > would have to register with the e-mail providers of all of their > > contributors, or that I as a (very small!) e-mail provider would have > > to figure out what is and isn't a list, doesn't scale. >=20 > This can be solved by having the owners of mailing lists publish a yet-to= -be- > defined DNS record in which they proclaim the presence of a mailing list > within that domain. I'm contemplating to write a draft for this, as more = than > one of the suggested solutions to the mailing list problem might benefit > from this. >=20 How does this solve anything? What prevents non-owners of mailing lists pro= claiming the presence of a mailing list within "that" domain? What prevents= malicious individuals setting up a mailing list and proclaiming it? > Having said that, I don't like the idea of designing all sorts of auxilli= ary > technologies to solve the problems introduced by DMARC, or better said: i= f > we'd come up with such helper technologies we should try to address as > many use cases, presented in [1], as possible. If we do not, at the the e= nd of > the day we'll have created a myriad of new technologies, considerably > increased the complexity of the e-mail ecosystem worldwide with a net > result of zero as long as senders still treat p=3Dreject as p=3Dnone/quar= antine. >=20 You will never avoid "local policy" - that is reality. As an aside, don't y= ou mean " as long as VALIDATORS still treat p=3Dreject as p=3Dnone/quaranti= ne." From nobody Thu Apr 9 08:29:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029B71A92AC for ; Thu, 9 Apr 2015 08:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 GW7YrgeSf5vd for ; Thu, 9 Apr 2015 08:29:19 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33D1A9236 for ; Thu, 9 Apr 2015 08:29:19 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3lN5xB0HFSz5Mgff; Thu, 9 Apr 2015 17:29:18 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3lN5x95nKHz1LBN4; Thu, 9 Apr 2015 17:29:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 748291234D5; Thu, 9 Apr 2015 17:29:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AABGFiRPGtfs; Thu, 9 Apr 2015 17:29:14 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 65B8A1234C8; Thu, 9 Apr 2015 17:29:14 +0200 (CEST) Message-ID: <55269AC9.8050405@sonnection.nl> Date: Thu, 09 Apr 2015 17:29:13 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "MH Michael Hammer (5304)" , Anne Bennett , "dmarc@ietf.org" References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1428593358; bh=7k+yp7du2YZ2vBb2BHPP9nE+SP/YRLk5cHablRHmxHo=; h=Message-ID:Date:From:To:Subject:From; b=V/C0jjpvefzXWintwkEptOewkk09ThKrsN4NxFvEUoKfi2Go4nTnv9ey8iugHc5cO aWCNGBCSGGeFdUPMbq2NjQmVreP/gAaa+C1IL2I7WqfwEZphV79Y/EjK9GWesbQbZE 2TFNogg4mZ0ie6slrUixDy8aRChY3hxh3Lk3a1fQ= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3lN5xB0HFSz5Mgff Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 15:29:21 -0000 On 04/09/2015 04:51 PM, MH Michael Hammer (5304) wrote: > >> -----Original Message----- >> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Rolf E. >> Sonneveld >> Sent: Thursday, April 09, 2015 10:17 AM >> To: Anne Bennett; dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft >> >> On 04/09/2015 03:24 PM, Anne Bennett wrote: >>> Hector Santos writes: >>> >>>> A database is still needed of which domains will have an outbound >>>> mail stream with two signatures. Some how the list domains will >>>> still need to register with the Yahoos and tell the Yahoos, >>>> "Please send us two signatures authorizing out list domain." I >>>> would like to call this a "registration" problem because thats seems >>>> to be the area of disagreement as a real problem. >>> I have to agree; if this is the case, to me, it is a show-stopper. >>> The genius of the DKIM and SPF and DMARC approaches is that they are >>> DNS-based, and thus completely decentralized. The idea that lists >>> would have to register with the e-mail providers of all of their >>> contributors, or that I as a (very small!) e-mail provider would have >>> to figure out what is and isn't a list, doesn't scale. >> This can be solved by having the owners of mailing lists publish a yet-to-be- >> defined DNS record in which they proclaim the presence of a mailing list >> within that domain. I'm contemplating to write a draft for this, as more than >> one of the suggested solutions to the mailing list problem might benefit >> from this. >> > How does this solve anything? At least it could help in discovering what domains potentially houses a mailing list. Whether to trust this assertion is something different. I can imagine ESPs could combine this information with information they already have about mailing lists (Yahoo once claimed there were only 30,000 of them, so one way or another they already had some list of mailing lists?). > What prevents non-owners of mailing lists proclaiming the presence of a mailing list within "that" domain? What prevents malicious individuals setting up a mailing list and proclaiming it? Nothing at all. But the same holds true for registering with the e-mail providers. Actually, publishing a DNS record might be seen as a submission for registration with the sender. The sending domain still determines whether to accept that registration (and use @fs=domain) or not. > >> Having said that, I don't like the idea of designing all sorts of auxilliary >> technologies to solve the problems introduced by DMARC, or better said: if >> we'd come up with such helper technologies we should try to address as >> many use cases, presented in [1], as possible. If we do not, at the the end of >> the day we'll have created a myriad of new technologies, considerably >> increased the complexity of the e-mail ecosystem worldwide with a net >> result of zero as long as senders still treat p=reject as p=none/quarantine. >> > You will never avoid "local policy" - that is reality. As an aside, don't you mean " as long as VALIDATORS still treat p=reject as p=none/quarantine." Yes, sorry, you're right: that should be 'validators'. /rolf From nobody Thu Apr 9 11:25:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0081B30BD for ; Thu, 9 Apr 2015 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 JX1dWrLy50B2 for ; Thu, 9 Apr 2015 11:25:29 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7DE1B30BA for ; Thu, 9 Apr 2015 11:25:28 -0700 (PDT) Received: (qmail 40103 invoked from network); 9 Apr 2015 18:25:27 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Apr 2015 18:25:27 -0000 Date: 9 Apr 2015 18:25:05 -0000 Message-ID: <20150409182505.1094.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:25:30 -0000 >That last sentence is basically what I said about both of my drafts, and >that logic was shot down. Once you've decided you don't like the arbitrary >changes, you know who to blame, but you still have to decide what you like >and what you don't. Yeah, now that I look at your drafts again, I see that we are both making the same assertion that this message is a mutated version of one that someone else sent. I still like mine better because trying to enumerate all of the possible kinds of changes doesn't work very well, e.g., subject tags and per-recipient S/MIME encryption. (Sympa can do the latter.) >"might be mailing lists" sounds like a place for heuristics. How would you >identify an address that might be a list, or content that's likely destined >for a list? The "-l" suffix isn't that common these days. Looking at my DMARC reports from Gmail, the tags suggest they have a pretty good idea of where the lists are. It doesn't have to be perfect, just avoid sending the weak signature to recipients who are likely to be malicious. Re other notes, there's no need to define what a "weak" signature is, since the conditional signature is an ordinary DKIM signature that is verified in the usual way, give or take the new @fs tag. It's up to the original signer how much latitude it wants to give forwarders. R's, John PS: for @ vs !, I think the bike shed would look great in a dusky rose with mocha-taupe trim. From nobody Thu Apr 9 11:27:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2359B1A87E1 for ; Thu, 9 Apr 2015 11:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 pr18BCZQbHdN for ; Thu, 9 Apr 2015 11:27:52 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF48B1A6FFC for ; Thu, 9 Apr 2015 11:27:51 -0700 (PDT) Received: (qmail 40559 invoked from network); 9 Apr 2015 18:27:50 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Apr 2015 18:27:50 -0000 Date: 9 Apr 2015 18:27:28 -0000 Message-ID: <20150409182728.1115.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <20559.1428585884@vindemiatrix.encs.concordia.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:27:56 -0000 >> A database is still needed of which domains will have an >> outbound mail stream with two signatures. Sorry, no, that's completely wrong. Please reread the draft. >I have not yet taken the time to fully understand the "weak and >strong signatures" idea, but if I may be forgiven for commenting >anyway: could the above problem be solved by having "original" >signers always supply various forms of signature (without >needing to figure out if the receiver address is a list), and >having "intermediate" signers (such as mailing lists) add more >signatures as described in the draft? No, the problem is that the intermediate signer has changed the message in a way that breaks normal signatures. You wouldn't want to accept a weak signature on its own, since then any malicious third party could have rewritten the messsage, not just the intended recipient. R's, John From nobody Thu Apr 9 11:29:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD11A8841 for ; Thu, 9 Apr 2015 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 hK5CUPtF99CP for ; Thu, 9 Apr 2015 11:29:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798251A8830 for ; Thu, 9 Apr 2015 11:29:47 -0700 (PDT) Received: (qmail 40820 invoked from network); 9 Apr 2015 18:29:46 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Apr 2015 18:29:46 -0000 Date: 9 Apr 2015 18:29:24 -0000 Message-ID: <20150409182924.1136.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <552689EE.4090408@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: R.E.Sonneveld@sonnection.nl Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:29:48 -0000 >This can be solved by having the owners of mailing lists publish a >yet-to-be-defined DNS record in which they proclaim the presence of a >mailing list within that domain. That's unlikely to work, because malicious people can publish anything that legitimate lists can. There's a fundamental rule that anything you publish about yourself can only decrease other people's opinion of mail that appears to be from you, not increase it. DMARC, for example, is all about saying mail that appears to be from you actually isn't. R's, John From nobody Thu Apr 9 11:36:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027E91A8854 for ; Thu, 9 Apr 2015 11:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_54=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 a2O3oAN9QAOj for ; Thu, 9 Apr 2015 11:36:30 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD291A8864 for ; Thu, 9 Apr 2015 11:36:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4664; t=1428604586; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zMsrcWZCzU+CXkalS+F05lXj9bI=; b=pAgsTXuGefDy+jQ6JD05 A1fD4QgiaVVSquKJg6H+Yh0Jy6PcBzDbNqALKlvzyI+PWx2zpJjEWBZ9C4OFwK5G H3ueqMturuiJ0NKPkW/OLDzkeIzGNY5i4HkTLFevH43cyaYebSDgYJSJyem02c1x 0SVkHCZuMgLdd20VcWc5bXA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 14:36:26 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2314606047.3150.5740; Thu, 09 Apr 2015 14:36:25 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4664; t=1428604360; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kAEbBJx lYqSvu8djKDpj/LhXLE/GNW0DtMbQLvV/Kx0=; b=hnLb4T4wqcfs553qSFSQNXk Yh7Hias/2Kjg/Prq4uBE29yDCJsOZS1hLMbVYDFvmMMR435GEtmJNdHThNXNvnmH xsZmtdnYxsh2QjjwbOhynwff404ergX8lzcUTBkvZ4Kc9rzVCDW6G7bHgYLsZkNe 7zuiPXpjGT2Q5ynpVnKE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 14:32:40 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 906895145.9.10372; Thu, 09 Apr 2015 14:32:38 -0400 Message-ID: <5526C6AA.2060508@isdg.net> Date: Thu, 09 Apr 2015 14:36:26 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, Anne Bennett , "dmarc@ietf.org" References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> In-Reply-To: <552689EE.4090408@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:36:33 -0000 On 4/9/2015 10:17 AM, Rolf E. Sonneveld wrote: > On 04/09/2015 03:24 PM, Anne Bennett wrote: >> Hector Santos writes: >> >>> A database is still needed of which domains will have an >>> outbound mail stream with two signatures. Some how the list domains >>> will still need to register with the Yahoos and tell the Yahoos, >>> "Please send us two signatures authorizing out list domain." I >>> would like to call this a "registration" problem because thats seems >>> to be the area of disagreement as a real problem. >> >> I have to agree; if this is the case, to me, it is a >> show-stopper. The genius of the DKIM and SPF and DMARC >> approaches is that they are DNS-based, and thus completely >> decentralized. The idea that lists would have to register with >> the e-mail providers of all of their contributors, or that I >> as a (very small!) e-mail provider would have to figure out >> what is and isn't a list, doesn't scale. > > This can be solved by having the owners of mailing lists publish a > yet-to-be-defined DNS record in which they proclaim the presence of a > mailing list within that domain. I'm contemplating to write a draft > for this, as more than one of the suggested solutions to the mailing > list problem might benefit from this. Its either going to be a internal database or a public database, and with internal, we begin to have targeted sites (those without a database). > Having said that, I don't like the idea of designing all sorts of > auxilliary technologies to solve the problems introduced by DMARC, or > better said: if we'd come up with such helper technologies we should > try to address as many use cases, presented in [1], as possible. If we > do not, at the the end of the day we'll have created a myriad of new > technologies, considerably increased the complexity of the e-mail > ecosystem worldwide with a net result of zero as long as senders still > treat p=reject as p=none/quarantine. > > /rolf > > [1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt +1 Following john's example, he wishes for "taugh.com" to authorize "ietf.org" as a 3rd party signer. Using ATPS, he would create a DNS record: base32(sha1("ietf.com"))._atps.taugh.com This would be it. The receiver will just check for this ATPS record. The only reason for the base32(sha1()) hashed subdomain was because there was a domain name length concern or some possible INTL character concern, as I recall. But I am not sure we need it, it would certainly remove API complexity when the record is simplified to: ietf.org._atps.taugh.com In any case, this would be it. The receivers will see: From: johnl@taugh.com To: dmarc@ietf.org DKIM-Signature: ...; d=ietf.org; ... new good strong 3rd party signature This provides the two variables for the DMARC+ATPS lookup: POLICY = DKIM_DMARC_ATPS(ADID, SDID) We can't be using a DNS lookup as a reason for not using ATPS and continue to investigate these alternatives which have even higher overhead. In DMARC+ATPS, you would have 1 additional DNS lookup. With the @FS=1 lookup ideas, you also have 1 additional signature key lookup. I agree that the "database" is the key issue here. But the above Protocol model is the same with a blackbox functionality where we have known inputs (ADID, SDID) and known outputs (ACCEPT, REJECT, QUARANTINE, DISCARD) we want to have. There are boundary limits here. All possible input and actions are known, including doing nothing. PS: This is what we have for our authorized signers under my isdg.net zone: e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" ) rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" ) Is it really a DNS concern these days if a textual zone file has 30k or 50K subdomain records? Is it a limit due to their text editor? I'm sure a GUI will help, but the text guys are still going to popup their editor too. Is that still a problem today? I don't think so. New tools can be written to automatic the process. This should not be a DNS or Configuration/Setup limitation issue. -- HLS From nobody Thu Apr 9 11:49:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633391A87B2 for ; Thu, 9 Apr 2015 11:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 Kv_kFRM2ibzx for ; Thu, 9 Apr 2015 11:49:55 -0700 (PDT) Received: from winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CD9071A87D4 for ; Thu, 9 Apr 2015 11:49:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=699; t=1428605381; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=o5Tpx6+mn5HJuUR7Crv1ku+bhyM=; b=CSNH614Z+fWYLKAMLpkJ XFqtwaBuNC/TmXd03Ll1s7yyvMFdUZG8j06t8eViSREQZow4cvPSyrQ3l52/khT5 T1kxXzBRSoq6TjpQ6SynSH0MHKDDlgroZWrGWH37ieUTnak2CexBE3jrGP3Aw6ex oImGfh63GQSXKA392GWfoW4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 14:49:41 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2315401184.3150.5776; Thu, 09 Apr 2015 14:49:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=699; t=1428605158; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=q34iJFQ DbkGGQrhcz87b0h3u2DHCJha0l0CzVmK9Y+w=; b=CXHU8X6YVgwcbOBmxsh2Kb6 izwqs2iZqnQJhVfwOeFZ+wF8V4t3A5a6CtGC6Esk+9s/Chm8AF+cN887OAC0p3eJ 0wBMvBz0wIwkiy7QHi1A2js8yDREhrtBlQoyh5X5bzilwkNozzHDW0jbAlQyqoSG WJqWjOod1W6W8DtznTeY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 14:45:58 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 907693910.9.11220; Thu, 09 Apr 2015 14:45:57 -0400 Message-ID: <5526C9C8.6070104@isdg.net> Date: Thu, 09 Apr 2015 14:49:44 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150409182728.1115.qmail@ary.lan> In-Reply-To: <20150409182728.1115.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:49:56 -0000 On 4/9/2015 2:27 PM, John Levine wrote: >>> A database is still needed of which domains will have an >>> outbound mail stream with two signatures. > > Sorry, no, that's completely wrong. Please reread the draft. > Do you have a reference point, text in the draft related to this to clear it up? How will signers know what domains will have the extra processing, dual signature creation enabled? Does all outbound mail get dual signatures? How will Yahoo know that ietf.org is an "authorized" 3rd party signer in order for yahoo to create two signatures? As you know this will create a major loophole. Your security section admits as much to the security loophole. -- HLS From nobody Thu Apr 9 11:53:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA31A88CE for ; Thu, 9 Apr 2015 11:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 UEea_CtMbm3x for ; Thu, 9 Apr 2015 11:53:35 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (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 BAA211A88C7 for ; Thu, 9 Apr 2015 11:53:34 -0700 (PDT) Received: by vnbf62 with SMTP id f62so24360431vnb.13 for ; Thu, 09 Apr 2015 11:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=d19QD/O8Evkvw6T9xmZ+amj61TOsOLnC7oPqIdrhD8M=; b=sKAGGI30a0EmVFWgaF+EGIH5TcX2WlrBo/U0pKYad5PrdZ67oTWyQuEYLUSNuMo91a GscyKQjfN/hdsybPIB6azAMU8fQ30IsPwNfKbmSBfvbxRwIbWmz5hDFUAofajfu9ZMiC k7lA0Pi3w+7LP8hFgOyxxvNbIXtgzG0xJtyHf3aSy/GmXCY4vEUlrVnooefv8um3ar+y kRCLQJ6svRfEhLyH46RWbLyPmm2KgFBZA5jFp1BbN2/NQ04Yw6Ljy174fppL4z30BQJU tKtjyNn09h0REBj146kvseGaY/fJO1PzFDDX+j7s/3kVeybck2KmMb6Oqrj2zkobWfnF BTtw== X-Received: by 10.140.22.234 with SMTP id 97mr37097153qgn.52.1428605613639; Thu, 09 Apr 2015 11:53:33 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id d64sm10463753qka.15.2015.04.09.11.53.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 11:53:32 -0700 (PDT) Message-ID: <5526CAAA.20508@gmail.com> Date: Thu, 09 Apr 2015 11:53:30 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> In-Reply-To: <20559.1428585884@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:53:36 -0000 On 4/9/15 6:24 AM, Anne Bennett wrote: Hector Santos writes: >> A database is still needed of which domains will have an >> outbound mail stream with two signatures. Some how the list domains >> will still need to register with the Yahoos and tell the Yahoos, >> "Please send us two signatures authorizing out list domain." I >> would like to call this a "registration" problem because thats seems >> to be the area of disagreement as a real problem. > I have to agree; if this is the case, to me, it is a > show-stopper. The genius of the DKIM and SPF and DMARC > approaches is that they are DNS-based, and thus completely > decentralized. The idea that lists would have to register with > the e-mail providers of all of their contributors, or that I > as a (very small!) e-mail provider would have to figure out > what is and isn't a list, doesn't scale. > > I have not yet taken the time to fully understand the "weak and > strong signatures" idea, but if I may be forgiven for commenting > anyway: could the above problem be solved by having "original" > signers always supply various forms of signature (without > needing to figure out if the receiver address is a list), and > having "intermediate" signers (such as mailing lists) add more > signatures as described in the draft? A message that arrives > with only the "original" signatures would be checked against > the strong one, and a message that arrives with "additional" > signatures would be checked as per the draft. > > Of course, if the idea of specifically setting up a third-party > trust is crucial to the proposal, then my suggestion is useless, > and the "registration problem" is not solvable. Dear Anne and Hector, Tag/conditional DKIM expects ESP now offloading support issues onto various third-parties to instead apply extremely limited signatures against all outbound messages while guessing their user's recipient's signing domain in hopes this new signature might satisfy DMARC's From alignment requirement as seen by receivers implementing DMARC. This still ignores Sender header fields claiming to have actually sent the message. ESPs would have less overhead and would handle smaller message sizes by simply ensuring clients see Sender header fields when used as a basis for acceptance. In any case DMARC should be adjusted to assert support for any new alignment or signature mode of operation. Outlook already provides a means to expose the Sender and can be done with rather simple MUA reconfiguration to select displayed headers. TPA-Label in comparison represents both a database established by the DMARC domain to eliminate any additional message overhead while not imposing changes on third-party services. ATPS remains flawed since it also required special DKIM signatures by third-party services to somehow also determine possible DNS label encoding variants employed by a user's domain. In essence, ATPS imposes a database support requirement onto those likely offering a free third-party service while also expecting similar support from ESPs. Tag/conditional DKIM is not really that much better, since it still depends on support from ESP's and fails to offer a better fallback mode when these ESPs fail to act. Regards, Douglas Otis From nobody Thu Apr 9 13:18:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6401A894F for ; Thu, 9 Apr 2015 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Qn9a2BU-B5YL for ; Thu, 9 Apr 2015 13:18:17 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 AA2B51A894E for ; Thu, 9 Apr 2015 13:18:17 -0700 (PDT) Received: by ignm3 with SMTP id m3so2164273ign.0 for ; Thu, 09 Apr 2015 13:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xRE6in2JX7WwXdYF1kcVus324FZwPVdprMISemVn/Z4=; b=d5MM+Wz0Th6HCNaLqNZcut5fw3fsSnyt+rKGmKGvR8EqlCl09SFRpxaWIYZ/7Ggddb rgeFzR+VOI+OweLIUUfKGHCIR5aPaV3tGVd6gFK84WiTvWNswlGy4zXEALHDykThz5kA XORlr30VY05t8Zb6oyGSLgwGp3Bi8xkUKiYAh0n3EjDxXygUVeze1OgDE8c7bmHSP3mX BH0BV3rg5kN1/LhV3mW0AurM+fG6EqZZgj6Z6z8czj0ykrXxD2vkkXAPNI1NoHx4EOHb S0UtpAztC4uXhPcAZ8ObX27WsDfBp7JsuSvfGXjlu9T1QO+8wdG+UZ+7W7BkSjVCiz7w 1tMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xRE6in2JX7WwXdYF1kcVus324FZwPVdprMISemVn/Z4=; b=PMziLtXXQ2AIolwf+cWjizJNbHt4vujbMs/zxwi88vZnk+2t5ZKl5XNBHl6H3V1O/A Hc+PniiDtEW5ReDYU/E0j0Z7N5YCLfDm/v3daEfz/xJ7k0JGomHO7zPPv+QzygPTt5En o0XHuRFTQ3v87J67kGuu+hm5gVSrN0hcpP4QU6thZ4DH21nRvghL7wj6VPA9K6bvB/ab ZFJUPdRtWbZsDw3wZ8DAiR2frBuJpYJ8DX8QjmEePLKyxYf9p7zTpYzDGevDe0A/o9wZ qPytCIbZA3Acl2+73eJSxS6ACykoqQA/Wi4A9uqnsb5GWkhI/E8mcyIL2Cvc2I9CDb5n Y6Ag== X-Gm-Message-State: ALoCoQmyrWmHFbI5sJddnq5DJzWXosJRYE/7ZYyV2aOcpeYuF5cCbUYG3xTL6TnW1hPW8IJK/X7x MIME-Version: 1.0 X-Received: by 10.107.164.69 with SMTP id n66mr49441839ioe.82.1428610696825; Thu, 09 Apr 2015 13:18:16 -0700 (PDT) Received: by 10.64.86.7 with HTTP; Thu, 9 Apr 2015 13:18:16 -0700 (PDT) In-Reply-To: <5526C6AA.2060508@isdg.net> References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> <5526C6AA.2060508@isdg.net> Date: Thu, 9 Apr 2015 13:18:16 -0700 Message-ID: From: Brandon Long To: Hector Santos Content-Type: multipart/alternative; boundary=001a1141c9301b86d30513505953 Archived-At: Cc: R.E.Sonneveld@sonnection.nl, "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:18:20 -0000 --001a1141c9301b86d30513505953 Content-Type: text/plain; charset=UTF-8 Since you're continuing this push for atps, I should point out again our issue. Its not with some editor or serving the large number of records. Its how do I validate 50k different third parties to say, sure, they can send with gmail.com. And it also won't help when someone creates yet another domain and now I need 50001 records. Every Google Apps domain has mailing lists (Google Groups) support, should I put all of them automatically on such a list? That's way more than 50k records at that point, and even if they're paying me (Google) money, I don't know if I would trust them to send from gmail.com or google.com. Currently, for sending mail as google.com, we require vendor level security audits... am I supposed to just say "ok" to every random mailing list that googlers are on? Brandon On Thu, Apr 9, 2015 at 11:36 AM, Hector Santos wrote: > On 4/9/2015 10:17 AM, Rolf E. Sonneveld wrote: > >> On 04/09/2015 03:24 PM, Anne Bennett wrote: >> >>> Hector Santos writes: >>> >>> A database is still needed of which domains will have an >>>> outbound mail stream with two signatures. Some how the list domains >>>> will still need to register with the Yahoos and tell the Yahoos, >>>> "Please send us two signatures authorizing out list domain." I >>>> would like to call this a "registration" problem because thats seems >>>> to be the area of disagreement as a real problem. >>>> >>> >>> I have to agree; if this is the case, to me, it is a >>> show-stopper. The genius of the DKIM and SPF and DMARC >>> approaches is that they are DNS-based, and thus completely >>> decentralized. The idea that lists would have to register with >>> the e-mail providers of all of their contributors, or that I >>> as a (very small!) e-mail provider would have to figure out >>> what is and isn't a list, doesn't scale. >>> >> >> This can be solved by having the owners of mailing lists publish a >> yet-to-be-defined DNS record in which they proclaim the presence of a >> mailing list within that domain. I'm contemplating to write a draft >> for this, as more than one of the suggested solutions to the mailing >> list problem might benefit from this. >> > > Its either going to be a internal database or a public database, and with > internal, we begin to have targeted sites (those without a database). > > Having said that, I don't like the idea of designing all sorts of >> auxilliary technologies to solve the problems introduced by DMARC, or >> better said: if we'd come up with such helper technologies we should >> try to address as many use cases, presented in [1], as possible. If we >> do not, at the the end of the day we'll have created a myriad of new >> technologies, considerably increased the complexity of the e-mail >> ecosystem worldwide with a net result of zero as long as senders still >> treat p=reject as p=none/quarantine. >> >> /rolf >> >> [1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt >> > > +1 > > Following john's example, he wishes for "taugh.com" to authorize "ietf.org" > as a 3rd party signer. Using ATPS, he would create a DNS record: > > base32(sha1("ietf.com"))._atps.taugh.com > > This would be it. The receiver will just check for this ATPS record. The > only reason for the base32(sha1()) hashed subdomain was because there was a > domain name length concern or some possible INTL character concern, as I > recall. But I am not sure we need it, it would certainly remove API > complexity when the record is simplified to: > > ietf.org._atps.taugh.com > > In any case, this would be it. The receivers will see: > > From: johnl@taugh.com > To: dmarc@ietf.org > DKIM-Signature: ...; d=ietf.org; ... new good strong 3rd party signature > > This provides the two variables for the DMARC+ATPS lookup: > > POLICY = DKIM_DMARC_ATPS(ADID, SDID) > > We can't be using a DNS lookup as a reason for not using ATPS and continue > to investigate these alternatives which have even higher overhead. In > DMARC+ATPS, you would have 1 additional DNS lookup. With the @FS=1 lookup > ideas, you also have 1 additional signature key lookup. > > I agree that the "database" is the key issue here. But the above Protocol > model is the same with a blackbox functionality where we have known inputs > (ADID, SDID) and known outputs (ACCEPT, REJECT, QUARANTINE, DISCARD) we > want to have. There are boundary limits here. All possible input and > actions are known, including doing nothing. > > > PS: This is what we have for our authorized signers under my isdg.net > zone: > > e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d= > megabytecoffee.com;" ) > jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d= > winserver.com;" ) > kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" > ) > n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d= > mipassoc.org;" ) > pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" > ) > q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" > ) > rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d= > mapurdy.com.au;" ) > tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d= > santronics.com;" ) > > Is it really a DNS concern these days if a textual zone file has 30k or > 50K subdomain records? Is it a limit due to their text editor? I'm sure a > GUI will help, but the text guys are still going to popup their editor > too. Is that still a problem today? I don't think so. New tools can be > written to automatic the process. This should not be a DNS or > Configuration/Setup limitation issue. > > > -- > HLS > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1141c9301b86d30513505953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since you're continuing this push for atps, I should p= oint out again our issue.=C2=A0 Its not with some editor or serving the lar= ge number of records.

Its how do I validate 50k differen= t third parties to say, sure, they can send with gmail.com.

And it also won't help when = someone creates yet another domain and now I need 50001 records.
=
Every Google Apps domain has mailing lists (Google Groups) s= upport, should I put all of them automatically on such a list?=C2=A0 That&#= 39;s way more than 50k records at that point, and even if they're payin= g me (Google) money, I don't know if I would trust them to send from gmail.com or g= oogle.com.=C2=A0 Currently, for sending mail as google.com, we require vendor level security audits... am I supp= osed to just say "ok" to every random mailing list that googlers = are on?

Brandon

On Thu, Apr 9, 2015 at 11:36 AM, Hector S= antos <hsantos@isdg.net> wrote:
On 4/9/2015 10:17 AM, Rolf E. Sonneveld wrote:
On 04/09/2015 03:24 PM, Anne Bennett wrote:
Hector Santos <hsa= ntos@isdg.net> writes:

A database is still needed of which domains will have an
outbound mail stream with two signatures.=C2=A0 Some how the list domains will still need to register with the Yahoos and tell the Yahoos,
"Please send us two signatures authorizing out list domain."=C2= =A0 =C2=A0 I
would like to call this a "registration" problem because thats se= ems
to be the area of disagreement as a real problem.

I have to agree; if this is the case, to me, it is a
show-stopper.=C2=A0 The genius of the DKIM and SPF and DMARC
approaches is that they are DNS-based, and thus completely
decentralized.=C2=A0 The idea that lists would have to register with
the e-mail providers of all of their contributors, or that I
as a (very small!) e-mail provider would have to figure out
what is and isn't a list, doesn't scale.

This can be solved by having the owners of mailing lists publish a
yet-to-be-defined DNS record in which they proclaim the presence of a
mailing list within that domain. I'm contemplating to write a draft
for this, as more than one of the=C2=A0 suggested solutions to the mailing<= br> list problem might benefit from this.

 Its either going to be a internal database or a public database, and with i= nternal, we begin to have targeted sites (those without a database).

Having said that, I don't like the idea of designing all sorts of
auxilliary technologies to solve the problems introduced by DMARC, or
better said: if we'd come up with such helper technologies we should try to address as many use cases, presented in [1], as possible. If we
do not, at the the end of the day we'll have created a myriad of new technologies, considerably increased the complexity of the e-mail
ecosystem worldwide with a net result of zero as long as senders still
treat p=3Dreject as p=3Dnone/quarantine.

/rolf

[1] https://tools.ietf.org/id/draft-ietf-dmarc= -interoperability-01.txt

 +1

Following john's example, he wishes for "taugh.com" to authorize "ietf.org" as a 3rd party signer.= =C2=A0 Using ATPS, he would create a DNS record:

=C2=A0 =C2=A0base32(sha1("ietf.com"))._atps.taugh.com

This would be it. The receiver will just check for this ATPS record. The on= ly reason for the base32(sha1()) hashed subdomain was because there was a d= omain name length concern or some possible INTL character concern, as I rec= all.=C2=A0 But I am not sure we need it, it would certainly remove API comp= lexity when the record is simplified to:

=C2=A0 =C2=A0 =C2=A0ietf.org._atps.taugh.com

In any case, this would be it.=C2=A0 The receivers will see:

=C2=A0 From: johnl@tau= gh.com
=C2=A0 To: dmarc@ietf.o= rg
=C2=A0 DKIM-Signature: ...; d=3Dietf.org; ... new good strong 3rd party signature

This provides the two variables for the DMARC+ATPS lookup:

=C2=A0 =C2=A0POLICY =3D DKIM_DMARC_ATPS(ADID, SDID)

We can't be using a DNS lookup as a reason for not using ATPS and conti= nue to investigate these alternatives which have even higher overhead.=C2= =A0 In DMARC+ATPS, you would have 1 additional DNS lookup. With the @FS=3D1= lookup ideas, you also have 1 additional signature key lookup.

I agree that the "database" is the key issue here.=C2=A0 But the = above Protocol model is the same with a blackbox functionality where we hav= e known inputs (ADID, SDID) and known outputs (ACCEPT, REJECT, QUARANTINE, = DISCARD) we want to have.=C2=A0 There are boundary limits here.=C2=A0 All p= ossible input and actions are known, including doing nothing.


PS: This is what we have for our authorized signers under my isdg.net zone:

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3D= megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Dwinse= rver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Dgmail.com= ;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Dmipass= oc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Dietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Disdg.net;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Dmapu= rdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT=C2=A0 =C2=A0 =C2=A0 ( &qu= ot;v=3Datps01; d=3Dsant= ronics.com;" )

Is it really a DNS concern these days if a textual zone file has 30k or 50K= subdomain records?=C2=A0 Is it a limit due to their text editor? I'm s= ure a GUI will help, but the text guys are still going to popup their edito= r too.=C2=A0 Is that still a problem today?=C2=A0 I don't think so.=C2= =A0 New tools can be written to automatic the process.=C2=A0 =C2=A0 This sh= ould not be a DNS or Configuration/Setup limitation issue.


--
HLS



_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--001a1141c9301b86d30513505953-- From nobody Thu Apr 9 13:46:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457FC1B3254 for ; Thu, 9 Apr 2015 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 ogGjLdvQxaBA for ; Thu, 9 Apr 2015 13:46:19 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB2E1B327E for ; Thu, 9 Apr 2015 13:44:59 -0700 (PDT) Received: from [100.95.158.83] (31.sub-70-208-140.myvzw.com [70.208.140.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 875CBC40243; Thu, 9 Apr 2015 15:44:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428612296; bh=gZaj42SC6FiMJVCdoUg0Hdlxnunns+sjcpqZdc+389c=; h=In-Reply-To:References:Subject:From:Date:To:From; b=0vq3lzXQngI4ShmblnMvHdc+NozEJjrEKK0nt52lPbG0m4NCo/XMAUxiW/5lFbAve ACY49Wb/wAkPXmdriS47kobWYD8a0R1bFTzRbyErJOf0T+N0adAf+XftYDkR64s4vC zXO5VM+VeKflI1BiA4wDnzuuU/3SOyH7jZAdazbE= User-Agent: K-9 Mail for Android In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <201504090029.t390TJtx016935@shadrach.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 09 Apr 2015 16:44:49 -0400 To: "dmarc@ietf.org" Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:46:21 -0000 On April 8, 2015 9:47:39 PM EDT, Steve Atkins wrote: > >On Apr 8, 2015, at 5:32 PM, John R Levine wrote: > >>> So why is DMARC any more useful than these "hacks"? >> >> Good question. As originally intended, DMARC was for mail from >sources where a failure reliably meant phish. Then AOL and Yahoo >repurposed it to push their support costs onto other people, and its >value has been under debate ever since. > >Also a major reason that people who were dubious about SPF policy and >extremely dubious about ADSP supported DMARC was that it has reporting >and dry run functionality. Run it in p=none mode; use the reports to >make sure that nothing breaks; if nothing breaks switch to p=reject. > >I didn't think that anyone significant would skip the testing, >reporting and decision making steps and leap directly to intentionally >breaking email for their users their users' correspondents. I don't think they were confused about the breakage (see Yahoo's original announcement of the change). They knew what would happen and decided it was Okay given the perceived benefit. Scott K From nobody Thu Apr 9 13:48:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9B1B32C6 for ; Thu, 9 Apr 2015 13:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tUVqZACdrMbY for ; Thu, 9 Apr 2015 13:48:09 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DB21B324F for ; Thu, 9 Apr 2015 13:46:50 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id t39KkgW2043756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 9 Apr 2015 13:46:47 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com t39KkgW2043756 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1428612407; bh=VzXcKD6qH5juA6KagycGV/lKJNfVFn2EdTIyDHaiWo4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=Ab6dnZEOJ8sCssZJ+9BrlAyEltW16x9KbL56GgI5DJn3nmtPP9H4Fpqgtxibv7nS/ 09iYgYEnXoa+Zvw3RJ7cmf7SHZQb3naEQs7hGa5e8DNd8KwaZrO26uTfEF/0TcHh1Q wV8amH5QD1G7JeSesAq8reOmyTcBJ9ETn/rcP/cI= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <5526E533.5020506@crash.com> Date: Thu, 09 Apr 2015 13:46:43 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="------------000602020709060404020701" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 09 Apr 2015 13:46:47 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] DMARC panel at RSA, 4/22 @ 10:20AM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:48:13 -0000 This is a multi-part message in MIME format. --------------000602020709060404020701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit For anybody who will be attending the RSA Conference in San Francisco about a week and a half from today, there's at least one panel focused on DMARC: "Curbing Email Threats & Spearphishing– The Promise & Results with DMARC" Wednesday, April 22nd, 10:20 - 11:10AM, West, Room 2018 Session code TECH-W03 Email is the most effective cyberattack vector, targeting users and businesses by initiating account takeovers, driving identity theft and serving as the data breach gateway. This session will share research into worldwide adoption of email authentication and DMARC, to show which technologies are proving to be effective countermeasures to thwart social-engineering email exploits and spearphishing. Featuring: Craig Siezle, OTA John Scarrow, Microsoft Trent Adams, PayPal Pat Peterson, Agari Link: https://www.rsaconference.com/events/us15/agenda/sessions/1743/curbing-email-threats-spearphishing-the-promise Enjoy, --Steve. --------------000602020709060404020701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit For anybody who will be attending the RSA Conference in San Francisco about a week and a half from today, there's at least one panel focused on DMARC:

"Curbing Email Threats & Spearphishing– The Promise & Results with DMARC"
Wednesday, April 22nd, 10:20 - 11:10AM, West, Room 2018
Session code TECH-W03
Email is the most effective cyberattack vector, targeting users and businesses by initiating account takeovers, driving identity theft and serving as the data breach gateway. This session will share research into worldwide adoption of email authentication and DMARC, to show which technologies are proving to be effective countermeasures to thwart social-engineering email exploits and spearphishing.

Featuring:

Craig Siezle, OTA
John Scarrow, Microsoft
Trent Adams, PayPal
Pat Peterson, Agari

Link: https://www.rsaconference.com/events/us15/agenda/sessions/1743/curbing-email-threats-spearphishing-the-promise

Enjoy,
--Steve. --------------000602020709060404020701-- From nobody Thu Apr 9 14:36:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293A51B3373 for ; Thu, 9 Apr 2015 14:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 060StWYklHPj for ; Thu, 9 Apr 2015 14:36:28 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (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 A92C01B3379 for ; Thu, 9 Apr 2015 14:36:26 -0700 (PDT) Received: by wgin8 with SMTP id n8so343493wgi.0 for ; Thu, 09 Apr 2015 14:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BMIsGTHAPxYSFlGgTau0yc5DpXa2REYcIJ6fVcR6O3Y=; b=xPIdwL9+g9BRXsMwefhH3XLhu9fyFrxyxLWjpXHRI383V92Hbeni+C2hHIGpdM+5C7 FNPIC/dWFBayHjaC8ik1J6Lvlzs//sxc0lxTdHEMVkNB8MEJC+h2CjD9utJCbHNae1Eq wx2gjD/v2kxjYEujdpEqSdVpetrpRbpexdX2MmWH8b3KRTi+isfhmwufZ4TZ5GwDpcxt 70xBjGcTk3OvUEfkCMbyw0o1PvEKdwzYdj43qdKp6k4JPpDQQld97kGUff01be/rUZpl qiXKwWSpQli4YKlD7sd+RcYJNOrtxlTcaRHCPoSNhbrGHGfdzA+ppbEyRBYQyq8MuUb+ wtOw== MIME-Version: 1.0 X-Received: by 10.180.99.2 with SMTP id em2mr9676451wib.59.1428615385476; Thu, 09 Apr 2015 14:36:25 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 9 Apr 2015 14:36:25 -0700 (PDT) In-Reply-To: <20150409182505.1094.qmail@ary.lan> References: <20150409182505.1094.qmail@ary.lan> Date: Thu, 9 Apr 2015 14:36:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d04426c6892731805135170cc Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:36:29 -0000 --f46d04426c6892731805135170cc Content-Type: text/plain; charset=UTF-8 On Thu, Apr 9, 2015 at 11:25 AM, John Levine wrote: > Yeah, now that I look at your drafts again, I see that we are both > making the same assertion that this message is a mutated version of > one that someone else sent. I still like mine better because trying > to enumerate all of the possible kinds of changes doesn't work very > well, e.g., subject tags and per-recipient S/MIME encryption. (Sympa > can do the latter.) What we're claiming is slightly different. Your approach is to trust that the "fs" domain isn't malicious; mine is to claim responsibility for only the original content and allow the second domain to claim its modifications. I guess it depends on which side we want to mess with more. -MSK --f46d04426c6892731805135170cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 9, 2015 at 11:25 AM, John Levine <johnl@taugh.c= om> wrote:
Yeah, now that I look at your drafts = again, I see that we are both
making the same assertion that this message is a mutated version of
one that someone else sent.=C2=A0 I still like mine better because trying to enumerate all of the possible kinds of changes doesn't work very
well, e.g., subject tags and per-recipient S/MIME encryption.=C2=A0 (Sympa<= br> can do the latter.)

What we're claiming= is slightly different.=C2=A0 Your approach is to trust that the "fs&q= uot; domain isn't malicious; mine is to claim responsibility for only t= he original content and allow the second domain to claim its modifications.= =C2=A0 I guess it depends on which side we want to mess with more.

<= /div>
-MSK
--f46d04426c6892731805135170cc-- From nobody Thu Apr 9 14:46:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7EF1B3398 for ; Thu, 9 Apr 2015 14:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 ijkpX2jJ8xtL for ; Thu, 9 Apr 2015 14:46:51 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB7E1B3396 for ; Thu, 9 Apr 2015 14:46:51 -0700 (PDT) Received: (qmail 73028 invoked from network); 9 Apr 2015 21:46:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11d43.5526f34a.k1504; bh=x1vMZYyiH5W6/jYxYaV/PQsamZMOtF0CU1b/nVy7LV8=; b=pQ+V1EtXfLNAwNhtr0gr3dYUic/J6vgpnF+g8vYvAbb4/jn8kY0bzxr4QkDjA895emBdGo1gJErvSSTAA9bvMDOaMKORVrrrGUVS1onKT0ERMRiwnLny+gwIuzsoIE1QhrTIJd/ylgb8uykdHlcds0jPd0j+nOJ+GLVaEstA45tuZ8kyXifVUb3RNkMh4D6zoOiVRBNLIbFGQz9KeS4HVPYQYZbRECNoFEcmbIdrZz73rriuvinra/PzbQ9RmGWM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11d43.5526f34a.k1504; bh=x1vMZYyiH5W6/jYxYaV/PQsamZMOtF0CU1b/nVy7LV8=; b=Zp0y/G3Om3xjdnu9RjoGXCYkwdlbA5obWTj0SLR3DhdbhbMhavNgPihtzWXj6QRkloGETAThJ+uJdR4nMcuIbUW/Ec+l8YQNOX2hdkbPwbFZb77e1yL3dy9zn+ZYLCHVnZjAG4xVEX3cYtauwzO/ZCNQk4wDh7pkRZ0fcTW+s3/HeXYAw1BVWdi14tFQWQe4FYFUYPNsJYQgy17rHYXZo3MLzbScXmf7R59KO3zDy34e+slKOnciZBT9Kk5z36Zq Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 09 Apr 2015 21:46:50 -0000 Date: 9 Apr 2015 17:46:50 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150409182505.1094.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:46:53 -0000 > What we're claiming is slightly different. Your approach is to trust that > the "fs" domain isn't malicious; mine is to claim responsibility for only > the original content and allow the second domain to claim its > modifications. I guess it depends on which side we want to mess with more. I suppose that it would be interesting to know what part of the message is whose fault to do forensics, it doesn't seem very useful for the pass/fail decisions we need from DKIM and DMARC. We all seem to agree that we're not going to tell people to display DKIM signed and unsigned parts of the message in different color, so I doubt we're going to tell them to display origin vs. list parts in different colors either. And I like subject tags. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Apr 9 14:47:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4D21A88C0 for ; Thu, 9 Apr 2015 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3yrufyYLyOWK for ; Thu, 9 Apr 2015 14:47:28 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 0589B1A8906 for ; Thu, 9 Apr 2015 14:47:28 -0700 (PDT) Received: by widdi4 with SMTP id di4so107775808wid.0 for ; Thu, 09 Apr 2015 14:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E5IXRUl0RuhsLfei3NNCwDcEQeSnonisLJOF1U1YcsY=; b=P+EJZp3glpH6FN21iltBBxAjGx7ij8emsQ0mRGmXa+CQlp3fX6yN9PnC3xxY3yghi+ K8918CJywnnleskldl3+8FwEjxssrZUjKkcR4JArMN+pDqt6tunRqRb6xemYFeckWkJA EqCJE/jdBuLAlEb7UK+PORO/sWZK4l8ssSGc2AeFrutxgNXkPmzA//cpHU0FYaoGj/RY Wz9r8qYal3qVxl3XB2j8bOhTNnCm3uTUOgqPUEyBwZZgdsJzQAIhqOXoad6NsWv41dtx lQruEsn+UPSIyPeGtWe6xbjFX+jzl5p1DoSrVXdPm49CjTLpEhaKgvnPVFNPfW57M/wZ yjhQ== MIME-Version: 1.0 X-Received: by 10.180.99.2 with SMTP id em2mr9733508wib.59.1428616046833; Thu, 09 Apr 2015 14:47:26 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 9 Apr 2015 14:47:26 -0700 (PDT) In-Reply-To: References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> <5526C6AA.2060508@isdg.net> Date: Thu, 9 Apr 2015 14:47:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Brandon Long Content-Type: multipart/alternative; boundary=f46d04426c68fdf4d20513519738 Archived-At: Cc: "" , Anne Bennett , "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:47:30 -0000 --f46d04426c68fdf4d20513519738 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 9, 2015 at 1:18 PM, Brandon Long wrote: > Since you're continuing this push for atps, I should point out again our > issue. Its not with some editor or serving the large number of records. > > Its how do I validate 50k different third parties to say, sure, they can > send with gmail.com. > > And it also won't help when someone creates yet another domain and now I > need 50001 records. > > Every Google Apps domain has mailing lists (Google Groups) support, should > I put all of them automatically on such a list? That's way more than 50k > records at that point, and even if they're paying me (Google) money, I > don't know if I would trust them to send from gmail.com or google.com. > Currently, for sending mail as google.com, we require vendor level > security audits... am I supposed to just say "ok" to every random mailing > list that googlers are on? > This is precisely why I am "showing my disinterest in completing the DKIM ATPS work", and also why I don't think things like DSAP or TPA will work either. They all amount to creating a registration burden on the author domain, and those sorts of approaches do not scale. Solutions to this problem have to be self-contained in order to stand a chance of being viable. The drafts before us now attempt to augment DKIM in a way that doesn't create any extra queries to the DNS or any other registry to validate. So far, this seems way more palatable. -MSK --f46d04426c68fdf4d20513519738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 9, 2015 at 1:18 PM, Brandon Long <blong@google= .com> wrote:
Since you&#= 39;re continuing this push for atps, I should point out again our issue.=C2= =A0 Its not with some editor or serving the large number of records.

Its how do I validate 50k different third part= ies to say, sure, they can send with gmail.com.

And it also won't help= when someone creates yet another domain and now I need 50001 records.

Every Google Apps domain has mailing lists (Google Gro= ups) support, should I put all of them automatically on such a list?=C2=A0 = That's way more than 50k records at that point, and even if they're= paying me (Google) money, I don't know if I would trust them to send f= rom gmail.com or google.com.=C2=A0 Currently, f= or sending mail as google.c= om, we require vendor level security audits... am I supposed to just sa= y "ok" to every random mailing list that googlers are on?

This is precisely why I am "showing = my disinterest in completing the DKIM ATPS work", and also why I don&#= 39;t think things like DSAP or TPA will work either.=C2=A0 They all amount = to creating a registration burden on the author domain, and those sorts of = approaches do not scale.

Solutions to this problem have to be self-c= ontained in order to stand a chance of being viable.=C2=A0 The drafts befor= e us now attempt to augment DKIM in a way that doesn't create any extra= queries to the DNS or any other registry to validate.=C2=A0 So far, this s= eems way more palatable.

-MSK
--f46d04426c68fdf4d20513519738-- From nobody Thu Apr 9 15:22:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A6A1A895E for ; Thu, 9 Apr 2015 15:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.801 X-Spam-Level: X-Spam-Status: No, score=-100.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 LwZlVnnZYh2t for ; Thu, 9 Apr 2015 15:22:20 -0700 (PDT) Received: from dkim.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 96BFA1B2DDE for ; Thu, 9 Apr 2015 15:22:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3674; t=1428618131; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=R/ywDEcKsljf3nyK6xBvkZCXIoU=; b=j4SMwBiQ1a1tFrnOKAV8 Z/2PmF6Wve1neKcJAZUFDktaUfbIMrYKgcF1Lpi1vYW7yHknTeEFQ2K26a/Rgn30 xAYVop+mOftz0r0wtiApQaG0erwxspixF0dEJMRDhF4P8Hzv4CnMGv1jvhi/BxuI oDEyC+BvF9XES7m6r9CXNs8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 18:22:11 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2328151473.3150.4052; Thu, 09 Apr 2015 18:22:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3674; t=1428617905; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DgKFdgq n2ppT5lalnOSdwG1ch6YOQ4mTNlft3OW/t4w=; b=RTBCAW9NlVJghSg2HR95xHS EY3FwJ1pW0yfnRV0nOjNm6lTKBFiddRjQg4UimhURLnH60v9GFYkEjrtmrDtdB2v e0vRMb4nUqOOqtE73NQnS8CmVKoLlr3FIaPfMMSrxVlAibSGRy6qYjb5X+J5kHg2 mImFiiuFswFLppCEz/Zo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 18:18:25 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 920441082.9.10024; Thu, 09 Apr 2015 18:18:24 -0400 Message-ID: <5526FB94.30806@isdg.net> Date: Thu, 09 Apr 2015 18:22:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> <5526C6AA.2060508@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Brandon Long , "Rolf E. Sonneveld" , Anne Bennett Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:22:23 -0000 On 4/9/2015 4:18 PM, Brandon Long wrote: > Since you're continuing this push for atps, I should point out again our > issue. Its not with some editor or serving the large number of records. I'm pushing for the original DKIM+POLICY framework using a DNS Lookup. SSP had 3rd party language, ADSP removed it thus shooting itself it the foot. Still a great idea, a "Super ADSP" was released called DMARC however, unfortunately, with the same ADSP limitations. The DKIM+POLICY protocol was incomplete. ATPS, TPA was proposed to closed that gap. They are on the table. I believe ATPS is the best and most practically approach we have. TPA is too complex to achieve the same result ATPS provides. This @FS= dual signature idea is the same thing, via more DKIM processing power, needlessly. There is no reduction in DNS calls. > Its how do I validate 50k different third parties to say, sure, they can > send with gmail.com. > > And it also won't help when someone creates yet another domain and now I > need 50001 records. I don't see how 50k, or even 100K, 1M or more records would limit you. Are you saying you can't create the tools to manage this? > Every Google Apps domain has mailing lists (Google Groups) support, should > I put all of them automatically on such a list? Perhaps, explore it. Maybe it will help in the automation. Also, do you really need for this to be instantaneous? Having all the records now to get started? Can it be gathered over time? What if we were starting brand new? Would it be a good idea then, learning and registering domains as they come? >That's way more than 50k > records at that point, and even if they're paying me (Google) money, I > don't know if I would trust them to send from gmail.com or google.com. Thats a different issue -- Trust. Thats layer 2, see below. > Currently, for sending mail as google.com, we require vendor level security > audits... am I supposed to just say "ok" to every random mailing list that > googlers are on? Perhaps not. Again, explore it. You already are doing the ADID Policy Lookup. All you would be doing is adding the SDID to the lookup model. The worst that can happen is a short term, perhaps even long term, dearth in published records (NXDOMAIN) and the end result is the same - a failed DMARC record policy with negative classification. That was the same issue with SPF and also DMARC now. We have 12 years of daily statistics collected (http://www.winserver.com/public/antispam) and it took quite a number of years before SPF even reached a 6% rejection rate it is today. The DNS overhead is already huge where to scale this properly, receivers are dependent on having excellent local or uplink cache. I'm sure Google can the overhead that comes with a DMARC+ATPS framework. There are two layers to this: o Layer 1, policy filtering. This removes the bad mail, the unexpected mail, deterministically, at the system level. You can quarantine it if you like, it doesn't matter. Same idea as long as the end result is the same -- the user is protected, the domain reputation is not harm, and receiver benefits too from controlling abuse. This layer 1 leaves behind a valid stream of DKIM signed mail preparing it for layer 2. o Layer 2, trust/reputation vendor services. This was to filter the "good mail", the trusted signer. This was the intention of DKIM STD. So to answer your question, the trust part can be inherently acceptable with the ADID authorizing the SDID via a subdomain DNS record or you can query some other Trust/Reputation Vendor service API to see if they vouch for the SDID. -- HLS From nobody Thu Apr 9 15:37:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B16C1A8AE0 for ; Thu, 9 Apr 2015 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 pauSw0xb6tuW for ; Thu, 9 Apr 2015 15:37:11 -0700 (PDT) Received: from dkim.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 40A041A8BC3 for ; Thu, 9 Apr 2015 15:37:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2227; t=1428619023; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ntu+PML8zIU2b/JLD05/rX/DuYY=; b=c+9JuYwOp3y5KSek7rPb RKjP3I3CdCc49l/QP3YXliPkpWiwMTpL8rGFhCAA5jWqK7cjjAn5s+vH5q9RSeeh t7eJhThzkbYlQ3R71/6V/DuSNcbCIhDskgWXk/1WAtVUf+Wvsfa9RBCRENZ58V2b WhjQtwK5vqaYyOJv3/B5cpU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 18:37:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2329042379.3150.6048; Thu, 09 Apr 2015 18:37:01 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2227; t=1428618800; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RsCyQOo cd3qRytLBDKRulCI1ejqQ0be2DscwrA1bv8E=; b=cL64+OWO6IYiIjIrdVssdsQ d3KuTka93Ls8ebmcmVu9/5g2TkVnvOXDOTJvpOd3ZafRKZS7hlpk+xYbe/7xrB6L gOrjiPW4Be4+BcApb0CwtjQGloW6cf/U1xLSdgqmwZbzsIrwRYVY8vMdDzEm7Gje VDo+w1jvjAjxlZ2pkwmI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 09 Apr 2015 18:33:20 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 921335582.9.1224; Thu, 09 Apr 2015 18:33:19 -0400 Message-ID: <5526FF13.60200@isdg.net> Date: Thu, 09 Apr 2015 18:37:07 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Brandon Long References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> <5526C6AA.2060508@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" , Anne Bennett , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:37:12 -0000 On 4/9/2015 5:47 PM, Murray S. Kucherawy wrote: >> >> Every Google Apps domain has mailing lists (Google Groups) support, should >> I put all of them automatically on such a list? That's way more than 50k >> records at that point, and even if they're paying me (Google) money, I >> don't know if I would trust them to send from gmail.com or google.com. >> Currently, for sending mail as google.com, we require vendor level >> security audits... am I supposed to just say "ok" to every random mailing >> list that googlers are on? >> > > This is precisely why I am "showing my disinterest in completing the DKIM > ATPS work", and also why I don't think things like DSAP or TPA will work > either. They all amount to creating a registration burden on the author > domain, and those sorts of approaches do not scale. It is still not convincing. You are already doing a DMARC lookup. You are adding a new parameter to the DNS lookup and only when the ADID != SDID condition is met. The registration is a long term process, just like SPF and now DMARC was. > Solutions to this problem have to be self-contained in order to stand a > chance of being viable. The drafts before us now attempt to augment DKIM > in a way that doesn't create any extra queries to the DNS or any other > registry to validate. So far, this seems way more palatable. I'm sorry, but its not. It would be more DKIM changes at the all points. It is not necessary to be done. Certainly more processing overhead and there are additional DNS calls. For each new 3rd party signature, you got a DNS hit. You can't avoid the DNS hit. Adding ATPS/TPA to DMARC adds only 1 more DNS call and thats only when the ADID != SDID. And how do you expect the new signer to learn when to create two signatures? Where is that registration coming from? Google still needs to learn 50K domains and also figure out how to automate it for Google Apps mailing list support. Its no different Murray. At this point, you need both ideas: If there is a @FS= record, check it, otherwise if ADID != SDID check ATPS. DKIM signers and verifiers should not be put into a design change and cost burden when its not necessary. -- HLS From nobody Thu Apr 9 18:23:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8390C1A004D for ; Thu, 9 Apr 2015 18:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qSOJ6s9QCUbx for ; Thu, 9 Apr 2015 18:23:21 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 313B91A899F for ; Thu, 9 Apr 2015 18:23:20 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so5312986pab.3 for ; Thu, 09 Apr 2015 18:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wryUCr1POkDajZZXyVhwWEwfJ9iYnRaGfoPtW0movGk=; b=iW867Aoq/aW0VRjSBK8QyWvc39RGDQelHkUdbY7X/LO0bY1Q7RbsDqgI+tG/dRetRo gmsCjK9zuzkG4cKs7+fl8P9ycy6IjWvk2+NXZ0m6tgV3ME0xWPwnXIyQ2IuCDK8L1Es5 pbpk+/78rlZor4gk6jH/5I2oReSJr+JGYg3HQBidInDf0gm3B5vmDmnc8tG4IaYl7xOQ 0NRWrLw0yaFnpcoFSWnJDMPYhsKu/1uSVgDAQFxzVka8y5MxIUMu4ED9+WB6BOaqu6Wc ncjAn/YbQrETw6UkPuKhxpYo2g8lnH1USIFZuI/bB1xovnLUXrEU/PKL0AS7LYfka+dL Me5g== X-Received: by 10.70.45.102 with SMTP id l6mr60760677pdm.90.1428629000591; Thu, 09 Apr 2015 18:23:20 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id bs4sm291859pdb.21.2015.04.09.18.23.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 18:23:19 -0700 (PDT) Message-ID: <55272602.9030308@gmail.com> Date: Thu, 09 Apr 2015 18:23:14 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <20559.1428585884@vindemiatrix.encs.concordia.ca> <552689EE.4090408@sonnection.nl> <5526C6AA.2060508@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 01:23:23 -0000 On 4/9/15 1:18 PM, Brandon Long wrote: > Since you're continuing this push for atps, I should point out again our > issue. Its not with some editor or serving the large number of records. > > Its how do I validate 50k different third parties to say, sure, they can > send with gmail.com. > > And it also won't help when someone creates yet another domain and now I > need 50001 records. > > Every Google Apps domain has mailing lists (Google Groups) support, should > I put all of them automatically on such a list? That's way more than 50k > records at that point, and even if they're paying me (Google) money, I > don't know if I would trust them to send from gmail.com or google.com. > Currently, for sending mail as google.com, we require vendor level security > audits... am I supposed to just say "ok" to every random mailing list that > googlers are on? Dear Brandon, It is not who is allowed to "send" using your services, it is which third-party services are used by your services. It makes sense to special case DMARC message handling when third-party services are known to convey legitimate messages originating from your services and are doing so without causing abuse that only the DMARC domain can ascertain. Apologies to Murray, it is NOT a matter about whether the scheme scales. This scheme was used by a small group to handle queries against a major portion of the worlds MTAs about a decade ago that audited more than 75% of the world's MTAs (millions and not thousands). Back then the scheme used Postgres which could import matrix tables and handle CIDR based queries to avoid SQL. SQL does not scale. Every 15 minutes reports were generated in the form of zone files carried forward by DNS. Part of this audit included detection of abuse and exclusion of mailing-lists failing to confirm subscriptions. We offered to demonstrate this scheme for a major provider to prove the TPA-Label approach easily scales without issue. ATPS can't. For example, at that time it was rather apparent your own MTAs could be differentiated into three groups of distinctly different levels of abuse. The TPA-Label scheme ensures an ability to react whenever abuse is detected leveraging a scheme offering low latency cached feedback. The complexity that has concerned Hector among others was an attempt to lessen the attack surface and not depend solely on DKIM. Perhaps this should have been made simpler to start. DMARC (ab)use of non-transactional messaging destroys the role of the Sender header field which makes it incompatible with SMTP. Making specific exceptions based on known or knowable relationships should not impose unwarranted risk. Especially when doing so prevents disrupting valuable services. Specialized DKIM signature schemes aimed at preserving just the From header field are based on guessing the next hop a message may take is highly problematic. Mailing-lists share messages among different groups which means a single value is not sufficient. Here again, TPA-Label is able to scale and react as required, but not specialized DKIM signature schemes. Do you really want to impose additional signature handling and overhead awkwardly attempting to cope with real world deployment that is never as simple as might be expected. Regards, Douglas Otis From nobody Thu Apr 9 20:26:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BE01AC3CE for ; Thu, 9 Apr 2015 20:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 XaG3IV8OdkEB for ; Thu, 9 Apr 2015 20:26:43 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA10E1AC3C9 for ; Thu, 9 Apr 2015 20:26:42 -0700 (PDT) Received: from [100.127.201.225] (44.sub-70-193-50.myvzw.com [70.193.50.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B939EC40029; Thu, 9 Apr 2015 22:26:41 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428636402; bh=oao3ColB/vsIZmG04dXzyS1/o22Nby/OQIgjfnU37Dw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=mx7RsUXIMCfoX/dA15W91ytQrQRu4OECIfv/lIj74T9n/IgmnqhVZPQTmFT/9YNZR eh0C9FYRUfQxbGCUuOY15Qs53ftuF57iBVBTLmi1VBlfencNZlL2FdN19Wh+95qnKt 6LAMyEtUiw9HbTPkza0k18ZTghaFrnLJIaqPhChY= User-Agent: K-9 Mail for Android In-Reply-To: <20150409020637.34444.qmail@ary.lan> References: <20150409020637.34444.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 09 Apr 2015 22:26:36 -0500 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 03:26:45 -0000 On April 8, 2015 9:06:37 PM CDT, John Levine wrote: >I updated my conditional signature draft, which is now (thanks to a >suggestion from Ned Freed) the mandatory tag draft. > >https://tools.ietf.org/html/draft-levine-dkim-conditional-01 > >The idea is that you have a weak signature on To, From, Date, >Message-ID but not subject or body, with a new tag that says the >signature is only valid if it's also signed by a specified other >party, who would be the entity that you expect to forward the message. > >So I send a message signed like this: > > From: johnl@taugh.com > To: dmarc@ietf.org > DKIM-Signature: ...; d=taugh.com; ... ordinary good strong signature >DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ... weak signature, >not good yet > >The list does what it does to the message, and now it's signed like >this: > > From: johnl@taugh.com > To: dmarc@ietf.org > DKIM-Signature: ...; d=taugh.com; ... broken strong signature >DKIM-Signature: ...; d=taugh.com; @fs=ietf.org; ... weak signature, >good because it's also signed by ietf.org > DKIM-Signature: ...; d=ietf.org; ... new good strong signature > >It seems to me that this addresses the same issues that the list >mutation stuff does with a lot less complication, and without having >to enumerate all of the ways that a list might change the message. It >only assumes that the list won't change To, From, Date, or Message-ID, >which matches my list experience. The list can make arbitrary changes >to the message body, but if it does, you know who to blame. > >As a lazy list operator, I also like the fact that it doesn't require >lists to do anything different from what they should be doing now, >sign their outgoing mail. Senders put additional weak signatures on >mail sent to addresses that might be mailing lists, verifiers have to >upgrade to understand new signatures. Note that smelling like a >mailing list is not the same as whitelisting mailing lists. > >R's, >John > >PS: The spec uses DKIM-Signature v=2 since mandatory tags aren't >backward compatible, but can we please not go down that rathole again, >at least not until we consider whether double signing is useful. I wouldn't go so far as to say I like this, but it's definitely the least bad solution I've seen so far. Good: 1. No lists of authorized third parties for either senders or receivers to maintain (if the level of security offered by this system is sufficient, then one could just add the new signature all the time). 2. No messing with the original DKIM design decision to not make DKIM mime aware. 3. Simple for middle senders like mailing lists. 4. Implementation and specification not very complex. Bad: 1. Doesn't help third party originators (which may be a feature). 2. Enables third parties to send arbitrary content that will pass (yes, this is the point, but it's also a negative to some degree). The key benefit is that it's only a single third party domain. I think that's reasonable. Although I haven't considered it deeply, I think DKIM v2 is right so that existing verifiers don't process these signatures. I do wonder though if there's a potential replay issue. Once a malicious domain arranges to receive a message with one of these signatures on it, then it can send an arbitrary array of bad things and still pass verification. I don't have a good solution. Short signature validity times is the only thing that comes to mind. Scott K From nobody Thu Apr 9 22:25:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF61ACDAB for ; Thu, 9 Apr 2015 22:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 muQUBtDHB7cr for ; Thu, 9 Apr 2015 22:25:51 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 24AFB1ACDA8 for ; Thu, 9 Apr 2015 22:25:50 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id BD1C11C3917; Fri, 10 Apr 2015 14:25:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A3EE5120EC9; Fri, 10 Apr 2015 14:25:49 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 10 Apr 2015 14:25:49 +0900 Message-ID: <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 05:25:52 -0000 John R Levine writes: > Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll > DKIM verify. Can someone explain in detail how a verifier is supposed to > use this new hack. "Paranoid and easy" approach: Check From alignment of original message parts. If verified, strip all additions and deliver, else check DMARC policy of author domain, and deliver stripped to appropriate folder per policy (ie, /dev/null for reject). This really is easy, the code for stripping specified parts is available in Mailman and presumably a ton of other email applications. More sophisticated approaches could be imagined, especially for mailbox providers who are also MUA providers. From nobody Thu Apr 9 22:38:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFEA1ACDBA for ; Thu, 9 Apr 2015 22:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=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 I9fPLscdO8OV for ; Thu, 9 Apr 2015 22:38:40 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 68FC91AC415 for ; Thu, 9 Apr 2015 22:38:40 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id DC2B51C3926; Fri, 10 Apr 2015 14:38:39 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C1521120EC9; Fri, 10 Apr 2015 14:38:39 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <20150409020637.34444.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 10 Apr 2015 14:38:39 +0900 Message-ID: <87d23cee5c.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 05:38:41 -0000 Murray S. Kucherawy writes: > "might be mailing lists" sounds like a place for heuristics. How > would you identify an address that might be a list, or content > that's likely destined for a list? The "-l" suffix isn't that > common these days. Mailing lists preemptively return-to-author p=reject domains with the advice to tell their mailbox provider to implement RFC ####, and then they'll accept posts from those folks. How to determine which destinations are lists is an exercise for the mailbox provider, but I would suppose the user would be asked to add their posting lists to their profiles, and/or mailbox providers could add *incoming* List-Post field contents to the user's profile, and/or we standardize the ML-Sez-Screw-You DSN so mailbox providers can even parse them out and resend.[1] That plus the "paranoid and easy" option of delivering only original parts per Murray's proposal I think is a good shot at a way forward for mailing lists. Footnotes: [1] This strikes me as a good way to create backscatter, so maybe that's not a great idea. From nobody Thu Apr 9 22:47:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55961A872F for ; Thu, 9 Apr 2015 22:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 EjN7Ir1p2wbZ for ; Thu, 9 Apr 2015 22:47:43 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 548571A7028 for ; Thu, 9 Apr 2015 22:47:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 946BD1C3926; Fri, 10 Apr 2015 14:47:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7BAC7120EC9; Fri, 10 Apr 2015 14:47:42 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <55266C2B.4040708@isdg.net> References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 10 Apr 2015 14:47:42 +0900 Message-ID: <87bniwedq9.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 05:47:44 -0000 Hector Santos writes: > Some how the list domains will still need to register with the > Yahoos and tell the Yahoos, "Please send us two signatures > authorizing out list domain." I would like to call this a > "registration" problem because thats seems to be the area of > disagreement as a real problem. It's an imaginary problem. The *posters*, not the mailing lists, will do the registration. In fact for lists that provide the RFC 2369 List-Post field, it can be done automatically by the MTA (or in the case of mailbox providers who provide the MUA, too, the MUA). > 2) Two (actually all) receivers now have to comply; the MLM MDA > receiver (middle ware) and the final User MDA receivers. All middle > ware MUST NOT strip the weak 1st party signature. The Mediators are the screwees in any case, they have a strong incentive to conform. It's the sending MTAs that are likely to balk. IMHO, worth a try. TPA is still on the table for other 3rd party services (invoicing etc), because conditional signatures do nothing for them. From nobody Fri Apr 10 02:32:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0701AD0B2 for ; Fri, 10 Apr 2015 02:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QcIxq7AlegWd for ; Fri, 10 Apr 2015 02:32:39 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 70A911AD1A6 for ; Fri, 10 Apr 2015 02:32:39 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lNYz862RNz1LBN4; Fri, 10 Apr 2015 11:32:36 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3lNYz84skdz1LBMt; Fri, 10 Apr 2015 11:32:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 7E06F1234E8; Fri, 10 Apr 2015 11:32:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MsvSnlTlX5Vs; Fri, 10 Apr 2015 11:32:35 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id ECDEA12341C; Fri, 10 Apr 2015 11:32:34 +0200 (CEST) Message-ID: <552798B2.2070509@sonnection.nl> Date: Fri, 10 Apr 2015 11:32:34 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" , Hector Santos References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <87bniwedq9.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87bniwedq9.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1428658356; bh=mUMEwTLqWU8bN1bmx/fkxOt7he+11V7jrl8YMxzU0pw=; h=Message-ID:Date:From:To:Subject:From; b=QhC/7dY8soIjl9IFr61HEHSVxoQBhI7mZIdDZuhydtMupzuhZfwiBZ1WzySK877XC jIw7Pb6xY1A8BjwqTQo0CEcRICqIvdzP+VeOnEAyotAHamNqw8OeJ/uYIX4E1JFp/Q WPY9LlbdYSKr0bfYuACH9Lw8OKTEKqs8DFPPS/ZA= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lNYz862RNz1LBN4 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:32:49 -0000 On 04/10/2015 07:47 AM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > Some how the list domains will still need to register with the > > Yahoos and tell the Yahoos, "Please send us two signatures > > authorizing out list domain." I would like to call this a > > "registration" problem because thats seems to be the area of > > disagreement as a real problem. > > It's an imaginary problem. The *posters*, not the mailing lists, will > do the registration. Oohooh, you mean posters, end users, human beings? And how are they supposed to know the address they use is a mailing list? Let me give you an example: I run a mailing list for parents of schoolkids, who maintain a schedule to take care of the kids during lunch time (go out with the kids to play football, eat with them etc.). They use the list to ask 'who can take my turn, I'm ill' and that sort of things. I'm pretty sure 90+ percent of these parents have no idea they're sending mail to a mailing list. Clicking on a spam button is something that can be explained, because people hate to receive spam. I doubt clicking on a 'this is a mailing list recipient' button is something that can easily be explained to people. As list manager I don't know how to explain this to them, as they're using all sorts of ESPs including some smaller national ones which probably won't have this button. Furthermore, as a list manager I set all Yahoo and AOL users to 'read-only' last year. How am I supposed to know when they will have marked my mailing list as 'mailing list recipient', so I can set them to read+write again? > In fact for lists that provide the RFC 2369 > List-Post field, it can be done automatically by the MTA (or in the > case of mailbox providers who provide the MUA, too, the MUA). This may be true for the 10 biggest ESPs of the world, but it won't hold for the thousands of smaller ESPs/ISPs or businesses who have medium to small IT departments and no specific e-mail expertise. > > > 2) Two (actually all) receivers now have to comply; the MLM MDA > > receiver (middle ware) and the final User MDA receivers. All middle > > ware MUST NOT strip the weak 1st party signature. > > The Mediators are the screwees in any case, they have a strong > incentive to conform. Even with a strong incentive it will take quite some time before all/most of the MLMs will have been upgraded to understand v2. /rolf From nobody Fri Apr 10 08:05:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72B31A1A29 for ; Fri, 10 Apr 2015 08:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 WOLzjrURdiAf for ; Fri, 10 Apr 2015 08:05:49 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542FF1A1A28 for ; Fri, 10 Apr 2015 08:05:49 -0700 (PDT) Received: (qmail 27970 invoked from network); 10 Apr 2015 15:05:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6d41.5527e6cc.k1504; bh=kULihkq1KBqlKtt5ths8zMxT9ub02/gKhuH39SbxNpg=; b=FpFGZd6u0tyq0/pYX3oZ6Nnh+Ou0cREH4dsbGiCeVySy62LRMPUGFbU/dp4tSnsZjPJTzZsjJw6xSMz6TtZ3HtTyxU7nfaEIvrtdyT9QVQ3Qp3peOPaQEqlrLLPn+7jPgZxSYQ1DlE26qJPjNpIQ2a/7gXaQ8iBhq+8gKC3bmSO85xALxCzWPehKM/xXk+OzkOgSJb7pE6olVP0iE3DuRSn+KKsVf99k6UGSjiUl7KBbKtG6ALrtZmjPrfWJJQdN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6d41.5527e6cc.k1504; bh=kULihkq1KBqlKtt5ths8zMxT9ub02/gKhuH39SbxNpg=; b=V8nshlHAioJ6i/x4F5Lw6iVyiiv4Wi/mT9ak345AX+O2Qfs10GTY5VGNa7GJLIl7XfCFPOXarlwVIEhKPjY2VC02y9AJDwYM3J1hYUDu5pqReUOGEOhMa080eIJwWEBwLXtyGHbWSmALjAPbBDqOlh4m2fMrTebc/qIj05rf4lSIIWXYm8m+Pk2nlB+/zg1uCnkWhghIAkOm7rg3lt9R0uc8r5DAuNU4HN0FiQSf8LwHyukiNC0vCsm/VYum2EKv Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 10 Apr 2015 15:05:48 -0000 Date: 10 Apr 2015 11:05:47 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 15:05:50 -0000 > > Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll > > DKIM verify. Can someone explain in detail how a verifier is supposed to > > use this new hack. > > "Paranoid and easy" approach: Check From alignment of original message > parts. If verified, strip all additions and deliver, ... Gee, list mail will look just like malware phishes, "we removed dangerous content from this message, but for reasons we can't explain we delivered it to you anyway". Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Apr 10 09:37:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406581A8712 for ; Fri, 10 Apr 2015 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_45=0.6] autolearn=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 JZ0igsgqrqp9 for ; Fri, 10 Apr 2015 09:37:31 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D1E731A3BA6 for ; Fri, 10 Apr 2015 09:37:30 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 63EAC1C393D; Sat, 11 Apr 2015 01:37:29 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4A0D1120EC9; Sat, 11 Apr 2015 01:37:29 +0900 (JST) From: "Stephen J. Turnbull" To: R.E.Sonneveld@sonnection.nl In-Reply-To: <552798B2.2070509@sonnection.nl> References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <87bniwedq9.fsf@uwakimon.sk.tsukuba.ac.jp> <552798B2.2070509@sonnection.nl> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 11 Apr 2015 01:37:29 +0900 Message-ID: <87sic8c52u.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:37:33 -0000 Rolf E. Sonneveld writes: > On 04/10/2015 07:47 AM, Stephen J. Turnbull wrote: > > It's an imaginary problem. The *posters*, not the mailing lists, will > > do the registration. > > Oohooh, you mean posters, end users, human beings? And how are they > supposed to know the address they use is a mailing list? It really doesn't matter at this stage? Don't let the impossible dream be the enemy of improvement. *Some* posters will know. *Other* posters will have clueful mailbox providers who will be adding addresses reaped from the List-Post field in the headers of incoming messages. AFAICS, assuming that there's no gaping security hole in the protocols enabling mass-spamming or mass-phishing, the protocol can be implemented reasonably rapidly and benefit a lot of users. Dunno if any of the big guys care, of course (a cynic would say "of course NOT"). And as a last resort, the mailing list can tell them when it explains why it isn't accepting their post. ;-) Or if you as a list owner don't like that, you can use one of several existing mitigations instead. Nobody (except *my* subscribers @$%&.com and @"&#$%!.com :-) need suffer, and some will be better off. > Furthermore, as a list manager I set all Yahoo and AOL users to > 'read-only' last year. How am I supposed to know when they will > have marked my mailing list as 'mailing list recipient', so I can > set them to read+write again? Same way you'll know now. If "no way", what have your subscribers lost? > > In fact for lists that provide the RFC 2369 > > List-Post field, it can be done automatically by the MTA (or in the > > case of mailbox providers who provide the MUA, too, the MUA). > > This may be true for the 10 biggest ESPs of the world, but it won't hold > for the thousands of smaller ESPs/ISPs or businesses who have medium to > small IT departments and no specific e-mail expertise. So they continue their current mitigations. Who loses by the availability of this new mitigation? > Even with a strong incentive it will take quite some time before > all/most of the MLMs will have been upgraded to understand v2. Unfortunately, "&#$%!.com and $%&.com don't follow your rules. They implement before having answers to your questions, screwing some of your subscribers. Bottom line: your complaint is ahead of its time. It's just the normal set of lags in deployment, meaning that some users don't get the benefits other users do, or don't get them until later. Tell us first about users who are *worse off* because of implementing such protocols (envy experienced by users at slow-to-implement providers and MLMs doesn't count). If we don't find any such (which I would count as a grave but not necessarily fatal defect), *then* we can start on benefit/cost analysis of whether enough users benefit to justify the costs. From nobody Fri Apr 10 09:44:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E923F1A886B for ; Fri, 10 Apr 2015 09:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 4L4fMSh3iLlq for ; Fri, 10 Apr 2015 09:44:21 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EF80C1A86F6 for ; Fri, 10 Apr 2015 09:44:20 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 581AC1C385C; Sat, 11 Apr 2015 01:44:20 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2FBAD120EC9; Sat, 11 Apr 2015 01:44:20 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 11 Apr 2015 01:44:20 +0900 Message-ID: <87r3rsc4rf.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:44:22 -0000 John R Levine writes: > > > Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll > > > DKIM verify. Can someone explain in detail how a verifier is supposed to > > > use this new hack. > > > > "Paranoid and easy" approach: Check From alignment of original message > > parts. If verified, strip all additions and deliver, ... > > Gee, list mail will look just like malware phishes, "we removed dangerous > content from this message, but for reasons we can't explain we delivered > it to you anyway". No, it will look exactly like what some folks think MLMs should be doing anyway: passing those posts through verbatim with no value-added doodads added. Users will never notice, I bet, and if they do, you explain and they go "oh, ok" 99.44%[1] of the time. (Boy you're in a pessimistic mood. Usually your criticisms are quite constructive even when they're negative, but this series has been quite, uh, "and your point might be?") Footnotes: [1] If you're not an ancient American, you might not recognize that figure: it's the old Ivory Soap claim of 99.44% purity. It's my way of saying "I made the number up, but I believe it to be high". From nobody Fri Apr 10 09:54:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B921AD35D for ; Fri, 10 Apr 2015 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 IrJjX_SKd7WX for ; Fri, 10 Apr 2015 09:54:13 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC361AD35E for ; Fri, 10 Apr 2015 09:54:12 -0700 (PDT) Received: (qmail 51283 invoked from network); 10 Apr 2015 16:54:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c852.55280033.k1504; bh=42wcWzemDeCMaYmMGii1MryUVwM0HxBPEbNl1WXuT/s=; b=wRXN/gl/kb6Q7cyRfODET9XO6azaTsKjkJtl4dC64cNhhGBMQ+TM0cfqV2qTZNIsdydrQ02qN+KrFUu7YAXMnnT6zlQbYyK/KY+EZnDN4W7Gt334yjhD9zJ61RbwMwm/RFuwPf2tjAru4zFqG6iC095Za+TOBtqy65qNibT8tWOPSOj+zfe9uYaiBuNCds4YOR/Jl2VboM2g6KnLwTw1NH2liQjX1pjZVcgqMYX3G659Ox5+gYOirXQtGBrNabAw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c852.55280033.k1504; bh=42wcWzemDeCMaYmMGii1MryUVwM0HxBPEbNl1WXuT/s=; b=2TvL/cTVyKIPzAyMSBEDLCdNhAsbxRkUjgOEgjcGwcs5XeNsU1alqZpzB3UEESA5mZLzUE0XHKwdge6D0aL+59JwzFVoPUmlAHuG9S9CFvCS8yyKCdlduw1eNpnO13uivlr2PDIluMdDAWLbK2++ZohoJnLpkveoL0uKPDCsEegHdFfgvAyepamcgrodJ02b5I1FtThOSzK6he1DC8NLRLv2iElYG5KFO107BdGirToaNY6MRG8j7F+8LVGUmwDI Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 10 Apr 2015 16:54:11 -0000 Date: 10 Apr 2015 12:54:10 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <87r3rsc4rf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> <87r3rsc4rf.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:54:14 -0000 > > Gee, list mail will look just like malware phishes, "we removed dangerous > > content from this message, but for reasons we can't explain we delivered > > it to you anyway". > > No, it will look exactly like what some folks think MLMs should be > doing anyway: passing those posts through verbatim with no value-added > doodads added. Users will never notice, I bet, and if they do, you > explain and they go "oh, ok" 99.44%[1] of the time. We have lists where we would be unhappy if the added stuff went away, e.g., a line at the front reminding people that the messages are private and not to be forwarded. Even in the unlikely event that MUAs would do this, which I find vanishingly unlikely, it doesn't do what lists managers need. I think it would be useful to limit ourselves to hacks that don't require changes to MUAs, minimal changes to list software and sending mail systems, and don't use external oracles. Then they might have some chance of adoption. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. [1] This proposal doesn't float. From nobody Fri Apr 10 10:09:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF191A1A11 for ; Fri, 10 Apr 2015 10:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 zH9k3onl6meP for ; Fri, 10 Apr 2015 10:09:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A82D1A0385 for ; Fri, 10 Apr 2015 10:09:19 -0700 (PDT) Received: (qmail 53271 invoked from network); 10 Apr 2015 17:09:18 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 10 Apr 2015 17:09:18 -0000 Date: 10 Apr 2015 17:08:56 -0000 Message-ID: <20150410170856.730.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 17:09:21 -0000 >I wouldn't go so far as to say I like this, but it's definitely the least bad solution I've >seen so far. That's how I intended it: This one stinks 47% less than the others! >1. Doesn't help third party originators (which may be a feature). I wouldn't say it's a feature, but third parties are a much harder problem. The least bad I can think of for that scenario is some sort of browser oauth thing that lets the third party log into the user's account to send the message, which is OK for individual mail an article but not for the PTA's mailing list. >2. Enables third parties to send arbitrary content that will pass (yes, this is the point, >but it's also a negative to some degree). ... >I do wonder though if there's a potential replay issue. I'm hoping that signing the Message-ID will limit the damage there. Many mail systems combine multiple messages with the same ID even if they don't have the same contents. R's, John From nobody Fri Apr 10 13:02:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB21A8842 for ; Fri, 10 Apr 2015 13:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 rulx-VI4R6u8 for ; Fri, 10 Apr 2015 13:02:30 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 094A51A87E8 for ; Fri, 10 Apr 2015 13:02:20 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 382601C3942; Sat, 11 Apr 2015 05:02:19 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0EB33120EC9; Sat, 11 Apr 2015 05:02:19 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> <87r3rsc4rf.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 11 Apr 2015 05:02:18 +0900 Message-ID: <87oamvda5x.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 20:02:32 -0000 John R Levine writes: > We have lists where we would be unhappy if the added stuff went away, > e.g., a line at the front reminding people that the messages are private > and not to be forwarded. OK, so that's new harm done by this behavior. On some such lists it might be mitigated by the fact that the mail actually gets through now. (But unambiguously in other cases the mail *was* getting through unscathed but now the recipient MTA decides to strip.) > Even in the unlikely event that MUAs would do this, MUAs, unlikely, I suppose. MTAs could do it too, and I think that's more likely. > which I find vanishingly unlikely, it doesn't do what lists > managers need. Stop exaggerating. It is not the case that anywhere near 100% of list managers actually *need* doodads, although a few (covering less than 1% of recipients, I bet) do need them, and many find them attractive. > I think it would be useful to limit ourselves to hacks that don't require > changes to MUAs, draft-kucherawy-dkim-list-canon requires no changes to MUAs, although mailbox + MUA providers *might* want to do it on the MUA side rather than the MTA side. > minimal changes to list software draft-kucherawy-dkim-list-canon requires no changes to list software, and it's purpose is to avoid changes to list configurations (or enable changes that currently must be avoided because of DMARC). > and sending mail systems, I don't see how draft-kucherawy-dkim-list-canon requires more changes of the sending *system* than draft-levine-dkim-conditional or draft-kucherawy-dkim-delegate does. True, the software would be more complex, but presumably it would be developed by Postfix, Exim, Sendmail, and Microsoft, plus maybe an independent milter project or two, and the "paranoid and easy" configuration is dead simple and possibly suitable as a default (although somewhat dangerous, see "unambiguously" above). > and don't use external oracles. I see no external oracles required. Oracles are optional and desirable, yes, but that's true of everything in mail filtering. > Then they might have some chance of adoption. From nobody Fri Apr 10 13:42:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1D41A88F7 for ; Fri, 10 Apr 2015 13:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 EXc4fAKpQdkB for ; Fri, 10 Apr 2015 13:42:41 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429651A88F4 for ; Fri, 10 Apr 2015 13:42:41 -0700 (PDT) Received: (qmail 87850 invoked from network); 10 Apr 2015 20:42:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15729.552835bf.k1504; bh=epNJ4R3dAqvhcZihQJ1y5Pn8VYnFwsjVBAPPSy8mdX8=; b=Zyc7Av/YjXLAMkEidyyr+bmfADZvnxjBHNuBGXU0ESRtkPWfASSpT4L0JvyTrZvydCZHTeoRflHgUvce92fFP6ZWdb7MQxfPTlUmZy+wF6a4DIHWFdPlx9bIOyivAFL1EfZLCtVm4+U7Ku7jeWtdpMff6C7i/waXf/yY0QbulrdTwUZfb95YHDosPIoVlE9ecu79e0CK52nnFXbywhjsKE0SIoYp/16t9L1Dyv4ZsdoV6f2g6UUnXtt5coXinBXU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15729.552835bf.k1504; bh=epNJ4R3dAqvhcZihQJ1y5Pn8VYnFwsjVBAPPSy8mdX8=; b=tivyx+ncjW7jwKONLHSrfByvCm15Q94Vn2I0wfEvn7GrwY6PoI45EaB8w+9O43dcp4cGN3zNELqEcUIxUoQZbg3h8PMg9yKBlDYCRQT0Oxg6CPYYzwS+Ct5ug2c0Q9eYstv6KOMdKg2sT+XFUiRbatBxl72F32vuZQQ4vIfwWLqwkFvPBeQSFXwVfeEKdnWm8gD94v0zKaBkacJOTylz9FwfYjjDn7E4G3XTXHDMKqUc4Sb+VJNag9Nd+spkNvZW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 10 Apr 2015 20:42:39 -0000 Date: 10 Apr 2015 16:42:38 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <87oamvda5x.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> <87r3rsc4rf.fsf@uwakimon.sk.tsukuba.ac.jp> <87oamvda5x.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 20:42:42 -0000 > Stop exaggerating. It is not the case that anywhere near 100% of list > managers actually *need* doodads, although a few (covering less than > 1% of recipients, I bet) do need them, and many find them attractive. Well, now we're back to arbitrarily close to 100% of list managers can live with rewriting the From: line, too. > > I think it would be useful to limit ourselves to hacks that don't require > > changes to MUAs, Well, OK, don't depends on recipients rewriting incoming messages. > > and sending mail systems, > > I don't see how draft-kucherawy-dkim-list-canon requires more changes > of the sending *system* That one doesn't. Other proposals involve the sending system publishing list of authorized forwarders and the like, which seems like a non-starter. > > and don't use external oracles. > I see no external oracles required. That would include global lists of known mailing lists. Again, Murray and I don't need them but other proposals do. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Apr 10 14:29:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58ACA1A8A7A for ; Fri, 10 Apr 2015 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7PM9lFqmyw8S for ; Fri, 10 Apr 2015 14:29:34 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (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 359691A8A7D for ; Fri, 10 Apr 2015 14:29:34 -0700 (PDT) Received: by wgin8 with SMTP id n8so29533932wgi.0 for ; Fri, 10 Apr 2015 14:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wXsS3ceDUsdMMlksQGasH1FQp4VEBcD/NJxXJIl1OKo=; b=hJ8devyG+mxd4ZZ2i8oQ3VciJKbQy9hD0wXHdZIYbuQOwkmgUfX/FGE/+tDtRJCdLV heJqz+0IdccsYdGrEPXwpV/g4zCXrh9XEvEttioFXZNrQoBQNV5S4LoV5TwiUkO7urBt +KMHOjElfuKJDC3L54Y62BeRigBnznmRIRsE5zvwghaIXUTagfdfmYRTBoI6440895mR ihMVk0ozglVXStxvfZGvujxfkNp6ykV+aDIQfR8srcyYVpL+hceE4+Ddl33c2C8inudh xsXtGrc4AxRJIcLuu+bPsiE5D/DVJi+rZuF7QUnKTDtbydjCQFzkoxwRh/2hALQ2koqX FIVA== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr6243357wjc.111.1428701372979; Fri, 10 Apr 2015 14:29:32 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Fri, 10 Apr 2015 14:29:32 -0700 (PDT) In-Reply-To: <87bniwedq9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150409020637.34444.qmail@ary.lan> <55266C2B.4040708@isdg.net> <87bniwedq9.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Fri, 10 Apr 2015 14:29:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7bacb11ed3a0a305136575f6 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:29:37 -0000 --047d7bacb11ed3a0a305136575f6 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 9, 2015 at 10:47 PM, Stephen J. Turnbull wrote: > TPA is still on the table for other 3rd party services (invoicing etc), > because conditional signatures do nothing for them. > I suggest that TPA or ATPS are way too complicated for third party services like invoicing, because in that case the relationship between the parties is solid enough that one could just give the other a signing key and be done with it. We can do that today. -MSK --047d7bacb11ed3a0a305136575f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 9, 2015 at 10:47 PM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
TPA is still on the tab= le for other 3rd party services (invoicing etc),
because conditional signatures do nothing for them.
I suggest that TPA or ATPS are way too complicated for third p= arty services like invoicing, because in that case the relationship between= the parties is solid enough that one could just give the other a signing k= ey and be done with it.=C2=A0 We can do that today.

-MSK =
--047d7bacb11ed3a0a305136575f6-- From nobody Fri Apr 10 14:40:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF21A8AC4 for ; Fri, 10 Apr 2015 14:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 Yx2HPBFynNNP for ; Fri, 10 Apr 2015 14:40:32 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3AD1A8AC1 for ; Fri, 10 Apr 2015 14:40:32 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 252C41C3953; Sat, 11 Apr 2015 06:40:31 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0B21C120EC9; Sat, 11 Apr 2015 06:40:31 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20150408161906.32839.qmail@ary.lan> <201504082308.t38N8Riw016536@shadrach.encs.concordia.ca> <87egnseeqq.fsf@uwakimon.sk.tsukuba.ac.jp> <87r3rsc4rf.fsf@uwakimon.sk.tsukuba.ac.jp> <87oamvda5x.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 11 Apr 2015 06:40:30 +0900 Message-ID: <87mw2fd5m9.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:40:34 -0000 John R Levine writes: > Again, Murray and I don't need them but other proposals do. OK, FWIW, I'm only interested in your proposals at the moment. :-) Thanks for the courteous response; I didn't entirely deserve it. From nobody Sun Apr 12 16:34:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10DD1B39E9 for ; Sun, 12 Apr 2015 16:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 l0PtM0cjLveR for ; Sun, 12 Apr 2015 16:34:07 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427D51B39E8 for ; Sun, 12 Apr 2015 16:34:07 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C94BDC40078 for ; Sun, 12 Apr 2015 18:34:05 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428881645; bh=bwgGPIEuW1GVqtUkcc+v0gNx01FG0Z+JjCZI9GMfDGI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=f7GCtygsaA9jBJ1C8aayS2bGaru36RCIStw2ByxCjVtr1qfkhDpm/z3eoVnHbMymR kBJo3FW7yoBrTXfJxHwYIXN4fJObGY7jJdNIRACii+ZbuWMQKFw1IFNK/qkyQBMmhO U7K7nNctiJJIpJSn9nm+xC4E5wMwswSSnpRQFVIU= From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 12 Apr 2015 19:34:06 -0400 Message-ID: <1646939.LNu9R6Ga10@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150410170856.730.qmail@ary.lan> References: <20150410170856.730.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 23:34:08 -0000 On Friday, April 10, 2015 05:08:56 PM John Levine wrote: > >I wouldn't go so far as to say I like this, but it's definitely the least > >bad solution I've seen so far. > > That's how I intended it: This one stinks 47% less than the others! > > >1. Doesn't help third party originators (which may be a feature). > > I wouldn't say it's a feature, but third parties are a much harder > problem. The least bad I can think of for that scenario is some sort > of browser oauth thing that lets the third party log into the user's > account to send the message, which is OK for individual mail an > article but not for the PTA's mailing list. Yeah. I don't think it's possible to allow sending by arbitrary 'authorized' third parties without also making it possible to allow sending by anyone. > >2. Enables third parties to send arbitrary content that will pass (yes, > >this is the point, but it's also a negative to some degree). ... > > > >I do wonder though if there's a potential replay issue. > > I'm hoping that signing the Message-ID will limit the damage there. > Many mail systems combine multiple messages with the same ID even if > they don't have the same contents. I know Message ID is supposed to be globally unique, I don't think that Message ID has historically been viewed as a security property. I got two copies of this message from you with Message ID Message-ID: <20150410170856.730.qmail@ary.lan>. One was sent directly to me and one via the mailing list. If I were tracking Message IDs for reuse, one of those messages would be considered bad. My system doesn't combine them, but if it did, I don't know what content would be displayed. For replay protection, I think the Message ID could work, but I think the list would have to change to use its own Message ID associated with its signature. The need to keep and consult a database of historical Message IDs does add a substantial negative in my book. Scott K From nobody Sun Apr 12 20:02:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E711A8A51 for ; Sun, 12 Apr 2015 20:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 sgEHpOFLyc9q for ; Sun, 12 Apr 2015 20:02:45 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA331A8A4B for ; Sun, 12 Apr 2015 20:02:45 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 645E61C3878; Mon, 13 Apr 2015 12:02:43 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4A383120EC9; Mon, 13 Apr 2015 12:02:43 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <1646939.LNu9R6Ga10@kitterma-e6430> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 13 Apr 2015 12:02:43 +0900 Message-ID: <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 03:02:47 -0000 Scott Kitterman writes: > Yeah. I don't think it's possible to allow sending by arbitrary > 'authorized' third parties without also making it possible to allow > sending by anyone. I don't know how you'd go about authorizing the third party and validating the authorization, but AFAICS an authorized sender, with that address in the Sender field and DMARC-but-with-Sender-Alignment, does for third parties what DMARC does for first parties in From. (Cue Douglas Otis pitching draft-otis-tpa-label and Hector Santos pitching some policy framework with authorization via DNS, but I don't think that auth-by-DNS scales to humongous mailbox providers.) > > >2. Enables third parties to send arbitrary content that will > > > pass (yes, this is the point, but it's also a negative to > > > some degree). ... Sure. So are the ads that some providers post on their webmail clients, and is allowing first parties to send mail at all. (I wish my employer would stop, or at least slow down, for example.) I really don't see how unwanted content from *authorized* 3rd parties can be considered to count against these proposals. If the recipient doesn't like it, they revoke the authorization; problem solved. > For replay protection, I think the Message ID could work, but I > think the list would have to change to use its own Message ID > associated with its signature. You can have your cake and eat it, too. The list can sign a Resent-Message-ID (as well as the original if it wants to). > The need to keep and consult a database of historical Message IDs > does add a substantial negative in my book. Not if you do it already, and many MUAs already do or have an option to do it. Remember, anti-spam measures don't have to be perfect, they just need to make the mischief unprofitable. From nobody Sun Apr 12 22:13:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263681B2B99 for ; Sun, 12 Apr 2015 22:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 t29nlKttK3XV for ; Sun, 12 Apr 2015 22:13:08 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::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 CFE471B2B75 for ; Sun, 12 Apr 2015 22:13:08 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so94969519pdb.0 for ; Sun, 12 Apr 2015 22:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gEP+s0pyv50Kfm68ShG/Dug0RyaThUgnHiEelkB137A=; b=ID67Z8NPaGG5VTq3z5fZ8qT5aXd+6mxurCgamQz4kO7apjB+QVgjGWFhfmVWmt5uj/ w2gJcwibiMfOP3Y/uIvLOjKJM/N+VSzGiIphEznmYs8V9I6mjfK+QI2UcLS8gpqvixwg Lh/z0q/su0ENv43qdJGD1DnyCTerrjd2n6dDajYtQSLotv+JoJZwyYlZr0x7iyYpnFwy S74U56Mzkl3wjNBeedl1x2sPCFSRVLV/aHbwKylI7Nxjgkv3tx5aMGLjS4LV0ojUGjKa Bi9wxG7C3UGtz9jCIBcEtxieI2+oe7iXpuf3P3szOWA7pmF0wG4hWdPxCf3CYVLTlmIw jtNA== X-Received: by 10.70.103.230 with SMTP id fz6mr23642837pdb.1.1428901987559; Sun, 12 Apr 2015 22:13:07 -0700 (PDT) Received: from justsomecomcastuser.selfip.org ([2601:9:3400:5f3:6d12:9c0e:1cb8:d7df]) by mx.google.com with ESMTPSA id p5sm5854714pdi.2.2015.04.12.22.13.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2015 22:13:05 -0700 (PDT) Message-ID: <552B5060.3000808@gmail.com> Date: Sun, 12 Apr 2015 22:13:04 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 05:13:20 -0000 On 4/12/15 8:02 PM, Stephen J. Turnbull wrote: > Scott Kitterman writes: > > > Yeah. I don't think it's possible to allow sending by arbitrary > > 'authorized' third parties without also making it possible to allow > > sending by anyone. > > I don't know how you'd go about authorizing the third party and > validating the authorization, but AFAICS an authorized sender, with > that address in the Sender field and DMARC-but-with-Sender-Alignment, > does for third parties what DMARC does for first parties in From. > (Cue Douglas Otis pitching draft-otis-tpa-label and Hector Santos > pitching some policy framework with authorization via DNS, but I don't > think that auth-by-DNS scales to humongous mailbox providers.) Dear Stephen, The TPA-Label scheme can signal new requirements, such as John's suggestion for a new browser authorization scheme. With respect to auth-by-DNS, SPF already does this for outbound IP addresses. The reason MAPS was acquired was to leverage DNS to reduce processing overhead essential for malware scanning. Back then, we were answering queries from about 70% of the world's MTAs and were processing about 5 million logs/sec. SQL could never handle this load on a single server. Custom routines were written in C doing heap or Judy sort before transferring to zones. Our normal deployment supported a free service. TPA-Label on the other hand would only need to handle a tiny fraction of the mail volume requiring a DMARC exception. Unlike the various DKIM signing schemes that attempt to predict the needs of the next hop, the TPA-Label scheme can separately accommodate all possible sources and distribution patterns while giving the DMARC domain an opportunity to quickly block abuse as determined by DMARC feedback which should address concerns related to this category of email. Requiring a signing process to guess the needs of the next hop will be wrong fairly often and ossify email into becoming more fragile and less reliable. The TPA-Label scheme could also permit incremental deployment of the next greatest thing without being tied to some potentially prone technique while also affording better message processing information. Message-IDs can help establish a path a message takes through various third-party services, and to identify where problems exist. No scheme is able to function when administrators fail to communicate, where TPA-Label offers actionable and authoritative input. If the DMARC domain fails to step up, then a reasonable fallback could require the display of the Sender header offering the needed alignment. That said, I am also working on plan B. Regards, Douglas Otis > > > > >2. Enables third parties to send arbitrary content that will > > > > pass (yes, this is the point, but it's also a negative to > > > > some degree). ... > > Sure. So are the ads that some providers post on their webmail > clients, and is allowing first parties to send mail at all. (I wish > my employer would stop, or at least slow down, for example.) I really > don't see how unwanted content from *authorized* 3rd parties can be > considered to count against these proposals. If the recipient doesn't > like it, they revoke the authorization; problem solved. > > > For replay protection, I think the Message ID could work, but I > > think the list would have to change to use its own Message ID > > associated with its signature. > > You can have your cake and eat it, too. The list can sign a > Resent-Message-ID (as well as the original if it wants to). > > > The need to keep and consult a database of historical Message IDs > > does add a substantial negative in my book. > > Not if you do it already, and many MUAs already do or have an option > to do it. > > Remember, anti-spam measures don't have to be perfect, they just need > to make the mischief unprofitable. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Apr 13 08:56:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B35E1A87C5 for ; Mon, 13 Apr 2015 00:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 pUsF6T0AwdMc for ; Mon, 13 Apr 2015 00:58:43 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ACBDA1A8799 for ; Mon, 13 Apr 2015 00:58:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 2AEAC1C388E; Mon, 13 Apr 2015 16:58:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 06066120EC9; Mon, 13 Apr 2015 16:58:41 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <552B5060.3000808@gmail.com> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 13 Apr 2015 16:58:41 +0900 Message-ID: <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: X-Mailman-Approved-At: Mon, 13 Apr 2015 08:56:38 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 07:58:45 -0000 Douglas Otis writes: > If the DMARC domain fails to step up, then a reasonable fallback > could require the display of the Sender header offering the needed > alignment. I don't understand this. We already see that most professional spammers exhibit From alignment on much of their traffic. Sender alignment is just as easy to implement, even if we could expect MUAs to conform to the "required display of Sender field". Users do not understand the Sender field as far as I can tell. Regards, From nobody Mon Apr 13 11:21:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93FC1AD0AE for ; Mon, 13 Apr 2015 11:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 MVaBqrPgNGjH for ; Mon, 13 Apr 2015 11:21:25 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 9E7821A1A0F for ; Mon, 13 Apr 2015 11:21:24 -0700 (PDT) Received: by wiun10 with SMTP id n10so77038713wiu.1 for ; Mon, 13 Apr 2015 11:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K6Vdi2PpBUMaphu0PGnn5jpbEIhmf/n1WxH436WG0Nc=; b=w7RKRXmwY+WHmEDcWLRsg2rhDbE18Ag3jL94vuLFtMUbpDUWG00ndd4bejC/kGq3fZ ByPbvlPLuuwtUsl9rzAuWTJZQD27mwm/TYtQvdgBRX2Y3ZX1BabuNS2rHUV0akhV/rfp mkNyxtPi3FSaLcwv0tXFTd+59kcqaT6dtdnfc0HS+6CfNPjzUoz1d24UkoQoHdG59Wc7 S4y/XEeuImbzOwpzGTlJgn+w5ZDndVRlmXjZ7Um0MQg/iwk2T1/bN15MDwqxgYWEf6h7 kI1inanEBLHPjvfXivrhqoaZbkMp23IOiC4186j0wVleQEROXC2V6NBK3YmnB7jAXOsq oWJw== MIME-Version: 1.0 X-Received: by 10.180.80.105 with SMTP id q9mr4922535wix.52.1428949283309; Mon, 13 Apr 2015 11:21:23 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Mon, 13 Apr 2015 11:21:23 -0700 (PDT) In-Reply-To: <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 13 Apr 2015 11:21:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d04428e3e6f0c4d05139f2e0e Archived-At: Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 18:21:26 -0000 --f46d04428e3e6f0c4d05139f2e0e Content-Type: text/plain; charset=UTF-8 On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull < turnbull@sk.tsukuba.ac.jp> wrote: > Douglas Otis writes: > > > If the DMARC domain fails to step up, then a reasonable fallback > > could require the display of the Sender header offering the needed > > alignment. > > I don't understand this. We already see that most professional > spammers exhibit From alignment on much of their traffic. Sender > alignment is just as easy to implement, even if we could expect MUAs > to conform to the "required display of Sender field". Users do not > understand the Sender field as far as I can tell. > To the extent comprehensible, TPA is meant to allow author A to tell receiver B that mail that has C in (for example) the List-ID field should be treated as though it came from A. However, I concur that it means an impostor can simply do what the TPA record says and thereby succeed; few of the properties TPA identifies are authenticated in any way. It might be helpful to get alignment working through paths that invalidate SPF or DKIM, but compared to the fact that it basically advertises how to get a "pass" in an invisible way, it's more scary to me than not. Now, if that isn't the case, then I suggest the document falls short of explaining how this is not an attack vector. Also, Doug insists that this is not registration, but I don't know how he can claim this since it requires a DNS entry for every {A, C} pair that exists which must then be queried by every B that might receive mail from C. Unless I'm not understanding use of the term, that's exactly how I believe we've been using "registration" lately, and the argument on the table is that any registration scheme is basically a non-starter for operators for which the cardinality of AxC is or could be large. As I've pointed out before, ATPS, DSAP, and all other earlier proposals that required a registration step have also been non-starters. I'm not picking on TPA here; I'm saying this entire family of solutions is probably not the best use of our time, and I suggest there's empirical evidence to support that claim. -MSK --f46d04428e3e6f0c4d05139f2e0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
Douglas Otis writes:

=C2=A0> If the DMARC domain fails to step up, then a reasonable fallback=
=C2=A0> could require the display of the Sender header offering the need= ed
=C2=A0> alignment.

I don't understand this.=C2=A0 We already see that most professi= onal
spammers exhibit From alignment on much of their traffic.=C2=A0 Sender
alignment is just as easy to implement, even if we could expect MUAs
to conform to the "required display of Sender field".=C2=A0 Users= do not
understand the Sender field as far as I can tell.

=
To the extent comprehensible, TPA is meant to allow author A to = tell receiver B that mail that has C in (for example) the List-ID field sho= uld be treated as though it came from A.=C2=A0 However, I concur that it me= ans an impostor can simply do what the TPA record says and thereby succeed;= few of the properties TPA identifies are authenticated in any way.=C2=A0 I= t might be helpful to get alignment working through paths that invalidate S= PF or DKIM, but compared to the fact that it basically advertises how to ge= t a "pass" in an invisible way, it's more scary to me than no= t.=C2=A0 Now, if that isn't the case, then I suggest the document falls= short of explaining how this is not an attack vector.

Also, Doug insists that this is not registration, but I don't = know how he can claim this since it requires a DNS entry for every {A, C} p= air that exists which must then be queried by every B that might receive ma= il from C.=C2=A0 Unless I'm not understanding use of the term, that'= ;s exactly how I believe we've been using "registration" late= ly, and the argument on the table is that any registration scheme is basica= lly a non-starter for operators for which the cardinality of AxC is or coul= d be large.

As I've pointed out before, ATPS, DSAP, a= nd all other earlier proposals that required a registration step have also = been non-starters.=C2=A0 I'm not picking on TPA here; I'm saying th= is entire family of solutions is probably not the best use of our time, and= I suggest there's empirical evidence to support that claim.
<= div>
-MSK
--f46d04428e3e6f0c4d05139f2e0e-- From nobody Mon Apr 13 14:23:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176091A8795 for ; Mon, 13 Apr 2015 14:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 HaHmD6wPWW1s for ; Mon, 13 Apr 2015 14:22:59 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 527B51A8797 for ; Mon, 13 Apr 2015 14:22:58 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3lQjbN2NGyz5Mgfl; Mon, 13 Apr 2015 23:22:56 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lQjbN1FS8z5Mgff; Mon, 13 Apr 2015 23:22:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id C24EF1234D4; Mon, 13 Apr 2015 23:22:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xiOiJ4C1lm41; Mon, 13 Apr 2015 23:22:53 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id D847B1234C8; Mon, 13 Apr 2015 23:22:52 +0200 (CEST) Message-ID: <552C33AC.3050009@sonnection.nl> Date: Mon, 13 Apr 2015 23:22:52 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "Stephen J. Turnbull" References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020302080905090409050806" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1428960176; bh=KfIKZdlrK5zPQf1atyf8cyiajIe7gczIsBxeFGF20tI=; h=Message-ID:Date:From:To:Subject:From; b=hS9O3oCXZhfASuKAT9iUhqE+5YDqtYqYEsW4WTmZHzy6lDQ4e9yXG0FIWvKEzBjuu Qq6V4UJ1s2iTI5MTakV9o1l1WyTAdT9YrEPNeyWa2dWz4wmlzkkRMaKc8ZRczULMv7 NGn6AjjzxZ2UkRpfgIjPLL8ERJio5ZjPCBZyhUnY= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3lQjbN2NGyz5Mgfl Archived-At: Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 21:23:02 -0000 This is a multi-part message in MIME format. --------------020302080905090409050806 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/13/2015 08:21 PM, Murray S. Kucherawy wrote: > On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull > > wrote: > > Douglas Otis writes: > > > If the DMARC domain fails to step up, then a reasonable fallback > > could require the display of the Sender header offering the needed > > alignment. > > I don't understand this. We already see that most professional > spammers exhibit From alignment on much of their traffic. Sender > alignment is just as easy to implement, even if we could expect MUAs > to conform to the "required display of Sender field". Users do not > understand the Sender field as far as I can tell. > > > To the extent comprehensible, TPA is meant to allow author A to tell > receiver B that mail that has C in (for example) the List-ID field > should be treated as though it came from A. However, I concur that it > means an impostor can simply do what the TPA record says and thereby > succeed; few of the properties TPA identifies are authenticated in any > way. It might be helpful to get alignment working through paths that > invalidate SPF or DKIM, but compared to the fact that it basically > advertises how to get a "pass" in an invisible way, it's more scary to > me than not. Now, if that isn't the case, then I suggest the document > falls short of explaining how this is not an attack vector. > > Also, Doug insists that this is not registration, but I don't know how > he can claim this since it requires a DNS entry for every {A, C} pair > that exists which must then be queried by every B that might receive > mail from C. Unless I'm not understanding use of the term, that's > exactly how I believe we've been using "registration" lately, and the > argument on the table is that any registration scheme is basically a > non-starter for operators for which the cardinality of AxC is or could > be large. But, if this 'registration' does not apply to the 'mandatory tag draft', that means that every sender will always add the weak signature + 'fs=' and a replay attack is reduced to breaking the weak signature? /rolf --------------020302080905090409050806 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 04/13/2015 08:21 PM, Murray S. Kucherawy wrote:
On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull <t= urnbull@sk.tsukuba.ac.jp> wrote:
Douglas Otis writes:

=A0> If the DMARC domain fails to step up, then a reasonable fallback
=A0> could require the display of the Sender header offering the needed
=A0> alignment.

I don't understand this.=A0 We already see that most professional
spammers exhibit From alignment on much of their traffic.=A0 Sender
alignment is just as easy to implement, even if we could expect MUAs
to conform to the "required display of Sender field".=A0 Users do not
understand the Sender field as far as I can tell.

To the extent comprehensible, TPA is meant to allow author A to tell receiver B that mail that has C in (for example) the List-ID field should be treated as though it came from A.=A0 However, I concur that it means an impostor can simply do what the TPA record says and thereby succeed; few of the properties TPA identifies are authenticated in any way.=A0 It might be helpful to get alignment working through paths that invalidate SPF or DKIM, but compared to the fact that it basically advertises how to get a "pass" in an invisible way, it's more scary to me than not.=A0 Now, if that isn't the case, then I suggest the document falls short of explaining how this is not an attack vector.

Also, Doug insists that this is not registration, but I don't know how he can claim this since it requires a DNS entry for every {A, C} pair that exists which must then be queried by every B that might receive mail from C.=A0 Unles= s I'm not understanding use of the term, that's exactly how I believe we've been using "registration" lately, and the argument on the table is that any registration scheme is basically a non-starter for operators for which the cardinality of AxC is or could be large.

But, if this 'registration' does not apply to the 'mandatory tag draft', that means that every sender will always add the weak signature + 'fs=3D<initial domain>' and a replay attack is reduced to breaking the weak signature?

/rolf
--------------020302080905090409050806-- From nobody Mon Apr 13 15:22:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081571ACEE3 for ; Mon, 13 Apr 2015 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 k-U_Nr0USewz for ; Mon, 13 Apr 2015 15:22:13 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D8B1ACE7E for ; Mon, 13 Apr 2015 15:22:13 -0700 (PDT) Received: from [IPv6:2600:1003:b124:2639:34f0:ea90:54fc:c302] (unknown [IPv6:2600:1003:b124:2639:34f0:ea90:54fc:c302]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E918EC40020; Mon, 13 Apr 2015 17:22:11 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428963732; bh=avzCGqjzOioaV5t7M5g6WMst9yiS5u6GknEOSa2Tvls=; h=In-Reply-To:References:Subject:From:Date:To:From; b=hmNt+EyWbc411gAfhHptR6P366rKqbFnoCPDOK4yedhbGbeP0GGttnPzpTF8BURGB MyAXo1aItjjQ5JK+V+UX/9uUnib7q1ZlkbTgfnBOgYw21uGALx1L7hVG/qYm/YIyvQ vAvjDwqsWQuogWzoUPGApjDBG6pE6XEr5/W4ZYDQ= User-Agent: K-9 Mail for Android In-Reply-To: <552C33AC.3050009@sonnection.nl> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Mon, 13 Apr 2015 18:22:05 -0400 To: "dmarc@ietf.org" Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 22:22:15 -0000 On April 13, 2015 5:22:52 PM EDT, "Rolf E. Sonneveld" wrote: >On 04/13/2015 08:21 PM, Murray S. Kucherawy wrote: >> On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull >> > wrote: >> >> Douglas Otis writes: >> >> > If the DMARC domain fails to step up, then a reasonable >fallback >> > could require the display of the Sender header offering the >needed >> > alignment. >> >> I don't understand this. We already see that most professional >> spammers exhibit From alignment on much of their traffic. Sender >> alignment is just as easy to implement, even if we could expect >MUAs >> to conform to the "required display of Sender field". Users do >not >> understand the Sender field as far as I can tell. >> >> >> To the extent comprehensible, TPA is meant to allow author A to tell >> receiver B that mail that has C in (for example) the List-ID field >> should be treated as though it came from A. However, I concur that >it >> means an impostor can simply do what the TPA record says and thereby >> succeed; few of the properties TPA identifies are authenticated in >any >> way. It might be helpful to get alignment working through paths that > >> invalidate SPF or DKIM, but compared to the fact that it basically >> advertises how to get a "pass" in an invisible way, it's more scary >to >> me than not. Now, if that isn't the case, then I suggest the >document >> falls short of explaining how this is not an attack vector. >> >> Also, Doug insists that this is not registration, but I don't know >how >> he can claim this since it requires a DNS entry for every {A, C} pair > >> that exists which must then be queried by every B that might receive >> mail from C. Unless I'm not understanding use of the term, that's >> exactly how I believe we've been using "registration" lately, and the > >> argument on the table is that any registration scheme is basically a >> non-starter for operators for which the cardinality of AxC is or >could >> be large. > >But, if this 'registration' does not apply to the 'mandatory tag >draft', >that means that every sender will always add the weak signature + >'fs=' and a replay attack is reduced to breaking the >weak signature? Yes, but the signature is weak in that it covers less of the content, not in any cryptographic sense. Far more concerning to me is that once someone has received a message with a valid 'weak' signature, the only protection against replay is Message ID tracking. Tied with short signature expiration, this may be Okay, but it needs to be explored. Scott K From nobody Mon Apr 13 16:20:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2861B2B2D for ; Mon, 13 Apr 2015 16:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 EmaR-GMOejou for ; Mon, 13 Apr 2015 16:20:48 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ABA561B2B2B for ; Mon, 13 Apr 2015 16:20:47 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 197E71C3871; Tue, 14 Apr 2015 08:20:46 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E1296120EBE; Tue, 14 Apr 2015 08:20:45 +0900 (JST) From: "Stephen J. Turnbull" To: R.E.Sonneveld@sonnection.nl In-Reply-To: <552C33AC.3050009@sonnection.nl> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 14 Apr 2015 08:20:45 +0900 Message-ID: <877ftf8vjm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Douglas Otis Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 23:20:49 -0000 Rolf E. Sonneveld writes: > But, if this 'registration' does not apply to the 'mandatory tag draft', > that means that every sender will always add the weak signature + > 'fs=' and a replay attack is reduced to breaking the > weak signature? Definitely not. Some senders may do that. I suppose many others will simply refuse to adopt the standard until it is clearly successful. Yet others may adopt heuristics to determine which of their users' correspondents are lists. Finally others might require registration of lists by the posters in their domains. Note that the signature is not "weak" (compared to DKIM) in the cryptographic sense. Rather it is weak in the sense that if you can break the crypto, you can pretend to be authorized to add material. However, if you can break the weak signature, you can break DKIM *by definition*, and therefore can pretend to be the author. So there's no need that I can see for more paranoia about the cryptography of "weak" signatures than there is for DKIM in general. The worry is that an authorized resigner might be suborned -- but that's true of TPA as well. I think the advantage of TPA is that it's very easy for the From domain to revoke the authorization and "publish" the revocation (simply by un-publishing the authorization). From nobody Mon Apr 13 17:55:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25D1ACCED for ; Mon, 13 Apr 2015 17:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1fwqEj5toxI3 for ; Mon, 13 Apr 2015 17:55:47 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (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 1999C1A8911 for ; Mon, 13 Apr 2015 17:55:47 -0700 (PDT) Received: by wgsk9 with SMTP id k9so98733547wgs.3 for ; Mon, 13 Apr 2015 17:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yZLTUMJznjkhoJNy5R1CZhVXlpB2s6kDWEm1Cv8Z8gA=; b=lu7Um2zd+VXXntLcbLCROuyQ0d7fvWmHszFO06VcHOh2hI52bCEeUyYXI23CoRLVKe dsQ7vAzolUJxC7/Z/9SCd9gCfZqx3bcAsNlsapT88JdyWIXgp0h38aojSPBhrMMYxpmi YKewWYWXGvkFzvLL3Utw4HV+c9ZmH+wnF+jlJ2woNVeX3Xt+BAgSvtfokl1WrpCt8tvR 8ChjfY3zvbqDWLbVMvWrjvQRoc3lrC7fXZoe9KzpFAFr2pNbwpHCMZ50Yyuy+S7bCMoI qxWxyVCK6IjhtlodLl2ChE1CMH44J0S3S4t9jPIe4KWxuSzMPCa5dChrxn7je6Cepw9R EuVQ== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr32676147wjc.111.1428972945873; Mon, 13 Apr 2015 17:55:45 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Mon, 13 Apr 2015 17:55:44 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Mon, 13 Apr 2015 17:55:44 -0700 (PDT) In-Reply-To: <552C33AC.3050009@sonnection.nl> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> Date: Mon, 13 Apr 2015 17:55:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=047d7bacb11ed522c50513a4b0ce Archived-At: Cc: dmarc@ietf.org, Douglas Otis , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:55:48 -0000 --047d7bacb11ed522c50513a4b0ce Content-Type: text/plain; charset=UTF-8 On Apr 13, 2015 2:22 PM, "Rolf E. Sonneveld" > But, if this 'registration' does not apply to the 'mandatory tag draft', that means that every sender will always add the weak signature + 'fs=' and a replay attack is reduced to breaking the weak signature? You can't reuse the weak signature without a proper signature from the fs domain on the same message. I imagine short expiration times mitigate that risk. -MSK --047d7bacb11ed522c50513a4b0ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 13, 2015 2:22 PM, "Rolf E. Sonneveld"
> But, if this 'registration' does not apply to the 'mandato= ry tag draft', that means that every sender will always add the weak si= gnature + 'fs=3D<initial domain>' and a replay attack is redu= ced to breaking the weak signature?

You can't reuse the weak signature without a proper sign= ature from the fs domain on the same message. I imagine short expiration ti= mes mitigate that risk.

-MSK

--047d7bacb11ed522c50513a4b0ce-- From nobody Mon Apr 13 18:47:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5233B1B2C37 for ; Mon, 13 Apr 2015 18:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 aHCjZxjhBRko for ; Mon, 13 Apr 2015 18:47:40 -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 1F34F1B2C35 for ; Mon, 13 Apr 2015 18:47:40 -0700 (PDT) Received: by qkhg7 with SMTP id g7so212480572qkh.2 for ; Mon, 13 Apr 2015 18:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XTOPVQhNQv8MC3TcLbJ1BibLkwK3c+Q3y/p9r0U4DlY=; b=b7ri/bh9qOMcfg6RdSV5uuGwgG6UKTEVLtQDSkd2zbh/IYHYIxJKOrdfUnJaeY1vd4 dnAezQTQgovj2tRoPhyNt2t9q+ZRmP5LTvmn0h4s1j/fM4953pf9cDbjtCkuxMZqaFZQ YfY/A4sYU+ZZc3zTWSJcA3jxMOecDO5RahPhKazyszQn8GdN7DCpj32EMKTF3Eo4cvua igEOjQe4iS9UpD6mysZwOmyXBaHdYBm66TVBfqKRJdaucsmiakILpHwlT4csO/MQqF9c p0mSVNC636acoeO+wPWXX4Y+pQcR5vbupQy6wGzECvxRaY30DrJtjXnHNfUB7efT4+0D zIPw== X-Received: by 10.140.239.76 with SMTP id k73mr22308528qhc.66.1428976059296; Mon, 13 Apr 2015 18:47:39 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id h65sm7232683qge.38.2015.04.13.18.47.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 18:47:38 -0700 (PDT) Message-ID: <552C71B7.4050402@gmail.com> Date: Mon, 13 Apr 2015 18:47:35 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 01:47:42 -0000 On 4/13/15 12:58 AM, Stephen J. Turnbull wrote: > Douglas Otis writes: > > > If the DMARC domain fails to step up, then a reasonable fallback > > could require the display of the Sender header offering the needed > > alignment. > > I don't understand this. We already see that most professional > spammers exhibit From alignment on much of their traffic. Sender > alignment is just as easy to implement, even if we could expect MUAs > to conform to the "required display of Sender field". Users do not > understand the Sender field as far as I can tell. Dear Stephen, I am writing an I-D expanding on DMARC's disruptive views in hopes of finding a stable path forward. As an analogy, the credit card industry outside the US assumes users will remember their PIN. In the US, often protection depends on sporadically checked signatures. When less is expected of users, less protection is afforded. Email as defined includes the role of Sender. When Sender is missing, the Author is assumed to play this role. There are ways to ensure the Sender header is displayed when aligned with SPF or DKIM records. Blocking valid messages by ignoring the Sender's role suggests email will not function as defined. Allowing DMARC alignment with Sender header fields along with the display of Sender content ultimately affords users greater protection. Only in the case where a domain just issues transactional messages will ignoring Sender header fields then make sense. Otherwise valid third-party messages will be placed into spam folders or the Author identity will be munged in response to Sender header field limitations imposed by the DMARC domain. Permitting a clean mode of delivery from a DMARC domain handling normal mail services should be permitted when Sender is aligned with SPF or DKIM records. Only by making an allowance for Sender header fields for normal email use can Authors be accurately and clearly conveyed. Yes, this expects users to understand they are primarily trusting the Sender which should be displayed much like the pad-lock on a website. TPA-Label can further increase protection by allowing a DMARC domain a means to signal established third-party relationships. This would normally involve a small portion of the email a DMARC domain might send. Like SPF or DKIM, TPA-Label would represent an even smaller overhead. Alternative efforts at creating weak signatures will also require advanced auditing of DMARC feedback and of outbound logs while not improving overall protections or providing more comprehensive coverage. TPA-Label may appear complex, but the added information reduces possible attack scenarios and better ensures various identifiers can be used to cull these messages. It is assumed these identifiers would result from an audit of the feedback characterizing what recipients should expect. This would not be the user telling a DMARC domain anything other than using the third-party service. TPA-Label is only used when an exception is to be used to safely handle third-party services. TPA-Label will not increase the message size or involve additional signatures. While TPA-Label may involve tens of thousands of domains, our feedback was processed in much the same manner approaching hundreds of millions queried by MTAs world wide without imposition of a fee because of its slight overhead. Use of TPA-Label offers greater scalability than domain lists included in draft-kucherawy-dkim-delegate or draft-levine-dkim-conditional. Unlike these two schemes, TPA-Label can impose or permit other options at the discretion of the DMARC domain. In this case a valid DKIM signature would be required before excusing a third-party domain from being subjected to the DMARC policy imposed by the From domain. This record would permit isp.com after it adds a valid DKIM signature. This would provide the same results as would be obtained by draft-kucherawy-dkim-delegate or draft-levine-dkim-conditional which must impose their decision isp.com is okay adding an additional signature. The possible number of third-party services approved to then forward the message is limited by the size of a list supported within the DKIM signature. There is no such limit for TPA-Label. The argument that a priori DNS publishing is too cumbersome overlooks the situation when this represents first use of a third-party domain where other a priori checks are likely needed as well. Once a third-party domain is listed, this offers a low latency lightweight signal to all of the DMARC domain's MTAs it okay to sign and send, and for others to then receive a message modified and resigned by isp.com. The receiver will not need to perform additional signature checks beyond normal confirmations for messages from isp.com containing the domain example.com looking up the following DNS record: _HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._smtp._tpa.example.com. IN TXT "v=tpa1; tpa=isp.com; param=d;" Imposing a specific path that email traverses be defined prior to the message being sent will ossify SMTP into becoming a fragile and unreliable process. A cure worse than the ailment. The goal is not to create a Pachinko like path for email to follow. The goal is to allow the DMARC domain a means to quickly mitigate abuse. Perhaps it should be noted, a common structure of safe third-party domains could be shared among many different domains, allowing an organization to specialize in monitoring and maintaining such a list. Regards, Douglas Otis From nobody Mon Apr 13 18:56:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2CE1B2C4B for ; Mon, 13 Apr 2015 18:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_PROFILE2=1.981, SPF_PASS=-0.001] autolearn=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 hY3-9eRdHIKr for ; Mon, 13 Apr 2015 18:56:36 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 A7EA31B2C47 for ; Mon, 13 Apr 2015 18:56:36 -0700 (PDT) Received: by qkx62 with SMTP id 62so211984761qkx.0 for ; Mon, 13 Apr 2015 18:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aMI9b8esIhlyiqEFnZQ5Aq3OG5iifMB33vTTZcb15OY=; b=orkH7AAreNMzhCbP04njspr7nFwlV3q0vAvod+hYtwD5PckPiWR0pGnNwcTxUH4b6g TqwUKpbS1TrEK8Ee108yQK64cAN5rD8xoNW1hQHoCxOjXI7hlQSF3yH2jC5p9Cw3rD38 mUIY3a+wrBeUOU+YEsqQej+PlyRU4XFNbIqNmDQ+9SBVJNb6fSNwwBBy+S1BAqhmA3fk KVlflLgjgGmZbN9KR7vR2rY/EwSqLmF10X49SBOYa5lmz8zAEWUEeoNBLK6cK/Xe+69+ LsbSdGub0aZcw08X/RW5eSr2yObTWhiaWvShOPv69F0QZt3rPRm0S02OkYAPMkRs2wUt EX/Q== X-Received: by 10.140.236.73 with SMTP id h70mr22188829qhc.41.1428976596041; Mon, 13 Apr 2015 18:56:36 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id k85sm7185949qkh.48.2015.04.13.18.56.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 18:56:35 -0700 (PDT) Message-ID: <552C73D0.3080001@gmail.com> Date: Mon, 13 Apr 2015 18:56:32 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "" References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org, "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 01:56:37 -0000 On 4/13/15 5:55 PM, Murray S. Kucherawy wrote: > On Apr 13, 2015 2:22 PM, "Rolf E. Sonneveld" >> But, if this 'registration' does not apply to the 'mandatory tag draft', > that means that every sender will always add the weak signature + > 'fs=' and a replay attack is reduced to breaking the weak > signature? > > You can't reuse the weak signature without a proper signature from the fs > domain on the same message. I imagine short expiration times mitigate that > risk. Dear Murray, We are currently dealing with Botnets leveraging DMARC to obtain acceptance or abuse detected weaknesses as previously mentioned. Botnets are extremely proficient at deploying new attacks to leverage detected vulnerabilities. In this case, this scheme itself represents its own vulnerability. Regards, Douglas Otis From nobody Tue Apr 14 03:58:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C3D1A88D1 for ; Tue, 14 Apr 2015 03:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 MJLVVJAz2MyZ for ; Tue, 14 Apr 2015 03:58:14 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D54A41A88CE for ; Tue, 14 Apr 2015 03:58:13 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id EBBD91C3886; Tue, 14 Apr 2015 19:58:11 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B6912120EBE; Tue, 14 Apr 2015 19:58:11 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 14 Apr 2015 19:58:11 +0900 Message-ID: <87fv83yo1o.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 10:58:15 -0000 Scott Kitterman writes: > Far more concerning to me is that once someone has received a > message with a valid 'weak' signature, the only protection against > replay is Message ID tracking. I don't understand the attack you have in mind. First, do you mean the Mediator identified in the fs= tag can replay? Or a third party? What is the damage that could be inflicted by this replay? To whom? Steve From nobody Tue Apr 14 04:40:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BC11A8A75 for ; Tue, 14 Apr 2015 04:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 gSqN2EwI0iQo for ; Tue, 14 Apr 2015 04:40:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD31E1A8A4D for ; Tue, 14 Apr 2015 04:39:51 -0700 (PDT) Received: from [192.168.111.105] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 04774C403D5; Tue, 14 Apr 2015 06:39:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429011591; bh=rBWV506pizEcLottxUhuICLR+LqXkrtl+DftMNYSOl4=; h=In-Reply-To:References:Subject:From:Date:To:From; b=omtSSmg4QLjQ71qkk798lEFQ3P8s4LC+Od7w4rfaKKCyj3JRBAGEVDW1iWGCtxOAa pUUTBgSNSVjmI3/6AtaPMamIQDHJ3pvh45lbi5kqn2/mXeZ9aAGD9QjsHVQTw785hq o8NEMgtToLhbhKUdqRj7t+8rdPYw5M9FrcCBhnm4= User-Agent: K-9 Mail for Android In-Reply-To: <87fv83yo1o.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> <87fv83yo1o.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 14 Apr 2015 07:39:48 -0400 To: "dmarc@ietf.org" Message-ID: <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 11:40:13 -0000 On April 14, 2015 6:58:11 AM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > Far more concerning to me is that once someone has received a > > message with a valid 'weak' signature, the only protection against > > replay is Message ID tracking. > >I don't understand the attack you have in mind. First, do you mean >the Mediator identified in the fs= tag can replay? Or a third party? >What is the damage that could be inflicted by this replay? To whom? The 'mediator'. Once I am in receipt of a message from you with a signature that is fs=me, then I can send mail on your behalf with any parts of the message not covered by the weak signature having arbitrary changes (including complete replacement). Keeping in mind that one of the advantages of this approach is not needing to keep a real time list of mediator addresses users in your domain might send to, to make this work at scale, I think the fs= signature has to be put on all messages. The reason I put mediator in quotes above is because it's anyone you send mail to. The damage is that all it takes is one message from your domain sent to a 'bad' domain and then that domain can generate arbitrary messages that will pass the test. The to whom is to the sender's brand and the receiver if it makes it through to the inbox. The one way to catch this that we've come up with so far is Message ID tracking, since that is signed in the fs= signature (so it can't be replaced). That's not ideal though. Scott K From nobody Tue Apr 14 06:44:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5314D1A9233 for ; Tue, 14 Apr 2015 06:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 PcCYYlcfVZNd for ; Tue, 14 Apr 2015 06:44:40 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 727311A9177 for ; Tue, 14 Apr 2015 06:44:40 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 4800E1C3869; Tue, 14 Apr 2015 22:44:39 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2C95F120EBE; Tue, 14 Apr 2015 22:44:39 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> References: <20150410170856.730.qmail@ary.lan> <1646939.LNu9R6Ga10@kitterma-e6430> <87d238d92k.fsf@uwakimon.sk.tsukuba.ac.jp> <552B5060.3000808@gmail.com> <878udwcvda.fsf@uwakimon.sk.tsukuba.ac.jp> <552C33AC.3050009@sonnection.nl> <87fv83yo1o.fsf@uwakimon.sk.tsukuba.ac.jp> <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 14 Apr 2015 22:44:39 +0900 Message-ID: <87k2xeddtk.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:44:43 -0000 Scott Kitterman writes: > Keeping in mind that one of the advantages of this approach is not > needing to keep a real time list of mediator addresses users in > your domain might send to, to make this work at scale, I think the > fs= signature has to be put on all messages. I don't think so. I think that a conservative approach of keeping the list in the user profile and doing weak signatures in the MUA will work for a large proportion of users (Yahoo!, AOL, GMail, Hotmail, up-to-date SquirrelMail etc installations), plus the hard core of Emacs users (Gnus will have a zero-day implementation, no doubt) and mutt users (I know, it's not like Emacs and mutt are a significant proportion anymore, it's the principle of the thing). Anybody who's thinking about putting fs= on all users on all outgoing mail will probably think twice and just not do it. Or I kinda hope so. > The damage is that all it takes is one message from your domain > sent to a 'bad' domain and then that domain can generate arbitrary > messages that will pass the test. OK, I hadn't envisioned the "let's see just how badly we can implement this protocol" scenario, but yes, it's a real issue. Note that Murray's other proposal (MIME-part-by-part signatures) supports a heuristic to get around this (if you can't find any original parts, it's spam). I guess you can come pretty close to arbitrary, though. Steve From nobody Tue Apr 14 07:07:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD591A1AA1 for ; Tue, 14 Apr 2015 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Eau6Ur6VcNoZ for ; Tue, 14 Apr 2015 07:07:50 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BEA1A0354 for ; Tue, 14 Apr 2015 07:07:50 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id F1C39C403D5 for ; Tue, 14 Apr 2015 09:07:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429020470; bh=TQ1THUVZbLJd80DD3jZljbuiad4wSDQqiECZCAsKA8Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=coKlrDlp/ucbtdkEcrYcKDO+3nmm/ghe5RPv7gMcjjTfeCI1BEGuI3MN/7We8T5rn QNi38vQpJ1W1PbAS2+PWS14UD+4U29XFZCd6HF6mlp2CwYpZuf+0VixhI3ZVojGEq5 Y9SuV5h1JkifUr02SyqD/gCf9b0Aarj2A3qw8upA= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 14 Apr 2015 10:07:49 -0400 Message-ID: <2843651.yGUcCboVsT@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87k2xeddtk.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150410170856.730.qmail@ary.lan> <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> <87k2xeddtk.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:07:52 -0000 On Tuesday, April 14, 2015 10:44:39 PM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > Keeping in mind that one of the advantages of this approach is not > > needing to keep a real time list of mediator addresses users in > > your domain might send to, to make this work at scale, I think the > > fs= signature has to be put on all messages. > > I don't think so. I think that a conservative approach of keeping the > list in the user profile and doing weak signatures in the MUA will > work for a large proportion of users (Yahoo!, AOL, GMail, Hotmail, > up-to-date SquirrelMail etc installations), plus the hard core of > Emacs users (Gnus will have a zero-day implementation, no doubt) and > mutt users (I know, it's not like Emacs and mutt are a significant > proportion anymore, it's the principle of the thing). Anybody who's > thinking about putting fs= on all users on all outgoing mail will > probably think twice and just not do it. Or I kinda hope so. > > > The damage is that all it takes is one message from your domain > > sent to a 'bad' domain and then that domain can generate arbitrary > > messages that will pass the test. > > OK, I hadn't envisioned the "let's see just how badly we can implement > this protocol" scenario, but yes, it's a real issue. Note that > Murray's other proposal (MIME-part-by-part signatures) supports a > heuristic to get around this (if you can't find any original parts, > it's spam). I guess you can come pretty close to arbitrary, though. I wasn't attempting to do it purposefully badly. I'm not aware of any significant DKIM signing done at the MUA level. I think (at least for real DKIM signatures) you have to have the MTA do it to mitigate risk of signature breakage to to MTA level transformations. If the signature has to be done at the MUA, then we're back to this only works once MUA upgrades are done. I thought we'd agreed forcing MUA modifications was not a post for success. If I misunderstood the proposal and it requires someone to be keeping a list of mailing lists used (either globally or by individual users), then I think this is not a good idea at all. I don't think any tracking/whitelisting design is going to succeed at scale. My view is that either we find a reasonable way to make this idea work without a list of mailing lists or we toss it on the pile of things that won't work. Scott K From nobody Tue Apr 14 07:56:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91651ACE1E for ; Tue, 14 Apr 2015 07:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 ySGZsqwVbo3N for ; Tue, 14 Apr 2015 07:56:22 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 40D461A1B79 for ; Tue, 14 Apr 2015 07:56:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CC8DE1C385A; Tue, 14 Apr 2015 23:56:20 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A8069120EBE; Tue, 14 Apr 2015 23:56:20 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <2843651.yGUcCboVsT@kitterma-e6430> References: <20150410170856.730.qmail@ary.lan> <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> <87k2xeddtk.fsf@uwakimon.sk.tsukuba.ac.jp> <2843651.yGUcCboVsT@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 14 Apr 2015 23:56:20 +0900 Message-ID: <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:56:24 -0000 Scott Kitterman writes: > I wasn't attempting to do it purposefully badly. I didn't mean you were *trying* to do it badly. However, using fs= for *all* addressees on *all* outgoing mail seems like the worst possible scenario. > I'm not aware of any significant DKIM signing done at the MUA > level. I think (at least for real DKIM signatures) Exactly. But the "Big 4" MUAs are in close cooperation (FSVO "close") with the "Big 4" MTAs. They could do it in the MUA, or they could invent a simple protocol to ask their MTAs to do it for the MUA. > you have to have the MTA do it to mitigate risk of signature > breakage to to MTA level transformations. If the signature has to > be done at the MUA, No, it doesn't *have* to be done at the MUA. I'm saying it *could* be done at the MUA, and with the exception of MTAs that rewrite Message-ID, I would think the risk for weak signatures is fairly minimal. (I know, I know, "famous last words".) > then we're back to this only works once MUA upgrades are done. I > thought we'd agreed forcing MUA modifications was not a post for > success. > > If I misunderstood the proposal and it requires someone to be > keeping a list of mailing lists used (either globally or by > individual users), then I think this is not a good idea at all. I > don't think any tracking/whitelisting design is going to succeed at > scale. I can't speak for Murray, but I can't see that his proposal does. My (informal) proposal is a way for the "Big 4" to get into this without a huge risk of replayable messages going to spammers on a large scale. > My view is that either we find a reasonable way to make this idea > work without a list of mailing lists or we toss it on the pile of > things that won't work. Unfortunately, we already have something that doesn't work, it is deployed at scale, and it continues to cause annoyance at scale (the guy next to me at the PyCon sprints just got a messaged rejected because he replied to a ".dmarc.invalid" address). Really, isn't the question whether Yahoo! and AOL are willing to do *anything* to mitigate? We need some participation from them or it's useless, and if at least one does participate, it's a win. What are they willing to think about implementing? From nobody Tue Apr 14 08:12:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1A71B2C8F for ; Tue, 14 Apr 2015 08:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 LebuKfII7atQ for ; Tue, 14 Apr 2015 08:12:36 -0700 (PDT) Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 296801B2B7A for ; Tue, 14 Apr 2015 08:11:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4955; t=1429024262; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=pp/Dw/rj1ryU8ATb9I+lrah2yLw=; b=OrIcjLjCUwxXMcV/yawO MVfj6LfMYX+eBS1gq/O0FhYTeYLyIz2mZhanRtrI+QAf7KjTp+XUZ7wNnpo3m/3g PsMDKwwsJwE4heT44xszMP8SpbsxOjndI0bpQbTwrsTRBUw+NSU9v2u1cLHJi3Ye G3LjHv8KM7L4JxyPaOfrUbU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 11:11:02 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2734277425.7719.2164; Tue, 14 Apr 2015 11:11:01 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4955; t=1429024030; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OJudjIB lp/ZuI7UwAg6MoBZwY1BhQVRR6YlHa/gsieg=; b=XAJUMByk/sFHsh0FdlNjCbl FYXwqJ2529kg4EP5b9KWnt+pqE0ZeVzxa4qb/r80vo+jAuCiY48FgiO2Nk7WAsIs 8Vjs7AAD/QvlNsM5Q3WANzt+NyXFBR/jCqD80HUFgMPu/cGKwGVZwKXMfZzBMgcO /YdoiYRWRTIMpvHPahDM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 11:07:10 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1326565707.9.5776; Tue, 14 Apr 2015 11:07:09 -0400 Message-ID: <552D2E04.8030101@isdg.net> Date: Tue, 14 Apr 2015 11:11:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> <87k2xeddtk.fsf@uwakimon.sk.tsukuba.ac.jp> <2843651.yGUcCboVsT@kitterma-e6430> In-Reply-To: <2843651.yGUcCboVsT@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:12:39 -0000 On 4/14/2015 10:07 AM, Scott Kitterman wrote:> > If I misunderstood the proposal and it requires someone to be keeping a list > of mailing lists used (either globally or by individual users), then I think > this is not a good idea at all. I don't think any tracking/whitelisting > design is going to succeed at scale. > > My view is that either we find a reasonable way to make this idea work without > a list of mailing lists or we toss it on the pile of things that won't work. Which is why the simple DNS lookup remains to be the ideal baseline and natural part of the generic DSAP (DKIM Signature Authorization Protocol) design. You need to cover all process model boundary conditions which include 1st and 3rd party mail streams. If you exclude one, its incomplete. The Publishing and "Registration" problem has been overblown. Registration basically means to find the domains (your network of signers) to publish. The latter is a business problem, not a IETF technical protocol problem. If we had used a "registration/scale problem" philosophy for other early IETF protocols, they were have never been completed as well and gotten to where we are at now. SPF has this same scale concern, and it still currently an extremely high wasteful DNS calling authorization check method for senders. The larger domains also had to "find" their network to register them as SPF machines. So this is not any different. The DNS "Lookup" algorithm has been the basic backbone idea since 2003, since LMAP ideas, since DNSRBL, since MAPS, well since forever, etc, the idea of "Looking up" an verified, integrity authenticated id for authorization, either its for bad or good, it became fashionable and an acceptable concept overtime by the DNS community. They bemoaned it but the DNS TXT-BASED applications was on the raise as an fast entry method to explore many new authorization ideas. We tried to get the "Good Signer" (SDID) lookup with the DKIM STD work. It didn't happen in the market place (it has issues that included the "Batteries Required" syndrome) and even if it did happen, the "Good Signer" methodology did not cover rudimentary DKIM signing failures checks (including missing). In all cases, you need a 3rd party Authorization list somewhere, whether everyone needs one or not, some will, some won't. That again is also a implementation and business decision. You can, in theory, have a more relaxed Signer Engine that double signs all mail or maybe under some rule that allows only outgoing LIST domains to be double signed. In all cases, this in-band method is still a registration concept, global or selective. The problem has been that some believe everyone will have this a huge need to "register" many domains, and IMV, this erroneous idea has crippled the completion of all DSAP protocols (SSP, ADSP, DMARC). No, only a few have such "registration" issues, whether thats a million or so, it still a small piece of the total domain space. We won't know how many for sure, but I have a pretty good feel the majority of domains will not need such large "list" needs. How many will you have to collect? I have 10. e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) LYKM653KJ7YXEIA665VA7LSZZTHCX7JJ._atps TXT ( "v=atps01; d=beta.winserver.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" ) ni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" ) Are we saying that MOST systems will not be able to handle their Network of known signers? As stated above, this issue is no different than with SPF where larger networks had to learn their network of senders and even then, many still use weak/relaxed policies (~ALL, ?ALL) lowering the payoff of the redundant calls with no actionable results, indeterminate conditions - a high waste most of the time. The MLM or the site mail receivers just needs to make sure it does a ADID/SDID check. If the WG wants to spend time on a weaker more complex double signature "in-band" solution because the DNS administrator is no longer needed, that still doesn't mean that this design will be acceptable to all. The weaker alternative is more code change and if you can avoid code change, the better. DMARC SHOULD offer the more ideal and simple DNS lookup because it is a natural part of the DNS lookup model that already exist for DMARC which currently isolates itself to the ADID==SDID conditions and automatically failures all other conditions. -- HLS From nobody Tue Apr 14 08:25:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BB41B2B7A for ; Tue, 14 Apr 2015 08:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 t4tam9gcr1D7 for ; Tue, 14 Apr 2015 08:25:16 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835E01ACE3C for ; Tue, 14 Apr 2015 08:25:16 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AEF40C403D5 for ; Tue, 14 Apr 2015 10:25:15 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429025115; bh=JkQ5ZiaCe/FA8Oym3lXLIcku6ibiCUmV80Ylm1dtXcA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MKeB/ZkvVL1a8MKfUuVYByP1Yrn9BZyTTmxulMJ8WKIVEZcS0jpyynHKq7o16Po4j dDwB2xADtyMbSKoede7L1M7dYI67gOU7nGoVj9IRaEeCi+Njk4JJ6A6GQPtJ4qVygi UUu0AFWItrsFRim5Xk+pLuVyFhsH+IFn3u4O2C6E= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 14 Apr 2015 11:25:15 -0400 Message-ID: <3164216.CDnEBjYtuG@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:25:20 -0000 On Tuesday, April 14, 2015 11:56:20 PM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > I wasn't attempting to do it purposefully badly. > > I didn't mean you were *trying* to do it badly. However, using fs= for > *all* addressees on *all* outgoing mail seems like the worst possible > scenario. I think it's the only one that scales, so worst or not, I think it's what you get. > > I'm not aware of any significant DKIM signing done at the MUA > > level. I think (at least for real DKIM signatures) > > Exactly. But the "Big 4" MUAs are in close cooperation (FSVO "close") > with the "Big 4" MTAs. They could do it in the MUA, or they could > invent a simple protocol to ask their MTAs to do it for the MUA. > > > you have to have the MTA do it to mitigate risk of signature > > breakage to to MTA level transformations. If the signature has to > > be done at the MUA, > > No, it doesn't *have* to be done at the MUA. I'm saying it *could* be > done at the MUA, and with the exception of MTAs that rewrite > Message-ID, I would think the risk for weak signatures is fairly > minimal. (I know, I know, "famous last words".) 8 bit to 7 bit transformations are also not rare. > > then we're back to this only works once MUA upgrades are done. I > > thought we'd agreed forcing MUA modifications was not a post for > > success. > > > > If I misunderstood the proposal and it requires someone to be > > keeping a list of mailing lists used (either globally or by > > individual users), then I think this is not a good idea at all. I > > don't think any tracking/whitelisting design is going to succeed at > > scale. > > I can't speak for Murray, but I can't see that his proposal does. I haven't reviewed his in detail, so I've no opinion. I was talking about this proposal. Not getting fancy with MIME parts would be nice, so if this one can work, I already like it better than Murray's, but if we have to pile this onto the stack of nice ideas, then that's probably what I'll look at next. > My (informal) proposal is a way for the "Big 4" to get into this > without a huge risk of replayable messages going to spammers on a > large scale. Which one is that? > > My view is that either we find a reasonable way to make this idea > > work without a list of mailing lists or we toss it on the pile of > > things that won't work. > > Unfortunately, we already have something that doesn't work, it is > deployed at scale, and it continues to cause annoyance at scale (the > guy next to me at the PyCon sprints just got a messaged rejected > because he replied to a ".dmarc.invalid" address). > > Really, isn't the question whether Yahoo! and AOL are willing to do > *anything* to mitigate? We need some participation from them or it's > useless, and if at least one does participate, it's a win. What are > they willing to think about implementing? Depends on who needs to change to mitigate things. If (as an example only) we decide that From rewriting is the best (least bad) solution, then that's a mediator change. We don't need Yahoo and AOL except to the extent they operate as mediators also, but AFAIK, that's different groups at Yahoo and AOL. Scott K From nobody Tue Apr 14 08:30:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845C01B2CB7 for ; Tue, 14 Apr 2015 08:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QPb-lbbxH0yU for ; Tue, 14 Apr 2015 08:30:38 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737951B2CE3 for ; Tue, 14 Apr 2015 08:30:25 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A7BA4C403D5 for ; Tue, 14 Apr 2015 10:30:24 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429025424; bh=pAPHkOXXlVYDcxOScl1LTJXCVdoW3u2dfCcWVJn0uvE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IvU4RksHW2/65YHQ2A7cZ5PeRsnrcdMmVPB6GTTuFCeIIhgy9dl/cpVrFurZq5w5P drgKOlJoQwD3luSxuUt3RfoqgeyeyeHpkthDhi5cC1+fnAse2Vy7V0DLVDCFu4oKUg x2LdRrHdqlGun2Un0FgAGj/VgRFHIhIr6E+xXV88= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 14 Apr 2015 11:30:24 -0400 Message-ID: <3116002.DAz6U52Rgm@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <552D2E04.8030101@isdg.net> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:30:45 -0000 On Tuesday, April 14, 2015 11:11:00 AM Hector Santos wrote: > On 4/14/2015 10:07 AM, Scott Kitterman wrote:> > > > If I misunderstood the proposal and it requires someone to be keeping a > > list of mailing lists used (either globally or by individual users), then > > I think this is not a good idea at all. I don't think any > > tracking/whitelisting design is going to succeed at scale. > > > > My view is that either we find a reasonable way to make this idea work > > without a list of mailing lists or we toss it on the pile of things that > > won't work. > Which is why the simple DNS lookup remains to be the ideal baseline > and natural part of the generic DSAP (DKIM Signature Authorization > Protocol) design. You need to cover all process model boundary > conditions which include 1st and 3rd party mail streams. If you > exclude one, its incomplete. > > The Publishing and "Registration" problem has been overblown. > Registration basically means to find the domains (your network of > signers) to publish. The latter is a business problem, not a IETF > technical protocol problem. If we had used a "registration/scale > problem" philosophy for other early IETF protocols, they were have > never been completed as well and gotten to where we are at now. SPF > has this same scale concern, and it still currently an extremely high > wasteful DNS calling authorization check method for senders. The > larger domains also had to "find" their network to register them as > SPF machines. So this is not any different. > > The DNS "Lookup" algorithm has been the basic backbone idea since > 2003, since LMAP ideas, since DNSRBL, since MAPS, well since forever, > etc, the idea of "Looking up" an verified, integrity authenticated id > for authorization, either its for bad or good, it became fashionable > and an acceptable concept overtime by the DNS community. They bemoaned > it but the DNS TXT-BASED applications was on the raise as an fast > entry method to explore many new authorization ideas. > > We tried to get the "Good Signer" (SDID) lookup with the DKIM STD > work. It didn't happen in the > market place (it has issues that included the "Batteries Required" > syndrome) and even if it did happen, the "Good Signer" methodology did > not cover rudimentary DKIM signing failures checks (including missing). > > In all cases, you need a 3rd party Authorization list somewhere, > whether everyone needs one or not, some will, some won't. That again > is also a implementation and business decision. You can, in theory, > have a more relaxed Signer Engine that double signs all mail or maybe > under some rule that allows only outgoing LIST domains to be double > signed. In all cases, this in-band method is still a registration > concept, global or selective. > > The problem has been that some believe everyone will have this a huge > need to "register" many domains, and IMV, this erroneous idea has > crippled the completion of all DSAP protocols (SSP, ADSP, DMARC). > No, only a few have such "registration" issues, whether thats a > million or so, it still a small piece of the total domain space. We > won't know how many for sure, but I have a pretty good feel the > majority of domains will not need such large "list" needs. > > How many will you have to collect? I have 10. > > e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; > d=megabytecoffee.com;" ) > jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; > d=winserver.com;" ) > kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) > LYKM653KJ7YXEIA665VA7LSZZTHCX7JJ._atps TXT ( "v=atps01; > d=beta.winserver.com;" ) > n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) > pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) > q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" ) > ni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; > d=mapurdy.com.au;" ) > tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; > d=santronics.com;" ) > > Are we saying that MOST systems will not be able to handle their > Network of known signers? > > As stated above, this issue is no different than with SPF where larger > networks had to learn their network of senders and even then, many > still use weak/relaxed policies (~ALL, ?ALL) lowering the payoff of > the redundant calls with no actionable results, indeterminate > conditions - a high waste most of the time. > > The MLM or the site mail receivers just needs to make sure it does a > ADID/SDID check. If the WG wants to spend time on a weaker more > complex double signature "in-band" solution because the DNS > administrator is no longer needed, that still doesn't mean that this > design will be acceptable to all. The weaker alternative is more > code change and if you can avoid code change, the better. DMARC > SHOULD offer the more ideal and simple DNS lookup because it is a > natural part of the DNS lookup model that already exist for DMARC > which currently isolates itself to the ADID==SDID conditions and > automatically failures all other conditions. There's a big difference between needing to know the outbound architecture of your own sending (as is needed by SPF and DMARC) and needing to know which of all the places you send mail are mediators. You seem to think keeping a list of mediators like mailing lists is feasible and offer a way to do it. I don't have an opinion on how good the method is because I don't there is no way keeping a list can be done regardless of how you store it. Also, for large providers like (for example) Google Groups, you wouldn't want to authorize them at the domain level since it's a mix of high quality wanted groups and spam groups. You'd have to do it at the individual mail box level to make it workable. This only amplifies my concern about scalability. Scott K From nobody Tue Apr 14 09:07:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713A01B2D90 for ; Tue, 14 Apr 2015 09:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 NG4wkDIOOZ86 for ; Tue, 14 Apr 2015 09:07:08 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 26E0E1B2DE4 for ; Tue, 14 Apr 2015 09:04:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id EA2C61C3867; Wed, 15 Apr 2015 01:04:34 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C9FC3120EBE; Wed, 15 Apr 2015 01:04:34 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <3164216.CDnEBjYtuG@kitterma-e6430> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> <3164216.CDnEBjYtuG@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 15 Apr 2015 01:04:34 +0900 Message-ID: <87twwik86l.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 16:07:14 -0000 Scott Kitterman writes: > 8 bit to 7 bit transformations are also not rare. In the header? I guess with RFC 6532 that could happen frequently (but those folks are likely to be in trouble with DKIM anyway for the foreseeable future). > > Really, isn't the question whether Yahoo! and AOL are willing to do > > *anything* to mitigate? We need some participation from them or it's > > useless, and if at least one does participate, it's a win. What are > > they willing to think about implementing? > > Depends on who needs to change to mitigate things. To implement any of the "weak signature" variants (see subject), the >From domain has to be involved as sender. That's why I'm asking. > If (as an example only) we decide that From rewriting is the best > (least bad) solution, That's not what this thread is about, and it obviously doesn't need participation from them. From nobody Tue Apr 14 09:09:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F281F1B2DD9 for ; Tue, 14 Apr 2015 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EmHwcBIRjZrw for ; Tue, 14 Apr 2015 09:09:06 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915201B2DDD for ; Tue, 14 Apr 2015 09:07:14 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B7D0FC40474 for ; Tue, 14 Apr 2015 11:07:13 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429027633; bh=ViCDZJMf0a9bW7eHIh8kgiMx5rv/+KgP65/U6BCLfQo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gZpVHzSLRErUr2xk/rq470ClPFJhPxecWEV/2pAjgF7b4fMLJnNr0/PdrkSgKmpEC W9eJto0NL2g9aoabaIyQHPRVy4X8z70NZg3qLrtxAJu+ANqD1nEIucmnGCdyZaPz9s gFZ3fjOuo0RLyvZ5DtG/iYPw0yqh0gk0ooK5Ncvs= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 14 Apr 2015 12:07:09 -0400 Message-ID: <15535566.Qr3Hnl0jTF@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87twwik86l.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150410170856.730.qmail@ary.lan> <3164216.CDnEBjYtuG@kitterma-e6430> <87twwik86l.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 16:09:08 -0000 On Wednesday, April 15, 2015 01:04:34 AM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > 8 bit to 7 bit transformations are also not rare. > > In the header? I guess with RFC 6532 that could happen frequently > (but those folks are likely to be in trouble with DKIM anyway for the > foreseeable future). Yeah, I forgot what parts of the message we were talking about. Scott K > > > Really, isn't the question whether Yahoo! and AOL are willing to do > > > *anything* to mitigate? We need some participation from them or it's > > > useless, and if at least one does participate, it's a win. What are > > > they willing to think about implementing? > > > > Depends on who needs to change to mitigate things. > > To implement any of the "weak signature" variants (see subject), the > From domain has to be involved as sender. That's why I'm asking. > > > If (as an example only) we decide that From rewriting is the best > > (least bad) solution, > > That's not what this thread is about, and it obviously doesn't need > participation from them. From nobody Tue Apr 14 09:53:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909951B2F26 for ; Tue, 14 Apr 2015 09:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Z_h2H_R9q06b for ; Tue, 14 Apr 2015 09:53:48 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 12F851B2EF4 for ; Tue, 14 Apr 2015 09:53:33 -0700 (PDT) Received: by qkgx75 with SMTP id x75so26452009qkg.1 for ; Tue, 14 Apr 2015 09:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tny5ejCdbThp03W2q95F4jaoriClhB5F3CqNjZFgOSs=; b=r7PNZDPbix5SVrPz6G93g9RsWV6a2X1ud8TY63HkaYVP/3TcigsvBAYhEuuSazYKUD k9uD+lxfStynefSzRlx/J2bRCE1ONTiR8VuyEu+v8ap7ZLDN1MyUfgYZs4fQPbNjUphC RryKeVG1lnLPYMcRKYVimMrsAL0As8RwFTafk3aHaoCf4CYs2e/Dz4j7EnbiRw/8lU4K QdRnU8gmiEZobE/MRdrAsMF8GL1QJODtxr9qCS1Nibw86/B5dD2YxO72ibyFaX4I67Ux 3LxvtDyktk7Ki06B425vJMv+30x4Ja4bKkP5ncjK7Jt4KbOm14fuxT0ozy48SYqqoBKt JJTg== X-Received: by 10.55.22.194 with SMTP id 63mr42694570qkw.3.1429030384902; Tue, 14 Apr 2015 09:53:04 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id f1sm1084034qhe.31.2015.04.14.09.53.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 09:53:03 -0700 (PDT) Message-ID: <552D45ED.3030707@gmail.com> Date: Tue, 14 Apr 2015 09:53:01 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> In-Reply-To: <3116002.DAz6U52Rgm@kitterma-e6430> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 16:53:50 -0000 On 4/14/15 8:30 AM, Scott Kitterman wrote: > On Tuesday, April 14, 2015 11:11:00 AM Hector Santos wrote: >> On 4/14/2015 10:07 AM, Scott Kitterman wrote:> >> >>> If I misunderstood the proposal and it requires someone to be keeping a >>> list of mailing lists used (either globally or by individual users), then >>> I think this is not a good idea at all. I don't think any >>> tracking/whitelisting design is going to succeed at scale. >>> >>> My view is that either we find a reasonable way to make this idea work >>> without a list of mailing lists or we toss it on the pile of things that >>> won't work. >> Which is why the simple DNS lookup remains to be the ideal baseline >> and natural part of the generic DSAP (DKIM Signature Authorization >> Protocol) design. You need to cover all process model boundary >> conditions which include 1st and 3rd party mail streams. If you >> exclude one, its incomplete. >> >> The Publishing and "Registration" problem has been overblown. >> Registration basically means to find the domains (your network of >> signers) to publish. The latter is a business problem, not a IETF >> technical protocol problem. If we had used a "registration/scale >> problem" philosophy for other early IETF protocols, they were have >> never been completed as well and gotten to where we are at now. SPF >> has this same scale concern, and it still currently an extremely high >> wasteful DNS calling authorization check method for senders. The >> larger domains also had to "find" their network to register them as >> SPF machines. So this is not any different. >> >> The DNS "Lookup" algorithm has been the basic backbone idea since >> 2003, since LMAP ideas, since DNSRBL, since MAPS, well since forever, >> etc, the idea of "Looking up" an verified, integrity authenticated id >> for authorization, either its for bad or good, it became fashionable >> and an acceptable concept overtime by the DNS community. They bemoaned >> it but the DNS TXT-BASED applications was on the raise as an fast >> entry method to explore many new authorization ideas. >> >> We tried to get the "Good Signer" (SDID) lookup with the DKIM STD >> work. It didn't happen in the >> market place (it has issues that included the "Batteries Required" >> syndrome) and even if it did happen, the "Good Signer" methodology did >> not cover rudimentary DKIM signing failures checks (including missing). >> >> In all cases, you need a 3rd party Authorization list somewhere, >> whether everyone needs one or not, some will, some won't. That again >> is also a implementation and business decision. You can, in theory, >> have a more relaxed Signer Engine that double signs all mail or maybe >> under some rule that allows only outgoing LIST domains to be double >> signed. In all cases, this in-band method is still a registration >> concept, global or selective. >> >> The problem has been that some believe everyone will have this a huge >> need to "register" many domains, and IMV, this erroneous idea has >> crippled the completion of all DSAP protocols (SSP, ADSP, DMARC). >> No, only a few have such "registration" issues, whether thats a >> million or so, it still a small piece of the total domain space. We >> won't know how many for sure, but I have a pretty good feel the >> majority of domains will not need such large "list" needs. >> >> How many will you have to collect? I have 10. >> >> e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; >> d=megabytecoffee.com;" ) >> jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; >> d=winserver.com;" ) >> kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) >> LYKM653KJ7YXEIA665VA7LSZZTHCX7JJ._atps TXT ( "v=atps01; >> d=beta.winserver.com;" ) >> n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) >> pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) >> q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" ) >> ni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; >> d=mapurdy.com.au;" ) >> tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; >> d=santronics.com;" ) >> >> Are we saying that MOST systems will not be able to handle their >> Network of known signers? >> >> As stated above, this issue is no different than with SPF where larger >> networks had to learn their network of senders and even then, many >> still use weak/relaxed policies (~ALL, ?ALL) lowering the payoff of >> the redundant calls with no actionable results, indeterminate >> conditions - a high waste most of the time. >> >> The MLM or the site mail receivers just needs to make sure it does a >> ADID/SDID check. If the WG wants to spend time on a weaker more >> complex double signature "in-band" solution because the DNS >> administrator is no longer needed, that still doesn't mean that this >> design will be acceptable to all. The weaker alternative is more >> code change and if you can avoid code change, the better. DMARC >> SHOULD offer the more ideal and simple DNS lookup because it is a >> natural part of the DNS lookup model that already exist for DMARC >> which currently isolates itself to the ADID==SDID conditions and >> automatically failures all other conditions. > There's a big difference between needing to know the outbound architecture of > your own sending (as is needed by SPF and DMARC) and needing to know which of > all the places you send mail are mediators. > > You seem to think keeping a list of mediators like mailing lists is feasible > and offer a way to do it. I don't have an opinion on how good the method is > because I don't there is no way keeping a list can be done regardless of how > you store it. > > Also, for large providers like (for example) Google Groups, you wouldn't want > to authorize them at the domain level since it's a mix of high quality wanted > groups and spam groups. You'd have to do it at the individual mail box level > to make it workable. This only amplifies my concern about scalability. Dear Scott and Hector, DMARC offers feedback to help identify where a listing is needed. This list can be placed in DNS using hash labels and TSIG, for example. There should only be one hash label function. Essentially, all the various schemes require mediators be identifiable. If it turns out a mediator is a source of abuse, it should already be in the incoming block list. Likely another DNS entry. Since your users will be unable to see a response anyway don't let users send to known abusers. DMARC can signal use of a mediator and flag this scheme rather than changing or adding DKIM signatures. No matter the scheme, they all require some form of vetting. A role that can be played by a repaired ATPS or TPA-Label. Since mailing-lists are likely to receive special handling It might be assumed that those allowed to post have been limited by subscription. Since a mediator may share a domain having other uses, TPA-Label is able to differentiate them to close a subscription gap. Any scheme to enable a third-party must be very concerned about restricting access. How would you envision access be restricted with draft-kucherawy-dkim-delegate or draft-levine-dkim-conditional? In many cases, the From is already being munged. Regards, Douglas Otis From nobody Tue Apr 14 10:00:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864D31B2EB3 for ; Tue, 14 Apr 2015 10:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 KIPTDCovV7QI for ; Tue, 14 Apr 2015 09:59:57 -0700 (PDT) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D89061B2EE6 for ; Tue, 14 Apr 2015 09:59:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3121; t=1429030792; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=DAoWJM5ni+ERGLhmH/pw34Pwx44=; b=rRbmFENiXZGTFlF/Ivr9 L4ZPZRO+t/vhMpVprNZFX+PHfWDeq5rl137EIPf3rXZjLNQLyCOetuVtewfw3Onq sJ4az91vVbmSnj212Z5bmq/32vjBLzXQfK7pLx57ScXxc7ajdUcjBeLWueUlRx0B KO10NDm2GW4MUFxzi8I/dJ0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 12:59:52 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2740807627.7719.3892; Tue, 14 Apr 2015 12:59:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3121; t=1429030560; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=J0uSaC8 9V0Y2OS934Ab3HpdKhs9RHwaUY+giMay6E1E=; b=JYOV7jTHsHrJZGlWzmi81/Z PbSvDO8Mhq5ZokMxBvTk5k9Yvrzux21Wp8kbq6WE4D8+RakPG/B5jZ01qMqgMzSe HLAs+QeKB0g5yEKGe56vz+t4GOwGPRuykWONDIuAJQACnyIpVdfMY4GTtEy4nbPh 2orWP5B+d8OzKaynXrpU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 12:56:00 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1333096285.9.10196; Tue, 14 Apr 2015 12:55:59 -0400 Message-ID: <552D4787.9080704@isdg.net> Date: Tue, 14 Apr 2015 12:59:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> In-Reply-To: <3116002.DAz6U52Rgm@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 17:00:03 -0000 On 4/14/2015 11:30 AM, Scott Kitterman wrote: > > There's a big difference between needing to know the outbound architecture of > your own sending (as is needed by SPF and DMARC) and needing to know which of > all the places you send mail are mediators. Sure, but first, from a protocol standpoint, it doesn't/shouldn't matter, its the same. Either the ADID publishes the information or not. Second, not every list/email application is the same, so yes, some will know and some will not. Many SPF larger domains do not know their outbound MTA, so they include many INCLUDE statements and many still have a relaxed policy. Its not causing a reject but it is waste in DNS traffic. We can't use a "scale" argument here when you have a already high wasteful scale issue with SPF. Just look at google.com. How many includes and its all for a softfail? Talk about waste. Yet, at times, I suppose most of the time, it works, with a PASS result to skip the remaining test. > You seem to think keeping a list of mediators like mailing lists is feasible > and offer a way to do it. I don't have an opinion on how good the method is > because I don't there is no way keeping a list can be done regardless of how > you store it. Its not that I believe its feasible, but that not unfeasible as well. Its all doable. We did it. The protocol is the same whether a particular site believes it can use it or not. For our signer engine, I can see it doing a @FS=SDID signature because for MLS, it makes the mail with a meta header "SIGN-THIS" telling the outbound signing engine a specific set of signing rules, i.e. like use l=0, don't hash bind the subject line, IOW, make the stream weaker. So it could be done for our product, but its code change and its weaker too. The receiver still needs to do more work. So think of the "Scaling" at all ends. For non-compliant (@FS=) receivers, we just double their verification work load, an extra DNS Key lookup, all for nothing. At scale, is that a problem? > Also, for large providers like (for example) Google Groups, you wouldn't want > to authorize them at the domain level since it's a mix of high quality wanted > groups and spam groups. You'd have to do it at the individual mail box level > to make it workable. This only amplifies my concern about scalability. We need to differentiate what we need by "scale" and everyone is different. For one of many examples, you are presuming a need for Google Groups. I don't need it, nor expect it and there will be millions of private operations domains who don't care for it either. In other words, lets not use marketing decisions to put up barriers to the general IETF technical protocol requirement to include the authorization for the ADID != SDID condition. Google is just one company and is it causing very very high waste with its soft SPF policy. This high scale, redundant waste didn't stop most people from using SPF. One day, Google will change it to -ALL perhaps. On the other hand for other companies, Yes, I believe it is very feasible and manageable. -- HLS From nobody Tue Apr 14 10:13:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C71A0397 for ; Tue, 14 Apr 2015 10:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 H-1cgZXZFkeF for ; Tue, 14 Apr 2015 10:13:03 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0089.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9061A0177 for ; Tue, 14 Apr 2015 10:12:44 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.136.3; Tue, 14 Apr 2015 17:12:23 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 17:12:22 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Publishing and Registration Concerns Thread-Index: AQHQdtR4gmTZLiYUhE6z++40+HrMyJ1MvWsQ Date: Tue, 14 Apr 2015 17:12:21 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> In-Reply-To: <552D4787.9080704@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.147.69] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(13464003)(479174004)(24454002)(377454003)(92566002)(62966003)(77156002)(33656002)(87936001)(68736005)(15975445007)(102836002)(86362001)(97736003)(19580405001)(4001540100001)(81156007)(107886001)(19580395003)(93886004)(4001410100001)(2501003)(46102003)(2656002)(105586002)(2950100001)(76176999)(106116001)(2900100001)(54356999)(50986999)(64706001)(101416001)(106356001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 054642504A received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 17:12:21.9011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 17:13:06 -0000 > On the other hand for other companies, Yes, I believe it is very feasible= and=20 > manageable. So, maybe I'm missing something here on the idea of TPA and registration of= mailing lists (in DNS), and mentioning Google Groups and how they can figu= re it out... but not every emailer controls the DNS of the domains they rel= ay email from. Google certainly owns gmail.com, and Microsoft owns outlook.= com and Hotmail.com, and Yahoo own yahoo.com, so conceivably they could aut= horize and auto-publish something. But there's no way Google Apps and Microsoft's Office 365 (for example) can= publish DNS entries for all of its small, medium, and large businesses tha= t use its service and subscribe to mailing lists, because many times those = companies don't control the DNS for their customers. They'd (we'd) have to = get customers to update their DNS entries for every mailing list they use i= f we don't have access to their DNS. Getting customers to update their DNS = is almost as pleasant as getting my teeth cleaned. That's what we mean when we say it doesn't scale. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Tuesday, April 14, 2015 10:00 AM To: dmarc@ietf.org Subject: [dmarc-ietf] Publishing and Registration Concerns On 4/14/2015 11:30 AM, Scott Kitterman wrote: > > There's a big difference between needing to know the outbound architectur= e of > your own sending (as is needed by SPF and DMARC) and needing to know whic= h of > all the places you send mail are mediators. Sure, but first, from a protocol standpoint, it doesn't/shouldn't=20 matter, its the same. Either the ADID publishes the information or=20 not. Second, not every list/email application is the same, so yes,=20 some will know and some will not. Many SPF larger domains do not know=20 their outbound MTA, so they include many INCLUDE statements and many=20 still have a relaxed policy. Its not causing a reject but it is=20 waste in DNS traffic. We can't use a "scale" argument here when you have a already high=20 wasteful scale issue with SPF. Just look at google.com. How many=20 includes and its all for a softfail? Talk about waste. Yet, at times,=20 I suppose most of the time, it works, with a PASS result to skip the=20 remaining test. > You seem to think keeping a list of mediators like mailing lists is feasi= ble > and offer a way to do it. I don't have an opinion on how good the method= is > because I don't there is no way keeping a list can be done regardless of = how > you store it. Its not that I believe its feasible, but that not unfeasible as well.=20 Its all doable. We did it. The protocol is the same whether a=20 particular site believes it can use it or not. For our signer=20 engine, I can see it doing a @FS=3DSDID signature because for MLS, it=20 makes the mail with a meta header "SIGN-THIS" telling the outbound=20 signing engine a specific set of signing rules, i.e. like use l=3D0,=20 don't hash bind the subject line, IOW, make the stream weaker. So it=20 could be done for our product, but its code change and its weaker too.=20 The receiver still needs to do more work. So think of the=20 "Scaling" at all ends. For non-compliant (@FS=3D) receivers, we just=20 double their verification work load, an extra DNS Key lookup, all for=20 nothing. At scale, is that a problem? > Also, for large providers like (for example) Google Groups, you wouldn't = want > to authorize them at the domain level since it's a mix of high quality wa= nted > groups and spam groups. You'd have to do it at the individual mail box l= evel > to make it workable. This only amplifies my concern about scalability. We need to differentiate what we need by "scale" and everyone is=20 different. For one of many examples, you are presuming a need for=20 Google Groups. I don't need it, nor expect it and there will be=20 millions of private operations domains who don't care for it either. In other words, lets not use marketing decisions to put up barriers to=20 the general IETF technical protocol requirement to include the=20 authorization for the ADID !=3D SDID condition. Google is just one=20 company and is it causing very very high waste with its soft SPF policy. This high scale, redundant waste didn't stop most people from using=20 SPF. One day, Google will change it to -ALL perhaps. On the other=20 hand for other companies, Yes, I believe it is very feasible and=20 manageable. --=20 HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Apr 14 10:25:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51751A01D5 for ; Tue, 14 Apr 2015 10:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 7mM-1pBp5sOq for ; Tue, 14 Apr 2015 10:25:48 -0700 (PDT) Received: from mail.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 695F71A0143 for ; Tue, 14 Apr 2015 10:25:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1650; t=1429032338; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=3o7xkJyJVeIOGPeS/l/AN/71PTg=; b=VBj9wRq+lrPmZ8vLDEbH 8HnNpIFDmktXtJ6BKln+/kUGwVItbFeV0j7rGA/Hrik8XSIsWOLkEGTNeOi1fz2q 0QbvEWEcjlFsaG4vGTpNbk3MnMWCKRYoS1puioSc/R+FQ4tz0ykl/ZLX92zQUxOs wY+FtWCVB6nNJNdnI2atGmE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 13:25:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2742352739.7719.3668; Tue, 14 Apr 2015 13:25:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1650; t=1429032103; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uhLKQrW qbvyIRqyE/neGZcUqh6qMG6VUvmBd+fSfIdE=; b=Cq9woch28fsM+JISdt+Gskl MYn4QJqn8OJFbwfGzsqeXGU9OesXihHKENK/nguv2AbPip9/OffouAXW1APEHMzf uDHkVPCcw1ycMXpKJe/74WSw5wcq/8TbDAurQfEvZhQcobr7rnx9ui6rY5V3SyOB yMgnuHhh8nE1dpDDvrSg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 13:21:42 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1334638691.9.5188; Tue, 14 Apr 2015 13:21:42 -0400 Message-ID: <552D4D8D.6070008@isdg.net> Date: Tue, 14 Apr 2015 13:25:33 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D45ED.3030707@gmail.com> In-Reply-To: <552D45ED.3030707@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 17:25:49 -0000 On 4/14/2015 12:53 PM, Douglas Otis wrote: > Dear Scott and Hector, > > DMARC offers feedback to help identify where a listing is > needed. This list can be placed in DNS using hash labels > and TSIG, for example. Sure Doug, yes, there are ways to automate this. The feedback is there and scripts can be written. > Since mailing-lists are likely to receive special handling > It might be assumed that those allowed to post have been > limited by subscription. Since a mediator may share a > domain having other uses, TPA-Label is able to differentiate > them to close a subscription gap. Any scheme to enable a > third-party must be very concerned about restricting > access. How would you envision access be restricted with > draft-kucherawy-dkim-delegate or > draft-levine-dkim-conditional? In many cases, the From is > already being munged. Too complicated. One assertion needs to be tested: Does the ADID authorize the SDID? You can query the ADID DNS database for this. How that data gets there is a whole different issue. In the mean time, the WG should work on the DMARC protocol making it ready for a 3rd party authorization method. Doug, TPA is too complicated. I am not convince it does anything more than what a simpler ATPS will offer or a basic Yes/No Query of the ADID/SDID. TPA is essentially the same lookup method but you tied extra meaning. I don't think its necessary. Nonetheless, lets propose a new "sam=" tag in DMARC, "Signature Authorization Method" v=DMARC1; sam=tpa|atps|fs This allows for the intelligent receiver to explore and learn which is the best method. -- HLS From nobody Tue Apr 14 10:47:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C061A1A6E for ; Tue, 14 Apr 2015 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JCGGGPt2la5o for ; Tue, 14 Apr 2015 10:47:21 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 44BD71A1A04 for ; Tue, 14 Apr 2015 10:47:21 -0700 (PDT) Received: by wizk4 with SMTP id k4so123583080wiz.1 for ; Tue, 14 Apr 2015 10:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTLbflHkVuHlVaqxqjSU6YOyy0Pk7GRzQKI9fmsW12A=; b=O/Bw01b1UyTuYGsVuAOtWXRr0yURnRF3U8esKCnG92+cRGsTwJ59hn+XF6TKkvAMj5 /QgdPlA1y82z/MX0+JnAmtj3s7vNfBnT2mXVu6zmiEAYBDOLLSwIJ1o8OJOsDt3P+Bdb +BiBuhokOElKzwOIPm4y5PKHk4JRKOZgrGZsbSkuJ84xqxr+ClifdyGeJ9nJCwWkj2jH qAd3nzAzjBCkne9RiMBW45VwVVtYk5WKjsYYVR7tfNF3egYVL9JaFIfrfd7mQHdGU74z WSCsHF3IDf0GjiqiFKXXxtoZEgrNlJbCoYVIDRxRtBY9MC1HFuvjEHCxhU5y2pfPzU6H w4SQ== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr41133828wjc.4.1429033640075; Tue, 14 Apr 2015 10:47:20 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 10:47:20 -0700 (PDT) In-Reply-To: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> Date: Tue, 14 Apr 2015 10:47:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e01419d1c7d28510513b2d222 Archived-At: Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 17:47:23 -0000 --089e01419d1c7d28510513b2d222 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 14, 2015 at 10:12 AM, Terry Zink wrote: > But there's no way Google Apps and Microsoft's Office 365 (for example) > can publish DNS entries for all of its small, medium, and large businesses > that use its service and subscribe to mailing lists, because many times > those companies don't control the DNS for their customers. They'd (we'd) > have to get customers to update their DNS entries for every mailing list > they use if we don't have access to their DNS. Getting customers to update > their DNS is almost as pleasant as getting my teeth cleaned. > ...and remove entries when one of them stops using a mailing list. And for all we know this might happen with such scale that it begins to affect DNS caching of other useful data. > That's what we mean when we say it doesn't scale. Right. And since the largest problem is with the largest operators (because they have the biggest impact), a solution they aren't likely to adopt is probably a waste of precious working group resources. It's not "marketing" to decide to abandon a protocol that nobody will actually use. Rather, it's a highly pragmatic engineering (and working group) decision. -MSK --089e01419d1c7d28510513b2d222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2015 at 10:12 AM, Terry Zink <= tzink@exchange.microsoft.com> wrote:
But there&#= 39;s no way Google Apps and Microsoft's Office 365 (for example) can pu= blish DNS entries for all of its small, medium, and large businesses that u= se its service and subscribe to mailing lists, because many times those com= panies don't control the DNS for their customers. They'd (we'd)= have to get customers to update their DNS entries for every mailing list t= hey use if we don't have access to their DNS. Getting customers to upda= te their DNS is almost as pleasant as getting my teeth cleaned.

...and remove entries when one of them stops using= a mailing list.=C2=A0 And for all we know this might happen with such scal= e that it begins to affect DNS caching of other useful data.
=C2=A0
<= /div>
That's what we mean when we say it doesn't scale.
=
Right.=C2=A0 And since the largest problem is with the large= st operators (because they have the biggest impact), a solution they aren&#= 39;t likely to adopt is probably a waste of precious working group resource= s.

It's not "marketing" to decide to abando= n a protocol that nobody will actually use.=C2=A0 Rather, it's a highly= pragmatic engineering (and working group) decision.

-MSK=
--089e01419d1c7d28510513b2d222-- From nobody Tue Apr 14 11:09:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF501A1E0E for ; Tue, 14 Apr 2015 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4vrHDUrIGcR6 for ; Tue, 14 Apr 2015 11:09:38 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (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 3AA371A1DBC for ; Tue, 14 Apr 2015 11:09:38 -0700 (PDT) Received: by qcpm10 with SMTP id m10so129580qcp.3 for ; Tue, 14 Apr 2015 11:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AR+pQIfAEFwgzxFN2VGz6IXpZpklBBWphhA3oJjoJ2E=; b=Qonp6gKBUFxI4bYfY/hSpcH3NbetPg74L57w/L+R0BgpauvN+qUcsXjpuqAIJdxoUG 8txFcHfIDCc/o1iZl/mcHYvyB7HXkVfVUIET/WkJRBpUvx1ZLkR/Ap+Cegpuf2FzHxzD 7NBMCtol+b5Wn9pm+GFy03e7hOaR+nfjGiuN26uP7JSFPLrfo/KQ7bk4PYJHKKI1comD GLVnQGKsMidyetDxHhyNLMSiU0AyqVgoRCPpU3AhWRKyO3l5vYzqcO8l4ZnuicAwl5MQ CeMNhj6at7HjI7tY7Xv1lYotp1qPP18+XtFBrTcU3XNdrsaWp9PJUfdicJFvruh3AT4Y psPQ== X-Received: by 10.140.128.73 with SMTP id 70mr27375303qha.75.1429034977344; Tue, 14 Apr 2015 11:09:37 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id q193sm1241570qha.14.2015.04.14.11.09.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 11:09:35 -0700 (PDT) Message-ID: <552D57DE.6070200@gmail.com> Date: Tue, 14 Apr 2015 11:09:34 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:09:40 -0000 On 4/14/15 10:12 AM, Terry Zink wrote: >> On the other hand for other companies, Yes, I believe it is very feasible and >> manageable. > So, maybe I'm missing something here on the idea of TPA and registration of mailing lists (in DNS), and mentioning Google Groups and how they can figure it out... but not every emailer controls the DNS of the domains they relay email from. Google certainly owns gmail.com, and Microsoft owns outlook.com and Hotmail.com, and Yahoo own yahoo.com, so conceivably they could authorize and auto-publish something. > > But there's no way Google Apps and Microsoft's Office 365 (for example) can publish DNS entries for all of its small, medium, and large businesses that use its service and subscribe to mailing lists, because many times those companies don't control the DNS for their customers. They'd (we'd) have to get customers to update their DNS entries for every mailing list they use if we don't have access to their DNS. Getting customers to update their DNS is almost as pleasant as getting my teeth cleaned. > > That's what we mean when we say it doesn't scale. Dear Terry, TPA-Label operates within its own sub-domain. This sub-domain can be delegated or use DNAME. This means this information can be handled by an organization dedicated to detecting and preventing third-party abuse. In essence, a role likely to entail sending notices to domains and ensuring problems are corrected or having their third-party provisions retracted. A function that Yahoo and AOL dumped on everyone else by (ab)using DMARC. How is the scaling issue really worse than the changes currently required for SPF? In fact, SPF often entails more DNS transactions per use. Initially I argued for APL RR rather than TXT. People were impatient and wanted something quickly kludged into every registrar system. This impatience resulted in a sizable overhead with many unused active macro script and policy features due to high error rates and why DMARC uses the logical OR of DKIM and SPF. Regards, Douglas Otis From nobody Tue Apr 14 11:11:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F611A1DE1 for ; Tue, 14 Apr 2015 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 tVi5DY0-tFuI for ; Tue, 14 Apr 2015 11:10:59 -0700 (PDT) Received: from listserv.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 06EB11A1BB5 for ; Tue, 14 Apr 2015 11:10:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1823; t=1429035042; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=CQNsvoHN3C3PUbnZZaIbniRfFO0=; b=qkf6tplmdPXPquWnIT3m yKXoSyO4cEfQtG78Siej3iu680fRiA2dhe0og+/UbKHV40JqWJAst/SvDe+bLIY1 ckktTWU5S7zUCSO5XipOz+pj3OY80eY1RnVGLhD/nlM37YfZISK688nT+r0/x8hw GpnksusnvzoG9R8bB07tLr8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 14:10:42 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2745057843.7719.1068; Tue, 14 Apr 2015 14:10:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1823; t=1429034808; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=DJmBEBO 6XKVFTa9o0m+2koU+jCKi+8tf+hg739jndDU=; b=fXcOhcal65MNY1OZSxndOZ9 OJUl6aCgDees9LtLGcFKyF8jdiu0BD239hMrCQN3Mxux/VejmDa3oA+88iiaKp4J 217b5oq0kpVY+j205gWHoGrWtpKSZTWyWx+O/rJmGwvfsaHcjtTubO8WM71nw8Ee AQHy7HdcG3QRfs/nemeU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 14:06:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1337343707.9.6804; Tue, 14 Apr 2015 14:06:47 -0400 Message-ID: <552D581E.4040008@isdg.net> Date: Tue, 14 Apr 2015 14:10:38 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:11:01 -0000 On 4/14/2015 1:47 PM, Murray S. Kucherawy wrote: > It's not "marketing" to decide to abandon a protocol that nobody will > actually use. Why do you keep repeating this when you know it is not true? We used it in real commercial products and it works as designed. It has scaled for us. >Rather, it's a highly pragmatic engineering (and working > group) decision. No, If it that was done, it would be a different story. It wasn't done. ADSP was bitterly abandoned and left for dead, you had a major conflict of interest with a reputation/trust modeling framework and vendors in the market place, therefore any add-on (TPA, ATPS) for it would not get serious traction at all. I always felt it will eventually, hence adding the support or the basic DKIM+POLICY into the framework. You got a different situation with DMARC replacing ADSP. It is a making a marketing decision when you exclude a perfectly logical, technical and natural part of a protocol out because A) you believe it impugns on resigner operations and B) make instantiated statements that won't scale. That SHOULD NOT be your position within the IETF to stop it from happening. You should support it because it is technically sound. Don't use it yourself but promote not to use it in others in a search for an alternative that is more complex, more insecure and more changes and doesn't resolve the so called "registration" problem,. Using parato's principle, it will scale for most of the domains because most domains are not Microsoft, Google, Aol or Yahoo. There are more small domains than these relatively few handful. Using parato's principle, most will not have a need to register thousands of list domains and using parato's principle, most can handle even larger big-data problems just fine. -- HLS From nobody Tue Apr 14 11:25:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB15A1A8853 for ; Tue, 14 Apr 2015 11:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 bd23X1bWuHj0 for ; Tue, 14 Apr 2015 11:25:20 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 C4D461A802A for ; Tue, 14 Apr 2015 11:25:19 -0700 (PDT) Received: by wiun10 with SMTP id n10so32300644wiu.1 for ; Tue, 14 Apr 2015 11:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Hp8n2OVT7E9HBfnsx388U5p7HljBgfin2mi4rzwSeTc=; b=DMwZAeQmKlZ4EKVOzYdgvkKFsjaDdyyj6FW7uvCV0xdWhPAWlJWTtaoL98qiwa6zhf LUkK9ukdz2bVCYJMet58uqFljdaVizbuclMTS23cP5MM00Nm8v17UPpwylgckJhfKziP v9oJ/bQDleD6RvqDkKLGaWEr4J6m6vF3/iLTLQVq2QLLRHdHn7LOKwd6OZQrQCCRn8GR Pk2vbGI1Fb2kW7dKbgHweMYOqcB6dZ/2anNblZ3dofK/vyz7Sb4UtpRNq0KTZmSmhSI0 iukUEvaxIvnnHYRd3I1Du7SQk+heUsJVKrgddwBJwiDnfHZky/SFnMpH9mLSzPeZTM/v x93g== MIME-Version: 1.0 X-Received: by 10.180.74.37 with SMTP id q5mr34998863wiv.59.1429035918566; Tue, 14 Apr 2015 11:25:18 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 11:25:18 -0700 (PDT) In-Reply-To: <20150410162632.3280.48979.idtracker@ietfa.amsl.com> References: <20150410162632.3280.48979.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 11:25:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7f244c29ad0513b35aa0 Archived-At: Subject: [dmarc-ietf] Fwd: WG Action: Formed Domain Boundaries (dbound) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:25:23 -0000 --f46d043c7f244c29ad0513b35aa0 Content-Type: text/plain; charset=UTF-8 Colleagues, The DBOUND working group has officially formed. We will be working on the question of what to do about our concerns with the Public Suffix List, which is an important component of DMARC, so it's relevant here. The chairs will be announcing to that list soon what our plan of attack is. Feel free to subscribe if interested. -MSK, one of the DBOUND chairs ---------- Forwarded message ---------- From: The IESG Date: Fri, Apr 10, 2015 at 9:26 AM Subject: WG Action: Formed Domain Boundaries (dbound) To: IETF-Announce Cc: dbound WG A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Domain Boundaries (dbound) ------------------------------------------------ Current Status: Proposed WG Chairs: Pete Resnick Murray Kucherawy Assigned Area Director: Barry Leiba Mailing list Address: dbound@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dbound Archive: http://www.ietf.org/mail-archive/web/dbound Charter: Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitary concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful to determine whether example.com and foo.example.com, or even example.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always "compare the rightmost two labels". Applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the "Additional Background Information" section of the working group wiki for more details: https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation For the purpose of this work, "domain names" are identifiers used by organizations and services, independent of underlying protocols or mechanisms, and an "organizational domain" is defined as a name that is at the top of an administrative hierarchy, defining transition from one "outside" administrative authority to another that is "inside" the organization. The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"), and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) under this charter. If such work is desirable, it will be assigned to another appropriate working group or defined as a work item in an updated charter. Rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: TBD --f46d043c7f244c29ad0513b35aa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The DBOUND working group has = officially formed.=C2=A0 We will be working on the question of what to do a= bout our concerns with the Public Suffix List, which is an important compon= ent of DMARC, so it's relevant here.

The chairs will be an= nouncing to that list soon what our plan of attack is.=C2=A0 Feel free to s= ubscribe if interested.

-MSK, one of the DBOUND chairs

---------- Forwarded message= ----------
From: The IESG <iesg-secretary@ietf= .org>
Date: Fri, Apr 10, 2015 at 9:26 AM
Subject: WG Ac= tion: Formed Domain Boundaries (dbound)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: dboun= d WG <dbound@ietf.org>

=
A new IETF working group has been formed in the Applications Area. For<= br> additional information please contact the Area Directors or the WG
Chairs.

Domain Boundaries (dbound)
------------------------------------------------
Current Status: Proposed WG

Chairs:
=C2=A0 Pete Resnick <presni= ck@qti.qualcomm.com>
=C2=A0 Murray Kucherawy <superuse= r@gmail.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleib= a@computer.org>

Mailing list
=C2=A0 Address: dbound@ietf.org
=C2=A0 To Subscribe: http://www.ietf.org/mailman/listinfo/dbound
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/dbound

Charter:

Various Internet protocols and applications require some mechanism for
determining whether two domain names are related. The meaning of
"related" in this context is not a unitary concept. The DBOUND wo= rking
group will develop one or more solutions to this family of problems,
and will clarify the types of relations relevant.

For example, it is often necessary or useful to determine whether
example.com and foo.example.com, or even= example.net, are subj= ect to
the same administrative control. To humans, the answer to this may be
obvious. However, the Domain Name System (DNS), which is the service
that handles domain name queries, does not provide the ability to mark
these sorts of relationships. This makes it impossible to discern
relationships algorithmically. The right answer is not always "compare=
the rightmost two labels".

Applications and organizations impose policies and procedures that
create additional structure in their use of domain names. This creates
many possible relationships that are not evident in the names
themselves or in the operational, public representation of the names.

Prior solutions for identifying relationships between domain names have
sought to use the DNS namespace and protocol to extract that information when it isn't actually there.=C2=A0 See the "Additional Background=
Information" section of the working group wiki for more details:
https://trac.tools.ietf.org/wg/dbound/tr= ac/wiki/AdditionalBackgroundInformation

For the purpose of this work, "domain names" are identifiers used= by
organizations and services, independent of underlying protocols or
mechanisms, and an "organizational domain" is defined as a name t= hat
is at the top of an administrative hierarchy, defining transition from
one "outside" administrative authority to another that is "i= nside" the
organization.

The current way most of this is handled is via a list published at
publicsuffix.org = (commonly known as the "Public Suffix List" or "PSL"),<= br> and the general goal is to accommodate anything people are
using that for today.=C2=A0 However, there are broadly speaking two use
patterns. The first is a "top ancestor organization" case. In thi= s case,
the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of
subordinate names. The second is to determine, given two different
names, whether they are governed by the same administrative authority.
The goal of the DBOUND working group is to develop a unified solution,
if possible, for determining organizational domain boundaries. However,
the working group may discover that the use cases require different
solutions. Should that happen, the working group will develop those
different solutions, using as many common pieces as it can.

Solutions will not involve the proposal of any changes to the DNS
protocol.=C2=A0 They might involve the creation of new resource record type= s.

This working group will not seek to amend the consuming protocols
themselves (standards for any web, email, or other such protocols) under this charter.=C2=A0 If such work is desirable, it will be assigned to anoth= er
appropriate working group or defined as a work item in an updated
charter. Rechartering will only be considered after completion of the
base work.

The working group has a pre-IETF draft to consider as a possible
starting point: draft-sullivan-dbound-problem-statement

Milestones:

TBD


--f46d043c7f244c29ad0513b35aa0-- From nobody Tue Apr 14 11:49:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F701AC445 for ; Tue, 14 Apr 2015 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 TABUVn71qjDf for ; Tue, 14 Apr 2015 11:49:53 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 2C7B81AC43B for ; Tue, 14 Apr 2015 11:49:53 -0700 (PDT) Received: by widdi4 with SMTP id di4so33260092wid.0 for ; Tue, 14 Apr 2015 11:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pEf9x+h1ZeB4GDlj3jr1/AvigOrWudVGhrKBzvWrLKw=; b=K8h+jAI9mizlWQYKLolXPlnSWbQS24+xmHNhILFCm4r3wGAnB0dBcqM/pRtfReeLph rryyf+AXAIj3QLwMlQ4XdIgxz0NnMlzJiYX5qg+2LqjxfNeiZ6B6N2VJpmp+9xGutUpy jdqNk5Q4tdQqVNG9HxbN/fsrjBwRtlRALNAKh/xrmKkwbcHHuVNg/MJsx1v2mBbgo3um dZIcW2jf1+n+7w4ylMuovjT6sKRgPhmUycWWi6g+LIOTfepPBVGf1IJ9/NTsKzK36DB4 FoO/nrLQ64fWK85VUsjxKk7ThQP4zq212xQianeGvxnGMs/Bcwh7Z0BfNnmct3T0L6K7 Yn+Q== MIME-Version: 1.0 X-Received: by 10.180.74.37 with SMTP id q5mr35164722wiv.59.1429037391966; Tue, 14 Apr 2015 11:49:51 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 11:49:51 -0700 (PDT) In-Reply-To: <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150410170856.730.qmail@ary.lan> <27825632-E019-4B54-914F-D37C633BF787@kitterman.com> <87k2xeddtk.fsf@uwakimon.sk.tsukuba.ac.jp> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 14 Apr 2015 11:49:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d043c7f241e775f0513b3b2c0 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:49:55 -0000 --f46d043c7f241e775f0513b3b2c0 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 14, 2015 at 7:56 AM, Stephen J. Turnbull wrote: > > If I misunderstood the proposal and it requires someone to be > > keeping a list of mailing lists used (either globally or by > > individual users), then I think this is not a good idea at all. I > > don't think any tracking/whitelisting design is going to succeed at > > scale. > > I can't speak for Murray, but I can't see that his proposal does. > Sorry, I've lost context. I assume you're talking about dkim-list-canon. You could apply it only when you know the mail is going to a list, maybe if you're worried about overall header size or crypto cost, but it's designed to be used generally. Since it's a signature that covers the whole message, it's not replayable (any more than basic DKIM is). Really, isn't the question whether Yahoo! and AOL are willing to do > *anything* to mitigate? We need some participation from them or it's > useless, and if at least one does participate, it's a win. What are > they willing to think about implementing? > At least one of them is subscribed, but I've no idea if they're actively monitoring. At the same time, I think the feedback we're getting from MS and Google is equally valuable, and they're active. -MSK --f46d043c7f241e775f0513b3b2c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2015 at 7:56 AM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
=C2=A0= > If I misunderstood the proposal and it requires someone to be
=C2=A0> keeping a list of mailing lists used (either globally or by
=C2=A0> individual users), then I think this is not a good idea at all.= =C2=A0 I
=C2=A0> don't think any tracking/whitelisting design is going to suc= ceed at
=C2=A0> scale.

I can't speak for Murray, but I can't see that his proposal = does.

Sorry, I've lost context.=C2= =A0 I assume you're talking about dkim-list-canon.

Yo= u could apply it only when you know the mail is going to a list, maybe if y= ou're worried about overall header size or crypto cost, but it's de= signed to be used generally.=C2=A0 Since it's a signature that covers t= he whole message, it's not replayable (any more than basic DKIM is).
Really, isn't the question whether Yahoo! and AOL are willing to do
*anything* to mitigate?=C2=A0 We need some participation from them or it= 9;s
useless, and if at least one does participate, it's a win.=C2=A0 What a= re
they willing to think about implementing?

At least one of them is subscribed, but I've no idea if they're = actively monitoring.=C2=A0 At the same time, I think the feedback we're= getting from MS and Google is equally valuable, and they're active.
-MSK
--f46d043c7f241e775f0513b3b2c0-- From nobody Tue Apr 14 12:00:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5061ACE01 for ; Tue, 14 Apr 2015 12:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 PYOpUTGqyIN2 for ; Tue, 14 Apr 2015 12:00:12 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 8AADB1ACDBF for ; Tue, 14 Apr 2015 11:59:24 -0700 (PDT) Received: by qku63 with SMTP id 63so33829614qku.3 for ; Tue, 14 Apr 2015 11:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0+V7L9IfD8QO9/BHfHmtgZUUh25a18Y3yZ5QEJeOnx8=; b=rVAMhs2ULu6fruE2U995YFLSADoi04GC5a+Xl5kbI2G0GFHzt2LqLgteh6Nb96uJUG 5kzVxK/fzcFZNPqn3jQuvBysdSjx2+1ZocUkDgYwj8KQlDuvR0mbTywVW62ZXCkH9AiE knSccrt7dWdgSpcKoIg6RBGm0LjCPRRLO+D2IsVDniYvxtiGuw6pEgFUNp03N9U77g6R JkmlMa+gLlNooNZEYelCDLfgcmH+/RN6QGUy3VoWdF7/IrU2s6PVzK6CxOX30VK6H7MG YqqWtYVOlu/8TruNY/dookpBLqktMCjgdE20Yux0KxQbToeTFfiFP91FQzub3jfqacDh YbQg== X-Received: by 10.140.146.142 with SMTP id 136mr28049609qhs.31.1429037936579; Tue, 14 Apr 2015 11:58:56 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 13sm1334617qku.20.2015.04.14.11.58.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 11:58:54 -0700 (PDT) Message-ID: <552D636D.3020305@gmail.com> Date: Tue, 14 Apr 2015 11:58:53 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:00:16 -0000 On 4/14/15 10:47 AM, Murray S. Kucherawy wrote: > On Tue, Apr 14, 2015 at 10:12 AM, Terry Zink > wrote: > >> But there's no way Google Apps and Microsoft's Office 365 (for example) >> can publish DNS entries for all of its small, medium, and large businesses >> that use its service and subscribe to mailing lists, because many times >> those companies don't control the DNS for their customers. They'd (we'd) >> have to get customers to update their DNS entries for every mailing list >> they use if we don't have access to their DNS. Getting customers to update >> their DNS is almost as pleasant as getting my teeth cleaned. > ...and remove entries when one of them stops using a mailing list. And for > all we know this might happen with such scale that it begins to affect DNS > caching of other useful data. >> That's what we mean when we say it doesn't scale. I have a fair amount of experience with this approach, since we published more than 1 billion resource records having 300 second TTLs without issue. DNS scales as will the scheme being proposed. Often these zones are limited to queries from MTAs given their own resolvers. What is being currently described represents orders of magnitude smaller deployments. It represents work that everyone wants to avoid. Clearly they don't care about third-party services and don't think email should have ever accommodated the role of Sender. > Right. And since the largest problem is with the largest operators > (because they have the biggest impact), a solution they aren't likely to > adopt is probably a waste of precious working group resources. > > It's not "marketing" to decide to abandon a protocol that nobody will > actually use. Rather, it's a highly pragmatic engineering (and working > group) decision. The problem we currently have today was born out of pragmatic reactions by the largest providers. Lets not waste time on measures unable to safely repair the damage, even when it means the community as a group must now carry the burden forced upon them. I don't think anyone has seriously considered the complexity related to publishing easily exploited DKIM signatures as if malefactors won't exploit such quick fixes published on mailing-lists. In the meantime, I'll soon post another alternative for dealing with DMARC. Regards, Douglas Otis From nobody Tue Apr 14 12:06:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1001ACEAD for ; Tue, 14 Apr 2015 12:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZIdeMvSgsPVQ for ; Tue, 14 Apr 2015 12:06:14 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FBE1ACE4D for ; Tue, 14 Apr 2015 12:03:37 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.136.3; Tue, 14 Apr 2015 19:03:35 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 19:03:35 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Publishing and Registration Concerns Thread-Index: AQHQdtR4gmTZLiYUhE6z++40+HrMyJ1MvWsQgAARPgCAAAygMA== Date: Tue, 14 Apr 2015 19:03:35 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> In-Reply-To: <552D57DE.6070200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.147.69] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(2900100001)(92566002)(68736005)(102836002)(86362001)(97736003)(450100001)(77156002)(33656002)(93886004)(4001540100001)(81156007)(46102003)(110136001)(62966003)(2501003)(107886001)(2351001)(2656002)(105586002)(66066001)(2950100001)(106356001)(101416001)(54356999)(76176999)(50986999)(87936001)(106116001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 054642504A received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 19:03:35.1662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:06:22 -0000 Hi, Doug, > TPA-Label operates within its own sub-domain. This > sub-domain can be delegated or use DNAME. =20 > How is the scaling issue really worse than the changes > currently required for SPF? In fact, SPF often entails more > DNS transactions per use When I talk about scale [1], it's not just a matter of doing DNS lookups. T= hat's important, but it's not what I worry about because we can solve it by= adding more hardware [2]. Instead, by "scale" I mean "management", that is= , having humans manage the process, or needing humans to do something. Getting someone to add anything to DNS doesn't work well [3] unless it is a= utomated because the majority of people that I work with in the customer sp= ace don't feel comfortable managing DNS; it is rare that I encounter someon= e who does and these are people who are in charge of email infrastructure. = This is the exact opposite of most people on this discussion list, many of = which manage their own zones. For many large organizations, there is a slow= change-review process. For medium and small businesses, they just want it = to work and therefore don't change much in their DNS unless they are expert= s, of which there aren't that many in real life. So to say "Oh, just set up a new DNS record and it will all work" is a majo= r obstacle to overcome and is close to a non-starter. I like the idea of th= e DKIM/FS from John Levine because at least that can be done at the MTA lev= el without any help from domain owners because it's the job of the MTA impl= ementer to figure it out; it's a much smaller set of people who need to und= erstand and can it make it work without domain owner awareness. -- Terry [1] I can't speak for everyone within Microsoft, or anyone within Google or= Yahoo but I would imagine they have the same issues because they're both l= arge companies. [2] That's my solution for everything. It's a simplified explanation, but a= good technical design and adding adequate hardware solves most of those pr= oblems... usually. [3] By "work well" I mean have the majority of people doing it, not that it= works technically. From nobody Tue Apr 14 12:16:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538BF1ACE4A for ; Tue, 14 Apr 2015 12:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 9rQvFFQfqKLc for ; Tue, 14 Apr 2015 12:16:26 -0700 (PDT) Received: from ntbbs.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 734021ACE35 for ; Tue, 14 Apr 2015 12:13:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1650; t=1429038818; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zhSM7KxJklCO8vARubE+k1vdRyY=; b=EADo0C1pvt0H6PutZ/v7 dq7aMUpesTZhXo5zTqaU60DEyHhKswrb01LJLP5bbcG2KvaMsN7tKuQ17nZbt3dI CMCw4hcshlJCN8LjFj2xYIkSjdSI91c7m+wm5B3f57F1DiOkx73WnFde6KOa8CTw TrwdHSetVAomI5Pypx7Jsfs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 15:13:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2748832942.7719.3400; Tue, 14 Apr 2015 15:13:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1650; t=1429038585; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9ojbJP+ HAFBm4DSpFiP/iTCtjNRQXB7V61c9dsKcIgg=; b=3U26Ievn+zqk7MPxnt+wmF+ U1mPBFGr+7Wg8R9ISEDktdonrP05AkK3Qge1YHNSnMCqHpSpqhHro37E27B5tED9 TALpRDa7soZaJpqeF3D5f490Bccks9hcSynSpkfnlns4Ashk/fgwyo2Gaz5rAht3 FLTRxeaRYkyace/wA09c= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 15:09:45 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1341121441.9.8976; Tue, 14 Apr 2015 15:09:45 -0400 Message-ID: <552D66E0.40300@isdg.net> Date: Tue, 14 Apr 2015 15:13:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> In-Reply-To: <552D57DE.6070200@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:16:28 -0000 On 4/14/2015 2:09 PM, Douglas Otis wrote: > On 4/14/15 10:12 AM, Terry Zink wrote: >> That's what we mean when we say it doesn't scale. > > Dear Terry, > > TPA-Label operates within its own sub-domain. This > sub-domain can be delegated or use DNAME. This means this > information can be handled by an organization dedicated to > detecting and preventing third-party abuse. In essence, a > role likely to entail sending notices to domains and > ensuring problems are corrected or having their third-party > provisions retracted. A function that Yahoo and AOL dumped > on everyone else by (ab)using DMARC. > > How is the scaling issue really worse than the changes > currently required for SPF? In fact, SPF often entails more > DNS transactions per use. It sure does have a much higher overhead. Just take a look at hotmail.com: "v=spf1 1 include:spf-a.outlook.com 2 include:spf-b.outlook.com ip4:157.55.9.128/25 3 include:spf.protection.outlook.com 4 include:spf-a.hotmail.com 5 include:_spf-ssg-b.microsoft.com 6 include:_spf-ssg-c.microsoft.com ~all" Six DNS calls at the top level and its final result is a relaxed ~all result. That is a super high scale/volume waste of processing. But here again is a large company not getting its list of senders completed. Doesn't stop SPF. And with DMARC, hotmail.com has no record, so all receivers will be doing high volume wasting calls. We should not expect anything different for a domain finding its network of signers. If it doesn't know its list of signers, then it just registered what it can and create a relaxed DMARC policy. -- HLS From nobody Tue Apr 14 12:18:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5871ACEC7 for ; Tue, 14 Apr 2015 12:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SpGmumoVczYd for ; Tue, 14 Apr 2015 12:17:57 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 0806A1ACED3 for ; Tue, 14 Apr 2015 12:15:18 -0700 (PDT) Received: by widdi4 with SMTP id di4so34062161wid.0 for ; Tue, 14 Apr 2015 12:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WSEi16D7NtA530iQcsjUQxxm4iAYCHsVlkcXzkG+GB4=; b=o+yPug0HA24Pt/5XfcZ3HIb2sZAZ+pkOZICIeKI/NjMimhOJ9zKgJRIfBefrJOWTbB SmU3rz8kTm6BBb8a+KY9kSKeU8CLHZAT9416byrBXr+lqHGCyyFPCkbKKzDiaSeoF6l8 vrBRhPLbz7+cnv6QTLJmMC9nqoksrl4Fm4oJF5KOuQ88B1gjvjF+zcMMmoQXV1DqDnDG jD+QkNIbvQiZRBOjy0Lbvq/e8X0SBJ20siK7qREqZF5bsiA/XsGm0cJsAwsCfQ9N6xYd arJs5pS137MS0pYf5UooUMUI2+qXSRwEcN4WAn9RV+hkb6U+6AcBR+J8ZfJItLWL4aTv O+ew== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr41763796wjc.4.1429038916840; Tue, 14 Apr 2015 12:15:16 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 12:15:16 -0700 (PDT) In-Reply-To: <3164216.CDnEBjYtuG@kitterma-e6430> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> <3164216.CDnEBjYtuG@kitterma-e6430> Date: Tue, 14 Apr 2015 12:15:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e01419d1c0236160513b40dc6 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:18:00 -0000 --089e01419d1c0236160513b40dc6 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman wrote: > I haven't reviewed his in detail, so I've no opinion. I was talking about > this proposal. Not getting fancy with MIME parts would be nice, so if this > one can work, I already like it better than Murray's, but if we have to > pile > this onto the stack of nice ideas, then that's probably what I'll look at > next. > The elegance of John's idea is that it's content-agnostic, and is apparently backward compatible because v=1 verifiers will not consider the weak signature to be valid (unless they're already quite broken). There's no need to learn to parse MIME structure in order to produce a signature. I think the concerning part is deciding when to add the weak signature. The simplest thing is to always add it along with an "@fs=" signature, but then you're basically allowing the forwarding domain to sign any content it wants and you'll be approving it too, implicitly. If you want to be selective about when you add it, you have to apply some kind of heuristic to make that decision. We obviously can't specify that, but it becomes a burden to signers. It's also prone to replays. It might be enough to use a short expiration time, but that relies on everyone processing "x=" properly (or at all), and you need to make a good guess as to what expiration time to use. Of all the proposals before us, this would be the easiest for me to adopt and try, followed by dkim-delegate. dkim-list-canon and dkim-transform would be the hardest, not only because they will require more code, but I'm nervous about how sensitive they are to misinterpretations or abuses of MIME. For example, I've no idea what would happen to messages with MIME preambles. Still, there's something attractive about being able to tell what the original message was and what the added/modified content was, and determining who was responsible for what. Depends on who needs to change to mitigate things. If (as an example only) > we > decide that From rewriting is the best (least bad) solution, then that's a > mediator change. We don't need Yahoo and AOL except to the extent they > operate as mediators also, but AFAIK, that's different groups at Yahoo and > AOL. > I don't think we need to be worried about their participation. Unless they plan to embarrass me later for saying so, they are indeed paying attention, and will participate in trying something that seems viable. -MSK --089e01419d1c0236160513b40dc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
I haven't reviewed = his in detail, so I've no opinion.=C2=A0 I was talking about
this proposal.=C2=A0 Not getting fancy with MIME parts would be nice, so if= this
one can work, I already like it better than Murray's, but if we have to= pile
this onto the stack of nice ideas, then that's probably what I'll l= ook at
next.

The elegance of John's idea i= s that it's content-agnostic, and is apparently backward compatible bec= ause v=3D1 verifiers will not consider the weak signature to be valid (unle= ss they're already quite broken).=C2=A0 There's no need to learn to= parse MIME structure in order to produce a signature.

I = think the concerning part is deciding when to add the weak signature.=C2=A0= The simplest thing is to always add it along with an "@fs=3D" si= gnature, but then you're basically allowing the forwarding domain to si= gn any content it wants and you'll be approving it too, implicitly.=C2= =A0 If you want to be selective about when you add it, you have to apply so= me kind of heuristic to make that decision.=C2=A0 We obviously can't sp= ecify that, but it becomes a burden to signers.=C2=A0 It's also prone t= o replays.=C2=A0 It might be enough to use a short expiration time, but tha= t relies on everyone processing "x=3D" properly (or at all), and = you need to make a good guess as to what expiration time to use.
=C2=A0<= br>
Of all the proposals before us, this would be the easiest for= me to adopt and try, followed by dkim-delegate.=C2=A0 dkim-list-canon and = dkim-transform would be the hardest, not only because they will require mor= e code, but I'm nervous about how sensitive they are to misinterpretati= ons or abuses of MIME.=C2=A0 For example, I've no idea what would happe= n to messages with MIME preambles.=C2=A0 Still, there's something attra= ctive about being able to tell what the original message was and what the a= dded/modified content was, and determining who was responsible for what.
Depends on who needs to change to mitigate things.= =C2=A0 If (as an example only) we
decide that From rewriting is the best (least bad) solution, then that'= s a
mediator change.=C2=A0 We don't need Yahoo and AOL except to the extent= they
operate as mediators also, but AFAIK, that's different groups at Yahoo = and AOL.

I don't think we need to b= e worried about their participation.=C2=A0 Unless they plan to embarrass me= later for saying so, they are indeed paying attention, and will participat= e in trying something that seems viable.

-MSK
<= /div>
--089e01419d1c0236160513b40dc6-- From nobody Tue Apr 14 12:24:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B211B29F8 for ; Tue, 14 Apr 2015 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 cK3eAa851Ggt for ; Tue, 14 Apr 2015 12:24:42 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 69A2D1B2EB8 for ; Tue, 14 Apr 2015 12:23:24 -0700 (PDT) Received: by wgso17 with SMTP id o17so23336216wgs.1 for ; Tue, 14 Apr 2015 12:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JDGQmqnXALrSeHFoJcbnrOdaKXngPmWIhLHfXeofQiw=; b=qYS0fvb7Ffr0NbHlZo8ewSFfqdHPDsSSaPmehEvIm2s94NYf14CHsdioITRvkz9K30 uq+KU6XT0edJzxL+hBIiDEVtjNdZ8C0U7Via4y0BMWUxmF0B2dKzEyJl2q9ZAex82WQE EypMXtaFo47JzKnwC3ENFCf1zyBUeAHlWIR3Tt2jLtFBz6w6TT8HBKTKy2Gi3UXJqY4F SS0qEXbDlCBLg7Hr+bxubl5jzqMMla2kJ+6n1cQrUVsNxWw/Z2lF3JgssW7k9sOQOI79 3e/jFZwdiL1JPk//NRHZCeiHjLk2VbgIc2vF2dEH+tpvMCMYtpL2d2gOfYM+mRRWGSBC XFMw== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr36127551wix.52.1429039403140; Tue, 14 Apr 2015 12:23:23 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 12:23:23 -0700 (PDT) In-Reply-To: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> Date: Tue, 14 Apr 2015 12:23:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=f46d044289e8fe8a340513b42949 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 19:24:43 -0000 --f46d044289e8fe8a340513b42949 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 14, 2015 at 12:03 PM, Terry Zink wrote: > Getting someone to add anything to DNS doesn't work well [3] unless it is > automated because the majority of people that I work with in the customer > space don't feel comfortable managing DNS; it is rare that I encounter > someone who does and these are people who are in charge of email > infrastructure. This is the exact opposite of most people on this > discussion list, many of which manage their own zones. For many large > organizations, there is a slow change-review process. For medium and small > businesses, they just want it to work and therefore don't change much in > their DNS unless they are experts, of which there aren't that many in real > life. > Just to pile on: There are probably security people many large organizations who would be unthrilled with the notion of automating an authorization process, which is really what this is. It might feel to them a lot like an injection attack, and I would argue they're correct. -MSK --f46d044289e8fe8a340513b42949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2015 at 12:03 PM, Terry Zink <= tzink@exchange.microsoft.com> wrote:
Getting som= eone to add anything to DNS doesn't work well [3] unless it is automate= d because the majority of people that I work with in the customer space don= 't feel comfortable managing DNS; it is rare that I encounter someone w= ho does and these are people who are in charge of email infrastructure. Thi= s is the exact opposite of most people on this discussion list, many of whi= ch manage their own zones. For many large organizations, there is a slow ch= ange-review process. For medium and small businesses, they just want it to = work and therefore don't change much in their DNS unless they are exper= ts, of which there aren't that many in real life.
=
Just to pile on: There are probably security people many lar= ge organizations who would be unthrilled with the notion of automating an a= uthorization process, which is really what this is.=C2=A0 It might feel to = them a lot like an injection attack, and I would argue they're correct.=

-MSK
--f46d044289e8fe8a340513b42949-- From nobody Tue Apr 14 13:24:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C841B29C8 for ; Tue, 14 Apr 2015 13:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WPU642rKuMFH for ; Tue, 14 Apr 2015 13:24:22 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id B25901B29AD for ; Tue, 14 Apr 2015 13:24:21 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3lRJFH3HPGz5Mgfl; Tue, 14 Apr 2015 22:24:19 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lRJFH2056z5Mgff; Tue, 14 Apr 2015 22:24:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id EBCAB123506; Tue, 14 Apr 2015 22:24:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5yPUJ_ZEmtXI; Tue, 14 Apr 2015 22:24:16 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 464F11234C8; Tue, 14 Apr 2015 22:24:16 +0200 (CEST) Message-ID: <552D776F.7080101@sonnection.nl> Date: Tue, 14 Apr 2015 22:24:15 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Scott Kitterman References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> <3164216.CDnEBjYtuG@kitterma-e6430> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040400050105070506010208" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1429043059; bh=wTkJHAaW5iIZ/A541bqyUpOa21mAjxJTYFlhabjO8cU=; h=Message-ID:Date:From:To:Subject:From; b=SkxKOPQoT5x2vOnVMo+2YKS8rMM3/mCEafzqUQRhpHncFRdEDBlDLt4Oz2I/Cp+pB rT66eJNNVPvPMPNhpoNcsKOCCb595xS2zJvwxjc45JMei2d87JvfFiSruzrxBaNhmy j3w1C9b6Ys4GP/Ko/au8y3TZ+7nntLIecDV9bA4U= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3lRJFH3HPGz5Mgfl Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 20:24:24 -0000 This is a multi-part message in MIME format. --------------040400050105070506010208 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/14/2015 09:15 PM, Murray S. Kucherawy wrote: > On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman > wrote: > > I haven't reviewed his in detail, so I've no opinion. I was > talking about > this proposal. Not getting fancy with MIME parts would be nice, > so if this > one can work, I already like it better than Murray's, but if we > have to pile > this onto the stack of nice ideas, then that's probably what I'll > look at > next. > > > The elegance of John's idea is that it's content-agnostic, and is > apparently backward compatible because v=1 verifiers will not consider > the weak signature to be valid (unless they're already quite broken). > There's no need to learn to parse MIME structure in order to produce a > signature. > > I think the concerning part is deciding when to add the weak > signature. The simplest thing is to always add it along with an > "@fs=" signature, but then you're basically allowing the forwarding > domain to sign any content it wants and you'll be approving it too, > implicitly. Remembering to what great lengths the ietf-dkim group went to make sure that every bit of a message was covered by the signature (and with the l= discussions in mind) I would really be surprised if adding the @fs= for all outbound mail would be an acceptable solution for the problem. /rolf --------------040400050105070506010208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 04/14/2015 09:15 PM, Murray S. Kucherawy wrote:
On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman <= span dir=3D"ltr"><sklist= @kitterman.com> wrote:
I haven't reviewed his in detail, so I've no opinion.=A0 I wa= s talking about
this proposal.=A0 Not getting fancy with MIME parts would b= e nice, so if this
one can work, I already like it better than Murray's, but if we have to pile
this onto the stack of nice ideas, then that's probably what I'll look at
next.

The elegance of John's idea is that it's content-agnostic, and is apparently backward compatible because v=3D1 verifiers will not consider the weak signatur= e to be valid (unless they're already quite broken).=A0 There's no need to learn to parse MIME structure in order to produce a signature.

I think the concerning part is deciding when to add the weak signature.=A0 The simplest thing is to always add it along with an "@fs=3D" signature, but then you're basically allowing the forwarding domain to sign any content it wants and you'll be approving it too, implicitly.


Remembering to what great lengths the ietf-dkim group went to make sure that every bit of a message was covered by the signature (and with the l=3D discussions in mind) I would really be surprised if adding the @fs=3D for all outbound mail would be an acceptable solution for the problem.

/rolf
--------------040400050105070506010208-- From nobody Tue Apr 14 13:55:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A191B2FB4 for ; Tue, 14 Apr 2015 13:55:18 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1QI1Zt-A3wYc for ; Tue, 14 Apr 2015 13:55:10 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9FC1B2FAC for ; Tue, 14 Apr 2015 13:55:10 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Tue, 14 Apr 2015 16:55:09 -0400 From: "MH Michael Hammer (5304)" To: "R.E.Sonneveld@sonnection.nl" , "Murray S. Kucherawy" , Scott Kitterman Thread-Topic: [dmarc-ietf] Updated mandatory tag/conditional signature draft Thread-Index: AQHQdsMvRnkGKSOI2k6i1eUP5PK2aJ1M4/GAgABARACAABNGgP//w3Bg Date: Tue, 14 Apr 2015 20:55:08 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> <3164216.CDnEBjYtuG@kitterma-e6430> <552D776F.7080101@sonnection.nl> In-Reply-To: <552D776F.7080101@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.221] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B0525FFA65CUSCLES544agnaam_" MIME-Version: 1.0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 20:55:18 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B0525FFA65CUSCLES544agnaam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been following the thread(s) regarding how to enable 3rd parties where= a formal relationship doesn't exist and this reinforces my thought that it= is ultimately easier systemically (even allowing for the arguments that it= is unfair) for intermediaries to take ownership of messages they (intentio= nally) modify and sign d=3D as first party signers. I understand that there is a one-time cost (my own organization incurred th= is cost in changing how we handle mail for our website domains) to changing= and I understand the reasons expressed by some for not wanting to make suc= h changes based on principle, etc. I understand the argument that some are = externalizing their costs. Mike From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Rolf E. Sonneveld Sent: Tuesday, April 14, 2015 4:24 PM To: Murray S. Kucherawy; Scott Kitterman Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft On 04/14/2015 09:15 PM, Murray S. Kucherawy wrote: On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman > wrote: I haven't reviewed his in detail, so I've no opinion. I was talking about this proposal. Not getting fancy with MIME parts would be nice, so if this one can work, I already like it better than Murray's, but if we have to pil= e this onto the stack of nice ideas, then that's probably what I'll look at next. The elegance of John's idea is that it's content-agnostic, and is apparentl= y backward compatible because v=3D1 verifiers will not consider the weak si= gnature to be valid (unless they're already quite broken). There's no need= to learn to parse MIME structure in order to produce a signature. I think the concerning part is deciding when to add the weak signature. Th= e simplest thing is to always add it along with an "@fs=3D" signature, but = then you're basically allowing the forwarding domain to sign any content it= wants and you'll be approving it too, implicitly. Remembering to what great lengths the ietf-dkim group went to make sure tha= t every bit of a message was covered by the signature (and with the l=3D di= scussions in mind) I would really be surprised if adding the @fs=3D for all= outbound mail would be an acceptable solution for the problem. /rolf --_000_CE39F90A45FF0C49A1EA229FC9899B0525FFA65CUSCLES544agnaam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been following= the thread(s) regarding how to enable 3rd parties where a forma= l relationship doesn’t exist and this reinforces my thought that it is ultimately easier systemically (even allowing for the arguments that= it is unfair) for intermediaries to take ownership of messages they (inten= tionally) modify and sign d=3D as first party signers.

 <= /p>

I understand that there i= s a one-time cost (my own organization incurred this cost in changing how w= e handle mail for our website domains) to changing and I understand the reasons expressed by some for not wanting to make such chan= ges based on principle, etc. I understand the argument that some are extern= alizing their costs.

 <= /p>

Mike

 <= /p>

From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Rolf E. Sonneveld
Sent: Tuesday, April 14, 2015 4:24 PM
To: Murray S. Kucherawy; Scott Kitterman
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signatur= e draft

 

On 04/14/2015 09:15 PM, Murray S. Kucherawy wrote:

On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman <= ;sklist@kitterman= .com> wrote:

I haven't reviewed his in detail, so I've no opinion= .  I was talking about
this proposal.  Not getting fancy with MIME parts would be nice, so if= this
one can work, I already like it better than Murray's, but if we have to pil= e
this onto the stack of nice ideas, then that's probably what I'll look at next.

 

The elegance of John'= s idea is that it's content-agnostic, and is apparently backward compatible= because v=3D1 verifiers will not consider the weak signature to be valid (= unless they're already quite broken).  There's no need to learn to parse MIME structure in order to produce a sig= nature.

I think the concerning part is deciding when to add = the weak signature.  The simplest thing is to always add it along with= an "@fs=3D" signature, but then you're basically allowing the fo= rwarding domain to sign any content it wants and you'll be approving it too, implicitly.



Remembering to what great lengths the ietf-dkim group went to make sure tha= t every bit of a message was covered by the signature (and with the l=3D di= scussions in mind) I would really be surprised if adding the @fs=3D for all= outbound mail would be an acceptable solution for the problem.

/rolf

--_000_CE39F90A45FF0C49A1EA229FC9899B0525FFA65CUSCLES544agnaam_-- From nobody Tue Apr 14 14:31:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C9D1A1A66 for ; Tue, 14 Apr 2015 14:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1cO60-EHzxTB for ; Tue, 14 Apr 2015 14:31:28 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 6758A1A1A1B for ; Tue, 14 Apr 2015 14:31:13 -0700 (PDT) Received: by widdi4 with SMTP id di4so38065153wid.0 for ; Tue, 14 Apr 2015 14:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zPYY08aSSvDqsqgLKWoCklPMZvvW0JJSFA9pdFEqB7A=; b=MznPuwxm82EMPr131DZ5J78lcTbOGjlj4MikQhT50v/F41oK9tzmENHpWSl6Vs4AN/ oTg5cTMpOo2rwDCzEzfonbtuU/Z1BnJe7AH4xKfGpcLT9d3GTs2MHuwNQ83XIgdQnmMM t0T6qLw6HOpeWvcXhKo1bIdbnLhtWeoWAN4gtUcyMrbqEy4KdaJx9M7e5q9M81b1gi1s ntwKwZuaEEmrwnhAAbahPnK2+II93qX+xEz/toHQm9WZp4DLtF0EG7zoLVExjPAWImCX FmI5faT3nlIa/WBNjnnpOU58/f854jMKHx2VttF7p669W8gceIi5cNrRXy6kSdUVPInN gOTA== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr42656353wjc.4.1429047072241; Tue, 14 Apr 2015 14:31:12 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 14 Apr 2015 14:31:11 -0700 (PDT) In-Reply-To: <552D776F.7080101@sonnection.nl> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> <3164216.CDnEBjYtuG@kitterma-e6430> <552D776F.7080101@sonnection.nl> Date: Tue, 14 Apr 2015 14:31:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=089e01419d1c1bbddb0513b5f338 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:31:29 -0000 --089e01419d1c1bbddb0513b5f338 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > Remembering to what great lengths the ietf-dkim group went to make sure > that every bit of a message was covered by the signature (and with the l= > discussions in mind) I would really be surprised if adding the @fs= for all > outbound mail would be an acceptable solution for the problem. > I agree in general, but I'm not sure that's a valid comparison. A bare "l=0" is a lot less restricted than one that also includes "@fs=" and, perhaps, something like a short expiration. It could well be that's a tolerable risk when compared with the cost of doing nothing here. -MSK --089e01419d1c1bbddb0513b5f338 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
Remembering to what great lengths the ietf-dkim group went to make sure that every bit of a message was covered by the signature (and with the l=3D discussions in mind) I would really be surprised if adding the @fs=3D for all outbound mail would be an acceptable solution for the problem.

I agree in general, b= ut I'm not sure that's a valid comparison.=C2=A0 A bare "l=3D0= " is a lot less restricted than one that also includes "@fs=3D&qu= ot; and, perhaps, something like a short expiration.=C2=A0 It could well be= that's a tolerable risk when compared with the cost of doing nothing h= ere.

-MSK
--089e01419d1c1bbddb0513b5f338-- From nobody Tue Apr 14 14:43:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD71A1B57 for ; Tue, 14 Apr 2015 14:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PEj6epN4HAuv for ; Tue, 14 Apr 2015 14:43:20 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525401A1AFB for ; Tue, 14 Apr 2015 14:43:20 -0700 (PDT) Received: from [IPv6:2600:1003:b11e:8d16:8cf0:4278:88db:1a63] (unknown [IPv6:2600:1003:b11e:8d16:8cf0:4278:88db:1a63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1A5F2C403D5; Tue, 14 Apr 2015 16:43:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429047799; bh=m5FykUGWXJCNj/Co1nHdmMb0W+WGz0BPcUO67pe1A+c=; h=In-Reply-To:References:Subject:From:Date:To:From; b=LCl9r/ApAlJZf8RKiccC1QWufNqhW3VdV9V4/Klomlglchsq13PshJuY+NUrkdPwF Oq6g1jEO2R0RzGUhUKyjSPGFLNlSxDHeXTbfTWXEOgJHQ59D18EvnWvsSXjL9y44Yy TNZgBoUGSseZKSnBDBNYSfwpV3R+Hx8O1x/sLXds= User-Agent: K-9 Mail for Android In-Reply-To: <552D66E0.40300@isdg.net> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D66E0.40300@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 14 Apr 2015 17:43:15 -0400 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:43:22 -0000 On April 14, 2015 3:13:36 PM EDT, Hector Santos wrote: >On 4/14/2015 2:09 PM, Douglas Otis wrote: > >> On 4/14/15 10:12 AM, Terry Zink wrote: >>> That's what we mean when we say it doesn't scale. >> >> Dear Terry, >> >> TPA-Label operates within its own sub-domain. This >> sub-domain can be delegated or use DNAME. This means this >> information can be handled by an organization dedicated to >> detecting and preventing third-party abuse. In essence, a >> role likely to entail sending notices to domains and >> ensuring problems are corrected or having their third-party >> provisions retracted. A function that Yahoo and AOL dumped >> on everyone else by (ab)using DMARC. >> >> How is the scaling issue really worse than the changes >> currently required for SPF? In fact, SPF often entails more >> DNS transactions per use. > >It sure does have a much higher overhead. Just take a look at >hotmail.com: > > "v=spf1 > 1 include:spf-a.outlook.com > 2 include:spf-b.outlook.com > ip4:157.55.9.128/25 > 3 include:spf.protection.outlook.com > 4 include:spf-a.hotmail.com > 5 include:_spf-ssg-b.microsoft.com > 6 include:_spf-ssg-c.microsoft.com > ~all" > >Six DNS calls at the top level and its final result is a relaxed ~all >result. That is a super high scale/volume waste of processing. But >here again is a large company not getting its list of senders >completed. Doesn't stop SPF. > >And with DMARC, hotmail.com has no record, so all receivers will be >doing high volume wasting calls. > >We should not expect anything different for a domain finding its >network of signers. If it doesn't know its list of signers, then it >just registered what it can and create a relaxed DMARC policy. Which is completely orthogonal to the question. Scale for this is about scaling the data collection and DNS record publishing. My essentially one person domain would have a more complex forwarder/mailing list list than the SPF records of even the largest providers. Scott K From nobody Tue Apr 14 14:47:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCBF1A1BF6 for ; Tue, 14 Apr 2015 14:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 WakuOPHfaAJw for ; Tue, 14 Apr 2015 14:47:49 -0700 (PDT) Received: from pop3.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B98DE1A1BB9 for ; Tue, 14 Apr 2015 14:47:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2104; t=1429048058; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VZhmd0RwmaxjFGL7CDwkHf1Nl1U=; b=K++CUmZh+30t8olg7lct aCScaoOvJNqxywMIyscH0FmCbKwG8Rucp5Rz8baevNk6TxYbX/9/P+ImG+Y7Gfpf WkSbweI6n3Vv0WzMp/js7XFxxBDvbRY9g19VntjPMq7v1zi0maT8QU4V2R93vXZo 6Kw3+5/KmN9ll9itIF4iSgg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 17:47:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2758073069.7719.2340; Tue, 14 Apr 2015 17:47:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2104; t=1429047825; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EjpIwP0 2y6SN1EGfpUBzGyEWj6Ms0qY5I3EiamFJEsg=; b=J/GNarnET7IJOMqDUZZwwKu Irdt5/pcnPLDslYuSVB3X2e8nFbrZwkjv4maHGMFVR9fdziWwC5+9wHSAkpbG37C H+FsnenKzwOjzs1qqhFap+PDv8p7dCii+BX0Pclt8A7cH8xG3FVjVoVbNttvTjS5 JkKKGAVfsGzeYRxtIJuw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 17:43:45 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1350360988.9.10360; Tue, 14 Apr 2015 17:43:44 -0400 Message-ID: <552D8AF8.6060101@isdg.net> Date: Tue, 14 Apr 2015 17:47:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:47:51 -0000 On 4/14/2015 3:03 PM, Terry Zink wrote: > Hi, Doug, > >> TPA-Label operates within its own sub-domain. This >> sub-domain can be delegated or use DNAME. >> How is the scaling issue really worse than the changes >> currently required for SPF? In fact, SPF often entails more >> DNS transactions per use > > When I talk about scale [1], it's not just a matter of doing DNS lookups. That's important, but it's not what I worry about because we can solve it by adding more hardware [2]. Instead, by "scale" I mean "management", that is, having humans manage the process, or needing humans to do something. But thats the same problem for everything. How will MS work it out for your hotmail.com SPF operations? For SPF, hotmail.com has a relaxed SPF policy with a long list of DNS lookups. Lots of processing waste here. For DMARC, thousands, perhaps millions, high volume of mail are getting NXDOMAIN on the expectation there is a DMARC record. Are we at a point where all DNS TXT-based solutions will need to be converted to in-band mail only solutions and we eliminate DNS from the picture? if ADID == SDID DO DNS_DMARC else DNS PROBLEM TOO HARD. Is that what we going to tell the DNS folks on last call? The better solution was punted because interfacing with DNS people is a tough problem. That is what is astonishing me the most here. Billion dollar corporations saying this problem is too hard for them to address. Wow. I'm sorry, but it seems odd that we were going for a far more complex workaround that has security holes just because the we can't get the DNS folks involved as part of the solution package when DNS is required in the first place. This all seems very strange to me to read this. I don't mind an In-band solution as an OPTIONAL alternative to the more optimized, more secured, more technically feasible, time tested simple DNS lookup solution. The IETF, this WG, the chairs owes it to the interested industry participants to offer and provide a solid solution, even if it involves getting DNS administration involved. -- HLS From nobody Tue Apr 14 14:59:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4D1A6FEA for ; Tue, 14 Apr 2015 14:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 oNtodFpRztle for ; Tue, 14 Apr 2015 14:59:11 -0700 (PDT) Received: from pop3.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 563851A7005 for ; Tue, 14 Apr 2015 14:58:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1408; t=1429048723; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=DAcYEimrOuucsnmESdLmJIYOcko=; b=fNMmBbO43Uo+riDBT18M taTFB0/JnRzMmOW7sBxfiojkj6VGOu8M6DjM/itjpK6x8ein/5BK69WpBMBWAFGK tZZGKwWJe2+RCxmzgj2dmfNDRFaqmw7whKthVA8l3MH4LvZnZoOgutX6gv3mbWQD JWLTh/nqq6m/BMyoR9QHvGw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 17:58:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2758738335.7719.3424; Tue, 14 Apr 2015 17:58:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1408; t=1429048491; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vbQtI4Q 4StseygMqkFZ4szUA335+uDUKaW6VWLq9dJk=; b=11MG9CzM4DEbFZUhfTX7Jo+ /CIRfI5xx+xW613qCEGHlPYoEB5D7Xtys6YZoLeQnIob0O7Wo0KS6a74/TOby22S 0oJhSAMrjyXwfdbHiohr0fRfA0e49HiZ3Cw7YabOytRZCjhHcANhXqWEIC1Uha8S /5Ad/F8elfJQ/Hq7JBJ4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 17:54:51 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1351027176.9.8592; Tue, 14 Apr 2015 17:54:50 -0400 Message-ID: <552D8D92.2020701@isdg.net> Date: Tue, 14 Apr 2015 17:58:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <87zj6akbcb.fsf@uwakimon.sk.tsukuba.ac.jp> <3164216.CDnEBjYtuG@kitterma-e6430> <552D776F.7080101@sonnection.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:59:13 -0000 On 4/14/2015 5:31 PM, Murray S. Kucherawy wrote: > On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld < > R.E.Sonneveld@sonnection.nl> wrote: > >> Remembering to what great lengths the ietf-dkim group went to make sure >> that every bit of a message was covered by the signature (and with the l= >> discussions in mind) I would really be surprised if adding the @fs= for all >> outbound mail would be an acceptable solution for the problem. >> > > I agree in general, but I'm not sure that's a valid comparison. A bare > "l=0" is a lot less restricted than one that also includes "@fs=" and, > perhaps, something like a short expiration. It could well be that's a > tolerable risk when compared with the cost of doing nothing here. That "cost" has already been long established. The simple DNS Lookup is cheaper to implement and more secured than the in-band alternative. All we are learning from this thread is that getting DNS involved is a tough problem. We already knew that for years, since day one of all these DNS TXT-based solutions. But how are you going to explain that the best and simplest solution for DMARC, the simple ADID/SDID, is being blocked because it is presumed that implementators will not be able to work with their DNS peers? Why can't both solutions be done? The optimized ADID/SDID DNS check and the fallback to a @fs=SDID signature check? -- HLS From nobody Tue Apr 14 15:41:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299C11B3021 for ; Tue, 14 Apr 2015 15:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 NI17pDvuZ_dH for ; Tue, 14 Apr 2015 15:41:32 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DBE1B3020 for ; Tue, 14 Apr 2015 15:41:32 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.136.3; Tue, 14 Apr 2015 22:41:29 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 22:41:29 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Publishing and Registration Concerns Thread-Index: AQHQdtR4gmTZLiYUhE6z++40+HrMyJ1MvWsQgAARPgCAAAygMIAAMEsAgAAMw9A= Date: Tue, 14 Apr 2015 22:41:29 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D8AF8.6060101@isdg.net> In-Reply-To: <552D8AF8.6060101@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.147.69] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(13464003)(479174004)(24454002)(377454003)(92566002)(77156002)(62966003)(87936001)(86362001)(15975445007)(68736005)(102836002)(33656002)(97736003)(81156007)(107886001)(4001540100001)(19580395003)(93886004)(19580405001)(46102003)(4001410100001)(2501003)(2656002)(105586002)(2950100001)(76176999)(106116001)(54356999)(50986999)(64706001)(101416001)(106356001)(2900100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 054642504A received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 22:41:29.5129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 22:41:35 -0000 >> When I talk about scale [1], it's not just a matter of doing DNS lookups= .=20 >> That's important, but it's not what I worry about because we can solve=20 >> it by adding more hardware [2]. Instead, by "scale" I mean "management", >> that is, having humans manage the process, or needing humans to do somet= hing. > But thats the same problem for everything. How will MS work it out=20 > for your hotmail.com SPF operations? For SPF, hotmail.com has a=20 > relaxed SPF policy with a long list of DNS lookups. Lots of=20 > processing waste here. For DMARC, thousands, perhaps millions, high=20 > volume of mail are getting NXDOMAIN on the expectation there is a=20 > DMARC record. Hi, Hector, sorry to derail your point, but I don't understand your point a= s it relates to what I was saying. At Microsoft, there's a dedicated team (= handful of people) who manage the SPF record and there's a change review pr= ocess, and expertise moves out of the team gradually. Still, there are peop= le that are assigned to it. In addition, Hotmail.com fits into the 10 DNS l= ookup limit as required by the RFC. My point was that Hotmail can inventory what all of its IPs are, and update= s its DNS records manually. But plenty of others don't know what their IPs = are; furthermore, Office 365 does email hosting for small, medium, and larg= e businesses. The part that doesn't scale is the following: 1. For Hotmail, every mailing list that our users are signed up for would r= esult in a new DNS entry. How do we manage the lifecycle around that? Shoul= d we automate its addition? Should we automate its removal? Do we delay ema= il before the DNS entries are published? Should we thereby bypass the chang= e review process? If so, how do we audit what's going in and what's coming = out of the Hotmail zone? 2. For Office 365, we can't publish DNS entries for most of our customers. = We could tell them what to publish but I guarantee you almost none of them = would for every single mail list their users signed up for, if they had to = do it every day. Most of them probably wouldn't even do it once. That's the part that doesn't scale. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Tuesday, April 14, 2015 2:48 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Publishing and Registration Concerns On 4/14/2015 3:03 PM, Terry Zink wrote: > Hi, Doug, > >> TPA-Label operates within its own sub-domain. This >> sub-domain can be delegated or use DNAME. >> How is the scaling issue really worse than the changes >> currently required for SPF? In fact, SPF often entails more >> DNS transactions per use > > When I talk about scale [1], it's not just a matter of doing DNS lookups.= That's important, but it's not what I worry about because we can solve it = by adding more hardware [2]. Instead, by "scale" I mean "management", that = is, having humans manage the process, or needing humans to do something. But thats the same problem for everything. How will MS work it out=20 for your hotmail.com SPF operations? For SPF, hotmail.com has a=20 relaxed SPF policy with a long list of DNS lookups. Lots of=20 processing waste here. For DMARC, thousands, perhaps millions, high=20 volume of mail are getting NXDOMAIN on the expectation there is a=20 DMARC record. Are we at a point where all DNS TXT-based solutions will need to be=20 converted to in-band mail only solutions and we eliminate DNS from the=20 picture? if ADID =3D=3D SDID DO DNS_DMARC else DNS PROBLEM TOO HARD. Is that what we going to tell the DNS folks on last call? The better=20 solution was punted because interfacing with DNS people is a tough=20 problem. That is what is astonishing me the most here. Billion dollar=20 corporations saying this problem is too hard for them to address.=20 Wow. I'm sorry, but it seems odd that we were going for a far more=20 complex workaround that has security holes just because the we can't=20 get the DNS folks involved as part of the solution package when DNS is=20 required in the first place. This all seems very strange to me to=20 read this. I don't mind an In-band solution as an OPTIONAL alternative to the=20 more optimized, more secured, more technically feasible, time tested=20 simple DNS lookup solution. The IETF, this WG, the chairs owes it to=20 the interested industry participants to offer and provide a solid=20 solution, even if it involves getting DNS administration involved. --=20 HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Apr 14 15:44:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26051B302F for ; Tue, 14 Apr 2015 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 a---_jQL7xph for ; Tue, 14 Apr 2015 15:44:39 -0700 (PDT) Received: from pop3.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E2C791B302D for ; Tue, 14 Apr 2015 15:44:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1849; t=1429051473; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=p0E8i3YS6EEcaS3EfAsnePbz3W8=; b=X0eikt5DLkDX0FtsrdSN ZgVOldNkO0UuM8NpZaHbLvgoxbJRvRRMIHupbE8fISzLQqNZVg6YJn3wFRxgfkSu M4juFCjPQWIe3rRtZdid4PXq0pgldY4XFhfEawyVPv2TGVRPDuQ5iACeBpAC3ZyP +dxPERSLPPVaz/tfCf/Xm1w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 18:44:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2761488383.7719.3896; Tue, 14 Apr 2015 18:44:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1849; t=1429051241; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jUUfw+9 2IfPyBVKv4uEMTV35+W0xkqH1ukHArbdpSFU=; b=3KaxFPrTKnyqmeZUuKNl4CF rH9KuOTc7sjC6dMGvf9A1Arr+W/OWLeextxrgL1r+ESiTM4Jz7pCIEm2H2kmkbl1 CWVo9E5fR6ixIHvCl8noW4Y7tykuzv36iposWvy6C4TmtX1omaDDgO7A7tDekKv+ QOi9x19qe+uyFp5NT7V0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 14 Apr 2015 18:40:41 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1353776785.9.11872; Tue, 14 Apr 2015 18:40:40 -0400 Message-ID: <552D9850.8030401@isdg.net> Date: Tue, 14 Apr 2015 18:44:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D66E0.40300@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 22:44:40 -0000 On 4/14/2015 5:43 PM, Scott Kitterman wrote: >> We should not expect anything different for a domain finding its >> network of signers. If it doesn't know its list of signers, then it >> just registered what it can and create a relaxed DMARC policy. > > Which is completely orthogonal to the question. Scale for this is about scaling the data collection and DNS record publishing. > Ok, so what else is different for any DNS based application? It is far more simpler to DMARC+TPA/ATPS method: 1a) Publish your ADID+SDID zone record, 1b) Have Receivers do a ADID+SDID lookup for existence. A positive result provides the SDID authorization as a signer. then use a dual signature @FS=SDID method: 2a) Change signer code to add a secondary signature, lets assume the simpler do it for all, the global vs selective dual signing. 2b) Change the receiver to look for @fs=SDID logic and use this explicit signature as an implicit indication that ADID authorizes the SDID. In both cases, you got an extra DNS check. i don't think you will have everyone doing 2a as a global outbound dual signer, but lets say thats done by most, now you have the incentive for the bad guys to create fake facsimiles of replayed mail. You don't have this under #1. > My essentially one person domain would have a more complex forwarder/mailing list list than the SPF records of even the largest providers. Ok. I have a feeling you would be fine, :) nonetheless. If exposure with @FS=SDID is ok, and looking directly for the SDID under the ADID zone is functionally the same, then why should companies who are perfectly capable of scaling and managing the ADID/SDID zone be limited to a more weaker more costly code changing solution? Why is there a presumption that this "scale" problem is universal? -- HLS From nobody Tue Apr 14 16:02:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2231B3041 for ; Tue, 14 Apr 2015 16:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 HsRY37M5Jo0H for ; Tue, 14 Apr 2015 16:02:12 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 CF5831B303D for ; Tue, 14 Apr 2015 16:02:11 -0700 (PDT) Received: by qkca135 with SMTP id a135so5110587qkc.1 for ; Tue, 14 Apr 2015 16:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xrkwDRfpZuxJ2HLdnpnW6JtLUA3x18ONo6FfP4ewiWQ=; b=kIracZc+sCXPbEXAi/djvzfIff0qz5S59jFG30D7d2HuTHpKYdLQAEVoNPxPTqNG3Y kygxTS34vDH0jEyozf1X8MiLBWjTsYFaWFNulz+5nK6EDW6RqUEtvsDGwJTyS6sCpGK9 eSc/jmFcTB/kIOxuWju6d5KjDO3V4lZin0jvhc3QmA20ttwUfAhaMHmBF1q9kRUqr9ZW b8vXJCmLGe99lNJoV9W+eCM0ukP0uOO8nr4bCKfFJQIguQPtRTV84Qmr5cJnFrWpOXa6 wWMi8aTQ7TP2nnNZLzxKn85d0/qJ8PcMAEFMiewLvbRcTHFXL0KwiwxoExCACYadbuhW V7dw== X-Received: by 10.55.22.65 with SMTP id g62mr34235307qkh.72.1429052531137; Tue, 14 Apr 2015 16:02:11 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 10sm1805605qha.38.2015.04.14.16.02.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 16:02:09 -0700 (PDT) Message-ID: <552D9C6F.8030101@gmail.com> Date: Tue, 14 Apr 2015 16:02:07 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D66E0.40300@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 23:02:13 -0000 On 4/14/15 2:43 PM, Scott Kitterman wrote: > On April 14, 2015 3:13:36 PM EDT, Hector Santos wrote: >> On 4/14/2015 2:09 PM, Douglas Otis wrote: >> >>> On 4/14/15 10:12 AM, Terry Zink wrote: >>>> That's what we mean when we say it doesn't scale. >>> Dear Terry, >>> >>> TPA-Label operates within its own sub-domain. This >>> sub-domain can be delegated or use DNAME. This means this >>> information can be handled by an organization dedicated to >>> detecting and preventing third-party abuse. In essence, a >>> role likely to entail sending notices to domains and >>> ensuring problems are corrected or having their third-party >>> provisions retracted. A function that Yahoo and AOL dumped >>> on everyone else by (ab)using DMARC. >>> >>> How is the scaling issue really worse than the changes >>> currently required for SPF? In fact, SPF often entails more >>> DNS transactions per use. >> It sure does have a much higher overhead. Just take a look at >> hotmail.com: >> >> "v=spf1 >> 1 include:spf-a.outlook.com >> 2 include:spf-b.outlook.com >> ip4:157.55.9.128/25 >> 3 include:spf.protection.outlook.com >> 4 include:spf-a.hotmail.com >> 5 include:_spf-ssg-b.microsoft.com >> 6 include:_spf-ssg-c.microsoft.com >> ~all" >> >> Six DNS calls at the top level and its final result is a relaxed ~all >> result. That is a super high scale/volume waste of processing. But >> here again is a large company not getting its list of senders >> completed. Doesn't stop SPF. >> >> And with DMARC, hotmail.com has no record, so all receivers will be >> doing high volume wasting calls. >> >> We should not expect anything different for a domain finding its >> network of signers. If it doesn't know its list of signers, then it >> just registered what it can and create a relaxed DMARC policy. > Which is completely orthogonal to the question. Scale for this is about scaling the data collection and DNS record publishing. > > My essentially one person domain would have a more complex forwarder/mailing list list than the SPF records of even the largest providers. Dear Scott and Terry, We had a similar effort focused on world wide abuse that had more than 100 collection points. Processing was automatic and would generate needed zone files in a sequence repeating every 15 minutes administrated by two people. DMARC can be setup to offer similar inputs which need to be compared against a collection of outbound logs. By avoiding the use of SQL, the process should complete with plenty of time to spare using a typical server. Spam traps in addition to DMARC feedback would detect abuse. No guesswork should be involved when done right. There was a larger staff handling logged communications aimed at abuse mitigation. A thankless job that must be done. I was shocked to hear a bulk sender at a recent conference say no one reads their abuse@ mail. I don't recall the provider. There are a few ways to reduce the complexity for each entity performing this process. Domains sharing a similar relationship to your domain could-- a) copy a list of mediators requiring DMARC exceptions. b) find a provider that maintains a _tpa list and delegate your _smtp._tpa. zone. c) find a provider that maintains a _tpa list and then synthesize CNAME responses. See RFC2672. d) find a provider that both maintains a _tpa list and that supports Non-Terminal DNS Name Redirection (DNAME). Even use of draft-levine-dkim-conditional will require a similar list be created to reduce both risk and overhead. Publishing this list in DNS ensures it can safely be distributed and handle the needs of SMTP. SQL methods may not be sufficient. When things go wrong because DKIM-Conditional becomes exploited, you could save the show by having a _tpa zone as a fall back. Murphy's Law, "Whatever can happen will happen." Regards, Douglas Otis From nobody Tue Apr 14 17:03:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35191A8BB6 for ; Tue, 14 Apr 2015 17:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 6qRKf_Q_jpwU for ; Tue, 14 Apr 2015 17:03:28 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6541A8BB2 for ; Tue, 14 Apr 2015 17:03:28 -0700 (PDT) Received: from [IPv6:2600:1003:b11e:8d16:8cf0:4278:88db:1a63] (unknown [IPv6:2600:1003:b11e:8d16:8cf0:4278:88db:1a63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2CD0CC403D5; Tue, 14 Apr 2015 19:03:27 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429056207; bh=5KrlPn38ciDcvUtAnXj4FNMoVwFTVgnO7zZSox1WAv0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=gp+EPgwkJfFJh70KpdEou+Mcop8qLtoGdnhZAtuJrcioc7Dn5BwN2HVatjaf1jEHR BOLwX58EEDUlqL25BdIguAXJoAh0pvyi/fpv6pDGkjDCHviHIuKtUoEWoFnOTyj0v2 UuE0OHf/4H9lgU48Mesic2VKqR6zQo0O173rBrfg= User-Agent: K-9 Mail for Android In-Reply-To: <552D9850.8030401@isdg.net> References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D66E0.40300@isdg.net> <552D9850.8030401@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 14 Apr 2015 20:03:23 -0400 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 00:03:30 -0000 On April 14, 2015 6:44:32 PM EDT, Hector Santos wrote: >On 4/14/2015 5:43 PM, Scott Kitterman wrote: > >>> We should not expect anything different for a domain finding its >>> network of signers. If it doesn't know its list of signers, then >it >>> just registered what it can and create a relaxed DMARC policy. >> >> Which is completely orthogonal to the question. Scale for this is >about scaling the data collection and DNS record publishing. >> > >Ok, so what else is different for any DNS based application? It is >far more simpler to > >DMARC+TPA/ATPS method: > > 1a) Publish your ADID+SDID zone record, > > 1b) Have Receivers do a ADID+SDID lookup for existence. A positive >result > provides the SDID authorization as a signer. > >then use a dual signature @FS=SDID method: > > 2a) Change signer code to add a secondary signature, lets assume >the simpler > do it for all, the global vs selective dual signing. > > 2b) Change the receiver to look for @fs=SDID logic and use this >explicit > signature as an implicit indication that ADID authorizes the SDID. > >In both cases, you got an extra DNS check. i don't think you will have >everyone doing 2a as a global outbound dual signer, but lets say thats >done by most, now you have the incentive for the bad guys to create >fake facsimiles of replayed mail. You don't have this under #1. The difference is that in the second one the originator isn't required to have a comprehensive list of mediators in advance. I agree describing such a list in DNS wouldn't be that hard. The problem is creating and maintaining such a list for domains with non-trivial numbers of users. That includes the complexity of explaining to most of these users what a mailing list is. >> My essentially one person domain would have a more complex >forwarder/mailing list list than the SPF records of even the largest >providers. > >Ok. I have a feeling you would be fine, :) nonetheless. If exposure >with @FS=SDID is ok, and looking directly for the SDID under the ADID >zone is functionally the same, then why should companies who are >perfectly capable of scaling and managing the ADID/SDID zone be >limited to a more weaker more costly code changing solution? > >Why is there a presumption that this "scale" problem is universal? I could do it, but I'm pretty sure I'd categorize it as more trouble than it's worth. How many different schemes do you think receivers will deploy? I think we get at most one solution that requires changes at the sender and receiver. Whatever it is needs to work as broadly as possible. Even if your approach would work for small domains, I think it needs to work for large providers too to be worth pursuing. Scott K From nobody Wed Apr 15 10:59:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8051B368A for ; Wed, 15 Apr 2015 10:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.78 X-Spam-Level: X-Spam-Status: No, score=-97.78 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 E02OqQtImUpE for ; Wed, 15 Apr 2015 10:58:56 -0700 (PDT) Received: from catinthebox.net (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B2D911B3688 for ; Wed, 15 Apr 2015 10:58:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7365; t=1429120725; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9OxXLlLN8bax0kjA9fRatoFAICA=; b=NzP7RLUrX4/tMH4ri9vN SX6//ZQsjMLGwRoPYjO9XzIRyc6d0ZvVK/AG+85Ee7VKlRzezOZ2w8qUJ5Co25/D nZqJUGcYdDRgDtTYUjfW61rGNpPG3a6v6YrEfXGKFDcSpwllkVCLzf0RN10XmzNo IQ8Dl1EF1foOUmB0MTibYhg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 13:58:45 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2830739707.10833.4440; Wed, 15 Apr 2015 13:58:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7365; t=1429120420; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JHPgNDN RKSbEy/HVQF9blEWV2p89+f7uJf8X+ufw2gQ=; b=LfYmhojOQz8u311L0RdCeyp d1egiSOT8gzOPWBlSq6Kw9Wux+ddR9Ji4rGD9G5Iwp8LB+/0mRjeOReWSHQZlosC AF0y7De9cq/90pck4dWIAH5tmKuiCgdnk5StFGupaCxMFJZopoNSRyZ1GztHmY2v c/Pjg0TiMvoyXEtLDpLs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 13:53:40 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1422956301.9.3728; Wed, 15 Apr 2015 13:53:39 -0400 Message-ID: <552EA68E.4020905@isdg.net> Date: Wed, 15 Apr 2015 13:57:34 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org, Terry Zink References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D8AF8.6060101@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 17:58:59 -0000 Hi Terry, I understand your point. Just consider, Microsoft still has its DNS TXT record for its original Caller ID for Email Protocol (CEP), the original clone of SPF that eventually became Sender-ID: D:\Users\Administrator>lmap _ep.hotmail.com Server: ns.santronics.com Address: 208.247.131.210 Non-authoritative answer: _ep.hotmail.com text = " list1._ep.hotmail.com list2._ep.hotmail.com list3._ep.hotmail.com " Early on, MS application developers were high on using XML, it was being explored for both program and data. Thats just to show you of the DNS changing mindset for accepting the additional overhead and increasing usage for app developers. The fact it hasn't been removed (and please don't yet, I like keeping it for prosperity), shows there is still some corporate/DNS controls. I do know that hotmail.com was acquired so that might still mean something people/team wise. Overall, I believe you are missing the software tools to manage this. Like most DNS applications like this, it still required the tools. However, my point, other than believing MS has the resources and power to do this, when it comes to the protocol itself, it should not, and it is generally isn't, a reason for excluding such a natural protocol idea like this even as a protocol option. Its a natural fit to detect 1st vs 3rd party and make authorization decisions. Finally, consider that its not always applicable across all email applications, especially for the larger public service area as you pointed out. But it still applies for many of the other mail hosting systems including other Microsoft email applications. For example, the MS Security Bulletins it has message ADID and SDID values such as: DKIM-Signature: d=email.microsoftemail.com From: e-mail.microsoft.com That is a third party. All you need to do is add a ATPS DNS TXT record: base64(sha1("email.microsoftemail.com")._atps.e-mail.microsoft.com and manage it of course. No code change is necessary on your end as a publisher and signer. The change is for DMARC receivers to add a extension to the lookup logic. Based on RFC4686 (Security threats Analysis) and RFC5016 (Requirements), the consensus which was also reflected by the APIs written, it used a ADID != SDID condition to do a POLICY lookup. So you can apply this. Harder for Hotmail.com, well understood, but not for microsoft.com which has a strong policy with known senders. Your SPF policy reflect this. For signers, well, you need 3rd party logic before e-mail.Microsoft.com flips the DMARC p=reject switch. -- HLS On 4/14/2015 6:41 PM, Terry Zink wrote: >>> When I talk about scale [1], it's not just a matter of doing DNS lookups. >>> That's important, but it's not what I worry about because we can solve >>> it by adding more hardware [2]. Instead, by "scale" I mean "management", >>> that is, having humans manage the process, or needing humans to do something. > >> But thats the same problem for everything. How will MS work it out >> for your hotmail.com SPF operations? For SPF, hotmail.com has a >> relaxed SPF policy with a long list of DNS lookups. Lots of >> processing waste here. For DMARC, thousands, perhaps millions, high >> volume of mail are getting NXDOMAIN on the expectation there is a >> DMARC record. > > Hi, Hector, sorry to derail your point, but I don't understand your point as it relates to what I was saying. At Microsoft, there's a dedicated team (handful of people) who manage the SPF record and there's a change review process, and expertise moves out of the team gradually. Still, there are people that are assigned to it. In addition, Hotmail.com fits into the 10 DNS lookup limit as required by the RFC. > > My point was that Hotmail can inventory what all of its IPs are, and updates its DNS records manually. But plenty of others don't know what their IPs are; furthermore, Office 365 does email hosting for small, medium, and large businesses. The part that doesn't scale is the following: > > 1. For Hotmail, every mailing list that our users are signed up for would result in a new DNS entry. How do we manage the lifecycle around that? Should we automate its addition? Should we automate its removal? Do we delay email before the DNS entries are published? Should we thereby bypass the change review process? If so, how do we audit what's going in and what's coming out of the Hotmail zone? > > 2. For Office 365, we can't publish DNS entries for most of our customers. We could tell them what to publish but I guarantee you almost none of them would for every single mail list their users signed up for, if they had to do it every day. Most of them probably wouldn't even do it once. > > That's the part that doesn't scale. > > -- Terry > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos > Sent: Tuesday, April 14, 2015 2:48 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Publishing and Registration Concerns > > On 4/14/2015 3:03 PM, Terry Zink wrote: >> Hi, Doug, >> >>> TPA-Label operates within its own sub-domain. This >>> sub-domain can be delegated or use DNAME. >>> How is the scaling issue really worse than the changes >>> currently required for SPF? In fact, SPF often entails more >>> DNS transactions per use >> >> When I talk about scale [1], it's not just a matter of doing DNS lookups. That's important, but it's not what I worry about because we can solve it by adding more hardware [2]. Instead, by "scale" I mean "management", that is, having humans manage the process, or needing humans to do something. > > But thats the same problem for everything. How will MS work it out > for your hotmail.com SPF operations? For SPF, hotmail.com has a > relaxed SPF policy with a long list of DNS lookups. Lots of > processing waste here. For DMARC, thousands, perhaps millions, high > volume of mail are getting NXDOMAIN on the expectation there is a > DMARC record. > > Are we at a point where all DNS TXT-based solutions will need to be > converted to in-band mail only solutions and we eliminate DNS from the > picture? > > if ADID == SDID > DO DNS_DMARC > else > DNS PROBLEM TOO HARD. > > Is that what we going to tell the DNS folks on last call? The better > solution was punted because interfacing with DNS people is a tough > problem. > > That is what is astonishing me the most here. Billion dollar > corporations saying this problem is too hard for them to address. > Wow. I'm sorry, but it seems odd that we were going for a far more > complex workaround that has security holes just because the we can't > get the DNS folks involved as part of the solution package when DNS is > required in the first place. This all seems very strange to me to > read this. > > I don't mind an In-band solution as an OPTIONAL alternative to the > more optimized, more secured, more technically feasible, time tested > simple DNS lookup solution. The IETF, this WG, the chairs owes it to > the interested industry participants to offer and provide a solid > solution, even if it involves getting DNS administration involved. > From nobody Wed Apr 15 11:08:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23B1A009B for ; Wed, 15 Apr 2015 11:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SV2a5wDR7RqR for ; Wed, 15 Apr 2015 11:08:48 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 73A821A008B for ; Wed, 15 Apr 2015 11:08:48 -0700 (PDT) Received: by widdi4 with SMTP id di4so70001564wid.0 for ; Wed, 15 Apr 2015 11:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eeEwm3wjD8z1JwDzUi7YZyw2Eq/kZioet/NGbAWBFcA=; b=IkyFxDNEcYPcOgfYaUWume6VUVly+vuw5rEcY87O1yfbK8gngXCuk5W9jRaCKnfzuD anE7WDhEUu2zZKtvcwVIsXwPfu7Xkvxnzo+xq8Jyo+De4HOJNakoeM68pjx4FZZh0Qi2 eamzHN5hlvIBDUaWENpNhSmsAYWadgqUR5OxTWu5MMhDBK+mVOQEegZQ4pzz1zhm9A21 SCTCB8vG+eD571aAV14SABFz4vnfxlv08nlvN3kLilYrdoy3fJv9fBorIzjF7VG3Wi/o cA9HgtD5vKBUt80mhbwIdwjG8bD1lGOqxBY/SITy5w+k2wFsqA+cDLkDHf5dFEAZ0NyN o12A== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr227540wix.52.1429121327240; Wed, 15 Apr 2015 11:08:47 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 15 Apr 2015 11:08:47 -0700 (PDT) In-Reply-To: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D8AF8.6060101@isdg.net> Date: Wed, 15 Apr 2015 11:08:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=f46d044289e80d1c080513c73daf Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 18:08:53 -0000 --f46d044289e80d1c080513c73daf Content-Type: text/plain; charset=UTF-8 On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink wrote: > 1. For Hotmail, every mailing list that our users are signed up for would > result in a new DNS entry. How do we manage the lifecycle around that? > Should we automate its addition? Should we automate its removal? Do we > delay email before the DNS entries are published? Should we thereby bypass > the change review process? If so, how do we audit what's going in and > what's coming out of the Hotmail zone? > > 2. For Office 365, we can't publish DNS entries for most of our customers. > We could tell them what to publish but I guarantee you almost none of them > would for every single mail list their users signed up for, if they had to > do it every day. Most of them probably wouldn't even do it once. > > That's the part that doesn't scale. +1. The mechanism of generating DNS records is not the issue; we even have an RFC that shows how that could be done in theory. It's the processes themselves that simply won't scale or would fail to thrive. -MSK --f46d044289e80d1c080513c73daf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink <t= zink@exchange.microsoft.com> wrote:
1. For Hotma= il, every mailing list that our users are signed up for would result in a n= ew DNS entry. How do we manage the lifecycle around that? Should we automat= e its addition? Should we automate its removal? Do we delay email before th= e DNS entries are published? Should we thereby bypass the change review pro= cess? If so, how do we audit what's going in and what's coming out = of the Hotmail zone?

2. For Office 365, we can't publish DNS entries for most of our custome= rs. We could tell them what to publish but I guarantee you almost none of t= hem would for every single mail list their users signed up for, if they had= to do it every day. Most of them probably wouldn't even do it once.
That's the part that doesn't scale.

+1.=C2=A0 The mechanism of generating DNS records is not the issue; we eve= n have an RFC that shows how that could be done in theory.=C2=A0 It's t= he processes themselves that simply won't scale or would fail to thrive= .

-MSK
--f46d044289e80d1c080513c73daf-- From nobody Wed Apr 15 11:41:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADB11A1A0B for ; Wed, 15 Apr 2015 11:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 4-lTKxuKQyLb for ; Wed, 15 Apr 2015 11:41:45 -0700 (PDT) Received: from catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E3A841A19F4 for ; Wed, 15 Apr 2015 11:41:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2752; t=1429123296; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=RfOz7nnmKaVCJRcUe5IJ80/fMXU=; b=gqfsusHAJVjE0AQmQ3H5 sQ3adMyEeEpGxUuFP3tvmHihxIkbE6KSbtzh1853F2kfmdt8GslpQSD3MUs+VKpj sTjZ8u828OlouIZhjwxbsTeowN8TDjQPNBqLU/F3x/aZjnf6Sxsa+R1NzyrNctd7 aBgSl53LtZTEw3FjaUiwCMM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 14:41:36 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2833309995.10833.1404; Wed, 15 Apr 2015 14:41:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2752; t=1429123063; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=9VVCME7 Onb4j75zB6pR44QvyZFPT8EuJpWvI4iPD/0k=; b=2xHFxwJb1vDznR8BzUHgO5+ Roa9SHYHZrh+6h8YOTfRwtu3iyx+RYQi6kk4jkq2zOzRT8CM1jKyO+GRXjzRvUme y9MIfGmJBfY6yAHUsSlRyJHKUtgqmxBtjfG4WP1Rez9xPJ4BlYDLGfrhG9BzMHep rkGpu1pR/IyfRnH6daG0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 14:37:43 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1425598785.9.11448; Wed, 15 Apr 2015 14:37:42 -0400 Message-ID: <552EB0E0.1080603@isdg.net> Date: Wed, 15 Apr 2015 14:41:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D8AF8.6060101@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 18:41:46 -0000 On 4/15/2015 2:08 PM, Murray S. Kucherawy wrote: > On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink > wrote: > >> 1. For Hotmail, every mailing list that our users are signed up for would >> result in a new DNS entry. How do we manage the lifecycle around that? >> Should we automate its addition? Should we automate its removal? Do we >> delay email before the DNS entries are published? Should we thereby bypass >> the change review process? If so, how do we audit what's going in and >> what's coming out of the Hotmail zone? >> >> 2. For Office 365, we can't publish DNS entries for most of our customers. >> We could tell them what to publish but I guarantee you almost none of them >> would for every single mail list their users signed up for, if they had to >> do it every day. Most of them probably wouldn't even do it once. >> >> That's the part that doesn't scale. > > > +1. The mechanism of generating DNS records is not the issue; we even have > an RFC that shows how that could be done in theory. It's the processes > themselves that simply won't scale or would fail to thrive. -1. There is no proof of this other than it hasn't been tried at large scale. Nonetheless, software guys can produce the tools for anyone to do this, today, successfully. Once again, by far, and I hope you agree, most domains will not need the level of scale that would begin to make it too complex to manage. Not everyone has the "complex processes" which I believe has been overblown and used as a flat out reason for excluding the most feasible idea we have. From a pure protocol standpoint, it is a natural fit. We are talking about satisfying the ADID != SDID condition lacking in DMARC which can be a protocol option: DMARC Receivers MAY use DSAP mechanisms for ADID != SDID conditions. which can translate into product configuration options. [X] Support DMARC [X] Support ATPS Extension [X] Support @FS= (o) Global (sign all) (_) Selective (Disabled, Future) It is unreasonable to impose more complex changes to both signers and receivers, all of them, with no option to do a simple lookup which is all that is required. I am open to having both a direct and inband methods with direct being the most efficient and least costly. You can not impose costly changes on all when it is clearly not necessary. IMV, the IETF should not be in a put into position where it is creating situations for Mail and DNS folks to battle over the highly subjective belief that it is just too hard to manage DNS records, thus lets make the mail less DKIM secured and more DKIM complex with more in-band (RFC5322) information. It isn't going to fly too well. -- HLS From nobody Wed Apr 15 12:26:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0621A88EB for ; Wed, 15 Apr 2015 12:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lqL9RUNZ_r3e for ; Wed, 15 Apr 2015 12:26:19 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5280D1A88E4 for ; Wed, 15 Apr 2015 12:26:19 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.136.3; Wed, 15 Apr 2015 19:26:17 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.014; Wed, 15 Apr 2015 19:26:17 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Publishing and Registration Concerns Thread-Index: AQHQdtR4gmTZLiYUhE6z++40+HrMyJ1MvWsQgAARPgCAAAygMIAAMEsAgAAMw9CAAUVNAIAAFkNA Date: Wed, 15 Apr 2015 19:26:16 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <2843651.yGUcCboVsT@kitterma-e6430> <552D2E04.8030101@isdg.net> <3116002.DAz6U52Rgm@kitterma-e6430> <552D4787.9080704@isdg.net> <552D57DE.6070200@gmail.com> <552D8AF8.6060101@isdg.net> <552EA68E.4020905@isdg.net> In-Reply-To: <552EA68E.4020905@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.28] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(3905003)(51704005)(199003)(13464003)(189002)(377454003)(479174004)(2656002)(101416001)(107886001)(66066001)(64706001)(15395725005)(87936001)(33656002)(97736003)(86362001)(68736005)(102836002)(15975445007)(2900100001)(2950100001)(46102003)(4001540100001)(81156007)(4001410100001)(2501003)(92566002)(77156002)(62966003)(105586002)(54356999)(50986999)(76176999)(93886004)(106116001)(106356001)(19580405001)(19580395003)(16193025007); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0547116B72 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 19:26:16.1763 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:26:22 -0000 PiBGb3IgZXhhbXBsZSwgDQo+IHRoZSBNUyBTZWN1cml0eSBCdWxsZXRpbnMgaXQgaGFzIG1lc3Nh Z2UgQURJRCBhbmQgU0RJRCB2YWx1ZXMgc3VjaCBhczoNCj4gICAgICBES0lNLVNpZ25hdHVyZTog ZD1lbWFpbC5taWNyb3NvZnRlbWFpbC5jb20NCj4gICAgICBGcm9tOiBlLW1haWwubWljcm9zb2Z0 LmNvbQ0KPiBUaGF0IGlzIGEgdGhpcmQgcGFydHkuICBBbGwgeW91IG5lZWQgdG8gZG8gaXMgYWRk IGEgQVRQUyBETlMgVFhUIHJlY29yZDoNCj4gICAgIGJhc2U2NChzaGExKCJlbWFpbC5taWNyb3Nv ZnRlbWFpbC5jb20iKS5fYXRwcy5lLW1haWwubWljcm9zb2Z0LmNvbQ0KDQpUaGlzIGlzIHNvbWV0 aGluZyB3ZSd2ZSBkb25lIG1hbnkgdGltZXMsIGV4Y2VwdCB0aGF0IHJhdGhlciB0aGFuIGNyZWF0 aW5nIGFuIEFUUFMgcmVjb3JkLCB3ZSBqdXN0IGFkZCB0aGUgM3JkIHBhcnR5J3MgSVBzIHRvIGEg c3ViZG9tYWluJ3MgU1BGIHJlY29yZCAoZS5nLiwgZW1haWwubWljcm9zb2Z0LmNvbSBvciBlLW1h aWwubWljcm9zb2Z0LmNvbSkgYW5kIHNldCB1cCBES0lNIGtleXMgZm9yIGl0LCBhbmQgdGhlbiB0 ZWxsIHRoZSAzcmQgcGFydHkgdG8gc2VuZCBlbWFpbCB0aGF0IHdheS4gVGhlIGV4YW1wbGUgeW91 IGhhdmUgaXMgbm90IGFsaWduZWQgYmVjYXVzZSBJIGhhdmVuJ3QgZG9uZSBldmVyeSBkb21haW4g d2l0aGluIE1pY3Jvc29mdCwgYnV0IGlmIEkgZXZlciBnZXQgdG8gdGhpcyBvbmUsIHRoYXQncyBo b3cgSSdsbCBkbyBpdC4NCg0KPiBhbmQgbWFuYWdlIGl0IG9mIGNvdXJzZS4NCg0KQW5kIGhlcmVp biBsaWVzIHRoZSB0cm91YmxlLiAiTWFuYWdlIGl0IG9mIGNvdXJzZSIgaXMgbW9yZSB0aGFuIGEg c2ltcGxlIGxpbmUgb2YgdGV4dC4gSWYgSSB3YW50IHRvIGFkZCBhIDNyZCBwYXJ0eSB0byBNaWNy b3NvZnQncyB6b25lOg0KDQoxLiBJIG5lZWQgZ2V0IHNpZ24gb2ZmIGZyb20gbmVjZXNzYXJ5IHBh cnRpZXMNCjIuIEkgY3JlYXRlIGEgRE5TIGNoYW5nZSByZXF1ZXN0DQozLiBJdCBnb2VzIHRocm91 Z2ggYSByZXZpZXcgcHJvY2Vzcw0KNC4gSSBoYXZlIHRvIHJldmlldyB0aGUgem9uZSB1cGRhdGVz IHNpbmNlIEkgY3JlYXRlZCB0aGUgdGlja2V0cw0KNS4gVGhleSB1c3VhbGx5IGFzayBtZSB0byB2 YWxpZGF0ZSBpdCBtYW51YWxseSB3aGVuIHRoZSBPcHMgdGVhbSBkb2VzIHRoZSBjaGFuZ2UuDQoN Ck5vbmUgb2YgdGhpcyBwcm9jZXNzIGlzIGF1dG9tYXRlZCwgYW5kIHRoYXQncyBpbnRlbnRpb25h bC4gSW5zdGVhZCwgd2UgbWFrZSBkZWxpYmVyYXRlIGNoYW5nZXMgdG8gdGhlIE1pY3Jvc29mdCB6 b25lIHNvIHdlIGtub3cgd2hhdCdzIGdvaW5nIGluLg0KDQpCeSBjb250cmFzdCwgdGhlIEFUUFMg Zm9yIDNyZCBwYXJ0aWVzIC0gbWFpbGluZyBsaXN0cyAtIGlzIG5vdCBzb21ldGhpbmcgd2Ugd291 bGQgYXV0b21hdGUuIEkga25vdyBvZiBhIGZldyBtYWlsIHNlcnZlcnMgdGhhdCBvdGhlciBlbXBs b3llZXMgdXNlIHRoYXQgcmVsYXlzIGVtYWlsIGFzIEBtaWNyb3NvZnQuY29tIGluIHRoZSBGcm9t OiBhZGRyZXNzIHRoYXQgd2lsbCBmYWlsIERNQVJDLiBCdXQgaWYgd2UgaGFkIHRvIGFkZCBldmVy eSAzcmQgcGFydHkgbWFpbGluZyBsaXN0IHRoYXQgZW1wbG95ZWVzIHVzZWQsIHdlJ2QgaGF2ZSB0 byBnbyB0aHJvdWdoIHRoaXMgY2hhbmdlIHJldmlldyBwcm9jZXNzIGVhY2ggdGltZS4gQnV0IGJl Y2F1c2UgZW1wbG95ZWVzIHNpZ25pbmcgdXAgZm9yIGEgbWFpbGluZyBsaXN0IGlzIG5vdCBvZmZp Y2lhbCBjb21wYW55IGJ1c2luZXNzLCB3ZSAqd291bGRuJ3QqIHVwZGF0ZSBvdXIgem9uZSBqdXN0 IGZvciB0aGF0IHdpdGhvdXQgYSBnb29kIHJlYXNvbi4NCg0KU2ltaWxhcmx5LCBmb3IgSG90bWFp bCwgd291bGQgd2UgcmVhbGx5IHdhbnQgdG8gdXBkYXRlIG91ciB6b25lcyBhdXRvbWF0aWNhbGx5 IGZvciBldmVyeSBtYWlsaW5nIGxpc3QgYSBzdWJzY3JpYmVyIHNpZ25zIHVwIGZvcj8gV2l0aG91 dCBhbnkgY2hhbmdlIGNvbnRyb2w/IEknbSBpbmNsaW5lZCB0byBzYXkgbm8uDQoNCi0tIFRlcnJ5 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIZWN0b3IgU2FudG9zIFttYWls dG86aHNhbnRvc0Bpc2RnLm5ldF0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE1LCAyMDE1IDEw OjU4IEFNDQpUbzogZG1hcmNAaWV0Zi5vcmc7IFRlcnJ5IFppbmsNClN1YmplY3Q6IFJlOiBbZG1h cmMtaWV0Zl0gUHVibGlzaGluZyBhbmQgUmVnaXN0cmF0aW9uIENvbmNlcm5zDQoNCkhpIFRlcnJ5 LA0KDQpJIHVuZGVyc3RhbmQgeW91ciBwb2ludC4gIEp1c3QgY29uc2lkZXIsIE1pY3Jvc29mdCBz dGlsbCBoYXMgaXRzIEROUyANClRYVCByZWNvcmQgZm9yIGl0cyBvcmlnaW5hbCBDYWxsZXIgSUQg Zm9yIEVtYWlsIFByb3RvY29sIChDRVApLCB0aGUgDQpvcmlnaW5hbCBjbG9uZSBvZiBTUEYgdGhh dCBldmVudHVhbGx5IGJlY2FtZSBTZW5kZXItSUQ6DQoNCiAgIEQ6XFVzZXJzXEFkbWluaXN0cmF0 b3I+bG1hcCBfZXAuaG90bWFpbC5jb20NCiAgIFNlcnZlcjogIG5zLnNhbnRyb25pY3MuY29tDQog ICBBZGRyZXNzOiAgMjA4LjI0Ny4xMzEuMjEwDQoNCiAgIE5vbi1hdXRob3JpdGF0aXZlIGFuc3dl cjoNCiAgIF9lcC5ob3RtYWlsLmNvbSB0ZXh0ID0NCg0KICAgICAgIjxlcCB4bWxucz0naHR0cDov L21zLm5ldC8xJyB0ZXN0aW5nPSd0cnVlJz4NCiAgICAgICAgPG91dD4NCiAgICAgICAgPG0+DQog ICAgICAgIDxpbmRpcmVjdD5saXN0MS5fZXAuaG90bWFpbC5jb208L2luZGlyZWN0Pg0KICAgICAg ICA8aW5kaXJlY3Q+bGlzdDIuX2VwLmhvdG1haWwuY29tPC9pbmRpcmVjdD4NCiAgICAgICAgPGlu ZGlyZWN0Pmxpc3QzLl9lcC5ob3RtYWlsLmNvbTwvaW5kaXJlY3Q+DQogICAgICAgIDwvbT4NCiAg ICAgICAgPC9vdXQ+DQogICAgICA8L2VwPiINCg0KRWFybHkgb24sIE1TIGFwcGxpY2F0aW9uIGRl dmVsb3BlcnMgd2VyZSBoaWdoIG9uIHVzaW5nIFhNTCwgaXQgd2FzIA0KYmVpbmcgZXhwbG9yZWQg Zm9yIGJvdGggcHJvZ3JhbSBhbmQgZGF0YS4gIFRoYXRzIGp1c3QgdG8gc2hvdyB5b3Ugb2YgDQp0 aGUgRE5TIGNoYW5naW5nIG1pbmRzZXQgZm9yIGFjY2VwdGluZyB0aGUgYWRkaXRpb25hbCBvdmVy aGVhZCBhbmQgDQppbmNyZWFzaW5nIHVzYWdlIGZvciBhcHAgZGV2ZWxvcGVycy4gIFRoZSBmYWN0 IGl0IGhhc24ndCBiZWVuIHJlbW92ZWQgDQooYW5kIHBsZWFzZSBkb24ndCB5ZXQsIEkgbGlrZSBr ZWVwaW5nIGl0IGZvciBwcm9zcGVyaXR5KSwgc2hvd3MgdGhlcmUgDQppcyBzdGlsbCBzb21lIGNv cnBvcmF0ZS9ETlMgY29udHJvbHMuICBJIGRvIGtub3cgdGhhdCBob3RtYWlsLmNvbSB3YXMgDQph Y3F1aXJlZCBzbyB0aGF0IG1pZ2h0IHN0aWxsIG1lYW4gc29tZXRoaW5nIHBlb3BsZS90ZWFtIHdp c2UuDQoNCk92ZXJhbGwsIEkgYmVsaWV2ZSB5b3UgYXJlIG1pc3NpbmcgdGhlIHNvZnR3YXJlIHRv b2xzIHRvIG1hbmFnZSB0aGlzLiANCkxpa2UgbW9zdCBETlMgYXBwbGljYXRpb25zIGxpa2UgdGhp cywgaXQgc3RpbGwgcmVxdWlyZWQgdGhlIHRvb2xzLg0KDQpIb3dldmVyLCBteSBwb2ludCwgb3Ro ZXIgdGhhbiBiZWxpZXZpbmcgTVMgaGFzIHRoZSByZXNvdXJjZXMgYW5kIHBvd2VyIA0KdG8gZG8g dGhpcywgd2hlbiBpdCBjb21lcyB0byB0aGUgcHJvdG9jb2wgaXRzZWxmLCBpdCBzaG91bGQgbm90 LCBhbmQgDQppdCBpcyBnZW5lcmFsbHkgaXNuJ3QsIGEgcmVhc29uIGZvciBleGNsdWRpbmcgc3Vj aCBhIG5hdHVyYWwgcHJvdG9jb2wgDQppZGVhIGxpa2UgdGhpcyBldmVuIGFzIGEgcHJvdG9jb2wg b3B0aW9uLiAgSXRzIGEgbmF0dXJhbCBmaXQgdG8gZGV0ZWN0IA0KMXN0IHZzIDNyZCBwYXJ0eSBh bmQgbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucy4NCg0KRmluYWxseSwgY29uc2lkZXIgdGhh dCBpdHMgbm90IGFsd2F5cyBhcHBsaWNhYmxlIGFjcm9zcyBhbGwgZW1haWwgDQphcHBsaWNhdGlv bnMsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXJnZXIgcHVibGljIHNlcnZpY2UgYXJlYSBhcyB5b3Ug DQpwb2ludGVkIG91dC4gIEJ1dCBpdCBzdGlsbCBhcHBsaWVzIGZvciBtYW55IG9mIHRoZSBvdGhl ciBtYWlsIGhvc3RpbmcgDQpzeXN0ZW1zIGluY2x1ZGluZyBvdGhlciBNaWNyb3NvZnQgZW1haWwg YXBwbGljYXRpb25zLiAgRm9yIGV4YW1wbGUsIA0KdGhlIE1TIFNlY3VyaXR5IEJ1bGxldGlucyBp dCBoYXMgbWVzc2FnZSBBRElEIGFuZCBTRElEIHZhbHVlcyBzdWNoIGFzOg0KDQogICAgICBES0lN LVNpZ25hdHVyZTogZD1lbWFpbC5taWNyb3NvZnRlbWFpbC5jb20NCiAgICAgIEZyb206IGUtbWFp bC5taWNyb3NvZnQuY29tDQoNClRoYXQgaXMgYSB0aGlyZCBwYXJ0eS4gIEFsbCB5b3UgbmVlZCB0 byBkbyBpcyBhZGQgYSBBVFBTIEROUyBUWFQgcmVjb3JkOg0KDQogICAgIGJhc2U2NChzaGExKCJl bWFpbC5taWNyb3NvZnRlbWFpbC5jb20iKS5fYXRwcy5lLW1haWwubWljcm9zb2Z0LmNvbQ0KDQph bmQgbWFuYWdlIGl0IG9mIGNvdXJzZS4gTm8gY29kZSBjaGFuZ2UgaXMgbmVjZXNzYXJ5IG9uIHlv dXIgZW5kIGFzIGEgDQpwdWJsaXNoZXIgYW5kIHNpZ25lci4gIFRoZSBjaGFuZ2UgaXMgZm9yIERN QVJDIHJlY2VpdmVycyB0byBhZGQgYSANCmV4dGVuc2lvbiB0byB0aGUgbG9va3VwIGxvZ2ljLiAg QmFzZWQgb24gUkZDNDY4NiAoU2VjdXJpdHkgdGhyZWF0cyANCkFuYWx5c2lzKSBhbmQgUkZDNTAx NiAoUmVxdWlyZW1lbnRzKSwgdGhlIGNvbnNlbnN1cyB3aGljaCB3YXMgYWxzbyANCnJlZmxlY3Rl ZCBieSB0aGUgQVBJcyB3cml0dGVuLCBpdCB1c2VkIGEgIEFESUQgIT0gU0RJRCBjb25kaXRpb24g dG8gZG8gDQphIFBPTElDWSBsb29rdXAuDQoNClNvIHlvdSBjYW4gYXBwbHkgdGhpcy4gIEhhcmRl ciBmb3IgSG90bWFpbC5jb20sIHdlbGwgdW5kZXJzdG9vZCwgYnV0IA0Kbm90IGZvciBtaWNyb3Nv ZnQuY29tIHdoaWNoIGhhcyBhIHN0cm9uZyBwb2xpY3kgd2l0aCBrbm93biBzZW5kZXJzLiANCllv dXIgU1BGIHBvbGljeSByZWZsZWN0IHRoaXMuICAgRm9yIHNpZ25lcnMsIHdlbGwsIHlvdSBuZWVk IDNyZCBwYXJ0eSANCmxvZ2ljIGJlZm9yZSBlLW1haWwuTWljcm9zb2Z0LmNvbSBmbGlwcyB0aGUg RE1BUkMgcD1yZWplY3Qgc3dpdGNoLg0KDQotLSANCkhMUw0KDQpPbiA0LzE0LzIwMTUgNjo0MSBQ TSwgVGVycnkgWmluayB3cm90ZToNCj4+PiBXaGVuIEkgdGFsayBhYm91dCBzY2FsZSBbMV0sIGl0 J3Mgbm90IGp1c3QgYSBtYXR0ZXIgb2YgZG9pbmcgRE5TIGxvb2t1cHMuDQo+Pj4gVGhhdCdzIGlt cG9ydGFudCwgYnV0IGl0J3Mgbm90IHdoYXQgSSB3b3JyeSBhYm91dCBiZWNhdXNlIHdlIGNhbiBz b2x2ZQ0KPj4+IGl0IGJ5IGFkZGluZyBtb3JlIGhhcmR3YXJlIFsyXS4gSW5zdGVhZCwgYnkgInNj YWxlIiBJIG1lYW4gIm1hbmFnZW1lbnQiLA0KPj4+IHRoYXQgaXMsIGhhdmluZyBodW1hbnMgbWFu YWdlIHRoZSBwcm9jZXNzLCBvciBuZWVkaW5nIGh1bWFucyB0byBkbyBzb21ldGhpbmcuDQo+DQo+ PiBCdXQgdGhhdHMgdGhlIHNhbWUgcHJvYmxlbSBmb3IgZXZlcnl0aGluZy4gIEhvdyB3aWxsIE1T IHdvcmsgaXQgb3V0DQo+PiBmb3IgeW91ciBob3RtYWlsLmNvbSBTUEYgb3BlcmF0aW9ucz8gRm9y IFNQRiwgaG90bWFpbC5jb20gaGFzIGENCj4+IHJlbGF4ZWQgU1BGIHBvbGljeSB3aXRoIGEgbG9u ZyBsaXN0IG9mIEROUyBsb29rdXBzLiAgTG90cyBvZg0KPj4gcHJvY2Vzc2luZyB3YXN0ZSBoZXJl LiBGb3IgRE1BUkMsIHRob3VzYW5kcywgcGVyaGFwcyBtaWxsaW9ucywgaGlnaA0KPj4gdm9sdW1l IG9mIG1haWwgYXJlIGdldHRpbmcgTlhET01BSU4gb24gdGhlIGV4cGVjdGF0aW9uIHRoZXJlIGlz IGENCj4+IERNQVJDIHJlY29yZC4NCj4NCj4gSGksIEhlY3Rvciwgc29ycnkgdG8gZGVyYWlsIHlv dXIgcG9pbnQsIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBwb2ludCBhcyBpdCByZWxhdGVz IHRvIHdoYXQgSSB3YXMgc2F5aW5nLiBBdCBNaWNyb3NvZnQsIHRoZXJlJ3MgYSBkZWRpY2F0ZWQg dGVhbSAoaGFuZGZ1bCBvZiBwZW9wbGUpIHdobyBtYW5hZ2UgdGhlIFNQRiByZWNvcmQgYW5kIHRo ZXJlJ3MgYSBjaGFuZ2UgcmV2aWV3IHByb2Nlc3MsIGFuZCBleHBlcnRpc2UgbW92ZXMgb3V0IG9m IHRoZSB0ZWFtIGdyYWR1YWxseS4gU3RpbGwsIHRoZXJlIGFyZSBwZW9wbGUgdGhhdCBhcmUgYXNz aWduZWQgdG8gaXQuIEluIGFkZGl0aW9uLCBIb3RtYWlsLmNvbSBmaXRzIGludG8gdGhlIDEwIERO UyBsb29rdXAgbGltaXQgYXMgcmVxdWlyZWQgYnkgdGhlIFJGQy4NCj4NCj4gTXkgcG9pbnQgd2Fz IHRoYXQgSG90bWFpbCBjYW4gaW52ZW50b3J5IHdoYXQgYWxsIG9mIGl0cyBJUHMgYXJlLCBhbmQg dXBkYXRlcyBpdHMgRE5TIHJlY29yZHMgbWFudWFsbHkuIEJ1dCBwbGVudHkgb2Ygb3RoZXJzIGRv bid0IGtub3cgd2hhdCB0aGVpciBJUHMgYXJlOyBmdXJ0aGVybW9yZSwgT2ZmaWNlIDM2NSBkb2Vz IGVtYWlsIGhvc3RpbmcgZm9yIHNtYWxsLCBtZWRpdW0sIGFuZCBsYXJnZSBidXNpbmVzc2VzLiBU aGUgcGFydCB0aGF0IGRvZXNuJ3Qgc2NhbGUgaXMgdGhlIGZvbGxvd2luZzoNCj4NCj4gMS4gRm9y IEhvdG1haWwsIGV2ZXJ5IG1haWxpbmcgbGlzdCB0aGF0IG91ciB1c2VycyBhcmUgc2lnbmVkIHVw IGZvciB3b3VsZCByZXN1bHQgaW4gYSBuZXcgRE5TIGVudHJ5LiBIb3cgZG8gd2UgbWFuYWdlIHRo ZSBsaWZlY3ljbGUgYXJvdW5kIHRoYXQ/IFNob3VsZCB3ZSBhdXRvbWF0ZSBpdHMgYWRkaXRpb24/ IFNob3VsZCB3ZSBhdXRvbWF0ZSBpdHMgcmVtb3ZhbD8gRG8gd2UgZGVsYXkgZW1haWwgYmVmb3Jl IHRoZSBETlMgZW50cmllcyBhcmUgcHVibGlzaGVkPyBTaG91bGQgd2UgdGhlcmVieSBieXBhc3Mg dGhlIGNoYW5nZSByZXZpZXcgcHJvY2Vzcz8gSWYgc28sIGhvdyBkbyB3ZSBhdWRpdCB3aGF0J3Mg Z29pbmcgaW4gYW5kIHdoYXQncyBjb21pbmcgb3V0IG9mIHRoZSBIb3RtYWlsIHpvbmU/DQo+DQo+ IDIuIEZvciBPZmZpY2UgMzY1LCB3ZSBjYW4ndCBwdWJsaXNoIEROUyBlbnRyaWVzIGZvciBtb3N0 IG9mIG91ciBjdXN0b21lcnMuIFdlIGNvdWxkIHRlbGwgdGhlbSB3aGF0IHRvIHB1Ymxpc2ggYnV0 IEkgZ3VhcmFudGVlIHlvdSBhbG1vc3Qgbm9uZSBvZiB0aGVtIHdvdWxkIGZvciBldmVyeSBzaW5n bGUgbWFpbCBsaXN0IHRoZWlyIHVzZXJzIHNpZ25lZCB1cCBmb3IsIGlmIHRoZXkgaGFkIHRvIGRv IGl0IGV2ZXJ5IGRheS4gTW9zdCBvZiB0aGVtIHByb2JhYmx5IHdvdWxkbid0IGV2ZW4gZG8gaXQg b25jZS4NCj4NCj4gVGhhdCdzIHRoZSBwYXJ0IHRoYXQgZG9lc24ndCBzY2FsZS4NCj4NCj4gLS0g VGVycnkNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZG1hcmMgW21h aWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVjdG9yIFNhbnRvcw0K PiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxNCwgMjAxNSAyOjQ4IFBNDQo+IFRvOiBkbWFyY0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIFB1Ymxpc2hpbmcgYW5kIFJlZ2lzdHJh dGlvbiBDb25jZXJucw0KPg0KPiBPbiA0LzE0LzIwMTUgMzowMyBQTSwgVGVycnkgWmluayB3cm90 ZToNCj4+IEhpLCBEb3VnLA0KPj4NCj4+PiBUUEEtTGFiZWwgb3BlcmF0ZXMgd2l0aGluIGl0cyBv d24gc3ViLWRvbWFpbi4gIFRoaXMNCj4+PiBzdWItZG9tYWluIGNhbiBiZSBkZWxlZ2F0ZWQgb3Ig dXNlIEROQU1FLg0KPj4+IEhvdyBpcyB0aGUgc2NhbGluZyBpc3N1ZSByZWFsbHkgd29yc2UgdGhh biB0aGUgY2hhbmdlcw0KPj4+IGN1cnJlbnRseSByZXF1aXJlZCBmb3IgU1BGPyAgSW4gZmFjdCwg U1BGIG9mdGVuIGVudGFpbHMgbW9yZQ0KPj4+IEROUyB0cmFuc2FjdGlvbnMgcGVyIHVzZQ0KPj4N Cj4+IFdoZW4gSSB0YWxrIGFib3V0IHNjYWxlIFsxXSwgaXQncyBub3QganVzdCBhIG1hdHRlciBv ZiBkb2luZyBETlMgbG9va3Vwcy4gVGhhdCdzIGltcG9ydGFudCwgYnV0IGl0J3Mgbm90IHdoYXQg SSB3b3JyeSBhYm91dCBiZWNhdXNlIHdlIGNhbiBzb2x2ZSBpdCBieSBhZGRpbmcgbW9yZSBoYXJk d2FyZSBbMl0uIEluc3RlYWQsIGJ5ICJzY2FsZSIgSSBtZWFuICJtYW5hZ2VtZW50IiwgdGhhdCBp cywgaGF2aW5nIGh1bWFucyBtYW5hZ2UgdGhlIHByb2Nlc3MsIG9yIG5lZWRpbmcgaHVtYW5zIHRv IGRvIHNvbWV0aGluZy4NCj4NCj4gQnV0IHRoYXRzIHRoZSBzYW1lIHByb2JsZW0gZm9yIGV2ZXJ5 dGhpbmcuICBIb3cgd2lsbCBNUyB3b3JrIGl0IG91dA0KPiBmb3IgeW91ciBob3RtYWlsLmNvbSBT UEYgb3BlcmF0aW9ucz8gRm9yIFNQRiwgaG90bWFpbC5jb20gaGFzIGENCj4gcmVsYXhlZCBTUEYg cG9saWN5IHdpdGggYSBsb25nIGxpc3Qgb2YgRE5TIGxvb2t1cHMuICBMb3RzIG9mDQo+IHByb2Nl c3Npbmcgd2FzdGUgaGVyZS4gRm9yIERNQVJDLCB0aG91c2FuZHMsIHBlcmhhcHMgbWlsbGlvbnMs IGhpZ2gNCj4gdm9sdW1lIG9mIG1haWwgYXJlIGdldHRpbmcgTlhET01BSU4gb24gdGhlIGV4cGVj dGF0aW9uIHRoZXJlIGlzIGENCj4gRE1BUkMgcmVjb3JkLg0KPg0KPiBBcmUgd2UgYXQgYSBwb2lu dCB3aGVyZSBhbGwgRE5TIFRYVC1iYXNlZCBzb2x1dGlvbnMgd2lsbCBuZWVkIHRvIGJlDQo+IGNv bnZlcnRlZCB0byBpbi1iYW5kIG1haWwgb25seSBzb2x1dGlvbnMgYW5kIHdlIGVsaW1pbmF0ZSBE TlMgZnJvbSB0aGUNCj4gcGljdHVyZT8NCj4NCj4gICAgIGlmIEFESUQgPT0gU0RJRA0KPiAgICAg ICAgRE8gRE5TX0RNQVJDDQo+ICAgICBlbHNlDQo+ICAgICAgICBETlMgUFJPQkxFTSBUT08gSEFS RC4NCj4NCj4gSXMgdGhhdCB3aGF0IHdlIGdvaW5nIHRvIHRlbGwgdGhlIEROUyBmb2xrcyBvbiBs YXN0IGNhbGw/ICBUaGUgYmV0dGVyDQo+IHNvbHV0aW9uIHdhcyBwdW50ZWQgYmVjYXVzZSBpbnRl cmZhY2luZyB3aXRoIEROUyBwZW9wbGUgaXMgYSB0b3VnaA0KPiBwcm9ibGVtLg0KPg0KPiBUaGF0 IGlzIHdoYXQgaXMgYXN0b25pc2hpbmcgbWUgdGhlIG1vc3QgaGVyZS4gQmlsbGlvbiBkb2xsYXIN Cj4gY29ycG9yYXRpb25zIHNheWluZyB0aGlzIHByb2JsZW0gaXMgdG9vIGhhcmQgZm9yIHRoZW0g dG8gYWRkcmVzcy4NCj4gV293LiBJJ20gc29ycnksIGJ1dCBpdCBzZWVtcyBvZGQgdGhhdCB3ZSB3 ZXJlIGdvaW5nIGZvciBhIGZhciBtb3JlDQo+IGNvbXBsZXggd29ya2Fyb3VuZCB0aGF0IGhhcyBz ZWN1cml0eSBob2xlcyBqdXN0IGJlY2F1c2UgdGhlIHdlIGNhbid0DQo+IGdldCB0aGUgRE5TIGZv bGtzIGludm9sdmVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHBhY2thZ2Ugd2hlbiBETlMgaXMN Cj4gcmVxdWlyZWQgaW4gdGhlIGZpcnN0IHBsYWNlLiAgVGhpcyBhbGwgc2VlbXMgdmVyeSBzdHJh bmdlIHRvIG1lIHRvDQo+IHJlYWQgdGhpcy4NCj4NCj4gSSBkb24ndCBtaW5kIGFuIEluLWJhbmQg c29sdXRpb24gYXMgYW4gT1BUSU9OQUwgYWx0ZXJuYXRpdmUgdG8gdGhlDQo+IG1vcmUgb3B0aW1p emVkLCBtb3JlIHNlY3VyZWQsIG1vcmUgdGVjaG5pY2FsbHkgZmVhc2libGUsIHRpbWUgdGVzdGVk DQo+IHNpbXBsZSBETlMgbG9va3VwIHNvbHV0aW9uLiAgIFRoZSBJRVRGLCB0aGlzIFdHLCB0aGUg Y2hhaXJzIG93ZXMgaXQgdG8NCj4gdGhlIGludGVyZXN0ZWQgaW5kdXN0cnkgcGFydGljaXBhbnRz IHRvIG9mZmVyIGFuZCBwcm92aWRlIGEgc29saWQNCj4gc29sdXRpb24sIGV2ZW4gaWYgaXQgaW52 b2x2ZXMgZ2V0dGluZyBETlMgYWRtaW5pc3RyYXRpb24gaW52b2x2ZWQuDQo+DQoNCg0K From nobody Wed Apr 15 13:39:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191EB1A8A79 for ; Wed, 15 Apr 2015 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wl0SjcmM7YEB for ; Wed, 15 Apr 2015 13:39:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2958B1A8A76 for ; Wed, 15 Apr 2015 13:39:15 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4FDEFC400C2 for ; Wed, 15 Apr 2015 15:39:13 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429130353; bh=XHcTdrcU0RG84eNLCvajhVBDNZeln/B+VmWo3ST8YnA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gEXgx9NBOb30RJJbT+N625NxQaVi6tvOBLEXjda2+3SKxuKtWMYn7A4DnakhhlYFi fz0iPd/srQivCTZFmGjWaKNMm4VwVxD/qa3QUOsApJuOTAkohdsD9847pHhTay28Fd f1VZhpdcLUALIaK2wnrN6jVLcFt7OjLVU4gKf5xo= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 15 Apr 2015 16:39:13 -0400 Message-ID: <2135687.mun7GpbTUA@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <552EB0E0.1080603@isdg.net> References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:39:17 -0000 On Wednesday, April 15, 2015 02:41:36 PM Hector Santos wrote: > On 4/15/2015 2:08 PM, Murray S. Kucherawy wrote: > > On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink > > > > wrote: > >> 1. For Hotmail, every mailing list that our users are signed up for would > >> result in a new DNS entry. How do we manage the lifecycle around that? > >> Should we automate its addition? Should we automate its removal? Do we > >> delay email before the DNS entries are published? Should we thereby > >> bypass > >> the change review process? If so, how do we audit what's going in and > >> what's coming out of the Hotmail zone? > >> > >> 2. For Office 365, we can't publish DNS entries for most of our > >> customers. > >> We could tell them what to publish but I guarantee you almost none of > >> them > >> would for every single mail list their users signed up for, if they had > >> to > >> do it every day. Most of them probably wouldn't even do it once. > >> > >> That's the part that doesn't scale. > > > > +1. The mechanism of generating DNS records is not the issue; we even > > have > > an RFC that shows how that could be done in theory. It's the processes > > themselves that simply won't scale or would fail to thrive. > > -1. > > There is no proof of this other than it hasn't been tried at large > scale. Nonetheless, software guys can produce the tools for anyone to > do this, today, successfully. Once again, by far, and I hope you > agree, most domains will not need the level of scale that would begin > to make it too complex to manage. Not everyone has the "complex > processes" which I believe has been overblown and used as a flat out > reason for excluding the most feasible idea we have. > > From a pure protocol standpoint, it is a natural fit. We are talking > about satisfying the ADID != SDID condition lacking in DMARC which can > be a protocol option: > > DMARC Receivers MAY use DSAP mechanisms for ADID != SDID conditions. > > which can translate into product configuration options. > > [X] Support DMARC > [X] Support ATPS Extension > [X] Support @FS= > (o) Global (sign all) > (_) Selective (Disabled, Future) > > > It is unreasonable to impose more complex changes to both signers and > receivers, all of them, with no option to do a simple lookup which is > all that is required. I am open to having both a direct and inband > methods with direct being the most efficient and least costly. You > can not impose costly changes on all when it is clearly not necessary. > > IMV, the IETF should not be in a put into position where it is > creating situations for Mail and DNS folks to battle over the highly > subjective belief that it is just too hard to manage DNS records, thus > lets make the mail less DKIM secured and more DKIM complex with more > in-band (RFC5322) information. It isn't going to fly too well. For the umpteenth time, the issue isn't managing a DNS zone. That's the easy part. The hard part is knowing what to put in it. Many companies, not even the really big ones, have thousands of domains. Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then tell me it's all easy to then figure out what the right list of authorized forwarders should be for each one. ScottK P.S. I'm done on the topic of is keeping a list of forwarders a useful solution for the group to work on. No matter how you wrap it up, it's not. From nobody Wed Apr 15 14:10:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915391A9029 for ; Wed, 15 Apr 2015 14:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0qkU-L5GruiE for ; Wed, 15 Apr 2015 14:10:42 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0090.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECADC1A901C for ; Wed, 15 Apr 2015 14:10:41 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.136.3; Wed, 15 Apr 2015 21:10:22 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.014; Wed, 15 Apr 2015 21:10:22 +0000 From: Terry Zink To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Publishing and Registration Concerns Thread-Index: AQHQdtR4gmTZLiYUhE6z++40+HrMyJ1MvWsQgAARPgCAAAygMIAAMEsAgAAMw9CAAUhvgIAACSsAgAAg3YCAAAiIYA== Date: Wed, 15 Apr 2015 21:10:21 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> In-Reply-To: <2135687.mun7GpbTUA@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.28] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(4001540100001)(4001410100001)(81156007)(101416001)(66066001)(87936001)(64706001)(2950100001)(2900100001)(2656002)(92566002)(33656002)(46102003)(2501003)(107886001)(106356001)(97736003)(86362001)(68736005)(102836002)(93886004)(77156002)(62966003)(105586002)(76176999)(50986999)(54356999)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0547116B72 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 21:10:21.9124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 21:10:43 -0000 > For the umpteenth time, the issue isn't managing a DNS zone. That's the = easy=20 > part. The hard part is knowing what to put in it. Many companies, not e= ven=20 > the really big ones, have thousands of domains. Go publish SPF, DKIM key= , and=20 > DMARC records for 4,000 domains and then tell me it's all easy to then fi= gure=20 > out what the right list of authorized forwarders should be for each one. +1. -- Terry From nobody Wed Apr 15 15:11:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B4F1A923B for ; Wed, 15 Apr 2015 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 O_5hbTLo1vve for ; Wed, 15 Apr 2015 15:11:51 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 5D1E51A923A for ; Wed, 15 Apr 2015 15:11:51 -0700 (PDT) Received: by wiax7 with SMTP id x7so121808477wia.0 for ; Wed, 15 Apr 2015 15:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KvMKszwRqY1tINKWF/keOj9dmjpZhBgvvFl+a/Ws4DA=; b=oYYzEystcddJPpIY2NaFYXP6+ISNZBTqFFhrltzOpfK1mhtka30zUFth7pIz4ZOiga 2kDLXCLT6iHC+Y8JJvSACO0n0J+u5F8GOG4nUQ/nyH/NviZOM+iUQzZtWz4cU/MjA+Zb zCGa1t8JqNDdpoeFQJMY/ywJN4WCrRDOqEOHIAh6r/T08dCkjYjBs2u+voGQqQ1LrKBb +xaaBcJg4a/7vm+3igffvUBgb1zynUsxPKdkfqpiUkkhy1I8rlWuGPvc+tafg+btFp+S wMIpZ5CZfQ5lHIAnq3jrN7xfbJZ23s7UooIIsvC0IF+wkU72GGAy2R6yruJLpp5RMCbg 9tzA== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr53335352wjc.4.1429135910150; Wed, 15 Apr 2015 15:11:50 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Wed, 15 Apr 2015 15:11:50 -0700 (PDT) In-Reply-To: <2135687.mun7GpbTUA@kitterma-e6430> References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> Date: Wed, 15 Apr 2015 15:11:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e01419d1c42a6fb0513caa2db Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 22:11:53 -0000 --089e01419d1c42a6fb0513caa2db Content-Type: text/plain; charset=UTF-8 On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman wrote: > For the umpteenth time, the issue isn't managing a DNS zone. That's the > easy > part. The hard part is knowing what to put in it. Many companies, not > even > the really big ones, have thousands of domains. Go publish SPF, DKIM key, > and > DMARC records for 4,000 domains and then tell me it's all easy to then > figure > out what the right list of authorized forwarders should be for each one. > +1. Also, if one were to interpret the Pareto Principle correctly, it actually favors the idea that the only things we should consider are the ones the large operators are willing to adopt, which means it's abundantly clear that registration protocols -- all of them -- are non-starters at this point. P.S. I'm done on the topic of is keeping a list of forwarders a useful > solution for the group to work on. No matter how you wrap it up, it's not. > +1. -MSK --089e01419d1c42a6fb0513caa2db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
For = the umpteenth time, the issue isn't managing a DNS zone.=C2=A0 That'= ;s the easy
part.=C2=A0 The hard part is knowing what to put in it.=C2=A0 Many companie= s, not even
the really big ones, have thousands of domains.=C2=A0 Go publish SPF, DKIM = key, and
DMARC records for 4,000 domains and then tell me it's all easy to then = figure
out what the right list of authorized forwarders should be for each one.

+1.

Also, if one were to interpret the Pareto= Principle=20 correctly, it actually favors the idea that the only things we should=20 consider are the ones the large operators are willing to adopt, which means= it's abundantly clear that registration protocols -- all of them -- ar= e=20 non-starters at this point.

P.S.=C2=A0 I'm done on the topic of is keeping a list of forwarders a u= seful
solution for the group to work on.=C2=A0 No matter how you wrap it up, it&#= 39;s not.

+1.

-MSK
--089e01419d1c42a6fb0513caa2db-- From nobody Wed Apr 15 16:51:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D39E1ACD98 for ; Wed, 15 Apr 2015 16:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cojiFR2mLCqU for ; Wed, 15 Apr 2015 16:51:10 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3D31ACD93 for ; Wed, 15 Apr 2015 16:51:09 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 3FD548005A for ; Wed, 15 Apr 2015 16:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1429141869; bh=Wjfum63R1D9473emWl7Y3vLNpX34nMpLOeVbG80GKJ8=; h=Subject:From:In-Reply-To:Date:References:To:From; b=EqMm/wGRAhYceNA9w/Ht8FlmrWS+5R78mIHvY74OWX0yA5UsupyFRr2x/vYjmZoIJ /wcsVDXBfB+ZI4OFEcQtjbkVmVw5b4mSpwVIOob+kWl+RrSoWQ3bvDM7XE99BNfzfx Ax3kProQOmOYgmVHKHHY0JLXPy7Vj6jOnQpPdngE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: Date: Wed, 15 Apr 2015 16:51:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C0C5C7A-A6FC-4AD6-90CD-34E6E30522FA@wordtothewise.com> References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 23:51:11 -0000 On Apr 15, 2015, at 3:11 PM, Murray S. Kucherawy = wrote: > On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman = wrote: >> For the umpteenth time, the issue isn't managing a DNS zone. That's = the easy >> part. The hard part is knowing what to put in it. Many companies, = not even >> the really big ones, have thousands of domains. Go publish SPF, DKIM = key, and >> DMARC records for 4,000 domains and then tell me it's all easy to = then figure >> out what the right list of authorized forwarders should be for each = one. >=20 > +1. >=20 > Also, if one were to interpret the Pareto Principle correctly, it = actually favors the idea that the only things we should consider are the = ones the large operators are willing to adopt, which means it's = abundantly clear that registration protocols -- all of them -- are = non-starters at this point. >=20 >> P.S. I'm done on the topic of is keeping a list of forwarders a = useful >> solution for the group to work on. No matter how you wrap it up, = it's not. >>=20 > +1. +1 Cheers, Steve= From nobody Wed Apr 15 17:48:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B161ACEFE for ; Wed, 15 Apr 2015 17:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.103 X-Spam-Level: X-Spam-Status: No, score=-100.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 H-Ji1e5yAoxc for ; Wed, 15 Apr 2015 17:48:13 -0700 (PDT) Received: from mail.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F18FA1ACF03 for ; Wed, 15 Apr 2015 17:48:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=950; t=1429145276; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vO2T8Q+x5PtwvnBQpJBjmM1b8P0=; b=nL1iY9zzA4oLL06r0Uop YZlszO3594UF9ygxJgYUnd3qrQ0ZHwzy+c2077Eu22VxNGNKrHNltT63NSpeDT7u UUA2TgEcyIkfUTeZGy7NEt/01dyM5xk8m/+tcefnEd3CXQlRs1/gNWsnk3aNwbuR 8Rap3kFtDPkiyHgxf47Cfnw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 20:47:56 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2855290333.10833.3432; Wed, 15 Apr 2015 20:47:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=950; t=1429145040; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gsfrF21 TGJideVgNC9R1q3qjHvLaJI1gRNnSs4nwXho=; b=ExX+8Bg7odK54V3VTLD1oNU ikarDALtLesH+OVR/e/Tvv8vs6wRhS2i2b30dj1aYSedLlkqCfrhQQUnXTLm3L2V qsMb1dQz75spQ0+HBO0LY2MD+6SL4nwSgZ0JFbfC1JawbsORwbNVxbavaO6Z3zyf 9FPt9lYzCA+b1Epdb7Wc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 20:44:00 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1447575691.9.6120; Wed, 15 Apr 2015 20:43:59 -0400 Message-ID: <552F06BA.7040505@isdg.net> Date: Wed, 15 Apr 2015 20:47:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> In-Reply-To: <2135687.mun7GpbTUA@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 00:48:15 -0000 On 4/15/2015 4:39 PM, Scott Kitterman wrote: > > For the umpteenth time, the issue isn't managing a DNS zone. That's the easy > part. The hard part is knowing what to put in it. Right. I never said it was hard problem. This didn't stop the large domain with SPF in adding INCLUDE and still have an unknown result. >Many companies, not even > the really big ones, have thousands of domains. and millions more does not. > Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then tell me > it's all easy to then figure out what the right list of authorized forwarders >should be for each one. For the umpteenth time, not everyone need 4000 domains. Most of the domains that will or may utilize it, simply don't need this scale. > P.S. I'm done on the topic of is keeping a list of forwarders a useful > solution for the group to work on. No matter how you wrap it up, it's not. So move on, scott. -- HLS From nobody Wed Apr 15 17:51:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD341ACF1C for ; Wed, 15 Apr 2015 17:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 Wzoa6eLI0dpN for ; Wed, 15 Apr 2015 17:51:28 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C44401ACF24 for ; Wed, 15 Apr 2015 17:51:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=495; t=1429145481; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=nDLvYGgXMFAcFV/o/gGptVCfD04=; b=wxJsClokyl7bBd63p83b w9mTNfNaIRV8zvD13PbOR1WMhtDmcL83G6q3UCyKIHi2UJjLKiLKGL39dmj+dpdc lR4876NM7ZKmZ2QPL6ymzTW84e1qsOsUZ57jL64Mkp6P5SoHAAxL/OeOkmYkgB08 wdf08P3EiPTEi9NeaGl567o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 20:51:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2855495428.10833.4788; Wed, 15 Apr 2015 20:51:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=495; t=1429145245; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=mqdO9hN bmqu0+qz+dpOV21y6+8Rm9sQphPrAh9cFdoc=; b=q7aCHOQn7QrUJ5OJodVlabF +GnRZUGiL3tcaW0wgQeKbjpNao7VJBFcpGwJIzcjoahbRqkNp/BIiKTvtiDd7k3y ynpXf57qz8fEAp2rnWxS4218IeNlbMpj3ZGBSH+Y3mduHF53OXKsa9TOb44iXICe fH5pb3s1zK04HANb12So= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 15 Apr 2015 20:47:25 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1447781691.9.11052; Wed, 15 Apr 2015 20:47:25 -0400 Message-ID: <552F0788.8020506@isdg.net> Date: Wed, 15 Apr 2015 20:51:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 00:51:28 -0000 On 4/15/2015 6:11 PM, Murray S. Kucherawy wrote: > Also, if one were to interpret the Pareto Principle correctly, it actually > favors the idea that the only things we should consider are the ones the > large operators are willing to adopt, which means it's abundantly clear > that registration protocols -- all of them -- are non-starters at this > point. Well, you interpreted it incorrectly. If that was the case, many IETF protocols would of never got off the ground. -- HLS From nobody Wed Apr 15 17:55:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35D31ACEF4 for ; Wed, 15 Apr 2015 17:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sWFI23eP6CpD for ; Wed, 15 Apr 2015 17:55:50 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403FA1AD055 for ; Wed, 15 Apr 2015 17:55:50 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.136.3; Thu, 16 Apr 2015 00:55:32 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.206]) with mapi id 15.01.0136.014; Thu, 16 Apr 2015 00:55:32 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Publishing and Registration Concerns Thread-Index: AQHQdtR4gmTZLiYUhE6z++40+HrMyJ1MvWsQgAARPgCAAAygMIAAMEsAgAAMw9CAAUhvgIAACSsAgAAg3YCAAEV7AIAAAUew Date: Thu, 16 Apr 2015 00:55:30 +0000 Message-ID: References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> <552F06BA.7040505@isdg.net> In-Reply-To: <552F06BA.7040505@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.28] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(199003)(13464003)(189002)(377454003)(479174004)(97736003)(66066001)(64706001)(101416001)(2656002)(33656002)(102836002)(2950100001)(68736005)(87936001)(86362001)(4001540100001)(2900100001)(15975445007)(81156007)(92566002)(4001410100001)(2501003)(77156002)(62966003)(105586002)(54356999)(50986999)(76176999)(93886004)(46102003)(106116001)(107886001)(19580395003)(19580405001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0548586081 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 00:55:31.6651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 00:55:53 -0000 Hi, Hector, > For the umpteenth time, not everyone need 4000 domains. Most of the=20 > domains that will or may utilize it, simply don't need this scale. I'm not sure you get the point that the others are trying to make. While th= is *may* scale for small domains (a big maybe), it won't scale for large do= mains like Hotmail, Yahoo, Google, AOL, and a lot of other large providers = who are unlikely to implement it. They make up a small number of implemente= rs but a massive number of users. If it won't work for this massive user ba= se, then it's not worth implementing even on a small scale because for the = average user (of which there are millions), the people they try to send to = (Hotmail, Google, Yahoo) aren't supporting this. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Wednesday, April 15, 2015 5:48 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Publishing and Registration Concerns On 4/15/2015 4:39 PM, Scott Kitterman wrote: > > For the umpteenth time, the issue isn't managing a DNS zone. That's the = easy > part. The hard part is knowing what to put in it. Right. I never said it was hard problem. This didn't stop the large=20 domain with SPF in adding INCLUDE and still have an unknown result. >Many companies, not even > the really big ones, have thousands of domains. and millions more does not. > Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then t= ell me > it's all easy to then figure out what the right list of authorized forwar= ders >should be for each one. For the umpteenth time, not everyone need 4000 domains. Most of the=20 domains that will or may utilize it, simply don't need this scale. > P.S. I'm done on the topic of is keeping a list of forwarders a useful > solution for the group to work on. No matter how you wrap it up, it's no= t. So move on, scott. --=20 HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 16 05:20:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8427F1A87E6 for ; Thu, 16 Apr 2015 05:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 1nXXM0Ow-S0M for ; Thu, 16 Apr 2015 05:20:34 -0700 (PDT) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 72AD81B2DDE for ; Thu, 16 Apr 2015 05:20:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2370; t=1429186828; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ESyCsQdoPk3dkE4DtquvSVshrNQ=; b=MybDv9prq0Qlvddeh29r 71pcQKiE780GoVomOw3P3i0R7GRED85JXwgduKRnFwvMAaUC9PW2xFgwhBQWSSPH 7Ft+DprryhpW8KmdJNz2/g0cmwUrRuWqVJn0Zl6Od+MoME6sBnu47uCRpxPEX7xa 5Dt7jLDOtUJm+B55JrfX2IY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 08:20:28 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2896840981.11543.5680; Thu, 16 Apr 2015 08:20:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2370; t=1429186591; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uzMVgA8 DgLCS9wL9ROLqz2uAVVGPgFOuwzhp1kQick0=; b=ZQDzhaghd3tRbkbLb9J/cpF rOVgkDl8/oLWkN+DwnwZ7hicAsWSHjjr6tipbmEUBavx4utT+1oHhNp9OuVtCA0u cZIRMJwlqJh0hMzEzda9LwCBiEWXNMjroOhw74TY3tItW8x8Co/Wgt2FIzkPiaFP fBa0neQRJrjTv/jKOmFo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 08:16:30 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1489126973.9.7292; Thu, 16 Apr 2015 08:16:30 -0400 Message-ID: <552FA90B.7050503@isdg.net> Date: Thu, 16 Apr 2015 08:20:27 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Terry Zink , "dmarc@ietf.org" References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> <552F06BA.7040505@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 12:20:41 -0000 On 4/15/2015 8:55 PM, Terry Zink wrote: > Hi, Hector, > >> For the umpteenth time, not everyone need 4000 domains. Most of the >> domains that will or may utilize it, simply don't need this scale. > > I'm not sure you get the point that the others are trying to make. While this *may* scale for small domains (a big maybe), Terry, Its not a "big maybe." Its in production code. It already been shown to scale. Smaller, even mid size organizations are simply not going to have this registration problem. Most domains are not going to need millions, nor thousand and probably not even hundreds of domains. Even if they did, its manageable. > ... it won't scale for large domains like Hotmail, Yahoo, Google, AOL, and a lot of other large providers who are unlikely to implement it. They make up a small number of implementers but a massive number of users. If it won't work for this massive user base, then it's not worth implementing even on a small scale because for the average user (of which there are millions), the people they try to send to (Hotmail, Google, Yahoo) aren't supporting this. > You know, I'll leave it at this. The same was said that no one will implement DKIM Policy ideas. And even if they did, it was said, that no one will use prepare hard policies, and even if they did, it was said, no one will turn on the rejection switch, that no one will honor it, especially the MLM. Well, we are here because it did happen. Questionable decisions were made in the past to abandoned policy ideas and its being repeated again. If the only problem is registration, this is not a reason to limit the protocol to just 1st party lookups. Finally, to use "large providers" arguments is generally not how IETF protocols are designed. I I will even suggest it borderlines conflict of IETF interest. There are millions of private operation domains and quite a few SMTP implementators. Not everyone uses Office 365, Hillary had her own servers :). They all will not have this registration issue and the protocol makes good engineering sense across the board. The direction the WG is headed is not only more unsecured but will exert more cost and pressure on everyone else. Thats not good, especially when the decision is the leave out the best idea we have for ALL kinds for systems, not just the big guy. -- HLS From nobody Thu Apr 16 07:13:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746751A90A9 for ; Thu, 16 Apr 2015 07:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7NsVIEfcGBhz for ; Thu, 16 Apr 2015 07:13:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977651B31BB for ; Thu, 16 Apr 2015 07:11:20 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7B5FDC40243 for ; Thu, 16 Apr 2015 09:11:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429193479; bh=7R0gqy8Kft+d3sxsnosTg/oItBQRDn/FFJAPm/O7Zrs=; h=From:To:Subject:Date:From; b=M8yhqFOGaQEJbAnKuxyWljT99zJJMq9CnQNXnEdNat19lpAr+FQdsjYaJrGSQjYF3 fXYOeDLv0tYATIIYQGOeam0mM1owI3W3wltB2DEUebVDv+a95E1PRDWwDTzDQfNCNB xTJqcrzBqtmSpC8bjQLFrS/w3qzChhRlclsePjIA= From: Scott Kitterman To: "dmarc@ietf.org" Date: Thu, 16 Apr 2015 10:11:14 -0400 Message-ID: <5719430.pnL5xihlrb@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 14:13:07 -0000 I will probably regret this, but since people are throwing around things like Pareto to argue in favor or against specific solution areas, I thought it might be useful to take a step back and look at what might make a solution (or set of solutions) useful to pursue. For indirect mail flows like mailing lists, there are three actors involved: 1. Originator 2. Mediator 3. Receiver For the purposes of this discussion I'll further categorize the entities involved as big and small (yes, it's way more complex than that, but I think that's sufficient). That leads to six combinations: Originator/Big, Originator/Small, Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. There have been solutions proposed that only require changes for one of the three above, that require changes at two of the above, and that require changes at all three. Two examples of solutions that require changes only for one actor are configuring mailing lists not to make changes that break DKIM signatures and mailing lists rewriting the body From to a local value. While both of those have drawbacks, from a utility analysis perspective, I think they are useful to include in the family of solutions to the indirect mail flow problems caused by DMARC. Rationale: They can be deployed by mediators both big and small with no further coordination with other actors. For mediators that choose to go down this path and accept the downsides of these approaches, they can solve the indirect mail flow problem. Another example of a potential solution is receivers amalgamating data from across their user base to identify forwarders and utilize a local policy override to not reject DMARC fail messages assessed to be sent via an indirect mail flow. This is supported by the DMARC specification, but it's not something that Receiver/Small is going to be able to do. It's only really useful for Receiver/Big. It should be included in the family of solutions, but it could not be said to 'solve' the indirect mail flow problem since it doesn't scale down. While none of these three solutions are complete, they are complete at least for those entities willing and able to deploy them. Once a solution requires changes from multiple actors, the assessment is more complex. If a solution requires (as an example) both sender and receiver changes to work, then if it only works for small entities, then I don't think it has utility. Since Big sends to Small and Small sends to Big, any solution that affects multiple types of actors needs to work for both Big and Small, otherwise if a Small only solution is deployed it will fail when Small sends to Big. Conversely, if a Big only solution is deployed, it will fail when Big sends to Small. This type of assessment is why I was attracted to John Levine's fs= proposal. While it is inherently very complex to deploy (it definitely requires sender and receiver changes and for some indirect mail flows [those that strip signatures today]), there is nothing inherently Big or Small about it. I think it has other problems that may or may not be resolvable, but from a solution space coverage perspective it is attractive. For the complex solution set that covers multiple actors, I think we have to have a single solution to propose. If we have multiple, multiple actor solutions, then interoperability in this space gets much more complex. For single actor solutions, any solution that works and can be deployed helps interoperability because if any actor deploys it, the breakage is reduced. For multi-actor solutions, adding additional solutions probably reduces interoperability since in any given mail transaction (Originator -> Mediator - > Receiver) all three have to have the same solution deployed. If the Originator and Receiver have deployed three part solution #1 and the Mediator has deployed three part solution #2, then both solutions fail. It's the same as having done nothing. In terms of what makes sense to specify in the output of the working group, I think we should be willing to accept as many single actor solutions as we discover and have energy to document. They are always good. None of these solutions is free of side effects and actors should be free to pick their poison as long as it doesn't break things elsewhere. For multi-entity solutions, I think we should be more constrained. I think any multi-actor solution has to work for both Big and Small actors or else there is no interoperability. I think at most one three actor modification solution ought to be included. I think there is possibly room for solutions that relate only to two actors in addition. We can't afford, both in terms of working group time and energy and in eventual interoperability to have a lot of choices in this more complex space. Note: This is not intended to say anything is in or out, just to give a framework for the discussion. Scott K From nobody Thu Apr 16 07:32:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD891B31BB for ; Thu, 16 Apr 2015 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 4V8Xdwvl4M6l for ; Thu, 16 Apr 2015 07:32:27 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D886A1B31BA for ; Thu, 16 Apr 2015 07:32:26 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 10:32:24 -0400 From: "MH Michael Hammer (5304)" To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis Thread-Index: AQHQeE96hn+PvBu9d0qqAFBdP7pSl51Ps4ew Date: Thu, 16 Apr 2015 14:32:24 +0000 Message-ID: References: <5719430.pnL5xihlrb@kitterma-e6430> In-Reply-To: <5719430.pnL5xihlrb@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.221] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 14:32:30 -0000 Scott, Thanks for laying the problem space out in this manner. Mike > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Scott Kitterman > Sent: Thursday, April 16, 2015 10:11 AM > To: dmarc@ietf.org > Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis >=20 > I will probably regret this, but since people are throwing around things = like > Pareto to argue in favor or against specific solution areas, I thought it= might > be useful to take a step back and look at what might make a solution (or = set > of solutions) useful to pursue. >=20 > For indirect mail flows like mailing lists, there are three actors involv= ed: >=20 > 1. Originator > 2. Mediator > 3. Receiver >=20 > For the purposes of this discussion I'll further categorize the entities = involved > as big and small (yes, it's way more complex than that, but I think that'= s > sufficient). >=20 > That leads to six combinations: Originator/Big, Originator/Small, > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. >=20 > There have been solutions proposed that only require changes for one of t= he > three above, that require changes at two of the above, and that require > changes at all three. >=20 > Two examples of solutions that require changes only for one actor are > configuring mailing lists not to make changes that break DKIM signatures = and > mailing lists rewriting the body From to a local value. While both of th= ose > have drawbacks, from a utility analysis perspective, I think they are use= ful to > include in the family of solutions to the indirect mail flow problems cau= sed by > DMARC. >=20 > Rationale: They can be deployed by mediators both big and small with no > further coordination with other actors. For mediators that choose to go > down this path and accept the downsides of these approaches, they can > solve the indirect mail flow problem. >=20 > Another example of a potential solution is receivers amalgamating data fr= om > across their user base to identify forwarders and utilize a local policy = override > to not reject DMARC fail messages assessed to be sent via an indirect mai= l > flow. This is supported by the DMARC specification, but it's not somethi= ng > that Receiver/Small is going to be able to do. It's only really useful f= or > Receiver/Big. It should be included in the family of solutions, but it c= ould not > be said to 'solve' the indirect mail flow problem since it doesn't scale = down. >=20 > While none of these three solutions are complete, they are complete at le= ast > for those entities willing and able to deploy them. >=20 > Once a solution requires changes from multiple actors, the assessment is > more complex. If a solution requires (as an example) both sender and > receiver changes to work, then if it only works for small entities, then = I don't > think it has utility. Since Big sends to Small and Small sends to Big, a= ny > solution that affects multiple types of actors needs to work for both Big= and > Small, otherwise if a Small only solution is deployed it will fail when S= mall > sends to Big. Conversely, if a Big only solution is deployed, it will fa= il when Big > sends to Small. >=20 > This type of assessment is why I was attracted to John Levine's fs=3D pro= posal. > While it is inherently very complex to deploy (it definitely requires sen= der > and receiver changes and for some indirect mail flows [those that strip > signatures today]), there is nothing inherently Big or Small about it. I= think it > has other problems that may or may not be resolvable, but from a solution > space coverage perspective it is attractive. >=20 > For the complex solution set that covers multiple actors, I think we have= to > have a single solution to propose. If we have multiple, multiple actor > solutions, then interoperability in this space gets much more complex. F= or > single actor solutions, any solution that works and can be deployed helps > interoperability because if any actor deploys it, the breakage is reduced= . > For multi-actor solutions, adding additional solutions probably reduces > interoperability since in any given mail transaction (Originator -> Media= tor - > > Receiver) all three have to have the same solution deployed. If the > Originator and Receiver have deployed three part solution #1 and the > Mediator has deployed three part solution #2, then both solutions fail. = It's > the same as having done nothing. >=20 > In terms of what makes sense to specify in the output of the working grou= p, I > think we should be willing to accept as many single actor solutions as we > discover and have energy to document. They are always good. None of > these solutions is free of side effects and actors should be free to pick= their > poison as long as it doesn't break things elsewhere. >=20 > For multi-entity solutions, I think we should be more constrained. I thi= nk any > multi-actor solution has to work for both Big and Small actors or else th= ere is > no interoperability. I think at most one three actor modification soluti= on > ought to be included. I think there is possibly room for solutions that = relate > only to two actors in addition. We can't afford, both in terms of workin= g > group time and energy and in eventual interoperability to have a lot of > choices in this more complex space. >=20 > Note: This is not intended to say anything is in or out, just to give a > framework for the discussion. >=20 > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 16 09:32:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B121B3329 for ; Thu, 16 Apr 2015 09:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 KhBD5JxUHyrb for ; Thu, 16 Apr 2015 09:32:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7051B3327 for ; Thu, 16 Apr 2015 09:32:01 -0700 (PDT) Received: (qmail 20198 invoked from network); 16 Apr 2015 16:31:59 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Apr 2015 16:31:59 -0000 Date: 16 Apr 2015 16:31:37 -0000 Message-ID: <20150416163137.2621.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5719430.pnL5xihlrb@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 16:32:02 -0000 >That leads to six combinations: Originator/Big, Originator/Small, >Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. This is indeed useful. But I think it's also important to look at technical vs. nontechnical costs for each actor. The whole reason we're having this discussion is that a few large originators had nontechnical costs that they decided to push off onto other people.* The most tedious and unhelpful discussions here have implicitly (or perhaps explicitly) assumed that receiver nontechnical costs don't matter, then repeatedly pointed out the true but useless fact that there are single party mediator changes with trivial technical costs. R's, John * - the essence of Internet economics is forcing as many of your costs onto other people as you can, but that doesn't make it a virtue From nobody Thu Apr 16 10:03:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FAB1B3300 for ; Thu, 16 Apr 2015 10:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 6jQi3TIia4H2 for ; Thu, 16 Apr 2015 10:03:36 -0700 (PDT) Received: from groups.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B11001B32F7 for ; Thu, 16 Apr 2015 10:03:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=21294; t=1429203805; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=KgQxTAt 83Cc4h4OaAa7vL3K69Pc=; b=scELu4Cx/NhRx5MYaJe2IaWnGS62KGa/o2StUa3 gjtDCwnQgL6DUSwZyjX4AeJK5KdMAgLdGoZ3G8x1gR0+vi2VnGFQ8VBl7iW79Y10 yFwAVwkZhabavC1thuaxRk5xhI/QpdAiO5l4mJbqvD5meaamNiXivhxb/9oiaR5Z he5Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 13:03:25 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2913817930.11543.5480; Thu, 16 Apr 2015 13:03:24 -0400 References: <5719430.pnL5xihlrb@kitterma-e6430> From: Hector Santos Content-Type: multipart/alternative; boundary=Apple-Mail-24AFEC1A-9CA8-4AF3-AC46-259095936BC3 X-Mailer: iPad Mail (12B435) In-Reply-To: <5719430.pnL5xihlrb@kitterma-e6430> Message-Id: <1E0B8116-0F14-40E9-AC57-33FBF60D92F8@isdg.net> Date: Thu, 16 Apr 2015 13:03:20 -0400 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 17:03:40 -0000 --Apple-Mail-24AFEC1A-9CA8-4AF3-AC46-259095936BC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Scott,=20 what is your summary with all this? We probably should understand optimization concepts such as Pareto Optimalit= y and Query Dissemination. Both are applicable here as well. I've actually have two receivers; one for the mediator and one for the end-u= sers. The problem was that Levine did not want the mediator receivers to s= upport policy. Hence ADSP got no support by MLM receivers (except for us, b= ut we didn't flip the rejection switch, just recorded results). What Levine= forgot was the user receivers, and that is what DMARC forgot too. Overall= , they presumed no one will take it serious and honor it, including controll= ing the MLM entry points. Well. It did. We got many IETF-MAN-YEARS of engineering into all this and the policy look= up was the method ultimately devised as the baseline. While it was confused= with mandates to limit the business damage to the resigner market, and a fo= cus to kill policy methods all together, it never removed the need to get 3= rd authorization from the ADID. =20 Blind resigners was a security threat. DKIM could not separate the purported= author from the signature and signer. The 5322.=46rom is required. If it w= asn't, we would then have a different security model. =46rom all historical= angles, from rewrites is simply not a good idea to crack open that door. I= t changes everything and makes the entire discussions moot. As mentioned b= efore, a rewrite is most certainly IETF Appeal sensitive. Just saying. RFC work was done for threats, requirements and overall the DKIM architectur= e and using 1st and 3rd party policy framework is a result and consistent wi= th all the IETF-MAN-YEARS put into this work. We were complaining about th= e actually record and query method and possible management complexity. Not= so much the registration part of it because that can also be learned over t= ime. This work is still relevant and even more so today because the mindset= has changed to enable policy (via DMARC). We simply did not have this befo= re with ADSP. So DMARC has changed the game.=20 The in-band is fine but it's weaker and more expensive to implement, and the= registration is still required by the organizations still interested in kee= ping with a higher level of DKIM security strength a policy framework provid= es. Let's not assume that given no other design option, sites will just bl= indly sign all mail. Given no other choice, who knows, you might force sit= es to re-invest in their DKIM engine to do this double signing and also do t= he policy level verification, Also, keep in mind, the failures points of the proposal too. That's very imp= ortant here. Are we ready to do the MUST/SHOULD for negative classification= (reject/discard/quarantine) when the detectable @fs=3D protocol failures ex= ist? Remember, it's not just about looking for the good, but filtering th= e failures from the stream, and we can't once again get the disillusionment t= hat no one will honor rejection because the two receivers are also using que= ry dissemination methods to minimize connection abuse issues. Look, supposedly opendkim has support for ADSP/ATPS. A simple change to pig= gy back off the DMARC record itself with the renewed interest for policy now= , we can better measure the level of support and also provide the opportunit= y for sites to do registration R&D. =20 -- Hector Santos http://www.santronics.com > On Apr 16, 2015, at 10:11 AM, Scott Kitterman wrote= : >=20 > I will probably regret this, but since people are throwing around things l= ike=20 > Pareto to argue in favor or against specific solution areas, I thought it m= ight=20 > be useful to take a step back and look at what might make a solution (or s= et=20 > of solutions) useful to pursue. >=20 > For indirect mail flows like mailing lists, there are three actors involve= d: >=20 > 1. Originator > 2. Mediator > 3. Receiver >=20 > For the purposes of this discussion I'll further categorize the entities=20= > involved as big and small (yes, it's way more complex than that, but I thi= nk=20 > that's sufficient). >=20 > That leads to six combinations: Originator/Big, Originator/Small,=20 > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. >=20 > There have been solutions proposed that only require changes for one of th= e=20 > three above, that require changes at two of the above, and that require=20= > changes at all three. >=20 > Two examples of solutions that require changes only for one actor are=20 > configuring mailing lists not to make changes that break DKIM signatures a= nd=20 > mailing lists rewriting the body =46rom to a local value. While both of t= hose=20 > have drawbacks, from a utility analysis perspective, I think they are usef= ul=20 > to include in the family of solutions to the indirect mail flow problems c= aused=20 > by DMARC. >=20 > Rationale: They can be deployed by mediators both big and small with no=20= > further coordination with other actors. For mediators that choose to go d= own=20 > this path and accept the downsides of these approaches, they can solve the= =20 > indirect mail flow problem. >=20 > Another example of a potential solution is receivers amalgamating data fro= m=20 > across their user base to identify forwarders and utilize a local policy=20= > override to not reject DMARC fail messages assessed to be sent via an indi= rect=20 > mail flow. This is supported by the DMARC specification, but it's not som= ething=20 > that Receiver/Small is going to be able to do. It's only really useful fo= r=20 > Receiver/Big. It should be included in the family of solutions, but it co= uld=20 > not be said to 'solve' the indirect mail flow problem since it doesn't sca= le=20 > down. >=20 > While none of these three solutions are complete, they are complete at lea= st=20 > for those entities willing and able to deploy them. >=20 > Once a solution requires changes from multiple actors, the assessment is m= ore=20 > complex. If a solution requires (as an example) both sender and receiver=20= > changes to work, then if it only works for small entities, then I don't th= ink=20 > it has utility. Since Big sends to Small and Small sends to Big, any solu= tion=20 > that affects multiple types of actors needs to work for both Big and Small= ,=20 > otherwise if a Small only solution is deployed it will fail when Small sen= ds=20 > to Big. Conversely, if a Big only solution is deployed, it will fail when= Big=20 > sends to Small. =20 >=20 > This type of assessment is why I was attracted to John Levine's fs=3D prop= osal. =20 > While it is inherently very complex to deploy (it definitely requires send= er=20 > and receiver changes and for some indirect mail flows [those that strip=20= > signatures today]), there is nothing inherently Big or Small about it. I=20= > think it has other problems that may or may not be resolvable, but from a=20= > solution space coverage perspective it is attractive. >=20 > For the complex solution set that covers multiple actors, I think we have t= o=20 > have a single solution to propose. If we have multiple, multiple actor=20= > solutions, then interoperability in this space gets much more complex. Fo= r=20 > single actor solutions, any solution that works and can be deployed helps=20= > interoperability because if any actor deploys it, the breakage is reduced.= =20 > For multi-actor solutions, adding additional solutions probably reduces=20= > interoperability since in any given mail transaction (Originator -> Mediat= or - >> Receiver) all three have to have the same solution deployed. If the > Originator and Receiver have deployed three part solution #1 and the Media= tor=20 > has deployed three part solution #2, then both solutions fail. It's the s= ame=20 > as having done nothing. >=20 > In terms of what makes sense to specify in the output of the working group= , I=20 > think we should be willing to accept as many single actor solutions as we=20= > discover and have energy to document. They are always good. None of thes= e=20 > solutions is free of side effects and actors should be free to pick their=20= > poison as long as it doesn't break things elsewhere. >=20 > For multi-entity solutions, I think we should be more constrained. I thin= k=20 > any multi-actor solution has to work for both Big and Small actors or else= =20 > there is no interoperability. I think at most one three actor modificatio= n=20 > solution ought to be included. I think there is possibly room for solutio= ns=20 > that relate only to two actors in addition. We can't afford, both in term= s of=20 > working group time and energy and in eventual interoperability to have a l= ot=20 > of choices in this more complex space. >=20 > Note: This is not intended to say anything is in or out, just to give a=20= > framework for the discussion. >=20 > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 --Apple-Mail-24AFEC1A-9CA8-4AF3-AC46-259095936BC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Scott, 

<= div>what is your summary with all this?

We probably= should understand optimization concepts such as Pareto Optimality and Query= Dissemination.  Both are applicable here as well.

=
I've actually have two receivers; one for the mediator and one for the e= nd-users.   The problem was that Levine did not want the mediator recei= vers to support policy.  Hence ADSP got no support by MLM receivers (ex= cept for us, but we didn't flip the rejection switch, just recorded results)= .  What Levine forgot was the user receivers, and that is what DMARC fo= rgot too.   Overall, they presumed no one will take it serious and hono= r it, including controlling the MLM entry points.

W= ell. It did.

We got many IETF-MAN-YEARS  of engineeri= ng into all this and the policy lookup was the method ultimately devised as t= he baseline.  While it was confused with mandates to limit the business= damage to the resigner market, and a focus to kill policy methods all toget= her,  it never removed the need to get 3rd authorization from the ADID.=  

Blind resigners was a security threat. DKIM= could not separate the purported author from the signature and signer. &nbs= p;The 5322.=46rom is required. If it wasn't, we would then have a different s= ecurity model.  =46rom all historical angles, from rewrites is simply n= ot a good idea to crack open that door.  It changes everything  an= d makes the entire discussions moot.  As mentioned before, a rewrite is= most certainly IETF Appeal sensitive.  Just saying.

RFC work was done for threats, requirements and overall the DKIM arch= itecture and using 1st and 3rd party policy framework is a result and consis= tent with all the IETF-MAN-YEARS put into this work.   We w= ere complaining about the  actually record and query method and possibl= e management complexity.  Not so much the registration part of it becau= se that can also be learned over time.  This work is still relevant and= even more so today because the mindset has changed to enable policy (via DM= ARC).  We simply did not have this before with ADSP.  So DMARC has= changed the game. 

The in-band is fine but it= 's weaker and more expensive to implement, and the registration is still req= uired by the organizations still interested in keeping with a higher level o= f DKIM security strength a policy framework provides.   Let's not assum= e that given no other design option, sites will just blindly sign all mail. &= nbsp; Given no other choice, who knows, you might force sites to re-invest i= n their DKIM engine to do this double signing  and also do the policy l= evel verification,

Also, keep in mind, the failures= points of the proposal too. That's very important here.  Are we ready t= o do the MUST/SHOULD for negative classification (reject/discard/quarantine)= when the detectable @fs=3D protocol failures exist?   Remember, it's n= ot just about looking for the good,  but filtering the failures from th= e stream, and we can't once again get the disillusionment that no one will h= onor rejection because the two receivers are also using query dissemination m= ethods to minimize connection abuse issues.

Look, s= upposedly opendkim has support for ADSP/ATPS.  A simple change to piggy= back off the DMARC record itself with the renewed interest for policy now, w= e can better measure the level of support and also provide the opportunity f= or sites to do registration R&D.   


On Apr 16, 2015, at 10:11 AM, Scot= t Kitterman <sklist@kitterman.com= > wrote:

I will pro= bably regret this, but since people are throwing around things like <= br>Pareto to argue in favor or against specific solution areas, I thou= ght it might
be useful to take a step back and look at what= might make a solution (or set
of solutions) useful to purs= ue.

For indirect mail flows like mailing li= sts, there are three actors involved:

1. &n= bsp;Originator
2.  Mediator
3.  Re= ceiver

For the purposes of this discussion I= 'll further categorize the entities
involved as big and sma= ll (yes, it's way more complex than that, but I think
that'= s sufficient).

That leads to six combinatio= ns: Originator/Big, Originator/Small,
Mediator/Big, Origina= tor/Small, Receiver/Big, and Receiver/Small.

There have been solutions proposed that only require changes for one of th= e
three above, that require changes at two of the above, an= d that require
changes at all three.

Two examples of solutions that require changes only for one actor= are
configuring mailing lists not to make changes that bre= ak DKIM signatures and
mailing lists rewriting the body =46rom= to a local value.  While both of those
have drawbacks= , from a utility analysis perspective, I think they are useful
to include in the family of solutions to the indirect mail flow problems= caused
by DMARC.

Rational= e:  They can be deployed by mediators both big and small with no
further coordination with other actors.  For mediators that c= hoose to go down
this path and accept the downsides of thes= e approaches, they can solve the
indirect mail flow problem= .

Another example of a potential solution i= s receivers amalgamating data from
across their user base t= o identify forwarders and utilize a local policy
override t= o not reject DMARC fail messages assessed to be sent via an indirect =
mail flow.  This is supported by the DMARC specification, but= it's not something
that Receiver/Small is going to be able= to do.  It's only really useful for
Receiver/Big. &nb= sp;It should be included in the family of solutions, but it could not be said to 'solve' the indirect mail flow problem since it doesn'= t scale
down.

While none o= f these three solutions are complete, they are complete at least
= for those entities willing and able to deploy them.

Once a solution requires changes from multiple actors, the as= sessment is more
complex.  If a solution requires (as a= n example) both sender and receiver
changes to work, then i= f it only works for small entities, then I don't think
it h= as utility.  Since Big sends to Small and Small sends to Big, any solut= ion
that affects multiple types of actors needs to work for= both Big and Small,
otherwise if a Small only solution is d= eployed it will fail when Small sends
to Big.  Convers= ely, if a Big only solution is deployed, it will fail when Big
sends to Small.  

This type of ass= essment is why I was attracted to John Levine's fs=3D proposal.  
While it is inherently very complex to deploy (it definitely requ= ires sender
and receiver changes and for some indirect mail= flows [those that strip
signatures today]), there is nothi= ng inherently Big or Small about it.  I
think it has o= ther problems that may or may not be resolvable, but from a
solution space coverage perspective it is attractive.

For the complex solution set that covers multiple actors, I thin= k we have to
have a single solution to propose.  If we= have multiple, multiple actor
solutions, then interoperabi= lity in this space gets much more complex.  For
single= actor solutions, any solution that works and can be deployed helps <= br>interoperability because if any actor deploys it, the breakage is r= educed.  
For multi-actor solutions, adding additional s= olutions probably reduces
interoperability since in any giv= en mail transaction (Originator -> Mediator -
Receiver) all three have to have the same solution deployed. &n= bsp;If the
Originator and Receiver have deploy= ed three part solution #1 and the Mediator
has deployed thr= ee part solution #2, then both solutions fail.  It's the same as having done nothing.

In terms of= what makes sense to specify in the output of the working group, I think we should be willing to accept as many single actor solutions a= s we
discover and have energy to document.  They are a= lways good.  None of these
solutions is free of side e= ffects and actors should be free to pick their
poison as lo= ng as it doesn't break things elsewhere.

Fo= r multi-entity solutions, I think we should be more constrained.  I thi= nk
any multi-actor solution has to work for both Big and Sm= all actors or else
there is no interoperability.  I th= ink at most one three actor modification
solution ought to b= e included.  I think there is possibly room for solutions
that relate only to two actors in addition.  We can't afford, both i= n terms of
working group time and energy and in eventual in= teroperability to have a lot
of choices in this more comple= x space.

Note:  This is not intended t= o say anything is in or out, just to give a
framework for t= he discussion.

Scott K

_______________________________________________
dmarc mailing list
dmarc@= ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

= --Apple-Mail-24AFEC1A-9CA8-4AF3-AC46-259095936BC3-- From nobody Thu Apr 16 11:07:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889B1B2ECA for ; Thu, 16 Apr 2015 11:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 z3bKnWLUlLCo for ; Thu, 16 Apr 2015 11:07:23 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 D46A81B2EA5 for ; Thu, 16 Apr 2015 11:07:22 -0700 (PDT) Received: by wiun10 with SMTP id n10so106814563wiu.1 for ; Thu, 16 Apr 2015 11:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Td3KfxPLa8akXRSx6SrPQS4230TNhOXAf5GGE6v8cSI=; b=jKqA8Vb0IEIKHt2ahKkg8N3Cjka1h+XRjCunJ8FQDYdkoL2PVJnbtFd/Viiwqw5lk4 hpO7kWBLa+PfXiqnlKq8jDe+JH/mIoUzhk8ACkYI7nVsFiuskW/+09KayElSkx2zo9Rv pyaEAGw3R07slAxcCbUXxg8PpYJaIehFVITniDAA8jqLj90+ndoBhFhIggmMEyLvv7Ym g3+bGyn0lNukNzv3gnHanFaW9c2xsUU/JpAMCfVJQM/LbuRoadf4Sn0p3wmSH1EcYpuj BMijmzxqn/e4z+1/oBPpBtwqX5XI2BZC8pmCy1ASpuw6/eQvxO9kcNHrbgXEKQJDgmzC 4vJg== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr61793135wjc.4.1429207641638; Thu, 16 Apr 2015 11:07:21 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 16 Apr 2015 11:07:21 -0700 (PDT) In-Reply-To: <20150416163137.2621.qmail@ary.lan> References: <5719430.pnL5xihlrb@kitterma-e6430> <20150416163137.2621.qmail@ary.lan> Date: Thu, 16 Apr 2015 11:07:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01419d1cca56300513db5587 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:07:24 -0000 --089e01419d1cca56300513db5587 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 16, 2015 at 9:31 AM, John Levine wrote: > The most tedious and unhelpful discussions here have implicitly (or > perhaps explicitly) assumed that receiver nontechnical costs don't > matter, then repeatedly pointed out the true but useless fact that > there are single party mediator changes with trivial technical costs. > Useless because it presumes the non-technical costs of those changes are high? --089e01419d1cca56300513db5587 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 16, 2015 at 9:31 AM, John Levine <johnl@taugh.c= om> wrote:
The most tedious and unhelpful discus= sions here have implicitly (or
perhaps explicitly) assumed that receiver nontechnical costs don't
matter, then repeatedly pointed out the true but useless fact that
there are single party mediator changes with trivial technical costs.

Useless because it presumes the non-technica= l costs of those changes are high?
--089e01419d1cca56300513db5587-- From nobody Thu Apr 16 11:34:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88FB1B3448 for ; Thu, 16 Apr 2015 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 a5L7oZJiqwDG for ; Thu, 16 Apr 2015 11:34:43 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8481B3440 for ; Thu, 16 Apr 2015 11:34:40 -0700 (PDT) Received: (qmail 43865 invoked from network); 16 Apr 2015 18:34:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ab56.553000bf.k1504; bh=gJj9RkUSMnzUHKufoFM7Akbldl7xXf0cmPCO48Jxtyc=; b=O/AKNeFGZOwDbjQ6MtgoEBusBvHbUAi9TqaIC0c2T49HANbKhNo7orEC4FgdqRrw0jGYzwrn6ooWIqo2eOOfb1nJ2v8e3xRzqF+DiFMQhKbKrqVxiyvZFTRqZwkkTO0uV+3a0iFX+HfOjOkE4GoeXupwnSOdgZSs91FJTj9WiYoUd7Ty+kdH97+ULoK2O0oeht9tNvc/u+BDO7m2mwOR42NMqiAX/BmBkCab6wwDFfvW0Oh/gatXWwJ3rN3O5OzY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ab56.553000bf.k1504; bh=gJj9RkUSMnzUHKufoFM7Akbldl7xXf0cmPCO48Jxtyc=; b=7C2Nu8xf+KQxQQOa1tvGwYS9JpttkZq60cpgX6SaR7VxZ64AtJiqL1msNtWeOfyRBpnnGZaXoKqkzqbNJG6jadio+/fFT5tRGw1xd6/VgrsbB6ca03ytUl6wJJH8bqbARJZYwHhHtAcRj0Ebd9/6Kbj3gVelBX2g93QbKP3CJw8jVlpVitVA2+/pSTWaSiwG39vBNkGhJv+Oyw669tgDx3soBgrkpft34dafv4AZWU44Cw1TdueKFE0cQ7vUbdnJ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 16 Apr 2015 18:34:39 -0000 Date: 16 Apr 2015 14:34:38 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> <20150416163137.2621.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:34:44 -0000 >> The most tedious and unhelpful discussions here have implicitly (or >> perhaps explicitly) assumed that receiver nontechnical costs don't >> matter, then repeatedly pointed out the true but useless fact that >> there are single party mediator changes with trivial technical costs. >> > > Useless because it presumes the non-technical costs of those changes are > high? At least, we need to look at what non-technical costs they push onto other parties. Some changes have insignificant non-techincal costs and are not controversial, e.g., adding a List-ID header for the benefit of recipients who know how to use it. Changes that seem similar may have quite different costs, e.g., adding a List-ID and removing subject tags, forcing recipients to change the way they sort and organize their incoming messages. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Apr 16 12:35:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D961B3542 for ; Thu, 16 Apr 2015 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CB5aL3L-f80J for ; Thu, 16 Apr 2015 12:35:51 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7AE1B34F1 for ; Thu, 16 Apr 2015 12:35:51 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lSW4Q0BQZz1L8nh; Thu, 16 Apr 2015 21:35:50 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lSW4P5JXSz5Mgff; Thu, 16 Apr 2015 21:35:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id AAE4A1234E8; Thu, 16 Apr 2015 21:35:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cqQKVHbsOrB5; Thu, 16 Apr 2015 21:35:46 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id D1C001234A1; Thu, 16 Apr 2015 21:35:45 +0200 (CEST) Message-ID: <55300F11.4080208@sonnection.nl> Date: Thu, 16 Apr 2015 21:35:45 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John R Levine , "Murray S. Kucherawy" References: <5719430.pnL5xihlrb@kitterma-e6430> <20150416163137.2621.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1429212950; bh=OxQ4MRbFtentHtkh8d+K5f0bQXly2JzfWMyyKBVcCS8=; h=Message-ID:Date:From:To:Subject:From; b=au6nYxXculeelI1JuS7HvQ+dLhv9mh1NwvERDoOV+AymPU2l9v0AInZdGpOj0WOgw Gu/dZAVZN4yC4Wm7CR6IKVcMPe2uV+qgfyGO/F5Ijixma2Jv12Hhe0H1kGlH+vzBt7 uwe12UqiwVBqqkgZdwvBGy5571oxxOn2BewVWk7k= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lSW4Q0BQZz1L8nh Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:35:53 -0000 On 04/16/2015 08:34 PM, John R Levine wrote: >>> The most tedious and unhelpful discussions here have implicitly (or >>> perhaps explicitly) assumed that receiver nontechnical costs don't >>> matter, then repeatedly pointed out the true but useless fact that >>> there are single party mediator changes with trivial technical costs. >>> >> >> Useless because it presumes the non-technical costs of those changes are >> high? > > At least, we need to look at what non-technical costs they push onto > other parties. > > Some changes have insignificant non-techincal costs and are not > controversial, e.g., adding a List-ID header for the benefit of > recipients who know how to use it. Changes that seem similar may have > quite different costs, e.g., adding a List-ID and removing subject > tags, forcing recipients to change the way they sort and organize > their incoming messages. I (think I) understand what you mean and I sympathize with your reasoning. But how are we supposed to compare non-technical costs with technical costs? And what would be the formula to make a fair comparison between Technical/Non-technical Costs for Big/Small Originators/Mediators/Receivers? The concept of technical vs non-technical cost at least doubles the six combinations, mentioned by Scott. /rolf From nobody Thu Apr 16 12:44:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7871A86FA for ; Thu, 16 Apr 2015 12:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MyJVWR97Y8T6 for ; Thu, 16 Apr 2015 12:44:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515041A854D for ; Thu, 16 Apr 2015 12:44:40 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 78334C40243 for ; Thu, 16 Apr 2015 14:44:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429213479; bh=O9298zrA9VLg+W5LCMt9qpvYu1peXWerNyvve7bE3w0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FyIVkp7hvIvYJzkyCF/ppyD9iG10x9aybIVrohgQ/MsW8+UVJHVagmOF1KWngl7EN hcEciu8JsBFCjB3D6AhVkIGQu8lu4Tn0IzinpK6wMp8Vbva8POxcpfr0k+DOJ0yVid 9Ct1SyHTN8GV2jTMaSoiZvcJc4Sz99Y0myevC0X0= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 16 Apr 2015 15:44:34 -0400 Message-ID: <10912683.ho9DWSQdnT@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1E0B8116-0F14-40E9-AC57-33FBF60D92F8@isdg.net> References: <5719430.pnL5xihlrb@kitterma-e6430> <1E0B8116-0F14-40E9-AC57-33FBF60D92F8@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:44:43 -0000 I don't have a summary. To the extent I mentioned any specific proposal it was meant to be merely exemplary. The point, is to come up with a framework to discuss solution utility. Because there is a certain breadth of deployment needed for interoperability for some solutions, I don't think Pareto analysis is useful at all. We've spent a lot of time going around in circles about various proposals and so I'm trying to come up with a useful way for us to focus. It doesn't eliminate the need to make sure any method we pursue works and is secure, it's just a way to see what clears the minimum threshold for deployability to provide a potential for interoperability. Your mail is mostly arguing about specifics of different solutions. That means we're not at all on the same page. I'm attempting a step back to define a framework we can use to move the group forward. Please look at it at that level and take a step back both from the well known history and the particular solutions you like or don't like. Scott K On Thursday, April 16, 2015 01:03:20 PM Hector Santos wrote: > Scott, > > what is your summary with all this? > > We probably should understand optimization concepts such as Pareto > Optimality and Query Dissemination. Both are applicable here as well. > > I've actually have two receivers; one for the mediator and one for the > end-users. The problem was that Levine did not want the mediator > receivers to support policy. Hence ADSP got no support by MLM receivers > (except for us, but we didn't flip the rejection switch, just recorded > results). What Levine forgot was the user receivers, and that is what > DMARC forgot too. Overall, they presumed no one will take it serious and > honor it, including controlling the MLM entry points. > > Well. It did. > > We got many IETF-MAN-YEARS of engineering into all this and the policy > lookup was the method ultimately devised as the baseline. While it was > confused with mandates to limit the business damage to the resigner market, > and a focus to kill policy methods all together, it never removed the need > to get 3rd authorization from the ADID. > > Blind resigners was a security threat. DKIM could not separate the purported > author from the signature and signer. The 5322.From is required. If it > wasn't, we would then have a different security model. From all historical > angles, from rewrites is simply not a good idea to crack open that door. > It changes everything and makes the entire discussions moot. As mentioned > before, a rewrite is most certainly IETF Appeal sensitive. Just saying. > > RFC work was done for threats, requirements and overall the DKIM > architecture and using 1st and 3rd party policy framework is a result and > consistent with all the IETF-MAN-YEARS put into this work. We were > complaining about the actually record and query method and possible > management complexity. Not so much the registration part of it because > that can also be learned over time. This work is still relevant and even > more so today because the mindset has changed to enable policy (via DMARC). > We simply did not have this before with ADSP. So DMARC has changed the > game. > > The in-band is fine but it's weaker and more expensive to implement, and the > registration is still required by the organizations still interested in > keeping with a higher level of DKIM security strength a policy framework > provides. Let's not assume that given no other design option, sites will > just blindly sign all mail. Given no other choice, who knows, you might > force sites to re-invest in their DKIM engine to do this double signing > and also do the policy level verification, > > Also, keep in mind, the failures points of the proposal too. That's very > important here. Are we ready to do the MUST/SHOULD for negative > classification (reject/discard/quarantine) when the detectable @fs= > protocol failures exist? Remember, it's not just about looking for the > good, but filtering the failures from the stream, and we can't once again > get the disillusionment that no one will honor rejection because the two > receivers are also using query dissemination methods to minimize connection > abuse issues. > > Look, supposedly opendkim has support for ADSP/ATPS. A simple change to > piggy back off the DMARC record itself with the renewed interest for policy > now, we can better measure the level of support and also provide the > opportunity for sites to do registration R&D. > > -- > Hector Santos > http://www.santronics.com > > > On Apr 16, 2015, at 10:11 AM, Scott Kitterman > > wrote: > > > > I will probably regret this, but since people are throwing around things > > like Pareto to argue in favor or against specific solution areas, I > > thought it might be useful to take a step back and look at what might > > make a solution (or set of solutions) useful to pursue. > > > > For indirect mail flows like mailing lists, there are three actors > > involved: > > > > 1. Originator > > 2. Mediator > > 3. Receiver > > > > For the purposes of this discussion I'll further categorize the entities > > involved as big and small (yes, it's way more complex than that, but I > > think that's sufficient). > > > > That leads to six combinations: Originator/Big, Originator/Small, > > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > > > There have been solutions proposed that only require changes for one of > > the > > three above, that require changes at two of the above, and that require > > changes at all three. > > > > Two examples of solutions that require changes only for one actor are > > configuring mailing lists not to make changes that break DKIM signatures > > and mailing lists rewriting the body From to a local value. While both > > of those have drawbacks, from a utility analysis perspective, I think > > they are useful to include in the family of solutions to the indirect > > mail flow problems caused by DMARC. > > > > Rationale: They can be deployed by mediators both big and small with no > > further coordination with other actors. For mediators that choose to go > > down this path and accept the downsides of these approaches, they can > > solve the indirect mail flow problem. > > > > Another example of a potential solution is receivers amalgamating data > > from > > across their user base to identify forwarders and utilize a local policy > > override to not reject DMARC fail messages assessed to be sent via an > > indirect mail flow. This is supported by the DMARC specification, but > > it's not something that Receiver/Small is going to be able to do. It's > > only really useful for Receiver/Big. It should be included in the family > > of solutions, but it could not be said to 'solve' the indirect mail flow > > problem since it doesn't scale down. > > > > While none of these three solutions are complete, they are complete at > > least for those entities willing and able to deploy them. > > > > Once a solution requires changes from multiple actors, the assessment is > > more complex. If a solution requires (as an example) both sender and > > receiver changes to work, then if it only works for small entities, then > > I don't think it has utility. Since Big sends to Small and Small sends > > to Big, any solution that affects multiple types of actors needs to work > > for both Big and Small, otherwise if a Small only solution is deployed it > > will fail when Small sends to Big. Conversely, if a Big only solution is > > deployed, it will fail when Big sends to Small. > > > > This type of assessment is why I was attracted to John Levine's fs= > > proposal. While it is inherently very complex to deploy (it definitely > > requires sender and receiver changes and for some indirect mail flows > > [those that strip signatures today]), there is nothing inherently Big or > > Small about it. I think it has other problems that may or may not be > > resolvable, but from a solution space coverage perspective it is > > attractive. > > > > For the complex solution set that covers multiple actors, I think we have > > to have a single solution to propose. If we have multiple, multiple > > actor solutions, then interoperability in this space gets much more > > complex. For single actor solutions, any solution that works and can be > > deployed helps interoperability because if any actor deploys it, the > > breakage is reduced. For multi-actor solutions, adding additional > > solutions probably reduces interoperability since in any given mail > > transaction (Originator -> Mediator -> > >> Receiver) all three have to have the same solution deployed. If the > > > > Originator and Receiver have deployed three part solution #1 and the > > Mediator has deployed three part solution #2, then both solutions fail. > > It's the same as having done nothing. > > > > In terms of what makes sense to specify in the output of the working > > group, I think we should be willing to accept as many single actor > > solutions as we discover and have energy to document. They are always > > good. None of these solutions is free of side effects and actors should > > be free to pick their poison as long as it doesn't break things > > elsewhere. > > > > For multi-entity solutions, I think we should be more constrained. I > > think > > any multi-actor solution has to work for both Big and Small actors or else > > there is no interoperability. I think at most one three actor > > modification > > solution ought to be included. I think there is possibly room for > > solutions that relate only to two actors in addition. We can't afford, > > both in terms of working group time and energy and in eventual > > interoperability to have a lot of choices in this more complex space. > > > > Note: This is not intended to say anything is in or out, just to give a > > framework for the discussion. > > > > Scott K > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 16 13:57:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8791A1BEF for ; Thu, 16 Apr 2015 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZT8yu0HC99JG for ; Thu, 16 Apr 2015 13:57:49 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (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 3674A1A1E0E for ; Thu, 16 Apr 2015 13:57:49 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so104695635pdb.2 for ; Thu, 16 Apr 2015 13:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=J1kBdjtkwwDNB1xpuVlgq6a2ozDWh0cPqozfmgGycnU=; b=ZEgCqDyku/bURdri1kcZEHxkrdiYhzTVIXWECiG9515D4eKtL8A3WLaXa7fEljbSoj x0CCaFsnrqJPQkYGs0RXksE07KiSxirhiXENfzfGHDZrYGa9hTi5562xslTurWQUfEN4 svp1uH+z5rUdxjmTaV54amGtKuFgnr+4PyJ/NLF2CajiE8HmtPHuu2eon4xw7xM6P4ox 73ogUXEo7ou1gfaFizFIMP9RM8slTcWyhW9W8pttSqhOoGq9M19bEWqjMOJZVKjHdVO1 lzaPI99ZUUyuKFDa8QYzSP9iZaEGafNNeJmETX79J0FsEjRmox8pw8BYS1a0/Vykqpbl 6/yw== X-Received: by 10.66.66.43 with SMTP id c11mr968423pat.20.1429217868881; Thu, 16 Apr 2015 13:57:48 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id jz10sm7998918pbc.48.2015.04.16.13.57.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 13:57:47 -0700 (PDT) Message-ID: <55302247.3060002@gmail.com> Date: Thu, 16 Apr 2015 13:57:43 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150410170856.730.qmail@ary.lan> <552EB0E0.1080603@isdg.net> <2135687.mun7GpbTUA@kitterma-e6430> <552F06BA.7040505@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publishing and Registration Concerns X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 20:57:51 -0000 Dear Terry, Since DMARC assertions cause compliance issues for third-party domains, and since some think customers would be unable to manage a third-party exception list needed for draft-otis-tpa-label, draft-levine-dkim-conditional, draft-kucherawy-dkim-delegate, and rfc6541, one solution would use DMARC assertions to delegate the heavy lifting to a separate organization specializing at handling third-party conflicts. That would allow all of their customers to expend little effort in their system configuration such as _dmarc TXT "v=DMARC1; p=quarantine; tpa=third-party-authority.com; This way, the most that administrator would concern themselves with is dealing with is simple TXT records from their perspective. Perhaps hotmail might even offer their zone on a fee basis. It also seems like an ideal way to ensure your customers are likely to remain happy and not leave. I would be happy to make tpa-label look more like atps, but I don't think the reasons for the additional terms were clearly understood. These terms ensure third-party messages could be differentiated from direct mailing using simple sort criteria. It would be equally wrong to suggest anything included in the dkim-conditional header would be indicating exactly what a malefactor needs to add to their message for acceptance. More on that later. Regards, Douglas Otis On 4/15/15 5:55 PM, Terry Zink wrote: > Hi, Hector, > >> For the umpteenth time, not everyone need 4000 domains. Most of the >> domains that will or may utilize it, simply don't need this scale. > I'm not sure you get the point that the others are trying to make. While this *may* scale for small domains (a big maybe), it won't scale for large domains like Hotmail, Yahoo, Google, AOL, and a lot of other large providers who are unlikely to implement it. They make up a small number of implementers but a massive number of users. If it won't work for this massive user base, then it's not worth implementing even on a small scale because for the average user (of which there are millions), the people they try to send to (Hotmail, Google, Yahoo) aren't supporting this. > > -- Terry > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos > Sent: Wednesday, April 15, 2015 5:48 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Publishing and Registration Concerns > > On 4/15/2015 4:39 PM, Scott Kitterman wrote: >> For the umpteenth time, the issue isn't managing a DNS zone. That's the easy >> part. The hard part is knowing what to put in it. > Right. I never said it was hard problem. This didn't stop the large > domain with SPF in adding INCLUDE and still have an unknown result. > >> Many companies, not even >> the really big ones, have thousands of domains. > and millions more does not. > >> Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then tell me >> it's all easy to then figure out what the right list of authorized forwarders >> should be for each one. > For the umpteenth time, not everyone need 4000 domains. Most of the > domains that will or may utilize it, simply don't need this scale. > >> P.S. I'm done on the topic of is keeping a list of forwarders a useful >> solution for the group to work on. No matter how you wrap it up, it's not. > So move on, scott. > From nobody Thu Apr 16 13:59:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2AC1A802A for ; Thu, 16 Apr 2015 13:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 jBI4b5XDKf_r for ; Thu, 16 Apr 2015 13:59:02 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 BCA721A6EF0 for ; Thu, 16 Apr 2015 13:59:00 -0700 (PDT) Received: by widdi4 with SMTP id di4so111973100wid.0 for ; Thu, 16 Apr 2015 13:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5OKBma/gryB3AUe5YBDSke57m7JAd7ZsolSMqaU83/0=; b=U0GC0gptRjv+JxLRs3LmUB1CjB+qU2ajnMNPtG5UNwFPCxyb8MKJKRuNnrQtPuXsbs 95SkcEf2tRXoGXpdxl5HKXLBXtRBIBcnJ+oMBcEOKh0JbBP3eSy4eQ3QBjLgZabjyahC tzMYOQQjxf/fN/E8TrOlnKrCJYH89Ctow+bhhd4VCk10Iutgq8WFg3Wf6HHiwkyQFr8u k9cvM+g20kR8r+tMa0+vEB1KXPSBuGJm0rCA/8LmWMqE9loZWJpIQWQj1m+RAPfe4jGy Lecy/1orLkCmLTp1eGhzXasmN+XDWRFy7fO2M8UlrYcni2MEqVO4pEhu3PBXc/mABM+2 TVSQ== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr62332912wjc.111.1429217939553; Thu, 16 Apr 2015 13:58:59 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Thu, 16 Apr 2015 13:58:59 -0700 (PDT) In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> <20150416163137.2621.qmail@ary.lan> Date: Thu, 16 Apr 2015 13:58:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7bacb11e98025c0513ddbb82 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 20:59:04 -0000 --047d7bacb11e98025c0513ddbb82 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > At least, we need to look at what non-technical costs they push onto other > parties. > > Some changes have insignificant non-techincal costs and are not > controversial, e.g., adding a List-ID header for the benefit of recipients > who know how to use it. Changes that seem similar may have quite different > costs, e.g., adding a List-ID and removing subject tags, forcing recipients > to change the way they sort and organize their incoming messages. > Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? For example, asserting that all parties should have to take on zero non-technical cost here seems like it might leave us dead in the water before we even start. I don't have a good non-zero suggestion though, because it's hard (or maybe even impossible) to be specific. -MSK --047d7bacb11e98025c0513ddbb82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine <johnl@tau= gh.com> wrote:
At least, we need to look at what= non-technical costs they push onto other parties.

Some changes have insignificant non-techincal costs and are not controversi= al, e.g., adding a List-ID header for the benefit of recipients who know ho= w to use it.=C2=A0 Changes that seem similar may have quite different costs= , e.g., adding a List-ID and removing subject tags, forcing recipients to c= hange the way they sort and organize their incoming messages.

Rolf kind of said what I'm thinking here: I agre= e that we need to look at the costs.=C2=A0 But are we willing, or not willi= ng, to accept costs that are not zero?

For example, asser= ting that all parties should have to take on zero non-technical cost here s= eems like it might leave us dead in the water before we even start.=C2=A0 I= don't have a good non-zero suggestion though, because it's hard (o= r maybe even impossible) to be specific.

-MSK
<= /div>
--047d7bacb11e98025c0513ddbb82-- From nobody Thu Apr 16 14:05:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBAD1B36E4 for ; Thu, 16 Apr 2015 14:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dcj5Dkbp7R-0 for ; Thu, 16 Apr 2015 14:05:56 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490B71B36E2 for ; Thu, 16 Apr 2015 14:05:56 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5D34FC40474 for ; Thu, 16 Apr 2015 16:05:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429218355; bh=roYfZG3+ApKNGSAbV14cWUEI7eKBhKRk6w4KaYVyrEc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iSfgyEtOO8CSY4jxs8uPcRvdPx6ps4W6rw4NtpLWB+hKg/r6xj9mbpg6FZB96aEhj 2ZD5HppR41lw77JFXSBFJPMo5HhsNmA5w9Y7ngcQAo5i1xBMz51q1ANb5wuuMO04dg DM5j5KXHtqLMhRsAjCqKQspC2YLXuelOjgifGx58= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 16 Apr 2015 17:05:55 -0400 Message-ID: <1505515.ElQdPk7U7u@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:05:58 -0000 On Thursday, April 16, 2015 01:58:59 PM Murray S. Kucherawy wrote: > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > > At least, we need to look at what non-technical costs they push onto other > > parties. > > > > Some changes have insignificant non-techincal costs and are not > > controversial, e.g., adding a List-ID header for the benefit of recipients > > who know how to use it. Changes that seem similar may have quite > > different > > costs, e.g., adding a List-ID and removing subject tags, forcing > > recipients > > to change the way they sort and organize their incoming messages. > > Rolf kind of said what I'm thinking here: I agree that we need to look at > the costs. But are we willing, or not willing, to accept costs that are > not zero? > > For example, asserting that all parties should have to take on zero > non-technical cost here seems like it might leave us dead in the water > before we even start. I don't have a good non-zero suggestion though, > because it's hard (or maybe even impossible) to be specific. I think there's a wide enough variety of participants in the working group that we'll know if it's 'too much', whatever that turns out to be. Scott K From nobody Thu Apr 16 14:20:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0531A1B3713 for ; Thu, 16 Apr 2015 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 JshMnHyeJ1gt for ; Thu, 16 Apr 2015 14:20:10 -0700 (PDT) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 089B41B3712 for ; Thu, 16 Apr 2015 14:20:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2011; t=1429219198; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Kxc4U+i2pKPUM2tvlkjZi0IX02M=; b=I2wT+trBNc8HYdEbfe4V Fmn6hQ4qhjSXDM98NVP4VV0au6nu8rGkT7MjpPZ0eAVmWxKEjVshO+O5TTcESh8u 0qdJudNfae5eF66VPe58oH5KAHFj7+y7X8cMLZhvL/DyFIAs6X41fspCgPFFPDpT 55kFWIGi3RlElzciTJSkeTQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 17:19:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2929211454.11543.4620; Thu, 16 Apr 2015 17:19:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2011; t=1429218964; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UIrIFgC +Fa3rokKrarrcY5JcmlnU2zPEtQ8nGOfU0CM=; b=Mc/w4T95V8XXAGcOcURgEkZ Iwh0BbqduGKgIEx9e8+cvbjXiJ3S+UrI77l2yTSeHTkukVqZKQD4KWpS6BUSfQXQ BNxCDt9AVl0kFwRjlY29WES4Fpg15/yekDOdJ12tKHzjeuRhybJW4OPteZfUhoF1 emYF4N5dQWXqKZ2YW4IU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 17:16:04 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1521500285.9.8972; Thu, 16 Apr 2015 17:16:03 -0400 Message-ID: <55302781.20205@isdg.net> Date: Thu, 16 Apr 2015 17:20:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <20150416163137.2621.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:20:13 -0000 On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote: > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > >> At least, we need to look at what non-technical costs they push onto other >> parties. >> >> Some changes have insignificant non-techincal costs and are not >> controversial, e.g., adding a List-ID header for the benefit of recipients >> who know how to use it. Changes that seem similar may have quite different >> costs, e.g., adding a List-ID and removing subject tags, forcing recipients >> to change the way they sort and organize their incoming messages. >> > > Rolf kind of said what I'm thinking here: I agree that we need to look at > the costs. But are we willing, or not willing, to accept costs that are > not zero? > > For example, asserting that all parties should have to take on zero > non-technical cost here seems like it might leave us dead in the water > before we even start. I don't have a good non-zero suggestion though, > because it's hard (or maybe even impossible) to be specific. Murray, we don't need to go that far. We are talking about a IETF protocol engine that has two basic flows: ADID == SDID conditions ADID != SDID conditions We just need to come up with the models for this and let the market decide. The problem is that ATPS was short-changed as an extension to ADSP which was being abandoned. The APIs were ready for this. Since DMARC replaces ADSP, you need to update RFC6541 to have it piggy back off DMARC. Since DMARC is now being adopted to replace ADSP in the industry, you now need to make it market ready for the 3rd party check allowing them to learn how to scale it too. If you want to do this IN-BAND stuff for those systems that can not do DMARC+ATPS, that would be great and it would cover a wider market, including the biggest one who can afford the additional changes to all this. They can also afford to do both ATPS and IN-BAND as well if they choose to so. -- HLS From nobody Thu Apr 16 14:21:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5851B370E for ; Thu, 16 Apr 2015 14:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 7krGE-iqVXtQ for ; Thu, 16 Apr 2015 14:21:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB44A1B370F for ; Thu, 16 Apr 2015 14:21:01 -0700 (PDT) Received: (qmail 73946 invoked from network); 16 Apr 2015 21:21:00 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Apr 2015 21:21:00 -0000 Date: 16 Apr 2015 21:20:38 -0000 Message-ID: <20150416212038.929.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:21:03 -0000 >Rolf kind of said what I'm thinking here: I agree that we need to look at >the costs. But are we willing, or not willing, to accept costs that are >not zero? Sure, everything has some cost. Something I should have made clearer is the difference between the costs of changes one imposes on one's self and those forced on third parties, particularly on third parties that didn't volunteer to accept them. R's, John From nobody Thu Apr 16 14:26:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069081A8AA4 for ; Thu, 16 Apr 2015 14:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 6BNX21HDRVs4 for ; Thu, 16 Apr 2015 14:26:06 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8251A8AA0 for ; Thu, 16 Apr 2015 14:26:06 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0FCE2C4001A for ; Thu, 16 Apr 2015 16:26:05 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429219565; bh=pfkSi8A9TW2+o82Cu1LX49iS+TEHic5TSjUg2Cjw89s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VtzbKAA/uuzH44OTtCueiLYa2uyiPeQjafH+26Ol3IAB0YwWasDkR232oUjW/fi/f Eeesvpg/RZ7uTpbXMqlLVDyCWn+9hzVrXjg8FC7yi8p1SL/YZzyiY1zNfO7Zo7fv8W lROPwtd4C9RwYmEmUVqbf3h9yWLtbesJs4PsqsA8= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 16 Apr 2015 17:26:05 -0400 Message-ID: <2296749.axXITXPEaU@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <55302781.20205@isdg.net> References: <5719430.pnL5xihlrb@kitterma-e6430> <55302781.20205@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:26:07 -0000 On Thursday, April 16, 2015 05:20:01 PM Hector Santos wrote: > On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote: > > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > >> At least, we need to look at what non-technical costs they push onto > >> other > >> parties. > >> > >> Some changes have insignificant non-techincal costs and are not > >> controversial, e.g., adding a List-ID header for the benefit of > >> recipients > >> who know how to use it. Changes that seem similar may have quite > >> different > >> costs, e.g., adding a List-ID and removing subject tags, forcing > >> recipients > >> to change the way they sort and organize their incoming messages. > > > > Rolf kind of said what I'm thinking here: I agree that we need to look at > > the costs. But are we willing, or not willing, to accept costs that are > > not zero? > > > > For example, asserting that all parties should have to take on zero > > non-technical cost here seems like it might leave us dead in the water > > before we even start. I don't have a good non-zero suggestion though, > > because it's hard (or maybe even impossible) to be specific. > > Murray, we don't need to go that far. > > We are talking about a IETF protocol engine that has two basic flows: > > ADID == SDID conditions > ADID != SDID conditions > > We just need to come up with the models for this and let the market > decide. > > The problem is that ATPS was short-changed as an extension to ADSP > which was being abandoned. > > The APIs were ready for this. Since DMARC replaces ADSP, you need to > update RFC6541 to have it piggy back off DMARC. Since DMARC is now > being adopted to replace ADSP in the industry, you now need to make it > market ready for the 3rd party check allowing them to learn how to > scale it too. > > If you want to do this IN-BAND stuff for those systems that can not do > DMARC+ATPS, that would be great and it would cover a wider market, > including the biggest one who can afford the additional changes to all > this. They can also afford to do both ATPS and IN-BAND as well if > they choose to so. I don't think market share in the abstract is useful for this discussion. Per my utility analysis, the question is not percent of market (however that is defined), but breadth of market scope being sufficient to enable interoperability when it's needed. I would still appreciate solution independent discussion of how to do the utility analysis or I fear we'll continue to just argue past each other. Scott K From nobody Thu Apr 16 14:57:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7872B1B3781 for ; Thu, 16 Apr 2015 14:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7bURaP20eL_k for ; Thu, 16 Apr 2015 14:57:14 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 203DB1B377F for ; Thu, 16 Apr 2015 14:57:14 -0700 (PDT) Received: by qgej70 with SMTP id j70so13090125qge.2 for ; Thu, 16 Apr 2015 14:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XCo781s1+l8WvkFxuG6uKi0V0sEuIaW5q48js03u7kk=; b=0jEHm+KsHKkw5TNuM3sRAfW8nekrxis3DHxcBSkcBJrl4RAy65qb2wc2hysEJtaFCr mSFcDnYWuJSLIBQR8sOO9CXBhhlPXBzgJgQ+j3+GfCa31+9oEL/E/xK0N0whqQoP9shk D3S+gwncyyYwJqWa7jJbBaOSqkHgLN8CsOjE1GF33ZFybibeBw0IvooMyOdweJFe+6g7 0bz9grpPNBIvyzNeiHoqRVOviAEiMjMafF4n5PMGJ9c5TIdVHqC63rAUyJgQQjPugx/3 yafKFCjNbTS5XzkKwwyIJdEVJijX32DQyXj+8PJZuSr83mGPmb4f4ClqxpBxFbqaD2Fp 5jpA== X-Received: by 10.140.150.78 with SMTP id 75mr43081039qhw.88.1429221433399; Thu, 16 Apr 2015 14:57:13 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id p73sm2218011qha.20.2015.04.16.14.57.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 14:57:11 -0700 (PDT) Message-ID: <55303036.8070009@gmail.com> Date: Thu, 16 Apr 2015 14:57:10 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <55302781.20205@isdg.net> <2296749.axXITXPEaU@kitterma-e6430> In-Reply-To: <2296749.axXITXPEaU@kitterma-e6430> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:57:15 -0000 On 4/16/15 2:26 PM, Scott Kitterman wrote: > I don't think market share in the abstract is useful for > this discussion. Per my utility analysis, the question is > not percent of market (however that is defined), but > breadth of market scope being sufficient to enable > interoperability when it's needed. I would still > appreciate solution independent discussion of how to do > the utility analysis or I fear we'll continue to just > argue past each other. Dear Scott, DMARC is leveraging a public-suffix list to reduce overhead. This approach will cause problems if it leaves a gap between the domains provided by a registrar and those listed as part of the public suffix. With the massive amounts of DMARC feedback being generated, perhaps there should be a way to consolidate these domains into some type of list. Of course, I'll suggest a hashed label approach. Can anyone envision some type of community or specialized effort at consolidating this category of the domain space? Regards, Douglas Otis From nobody Thu Apr 16 15:21:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD91B37BA for ; Thu, 16 Apr 2015 15:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 koVeG5Mbhj1r for ; Thu, 16 Apr 2015 15:21:39 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id BE31B1B37B9 for ; Thu, 16 Apr 2015 15:21:38 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lSZlj1CcWz1L8nh; Fri, 17 Apr 2015 00:21:37 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lSZlh70qqz5Mgff; Fri, 17 Apr 2015 00:21:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id B84491234E8; Fri, 17 Apr 2015 00:21:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iWF8yIE8V1rB; Fri, 17 Apr 2015 00:21:34 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id E52F21234A1; Fri, 17 Apr 2015 00:21:33 +0200 (CEST) Message-ID: <553035ED.7040708@sonnection.nl> Date: Fri, 17 Apr 2015 00:21:33 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20150416212038.929.qmail@ary.lan> In-Reply-To: <20150416212038.929.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1429222897; bh=JqC2RvfSxqOAMI7SuKytHz9c4iJyaaTfc6/AsI101I0=; h=Message-ID:Date:From:To:Subject:From; b=KBck4VzohjiwlZXtekgliJa6uQ2XgBIdLQwUGenI8ovzphkxhE7eU1TMR4TMAJJIf m4EkwTK4RLx5GIsh57gJd35I1FQ3QV4gmETSWrhIJf9JOUvDda9NXZYVc/d8Bs09co yldhmufWcVnzrz5eiCUdLXzLCRNexICAKlhS6mPw= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lSZlj1CcWz1L8nh Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 22:21:41 -0000 On 04/16/2015 11:20 PM, John Levine wrote: >> Rolf kind of said what I'm thinking here: I agree that we need to look at >> the costs. But are we willing, or not willing, to accept costs that are >> not zero? > Sure, everything has some cost. Something I should have made clearer > is the difference between the costs of changes one imposes on one's > self and those forced on third parties, particularly on third parties > that didn't volunteer to accept them. yes, but the problem with cost imposed on third parties is that it is valued different by the one who imposes it on someone else and the one, on which is it imposed. And that is due to the fact, like you said earlier today: > The whole reason > we're having this discussion is that a few large originators had > nontechnical costs that they decided to push off onto other people. Now I think Scott is right that we need to make a step back and his analysis might help us to know on which solutions we'd best spend most of our time. However, having said that, I'm afraid that we're biased by our discussions around the 'DMARC/Mailing List problem'. Let's not forget the other use cases of draft-ietf-dmarc-interoperability. I believe a number of the Mediators, described in par. 3.2 of https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot easily be changed. To give an example: recently when I was working for company A, I forwarded an invitation I got from company B to one of my addresses at ESP C. I just used the Exchange/Outlook forward function at company A and discovered that the mail client I used at ESP C showed the address of company B, no the address I have with company A. Company A is using Exchange/Outlook 2010 and has no plans to upgrade for the next couple of years. Should Microsoft update Exchange to support some mediator 'change' for DMARC, then this probably won't be 'retrofitted' into Exchange 2010. So it may take many years before I can use a version that supports DMARC 'mediation'. Maybe we should assign a higher score/priority to solutions that only cover Originator and Receiver, as (in general) the Originator and Receiver are primary stakeholders re. the proper transfer and delivery of the message. /rolf From nobody Thu Apr 16 15:42:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483A81B381A for ; Thu, 16 Apr 2015 15:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ngI5ip98cXIZ for ; Thu, 16 Apr 2015 15:42:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA951B3819 for ; Thu, 16 Apr 2015 15:42:21 -0700 (PDT) Received: from [IPv6:2600:1003:b12d:544d:6466:5368:2c0c:ac8f] (unknown [IPv6:2600:1003:b12d:544d:6466:5368:2c0c:ac8f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8442AC40243; Thu, 16 Apr 2015 17:42:20 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429224140; bh=heI1Sh4+ryO3Kdo7vyTT2ldd6RFbDnSVzD1Ef2yaweQ=; h=In-Reply-To:References:Subject:From:Date:To:From; b=uG3jkWe8HIkqqPSUJX1wlryWhecVqkBLUDU0YtCfteQGprmZQPawhdmiDh4uh0dDx rvhZj1jOk7xQDN02y3Ilxo52vR94ICvMQhofutqkW+CSuzmiqedeiBR+JB1ycFCVw8 KW7+6jpEkVXOnFkzRbk7dzDid42xB2/Trddg3rqM= User-Agent: K-9 Mail for Android In-Reply-To: <55303036.8070009@gmail.com> References: <5719430.pnL5xihlrb@kitterma-e6430> <55302781.20205@isdg.net> <2296749.axXITXPEaU@kitterma-e6430> <55303036.8070009@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 16 Apr 2015 18:40:59 -0400 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 22:42:23 -0000 On April 16, 2015 5:57:10 PM EDT, Douglas Otis wrote: > > >On 4/16/15 2:26 PM, Scott Kitterman wrote: >> I don't think market share in the abstract is useful for >> this discussion. Per my utility analysis, the question is >> not percent of market (however that is defined), but >> breadth of market scope being sufficient to enable >> interoperability when it's needed. I would still >> appreciate solution independent discussion of how to do >> the utility analysis or I fear we'll continue to just >> argue past each other. >Dear Scott, > >DMARC is leveraging a public-suffix list to reduce >overhead. This approach will cause problems if it leaves a >gap between the domains provided by a registrar and those >listed as part of the public suffix. With the massive >amounts of DMARC feedback being generated, perhaps there >should be a way to consolidate these domains into some type >of list. Of course, I'll suggest a hashed label approach. >Can anyone envision some type of community or specialized >effort at consolidating this category of the domain space? I think it would be better to await the results of the recently chartered dbound working group. Whatever DMARC does should, in the end, align to that, so it would be better not to have this group expend effort in that area for now. Scott K From nobody Thu Apr 16 16:06:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625231A1A7D for ; Thu, 16 Apr 2015 16:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 aqstapNplnj5 for ; Thu, 16 Apr 2015 16:06:08 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D43781A1AFB for ; Thu, 16 Apr 2015 16:06:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=997; t=1429225563; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gix9FGkagRBX2ZGtzE8rS/hdn1k=; b=V9ZWwfWV9T0NpU1nZkO7 QYX/OFabBvumbCpfam1MT49MpC2g6cf4D1xk29adoMGalRDzA7xjWXfdvKjYwsYu nSEp6mjt4bc3CY5zsSxRPoYbtRkDUdKsXMBGPIkYlpnSqT8LFkSSquaM46kEy2IS LIjzh1YpKnm/pY0QYXykHE8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 19:06:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2935576591.11543.3428; Thu, 16 Apr 2015 19:06:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=997; t=1429225325; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+fgzrLe Zi2uYBqRt5ZWwQm0oKPAELnIouFrTAcD6cAs=; b=JDE2fWe41N6AEYfvApDcJ4h B5Ksei2WDLEAFiXn5IWK2vdorzbgAnYrwncppjOHjar6p1ckQJ6LZqiEw0vTGcod W/wg9RUm40aAqdY/Ejx11v1LSoPUyjKCXKgU9xGfjwgagJZ3lMC91m8nDsFpG4qy EwuA7FMsH2RcreKjDbIo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 16 Apr 2015 19:02:05 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1527860738.9.3808; Thu, 16 Apr 2015 19:02:04 -0400 Message-ID: <5530405A.10605@isdg.net> Date: Thu, 16 Apr 2015 19:06:02 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150416212038.929.qmail@ary.lan> <553035ED.7040708@sonnection.nl> In-Reply-To: <553035ED.7040708@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 23:06:10 -0000 On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote: > Now I think Scott is right that we need to make a step back and his > analysis might help us to know on which solutions we'd best spend most > of our time. However, having said that, I'm afraid that we're biased > by our discussions around the 'DMARC/Mailing List problem'. Let's not > forget the other use cases of draft-ietf-dmarc-interoperability. +1 Extremely bias. Lets keep in mind that there are two minimum receivers generally with a MLM transaction that also need to be part of the cost and impact analysis: MDA1 -- receiver and resigner MDA2 -- final user(s) receiver(s). Another solution (partial) is for MDA1 honor policy and not allow resigning to take place. The one that is talked about the most are the MDA2 end user receivers rejecting messages. We will want to maximize the MDA2 consistent and persistent result factor since there could be many different implementations at the MDA2 nodes. -- HLS From nobody Thu Apr 16 17:04:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDF31A038C for ; Thu, 16 Apr 2015 17:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 KZHrgPENnGDj for ; Thu, 16 Apr 2015 17:04:04 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630D81A005B for ; Thu, 16 Apr 2015 17:04:04 -0700 (PDT) Received: (qmail 97525 invoked from network); 17 Apr 2015 00:04:02 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Apr 2015 00:04:02 -0000 Date: 17 Apr 2015 00:03:40 -0000 Message-ID: <20150417000340.1305.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <553035ED.7040708@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: R.E.Sonneveld@sonnection.nl Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 00:04:05 -0000 >yes, but the problem with cost imposed on third parties is that it is >valued different by the one who imposes it on someone else and the one, >on which is it imposed. Well, sure. If I can force you to solve my problem, as far as I'm concerned that's a free solution. I hope we agree we want to stay away from that dark corner. >I believe a number of the Mediators, described in par. 3.2 of >https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot >easily be changed. That seems reasonable. We can have a discussion about whether things like my double signer trick, which might be implemented in a wrapper or a postprocessor qualify as not changing the mediator. R's, John From nobody Thu Apr 16 17:05:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC65D1A03A8 for ; Thu, 16 Apr 2015 17:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 cNPj-hJL_KM6 for ; Thu, 16 Apr 2015 17:05:29 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 6574E1A03A2 for ; Thu, 16 Apr 2015 17:05:29 -0700 (PDT) Received: by qgdy78 with SMTP id y78so14280397qgd.0 for ; Thu, 16 Apr 2015 17:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=eWAfMm8KE1n1gNwLcfBJsbrleaFFr3ppEqg+47s0FNE=; b=uava96z2Hw4R5PS+rt0bVvWP5I75uNx3xLwQJ9bRTLCbVqwPsmKZm8hBxYO+H076n+ dtc2G8dN0sl4p4z7ZlEIjFA5R1zSEvGafzzLoacYCwtt2CvI+Aomt7GfYng/NVLajcQk BrDfeeFclPnQun6JEs4EsnreslytHMxYLYqFB6MuSE6xrqAUaLteRpc3aP6c4f6eOYOV clnIzw4+u4gMzbnlhBvSvh3J5VG5j6IKbw3o0UBpzrCFWb9xfMQHHwc8fnc+d/LxzyZX KVuIfPaB96V1Ie06J7/ML/7PrjizqRZ9t8EI/Ay7yCEJOVg4peGqlw4A1UVOKJlq8Edc Fcbg== X-Received: by 10.229.45.5 with SMTP id c5mr414166qcf.17.1429229128694; Thu, 16 Apr 2015 17:05:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id f33sm6789923qkh.23.2015.04.16.17.05.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 17:05:27 -0700 (PDT) Message-ID: <55304E45.8000203@gmail.com> Date: Thu, 16 Apr 2015 17:05:25 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <55302781.20205@isdg.net> <2296749.axXITXPEaU@kitterma-e6430> <55303036.8070009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 00:05:31 -0000 On 4/16/15 3:40 PM, Scott Kitterman wrote: > I think it would be better to await the results of the recently chartered dbound working group. Whatever DMARC does should, in the end, align to that, so it would be better not to have this group expend effort in that area for now. Dear Scott, This misses the point. There is precedence for DMARC using lists composed without an official basis yet essential to its operation. Why wait for dbound aimed at offering completely different results? As this WG considers special handling for domains that operate some type of third-party service, these same considerations become critical elements in achieving a network effect toward practical solutions safely restoring the role of Sender wholly ignored by DMARC. Achieving a network effect requires consensus on how to effectively deal with problems DMARC creates when handling third-party services and dealing with misleading assertions made in DMARC policy. Consensus should avoid endorsing modes of operation that detract from the social and civic benefits derived from an open exchange of email. The WG should strive to ensure an email notification scheme will not cripple other services in use for decades. Finding a balance likely means algorithmically categorizing either third-party domains or domains making misleading assertions. Regards, Douglas Otis From nobody Thu Apr 16 17:16:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0E1A1A5D for ; Thu, 16 Apr 2015 17:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1MVYwdzTtm1n for ; Thu, 16 Apr 2015 17:16:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F481A038D for ; Thu, 16 Apr 2015 17:16:24 -0700 (PDT) Received: from [IPv6:2600:1003:b12d:544d:6466:5368:2c0c:ac8f] (unknown [IPv6:2600:1003:b12d:544d:6466:5368:2c0c:ac8f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5F919C400C2; Thu, 16 Apr 2015 19:16:23 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429229783; bh=K6nz7pzrIOXRILppKlgpG9+O4HZ2WwSb0PuJ0WqsYnI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=es4+wjdUGFTyn0Vc7oltFCsXfHA3x7oNdHlC7amgYoOA+8pPzSlDet1U7YQ49i7u/ bESOd2nzzxr7IgdVtD/EEw2d4usrnudoHTC2R8YFFpiI/yuzWSxm9A2a/0mxG6MDvY 07d6Vmhi9p9icFBY8QQUj7jEaGn6B96i8Pr2xaAw= User-Agent: K-9 Mail for Android In-Reply-To: <5530405A.10605@isdg.net> References: <20150416212038.929.qmail@ary.lan> <553035ED.7040708@sonnection.nl> <5530405A.10605@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 16 Apr 2015 20:16:11 -0400 To: dmarc@ietf.org Message-ID: <47F53DFE-C81C-4653-8AA6-E32B0A784110@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 00:16:53 -0000 On April 16, 2015 7:06:02 PM EDT, Hector Santos wrote: >On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote: > >> Now I think Scott is right that we need to make a step back and his >> analysis might help us to know on which solutions we'd best spend >most >> of our time. However, having said that, I'm afraid that we're biased >> by our discussions around the 'DMARC/Mailing List problem'. Let's not >> forget the other use cases of draft-ietf-dmarc-interoperability. > >+1 Extremely bias. > >Lets keep in mind that there are two minimum receivers generally with >a MLM transaction that also need to be part of the cost and impact >analysis: > > MDA1 -- receiver and resigner > MDA2 -- final user(s) receiver(s). > >Another solution (partial) is for MDA1 honor policy and not allow >resigning to take place. The one that is talked about the most are >the MDA2 end user receivers rejecting messages. We will want to >maximize the MDA2 consistent and persistent result factor since there >could be many different implementations at the MDA2 nodes. It's a bit more complex than just not resigning (actually resigning shouldn't hurt). What MDA/MTA1 needs to do is avoid any transformations that would invalidate the originator's DKIM signature. For some, that's a reasonable solution, but for others it's not because they aren't willing to give up the traditional mailing list transformations, i.e. there is a side effect that leads the mediator to consider the approach to costly (costs aren't just money). Although we've been focused on mailing lists in discussing the possible solution space, the framework I laid out is suitable for any mediated message transaction. I think the solution space for third-party originators is likely disjoint from the solution space for mediated transactions, so I haven't worried about it too much. I'd still rather focus on an assessment framework before we go zooming into solutions again. I don't think we're getting very far without it. Scott K From nobody Thu Apr 16 17:21:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE1D1A1A68 for ; Thu, 16 Apr 2015 17:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KNVuxdN9Ihg5 for ; Thu, 16 Apr 2015 17:21:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAFB1A1A65 for ; Thu, 16 Apr 2015 17:21:48 -0700 (PDT) Received: from [IPv6:2600:1003:b12d:544d:6466:5368:2c0c:ac8f] (unknown [IPv6:2600:1003:b12d:544d:6466:5368:2c0c:ac8f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 55FF2C400C2; Thu, 16 Apr 2015 19:21:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429230107; bh=m4Zalq1u5E9C7OhKu7xS/fNAG2BU2D9iZsvuhe88Sp4=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ptsLObuzdIeV0nWmWdGF3Wf3jATBUiCjsl99DNFqQphVPdaGlhgGuYUPfKTSOSv0O 5NaupUtMf8xg95Vp6Hj4Lj6ihSJANgfbfhoV5vHknBNgs8X54UAuhZUyMs1LBLoVjX JO3fma99nsCYDKC4IHoAn0SyfGUIRb1vjA7K26e0= User-Agent: K-9 Mail for Android In-Reply-To: <55304E45.8000203@gmail.com> References: <5719430.pnL5xihlrb@kitterma-e6430> <55302781.20205@isdg.net> <2296749.axXITXPEaU@kitterma-e6430> <55303036.8070009@gmail.com> <55304E45.8000203@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 16 Apr 2015 20:21:36 -0400 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 00:21:49 -0000 On April 16, 2015 8:05:25 PM EDT, Douglas Otis wrote: > > >On 4/16/15 3:40 PM, Scott Kitterman wrote: >> I think it would be better to await the results of the recently >chartered dbound working group. Whatever DMARC does should, in the end, >align to that, so it would be better not to have this group expend >effort in that area for now. >Dear Scott, > >This misses the point. There is precedence for DMARC using >lists composed without an official basis yet essential to >its operation. Why wait for dbound aimed at offering >completely different results? As this WG considers special >handling for domains that operate some type of third-party >service, these same considerations become critical elements >in achieving a network effect toward practical solutions >safely restoring the role of Sender wholly ignored by DMARC. > >Achieving a network effect requires consensus on how to >effectively deal with problems DMARC creates when handling >third-party services and dealing with misleading assertions >made in DMARC policy. Consensus should avoid endorsing >modes of operation that detract from the social and civic >benefits derived from an open exchange of email. The WG >should strive to ensure an email notification scheme will >not cripple other services in use for decades. Finding a >balance likely means algorithmically categorizing either >third-party domains or domains making misleading assertions. We're going to have to use whatever PSL replacement dbound produces. Let's not have to change twice. I agree that harmonizing DMARC and various third-party originator's operations will be complicated. I think the mediator case is more tractable, so I have focused there for now. Scott K From nobody Fri Apr 17 10:30:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047C91A8A4D for ; Fri, 17 Apr 2015 10:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.438 X-Spam-Level: X-Spam-Status: No, score=-98.438 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 pEukaTudqy6J for ; Fri, 17 Apr 2015 10:30:00 -0700 (PDT) Received: from winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B0B1D1A902D for ; Fri, 17 Apr 2015 10:29:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4977; t=1429291785; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7JKrQQekZavs7zp9DXswDSc/MZs=; b=oz4bktagAxhcPNTA+qKy It+JIk1MmzJQye1XN1FbTI6t/Qtwvfy1Ib2chIMBJim07SiOiKn0XXhkNjnIiutK BcRrVLidh6SRPMsF782lLWTbxv4lF+cHepk4ZuweokfRUifOgyVLicRZjh8FBlde qyeNlbr6xJ8wtL4E8IJsAwc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 17 Apr 2015 13:29:45 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3001797378.13376.3540; Fri, 17 Apr 2015 13:29:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4977; t=1429291549; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ajmLPgf +0BELbnw1vQIAYLTFqv8KaU8GG5Lo07RrgnI=; b=YJdcCmh1TqPbvhiLc6DhLlq go8FRQyIuj5CJX8V6vuU/aBm1LehzOPnc3/0NYr5F7ecmtC6N56+482OnhKZf6m/ FOUJOVdWbax/USAK8NCLYEnGmMnkzD4+pgtIACKnsNL+nXMMdw2pc5ohKxnOOmCZ Fc9BScq9axtLf3LpEx3U= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 17 Apr 2015 13:25:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1594084457.9.6548; Fri, 17 Apr 2015 13:25:48 -0400 Message-ID: <5531430C.9050407@isdg.net> Date: Fri, 17 Apr 2015 13:29:48 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150416212038.929.qmail@ary.lan> <553035ED.7040708@sonnection.nl> <5530405A.10605@isdg.net> <47F53DFE-C81C-4653-8AA6-E32B0A784110@kitterman.com> In-Reply-To: <47F53DFE-C81C-4653-8AA6-E32B0A784110@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 17:30:03 -0000 On 4/16/2015 8:16 PM, Scott Kitterman wrote: >> +1 Extremely bias. >> >> Lets keep in mind that there are two minimum receivers generally with >> a MLM transaction that also need to be part of the cost and impact >> analysis: >> >> MDA1 -- receiver and resigner >> MDA2 -- final user(s) receiver(s). >> >> Another solution (partial) is for MDA1 honor policy and not allow >> resigning to take place. The one that is talked about the most are >> the MDA2 end user receivers rejecting messages. We will want to >> maximize the MDA2 consistent and persistent result factor since there >> could be many different implementations at the MDA2 nodes. > > It's a bit more complex than just not resigning (actually resigning shouldn't hurt). What I meant about actually, is for the MDA1 to respect the restrictive policy and reject the message (list submission, subscription attempts, etc) and use a reply code/response to explain why. > What MDA/MTA1 needs to do is avoid any transformations that would invalidate the originator's DKIM signature. Thats optional. Again Domain Policy based: Policy is relaxed, the MLM may resign, including stripping. Policy is strict, the MLM should block the subscription/submission. Again, as long as the policy also give options for the 3rd party, it can satisfy all boundary conditions. See below. > For some, that's a reasonable solution, but for others it's not because they aren't willing to give up the traditional mailing list transformations, i.e. there is a side effect that leads the mediator to consider the approach to costly (costs aren't just money). > Scott, when it comes to products, you will have all sides and the good way to address is to make it optional. Everyone is happy. Sure, its more work, but thats the life of a product developer. So yes, we need to separate all the subjective, possible Administrator/Operator options, local policy related stuff and extract the basic protocol engine stuff, the state machine. If you control the access points, then much of this is resolved. See below. > I'd still rather focus on an assessment framework before we go zooming into solutions again. I don't think we're getting very far without it. > We went thru a threat analysis (RFC4686) and functional requirements (RFC5016) RFC productions and have the basic ideas and problem points well understood. At the end of the day, no matter what, the receiver will have a fixed set of boundary conditions regarding what the ADID and SDID will look like. There are nine basic combinations of signatures when you assign to each NEVER, ALWAYS, OPTIONAL expectations: 1st party: NEVER, ALWAYS, OPTIONAL 3rd party: NEVER, ALWAYS, OPTIONAL So your protocol engine needs to be able to deal with each combination of possible policy. Some will fold providing a smaller set of conditions. The following is an example diagram illustrating this: +-----------+ | PAYLOAD | +-----------+ | v +----------------+ | | +------------+ | DKIM |--------------------------->| CONTINUE | | Signature | UNSIGNED: OPTIONAL (1) +------------+ | Authorization | | Protocol | | | +------------+ | |--------------------------->| | | | SIGNED: EXPIRED (2) | | | |--------------------------->| | | | NO MAIL EXPECTED (3) | FAILURE/ | | |--------------------------->| CLASSIFY | | | UNSIGNED: REQUIRED (4) | | | |--------------------------->| | | | SIGNED: NOT EXPECTED (5) | | | |--------------------------->| | | | 3P SIGNED: NOT ALLOWED (6) | | +----------------+ +------------+ | | SIGNED MESSAGE | v +------------+ +--------------+ | CONTINUE/ | | |--------------------------->| CLASSIFY | | | INVALID SIGNATURE +------------+ | DKIM | | SIGNATURE | | VERIFICATION | +------------+ | (7) |--------------------------->| PASS | | | VALID SIGNATURE +------------+ +--------------+ No matter what system you have, they all have be persistent and consistent on what is expected for each condition. That is not a mandate (you have local policy), but it tells you what are the MUSTs, SHOULDs and MAYs. Overall, you are looking for the failure points. (1) Unsigned mail arrives and the policy says its optional. Indeterminate condition, punt, continue. (2) Signed mail, but it expired. Negative classification. (3) No mail is expected for this domain, Negative classification. (4) Unsigned mail arrives and the policy says its required. Negative classification. (5) The main is signed, but it wasn't expected. Negative classification. (6) The mail is signed by 3rd party and policy doesn't allow that. Negative classification. While some of the conditions can be folded, we are missing #6 which allows for checking for 3rd party signature authorization. But it can even be just that you don't expect it, hence a condition that allows for strong failure detection. -- HLS From nobody Tue Apr 21 16:10:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73961B2E1E for ; Tue, 21 Apr 2015 16:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 GfB-1t7IkVF8 for ; Tue, 21 Apr 2015 16:10:17 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 437991B2E16 for ; Tue, 21 Apr 2015 16:10:17 -0700 (PDT) Received: by paboj16 with SMTP id oj16so254765660pab.0 for ; Tue, 21 Apr 2015 16:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=2ESsdXvB2SneCmyQKzVUQNUte1rhB5CklsVuawsOuec=; b=gFHChQyMrtZ1cWluzdiC9mSZOfZW4xUuehOAz2FXklgCW/pkVpo2YFOlOy7yCLuhNu 3Wxo2gonqYwbru2mouVPVM9z5REnS1EDh65Vh1EWLHY+AHC5g22k3E7AcmZOLQqLCyF9 vLmBVZMoUeORG1A7SP9HpBIDb8OVJbQv+rcRmTI2YDFVLNstMs/9ANZmIjx/sKulpt5Z VZSm/DAlPowcNQUMeujhA5T8F2bOhgSOVm2Zdv2y1noAw1UJSSZ6Qy9BTe89JHEbh9Bb EqEfxGpZrlMGLirYmszusX+XkXSkjE0O3Zg5KuyW4lC96zd4RQkkLh0RfHGcwdhYssLQ nQXg== X-Received: by 10.66.62.201 with SMTP id a9mr41566898pas.101.1429657817010; Tue, 21 Apr 2015 16:10:17 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ia3sm3037926pbc.31.2015.04.21.16.10.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 16:10:16 -0700 (PDT) Message-ID: <5536D8D6.7080305@gmail.com> Date: Tue, 21 Apr 2015 16:10:14 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc ietf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 23:10:18 -0000 Dear WG, A draft has been posted offering two alternatives not requiring cooperation of disruptive ESPs. Basic unilateral escape methods include use of a From replacement header IM-From:. This header can include the tag normally added to the Subject line as the display name in the Group syntax. It also includes a placeholder for resource connection used in a "live" discussions, hence the use of IM. This header is free to carry the author role since it will not be excluded by DMARC policy. The other unilateral mode is to defined a DMARC fallback policy 'p' for public user accounts. This mode permits acceptance based on the Sender header field alignment with assumed MUA displaying the identity sourcing the message. It also attempts to remove concerns related to adoption of TPA-Label from the perspective of large providers by allowing DMARC policy to indicate a consolidated tpa-label zone rather than being directly accessed from the customer's zone. This avoids use of DNAME or zone delegations. While TPA-Label may appear to contain too much information, all of it is optional. The goal behind providing a structure for additional third-party information is to allow anticipated limitations be imposed on the scope of authorization granted. This scope also selectively permits other authentication methods be accepted beyond just DKIM or SPF. It is able to indicate the message must be DKIM signed AND must contain a specific LIST-ID header, for example. This ensures recipients in this domain can depend on safer sorting of disparate messages sources from the same domain. http://tools.ietf.org/html/draft-otis-dmarc-escape-00 Regards, Douglas Otis From nobody Tue Apr 21 16:20:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4381B2E62 for ; Tue, 21 Apr 2015 16:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 r8e21n-HP-MG for ; Tue, 21 Apr 2015 16:20:23 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7501B2E55 for ; Tue, 21 Apr 2015 16:20:23 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.160.4; Tue, 21 Apr 2015 23:20:02 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) with mapi id 15.01.0160.000; Tue, 21 Apr 2015 23:20:02 +0000 From: Terry Zink To: Douglas Otis , dmarc ietf Thread-Topic: [dmarc-ietf] Dmarc-escape draft available Thread-Index: AQHQfIhiDokkbZdMr06f8XE7BXT8aZ1YGdwA Date: Tue, 21 Apr 2015 23:20:02 +0000 Message-ID: References: <5536D8D6.7080305@gmail.com> In-Reply-To: <5536D8D6.7080305@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.95] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(13464003)(199003)(77156002)(81156007)(1720100001)(102836002)(66066001)(5001830100001)(64706001)(4001540100001)(68736005)(86362001)(5001770100001)(92566002)(97736004)(87936001)(62966003)(15975445007)(107886001)(33656002)(76176999)(54356999)(50986999)(106116001)(105586002)(106356001)(101416001)(19580405001)(2900100001)(46102003)(2950100001)(2656002)(19580395003)(5001860100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0553CBB77A received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2015 23:20:02.3048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 23:20:26 -0000 Some quick comments: - Section 3 is really short. Some examples of how it would work would be ni= ce. - Regarding this from section 3: This makes an assumption users employ Mail User Agents that display t= he identity contained in the Sender header field when used as a basis for acceptance. =20 I've tested Hotmail and Gmail and both suppress the Sender: header in fav= or of the 5322.From address. Conversely, Outlook and Outlook Web Access (OW= A) show it as " on behalf of ". -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis Sent: Tuesday, April 21, 2015 4:10 PM To: dmarc ietf Subject: [dmarc-ietf] Dmarc-escape draft available Dear WG, A draft has been posted offering two alternatives not requiring cooperation of disruptive ESPs. Basic unilateral escape methods include use of a From replacement header IM-From:. This header can include the tag normally added to the Subject line as the display name in the Group syntax. It also includes a placeholder for resource connection used in a "live" discussions, hence the use of IM. This header is free to carry the author role since it will not be excluded by DMARC policy. The other unilateral mode is to defined a DMARC fallback policy 'p' for public user accounts. This mode permits acceptance based on the Sender header field alignment with assumed MUA displaying the identity sourcing the message. It also attempts to remove concerns related to adoption of TPA-Label from the perspective of large providers by allowing DMARC policy to indicate a consolidated tpa-label zone rather than being directly accessed from the customer's zone. This avoids use of DNAME or zone delegations. While TPA-Label may appear to contain too much information, all of it is optional. The goal behind providing a structure for additional third-party information is to allow anticipated limitations be imposed on the scope of authorization granted. This scope also selectively permits other authentication methods be accepted beyond just DKIM or SPF. It is able to indicate the message must be DKIM signed AND must contain a specific LIST-ID header, for example.=20 This ensures recipients in this domain can depend on safer sorting of disparate messages sources from the same domain. http://tools.ietf.org/html/draft-otis-dmarc-escape-00 Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Apr 22 10:58:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF71A8714 for ; Wed, 22 Apr 2015 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.258 X-Spam-Level: *** X-Spam-Status: No, score=3.258 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_PROFIT1=3.858, SPF_PASS=-0.001] autolearn=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 wi-sM-Zzbh03 for ; Wed, 22 Apr 2015 10:58:18 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 1D45A1ACE9F for ; Wed, 22 Apr 2015 10:58:07 -0700 (PDT) Received: by paboj16 with SMTP id oj16so279427846pab.0 for ; Wed, 22 Apr 2015 10:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0BLRQkB3Pjfh9wrVc5qKdqy5sDMKLwdqq3NtYBu3evw=; b=UnRAoUHYY5PWa4SZwmaYdA1/LcQjZyqRrdlv9OGYqoGy3RNjCEn2owCuJGk1Ej1oiq yhn3kQ9VBHlOLUI+R0qCj1OLOMDne4wh+8++aCN8W8moGYQ83NeJsAIHvuUCbreGlDVz OD0BV/QLKA5esqPEENrW8JOgrzy9cx+tZfkd4iFwqpN5LXOKJbkQsniGcyNYf7z6oa+t h9vy47bklGgz1gKHjGt5sKq47TSc9azUeNwmI8NHEWPUYP/lqFYMBJgG8Pf2so7hlp5b no74RSjetYfwAUw/7ngEoQ+AY1Wjq7wwAewRaqsU6osHUbypZsl7vECoepzwTeqU7CBx NkSw== X-Received: by 10.66.66.225 with SMTP id i1mr46659288pat.30.1429725486816; Wed, 22 Apr 2015 10:58:06 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id q4sm5715552pdo.42.2015.04.22.10.58.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 10:58:05 -0700 (PDT) Message-ID: <5537E12B.6030607@gmail.com> Date: Wed, 22 Apr 2015 10:58:03 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc ietf References: <5536D8D6.7080305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:58:24 -0000 On 4/21/15 4:20 PM, Terry Zink wrote: > Some quick comments: > > - Section 3 is really short. Some examples of how it would work would be nice. > - Regarding this from section 3: > > This makes an assumption users employ Mail User Agents that display the > identity contained in the Sender header field when used as a basis > for acceptance. > > I've tested Hotmail and Gmail and both suppress the Sender: header in favor of the 5322.From address. Conversely, Outlook and Outlook Web Access (OWA) show it as " on behalf of ". > > -- Terry > On 4/21/15 4:20 PM, Terry Zink wrote: > Some quick comments: > > - Section 3 is really short. Some examples of how it would work would be nice. > - Regarding this from section 3: > > This makes an assumption users employ Mail User Agents that display the > identity contained in the Sender header field when used as a basis > for acceptance. > > I've tested Hotmail and Gmail and both suppress the Sender: header in favor of the 5322.From address. Conversely, Outlook and Outlook Web Access (OWA) show it as " on behalf of ". > > -- Terry Dear Terry, You make a good point. I consider on behalf of a reasonable approach. It takes seconds using OS X Mail (Mail, Preferences, Viewing, Show message headers: custom, type Sender) to display the Sender header. It is not displayed when it is not there of course, nor is this setting the default. For Thunderbird, users will need to access Preferences, Advanced, General tab, click Config Editor, Enter mail.compose.other.header and double click mail.compose.other.header entry and type the desired headers in the string dialog. For other MUAs beyond Outlook, Mail, and Thunderbird, this may require plugins or similar tinkering. Nonetheless, Sender header protection is available and likely something better configured using a script offered by the provider. In the early days when working with Iconix, they were able to offer fairly comprehensive coverage for web access and MUA using javascript overlays with company icons. This improved source trust based on verification methods then available. It seems these MUAs offer proof it can be done and Iconix proved people could understand the results. This seems rather important since it is the Sender being trusted in most cases; the result of mail's store and forwarding protocol. DKIM and SPF only offer assurances between hops. Use of IM-From better protects the role of author and enables improved availability for direct paths while also offering greater flexibility at adding easily noticable information. http://tools.ietf.org/html/draft-otis-dmarc-escape-00 Regards, Douglas Otis From nobody Wed Apr 22 17:28:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913A11B2C20 for ; Wed, 22 Apr 2015 17:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.47 X-Spam-Level: ** X-Spam-Status: No, score=2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_PROFIT1=3.858, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 nYd0HFcnFKbF for ; Wed, 22 Apr 2015 17:28:53 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 98C8B1B2C19 for ; Wed, 22 Apr 2015 17:28:45 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so2039388obb.3 for ; Wed, 22 Apr 2015 17:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IC/fP7Ym4NAW1Tazjw+KKsnbZ1A3n3nv09rXq7jtW8k=; b=TYloAzBiSufq25bAC7WBMIZkwWXRmvev5bwOfS7v2dTwwTqUlxiYUdTW4uSoDA2Upd X1QoWgevwhX07P1pjXlmVCXT682P8sGPXzYvhwL9KJ6JRjhwxbtGv91L7LFbqJbxL13w 0qPf6x6MEvlCUfr0C9RGmyYovbSt6wQX7i/7ObPI3PPrxe8g9ykUpkpuFX3i92VsG0PQ cNKs9ZviEjHlzGaaCIxWoCAq0k/d91AU0pangyAyVrkijgMBqVjPP47rQazG5uMMglVI M+8exGB0ymxQNycDrVBxlfZDUYB4l2A8ZClc2I1Qp6QZZ1/anXW9XO+NVtrRfS0pyliw tovA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IC/fP7Ym4NAW1Tazjw+KKsnbZ1A3n3nv09rXq7jtW8k=; b=gyrMwGh/l2fvOhFKi6secYrGentkEgNGS1HgS0ibDy6RXsJD5tuYQ08Ad9zTTT/fXe kmZEoQrYAOKPN3+drO6utFiDaE3UpAz3omDIvNdVC+zLst6NBvh3Ncoc7KLrr59PHY1P CzJCzioslQlqZhAtMbZrky9yHRYzZuxLqQiYwIOrAmlUWNHiWlwtSL+h+0YxhYCcMjQk kplNLTA3HRiqVzFyDXJ9o4V5093JZwRNjmqcaTl80RLJoFx6TS6bm3jiRXh2X0n5qhQ5 GaRLI1GeVB3hJRb4QQj1a/XeWuGgj4hR/6W+O6roHo8eippmUP5GpkPOiEIRUrL3xjNs oyeg== X-Gm-Message-State: ALoCoQm8eaDXbfaM4eJkL42Tc5C9bPSElg2XdNO0mOmjgAeEt2jD8avYa1XCpw+T/KEzg4lDsjUN MIME-Version: 1.0 X-Received: by 10.60.82.67 with SMTP id g3mr159728oey.29.1429748925022; Wed, 22 Apr 2015 17:28:45 -0700 (PDT) Received: by 10.182.108.7 with HTTP; Wed, 22 Apr 2015 17:28:44 -0700 (PDT) In-Reply-To: <5537E12B.6030607@gmail.com> References: <5536D8D6.7080305@gmail.com> <5537E12B.6030607@gmail.com> Date: Wed, 22 Apr 2015 17:28:44 -0700 Message-ID: From: Brandon Long To: Douglas Otis Content-Type: multipart/alternative; boundary=047d7b676d52cb8fe80514595cd1 Archived-At: Cc: dmarc ietf Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 00:28:55 -0000 --047d7b676d52cb8fe80514595cd1 Content-Type: text/plain; charset=UTF-8 Gmail will display the Sender information with a on behalf of or similar in certain circumstances when we think its necessary to give the user more information. 99% of users won't use the more information for anything useful or even really notice it or at best get confused, but eh. More information: https://support.google.com/mail/answer/1311182?hl=en So, the messages on this list have "via ietf.org" next to the author, for example. Brandon On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis wrote: > > > On 4/21/15 4:20 PM, Terry Zink wrote: > > Some quick comments: > > > > - Section 3 is really short. Some examples of how it would work would be > nice. > > - Regarding this from section 3: > > > > This makes an assumption users employ Mail User Agents that > display the > > identity contained in the Sender header field when used as a basis > > for acceptance. > > > > I've tested Hotmail and Gmail and both suppress the Sender: header in > favor of the 5322.From address. Conversely, Outlook and Outlook Web Access > (OWA) show it as " on behalf of ". > > > > -- Terry > > > > On 4/21/15 4:20 PM, Terry Zink wrote: > > > Some quick comments: > > > > - Section 3 is really short. Some examples of how it would work would be > nice. > > - Regarding this from section 3: > > > > This makes an assumption users employ Mail User Agents that > display the > > identity contained in the Sender header field when used as a basis > > for acceptance. > > > > I've tested Hotmail and Gmail and both suppress the Sender: header in > favor of the 5322.From address. Conversely, Outlook and Outlook Web Access > (OWA) show it as " on behalf of ". > > > > -- Terry > > Dear Terry, > > You make a good point. I consider on behalf of > a reasonable approach. It takes seconds using OS X > Mail (Mail, Preferences, Viewing, Show message headers: > custom, type Sender) to display the Sender header. It is > not displayed when it is not there of course, nor is this > setting the default. > > For Thunderbird, users will need to access Preferences, > Advanced, General tab, click Config Editor, Enter > mail.compose.other.header and double click > mail.compose.other.header entry and type the desired headers > in the string dialog. For other MUAs beyond Outlook, Mail, > and Thunderbird, this may require plugins or similar > tinkering. Nonetheless, Sender header protection is > available and likely something better configured using a > script offered by the provider. > > In the early days when working with Iconix, they were able > to offer fairly comprehensive coverage for web access and > MUA using javascript overlays with company icons. This > improved source trust based on verification methods then > available. It seems these MUAs offer proof it can be done > and Iconix proved people could understand the results. This > seems rather important since it is the Sender being trusted > in most cases; the result of mail's store and forwarding > protocol. DKIM and SPF only offer assurances between hops. > Use of IM-From better protects the role of author and > enables improved availability for direct paths while also > offering greater flexibility at adding easily noticable > information. > > http://tools.ietf.org/html/draft-otis-dmarc-escape-00 > > > Regards, > Douglas Otis > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b676d52cb8fe80514595cd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gmail will display the Sender information with a on behalf= of or similar in certain circumstances when we think its necessary to give= the user more information.

99% of users won't use t= he more information for anything useful or even really notice it or at best= get confused, but eh.


So,= the messages on this list have "via ietf.= org" next to the author, for example.

Bra= ndon

O= n Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis <doug.mtview@gmail.com> wrote:

On 4/21/15 4:20 PM, Terry Zink wrote:
> Some quick comments:
>
> - Section 3 is really short. Some examples of how it would work would = be nice.
> - Regarding this from section 3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This makes an assumption users employ Mail U= ser Agents that display the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity contained in the Sender header fiel= d when used as a basis
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for acceptance.
>
>=C2=A0 =C2=A0I've tested Hotmail and Gmail and both suppress the Se= nder: header in favor of the 5322.From address. Conversely, Outlook and Out= look Web Access (OWA) show it as "<sender> on behalf of <from= >".
>
> -- Terry
>

On 4/21/15 4:20 PM, Terry Zink wrote:

> Some quick comments:
>
> - Section 3 is really short. Some examples of how it would work would = be nice.
> - Regarding this from section 3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This makes an assumption users employ Mail U= ser Agents that display the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity contained in the Sender header fiel= d when used as a basis
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for acceptance.
>
>=C2=A0 =C2=A0I've tested Hotmail and Gmail and both suppress the Se= nder: header in favor of the 5322.From address. Conversely, Outlook and Out= look Web Access (OWA) show it as "<sender> on behalf of <from= >".
>
> -- Terry

Dear Terry,

You make a good point. I consider <sender> on behalf of
<from> a reasonable approach. It takes seconds using OS X
Mail (Mail, Preferences, Viewing, Show message headers:
custom, type Sender) to display the Sender header.=C2=A0 It is
not displayed when it is not there of course, nor is this
setting the default.

For Thunderbird, users will need to access Preferences,
Advanced, General tab, click Config Editor, Enter
mail.compose.other.header and double click
mail.compose.other.header entry and type the desired headers
in the string dialog.=C2=A0 For other MUAs beyond Outlook, Mail,
and Thunderbird, this may require plugins or similar
tinkering.=C2=A0 Nonetheless, Sender header protection is
available and likely something better configured using a
script offered by the provider.

In the early days when working with Iconix, they were able
to offer fairly comprehensive coverage for web access and
MUA using javascript overlays with company icons.=C2=A0 This
improved source trust based on verification methods then
available.=C2=A0 It seems these MUAs offer proof it can be done
and Iconix proved people could understand the results.=C2=A0 This
seems rather important since it is the Sender being trusted
in most cases; the result of mail's store and forwarding
protocol. DKIM and SPF only offer assurances between hops.
Use of IM-From better protects the role of author and
enables improved availability for direct paths while also
offering greater flexibility at adding easily noticable
information.

http://tools.ietf.org/html/draft-otis-dmarc-escape-00


Regards,
Douglas Otis

_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--047d7b676d52cb8fe80514595cd1-- From nobody Thu Apr 23 10:35:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12D1B30F8 for ; Thu, 23 Apr 2015 10:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.856 X-Spam-Level: *** X-Spam-Status: No, score=3.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FRT_PROFIT1=3.858, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 2_X44FrJNrek for ; Thu, 23 Apr 2015 10:35:24 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0089.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104DA1B3103 for ; Thu, 23 Apr 2015 10:34:10 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.160.4; Thu, 23 Apr 2015 17:33:54 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) with mapi id 15.01.0160.000; Thu, 23 Apr 2015 17:33:54 +0000 From: Terry Zink To: Brandon Long , Douglas Otis Thread-Topic: [dmarc-ietf] Dmarc-escape draft available Thread-Index: AQHQfIhiDokkbZdMr06f8XE7BXT8aZ1YGdwAgAE41ICAAG0oAIABHCLA Date: Thu, 23 Apr 2015 17:33:53 +0000 Message-ID: References: <5536D8D6.7080305@gmail.com> <5537E12B.6030607@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.107] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(199003)(51704005)(377454003)(189002)(479174004)(24454002)(105586002)(76176999)(54356999)(50986999)(19625215002)(68736005)(92566002)(106356001)(2656002)(102836002)(5001860100001)(19609705001)(62966003)(77156002)(15975445007)(19580405001)(64706001)(86362001)(101416001)(19580395003)(106116001)(87936001)(4001540100001)(97736004)(5001770100001)(66066001)(46102003)(5001830100001)(81156007)(93886004)(19617315012)(33656002)(16236675004)(2950100001)(2900100001)(19300405004)(16601075003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0555EC8317 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB6059E06DFC7F141EFF118B696ED0BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2015 17:33:54.0922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Cc: dmarc ietf Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:35:27 -0000 --_000_BL2SR01MB6059E06DFC7F141EFF118B696ED0BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIHBsYXllZCBhcm91bmQgYSBiaXQgd2l0aCBHbWFpbCwgSG90bWFpbC9vdXRsb29rLmNv bSwgYW5kIE91dGxvb2sgZGVza3RvcCBjbGllbnQuIEhlcmXigJlzIHdoYXQgSSBoYXZlIGZvdW5k IHNvIGZhci4NCg0KR21haWwgYW5kIEhvdG1haWwgaGF2ZSBzaW1pbGFyIGJ1dCBub3QgaWRlbnRp Y2FsIGJlaGF2aW9yOg0KDQoNCjEuICAgICAgIElmIHRoZSA1MzIyLkZyb20gYWRkcmVzcyBpcyBp biB5b3VyIGFkZHJlc3MgYm9vayBvciB5b3UgaGF2ZSBhIGNvbnZlcnNhdGlvbmFsIGhpc3Rvcnkg KGltcGxpY2l0IGNvbnRhY3QpIG9yIGlzIG9uIHlvdXIgc2FmZSBzZW5kZXJzIChpbiBIb3RtYWls KSwgdGhlbiBHbWFpbCwgSG90bWFpbCwgYW5kIE91dGxvb2sgc2hvdyBvbmx5IHRoZSBGcmllbmRs eSBGcm9tIChkaXNwbGF5IGZyb20pIGFuZCBub3QgdGhlIDUzMjIuRnJvbSBmdWxsIGFkZHJlc3Mu IElmIGl0IGlzbuKAmXQgaW4geW91ciBjb250YWN0cywgdGhlbiBhbGwgc2hvdyB0aGUgZGlzcGxh eSBmcm9tICsgNTMyMi5mcm9tIGVtYWlsIGFkZHJlc3MuDQoNCjIuICAgICAgIElmIHRoZSA1MzIx Lm1haWxmcm9tIGlzIGRpZmZlcmVudCB0aGFuIHRoZSA1MzIyLkZyb20sIEdtYWlsIHNob3dzIOKA nERpc3BsYXkgRnJvbSA8YW5kIDUzMjIuRnJvbSBpZiBub3QgaW4gYWRkcmVzcyBib29rPiB2aWEg NTMyMS5tYWlsZnJvbeKAnSB3aGVyZWFzIG91dGxvb2suY29tIGFuZCBPdXRsb29rIGRlc2t0b3Ag ZG9u4oCZdCBzaG93IHRoZSBkaXNjcmVwYW5jeSBhdCBhbGwgKGkuZS4sIG5vIGVxdWl2YWxlbnQg b2Yg4oCYdmlh4oCZIGluIEhvdG1haWwgb3IgT3V0bG9vayBkZXNrdG9wKS4gR21haWwgZG9lcyBu b3Qgc2hvdyB0aGUgdmlhIGlmIHRoZSA1MzIyLmZyb20gZG9tYWluIGFuZCA1MzIxLm1haWxmcm9t IGRvbWFpbnMgYXJlIHRoZSBzYW1lIHdoaWNoIGlzIHdoeSB0aGVyZSBpcyBhIHJlY29tbWVuZGF0 aW9uIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIFNQRiBhbmQgREtJTS4NCg0KMy4gICAgICAgTmVpdGhl ciBHbWFpbCBub3IgSG90bWFpbCBzaG93IHRoZSBTZW5kZXI6IGhlYWRlciBhdCBhbGwuIE91dGxv b2sgZGVza3RvcCBzaG93cyDigJw8c2VuZGVyPiBvbiBiZWhhbGYgb2YgPGZyb20+LuKAnQ0KDQpJ IGhhdmVu4oCZdCBkb25lIGEgbGFyZ2UgbWF0cml4IG9mIHRlc3RpbmcgYnV0IEkgaGF2ZSBwbGF5 ZWQgYXJvdW5kIHdpdGggZGlmZmVyZW50IHJlbmRlcmluZzsgb2J2aW91c2x5LCBzcGFtIGZpbHRl cmluZyBhbmQgc2VhcmNoaW5nIGZvciBjb252ZXJzYXRpb25hbCBoaXN0b3J5IG1heSBoYXZlIHNv bWV0aGluZyB0byBkbyB3aXRoIGl0LCB0b28uDQoNCi0tIFRlcnJ5DQoNCkZyb206IGRtYXJjIFtt YWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyYW5kb24gTG9uZw0K U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyMiwgMjAxNSA1OjI5IFBNDQpUbzogRG91Z2xhcyBPdGlz DQpDYzogZG1hcmMgaWV0Zg0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBEbWFyYy1lc2NhcGUg ZHJhZnQgYXZhaWxhYmxlDQoNCkdtYWlsIHdpbGwgZGlzcGxheSB0aGUgU2VuZGVyIGluZm9ybWF0 aW9uIHdpdGggYSBvbiBiZWhhbGYgb2Ygb3Igc2ltaWxhciBpbiBjZXJ0YWluIGNpcmN1bXN0YW5j ZXMgd2hlbiB3ZSB0aGluayBpdHMgbmVjZXNzYXJ5IHRvIGdpdmUgdGhlIHVzZXIgbW9yZSBpbmZv cm1hdGlvbi4NCg0KOTklIG9mIHVzZXJzIHdvbid0IHVzZSB0aGUgbW9yZSBpbmZvcm1hdGlvbiBm b3IgYW55dGhpbmcgdXNlZnVsIG9yIGV2ZW4gcmVhbGx5IG5vdGljZSBpdCBvciBhdCBiZXN0IGdl dCBjb25mdXNlZCwgYnV0IGVoLg0KDQpNb3JlIGluZm9ybWF0aW9uOiBodHRwczovL3N1cHBvcnQu Z29vZ2xlLmNvbS9tYWlsL2Fuc3dlci8xMzExMTgyP2hsPWVuDQoNClNvLCB0aGUgbWVzc2FnZXMg b24gdGhpcyBsaXN0IGhhdmUgInZpYSBpZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmc+IiBuZXh0IHRv IHRoZSBhdXRob3IsIGZvciBleGFtcGxlLg0KDQpCcmFuZG9uDQoNCk9uIFdlZCwgQXByIDIyLCAy MDE1IGF0IDEwOjU4IEFNLCBEb3VnbGFzIE90aXMgPGRvdWcubXR2aWV3QGdtYWlsLmNvbTxtYWls dG86ZG91Zy5tdHZpZXdAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KT24gNC8yMS8xNSA0OjIwIFBN LCBUZXJyeSBaaW5rIHdyb3RlOg0KPiBTb21lIHF1aWNrIGNvbW1lbnRzOg0KPg0KPiAtIFNlY3Rp b24gMyBpcyByZWFsbHkgc2hvcnQuIFNvbWUgZXhhbXBsZXMgb2YgaG93IGl0IHdvdWxkIHdvcmsg d291bGQgYmUgbmljZS4NCj4gLSBSZWdhcmRpbmcgdGhpcyBmcm9tIHNlY3Rpb24gMzoNCj4NCj4g ICAgICAgVGhpcyBtYWtlcyBhbiBhc3N1bXB0aW9uIHVzZXJzIGVtcGxveSBNYWlsIFVzZXIgQWdl bnRzIHRoYXQgZGlzcGxheSB0aGUNCj4gICAgICAgaWRlbnRpdHkgY29udGFpbmVkIGluIHRoZSBT ZW5kZXIgaGVhZGVyIGZpZWxkIHdoZW4gdXNlZCBhcyBhIGJhc2lzDQo+ICAgICAgIGZvciBhY2Nl cHRhbmNlLg0KPg0KPiAgIEkndmUgdGVzdGVkIEhvdG1haWwgYW5kIEdtYWlsIGFuZCBib3RoIHN1 cHByZXNzIHRoZSBTZW5kZXI6IGhlYWRlciBpbiBmYXZvciBvZiB0aGUgNTMyMi5Gcm9tIGFkZHJl c3MuIENvbnZlcnNlbHksIE91dGxvb2sgYW5kIE91dGxvb2sgV2ViIEFjY2VzcyAoT1dBKSBzaG93 IGl0IGFzICI8c2VuZGVyPiBvbiBiZWhhbGYgb2YgPGZyb20+Ii4NCj4NCj4gLS0gVGVycnkNCj4N Cg0KT24gNC8yMS8xNSA0OjIwIFBNLCBUZXJyeSBaaW5rIHdyb3RlOg0KDQo+IFNvbWUgcXVpY2sg Y29tbWVudHM6DQo+DQo+IC0gU2VjdGlvbiAzIGlzIHJlYWxseSBzaG9ydC4gU29tZSBleGFtcGxl cyBvZiBob3cgaXQgd291bGQgd29yayB3b3VsZCBiZSBuaWNlLg0KPiAtIFJlZ2FyZGluZyB0aGlz IGZyb20gc2VjdGlvbiAzOg0KPg0KPiAgICAgICBUaGlzIG1ha2VzIGFuIGFzc3VtcHRpb24gdXNl cnMgZW1wbG95IE1haWwgVXNlciBBZ2VudHMgdGhhdCBkaXNwbGF5IHRoZQ0KPiAgICAgICBpZGVu dGl0eSBjb250YWluZWQgaW4gdGhlIFNlbmRlciBoZWFkZXIgZmllbGQgd2hlbiB1c2VkIGFzIGEg YmFzaXMNCj4gICAgICAgZm9yIGFjY2VwdGFuY2UuDQo+DQo+ICAgSSd2ZSB0ZXN0ZWQgSG90bWFp bCBhbmQgR21haWwgYW5kIGJvdGggc3VwcHJlc3MgdGhlIFNlbmRlcjogaGVhZGVyIGluIGZhdm9y IG9mIHRoZSA1MzIyLkZyb20gYWRkcmVzcy4gQ29udmVyc2VseSwgT3V0bG9vayBhbmQgT3V0bG9v ayBXZWIgQWNjZXNzIChPV0EpIHNob3cgaXQgYXMgIjxzZW5kZXI+IG9uIGJlaGFsZiBvZiA8ZnJv bT4iLg0KPg0KPiAtLSBUZXJyeQ0KDQpEZWFyIFRlcnJ5LA0KDQpZb3UgbWFrZSBhIGdvb2QgcG9p bnQuIEkgY29uc2lkZXIgPHNlbmRlcj4gb24gYmVoYWxmIG9mDQo8ZnJvbT4gYSByZWFzb25hYmxl IGFwcHJvYWNoLiBJdCB0YWtlcyBzZWNvbmRzIHVzaW5nIE9TIFgNCk1haWwgKE1haWwsIFByZWZl cmVuY2VzLCBWaWV3aW5nLCBTaG93IG1lc3NhZ2UgaGVhZGVyczoNCmN1c3RvbSwgdHlwZSBTZW5k ZXIpIHRvIGRpc3BsYXkgdGhlIFNlbmRlciBoZWFkZXIuICBJdCBpcw0Kbm90IGRpc3BsYXllZCB3 aGVuIGl0IGlzIG5vdCB0aGVyZSBvZiBjb3Vyc2UsIG5vciBpcyB0aGlzDQpzZXR0aW5nIHRoZSBk ZWZhdWx0Lg0KDQpGb3IgVGh1bmRlcmJpcmQsIHVzZXJzIHdpbGwgbmVlZCB0byBhY2Nlc3MgUHJl ZmVyZW5jZXMsDQpBZHZhbmNlZCwgR2VuZXJhbCB0YWIsIGNsaWNrIENvbmZpZyBFZGl0b3IsIEVu dGVyDQptYWlsLmNvbXBvc2Uub3RoZXIuaGVhZGVyIGFuZCBkb3VibGUgY2xpY2sNCm1haWwuY29t cG9zZS5vdGhlci5oZWFkZXIgZW50cnkgYW5kIHR5cGUgdGhlIGRlc2lyZWQgaGVhZGVycw0KaW4g dGhlIHN0cmluZyBkaWFsb2cuICBGb3Igb3RoZXIgTVVBcyBiZXlvbmQgT3V0bG9vaywgTWFpbCwN CmFuZCBUaHVuZGVyYmlyZCwgdGhpcyBtYXkgcmVxdWlyZSBwbHVnaW5zIG9yIHNpbWlsYXINCnRp bmtlcmluZy4gIE5vbmV0aGVsZXNzLCBTZW5kZXIgaGVhZGVyIHByb3RlY3Rpb24gaXMNCmF2YWls YWJsZSBhbmQgbGlrZWx5IHNvbWV0aGluZyBiZXR0ZXIgY29uZmlndXJlZCB1c2luZyBhDQpzY3Jp cHQgb2ZmZXJlZCBieSB0aGUgcHJvdmlkZXIuDQoNCkluIHRoZSBlYXJseSBkYXlzIHdoZW4gd29y a2luZyB3aXRoIEljb25peCwgdGhleSB3ZXJlIGFibGUNCnRvIG9mZmVyIGZhaXJseSBjb21wcmVo ZW5zaXZlIGNvdmVyYWdlIGZvciB3ZWIgYWNjZXNzIGFuZA0KTVVBIHVzaW5nIGphdmFzY3JpcHQg b3ZlcmxheXMgd2l0aCBjb21wYW55IGljb25zLiAgVGhpcw0KaW1wcm92ZWQgc291cmNlIHRydXN0 IGJhc2VkIG9uIHZlcmlmaWNhdGlvbiBtZXRob2RzIHRoZW4NCmF2YWlsYWJsZS4gIEl0IHNlZW1z IHRoZXNlIE1VQXMgb2ZmZXIgcHJvb2YgaXQgY2FuIGJlIGRvbmUNCmFuZCBJY29uaXggcHJvdmVk IHBlb3BsZSBjb3VsZCB1bmRlcnN0YW5kIHRoZSByZXN1bHRzLiAgVGhpcw0Kc2VlbXMgcmF0aGVy IGltcG9ydGFudCBzaW5jZSBpdCBpcyB0aGUgU2VuZGVyIGJlaW5nIHRydXN0ZWQNCmluIG1vc3Qg Y2FzZXM7IHRoZSByZXN1bHQgb2YgbWFpbCdzIHN0b3JlIGFuZCBmb3J3YXJkaW5nDQpwcm90b2Nv bC4gREtJTSBhbmQgU1BGIG9ubHkgb2ZmZXIgYXNzdXJhbmNlcyBiZXR3ZWVuIGhvcHMuDQpVc2Ug b2YgSU0tRnJvbSBiZXR0ZXIgcHJvdGVjdHMgdGhlIHJvbGUgb2YgYXV0aG9yIGFuZA0KZW5hYmxl cyBpbXByb3ZlZCBhdmFpbGFiaWxpdHkgZm9yIGRpcmVjdCBwYXRocyB3aGlsZSBhbHNvDQpvZmZl cmluZyBncmVhdGVyIGZsZXhpYmlsaXR5IGF0IGFkZGluZyBlYXNpbHkgbm90aWNhYmxlDQppbmZv cm1hdGlvbi4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3Rpcy1kbWFyYy1l c2NhcGUtMDANCg0KDQpSZWdhcmRzLA0KRG91Z2xhcyBPdGlzDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbWFyYyBtYWlsaW5nIGxpc3QNCmRtYXJj QGlldGYub3JnPG1haWx0bzpkbWFyY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG1hcmMNCg0K --_000_BL2SR01MB6059E06DFC7F141EFF118B696ED0BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTg3Mzg4MDI2MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6OTk1NjMwNjY4IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ SeKAmXZlIHBsYXllZCBhcm91bmQgYSBiaXQgd2l0aCBHbWFpbCwgSG90bWFpbC9vdXRsb29rLmNv bSwgYW5kIE91dGxvb2sgZGVza3RvcCBjbGllbnQuIEhlcmXigJlzIHdoYXQgSSBoYXZlIGZvdW5k IHNvIGZhci48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkdtYWlsIGFuZCBIb3RtYWlsIGhhdmUgc2ltaWxhciBidXQgbm90 IGlkZW50aWNhbCBiZWhhdmlvcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPklmIHRoZSA1MzIyLkZyb20gYWRkcmVzcyBpcyBpbiB5b3VyIGFkZHJl c3MgYm9vayBvciB5b3UgaGF2ZSBhIGNvbnZlcnNhdGlvbmFsIGhpc3RvcnkgKGltcGxpY2l0IGNv bnRhY3QpIG9yIGlzIG9uIHlvdXIgc2FmZSBzZW5kZXJzIChpbiBIb3RtYWlsKSwgdGhlbg0KIEdt YWlsLCBIb3RtYWlsLCBhbmQgT3V0bG9vayBzaG93IG9ubHkgdGhlIEZyaWVuZGx5IEZyb20gKGRp c3BsYXkgZnJvbSkgYW5kIG5vdCB0aGUgNTMyMi5Gcm9tIGZ1bGwgYWRkcmVzcy4gSWYgaXQgaXNu 4oCZdCBpbiB5b3VyIGNvbnRhY3RzLCB0aGVuIGFsbCBzaG93IHRoZSBkaXNwbGF5IGZyb20gJiM0 MzsgNTMyMi5mcm9tIGVtYWlsIGFkZHJlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgdGhlIDUzMjEu bWFpbGZyb20gaXMgZGlmZmVyZW50IHRoYW4gdGhlIDUzMjIuRnJvbSwgR21haWwgc2hvd3Mg4oCc RGlzcGxheSBGcm9tICZsdDthbmQgNTMyMi5Gcm9tIGlmIG5vdCBpbiBhZGRyZXNzIGJvb2smZ3Q7 IHZpYSA1MzIxLm1haWxmcm9t4oCdIHdoZXJlYXMgb3V0bG9vay5jb20NCiBhbmQgT3V0bG9vayBk ZXNrdG9wIGRvbuKAmXQgc2hvdyB0aGUgZGlzY3JlcGFuY3kgYXQgYWxsIChpLmUuLCBubyBlcXVp dmFsZW50IG9mIOKAmHZpYeKAmSBpbiBIb3RtYWlsIG9yIE91dGxvb2sgZGVza3RvcCkuIEdtYWls IGRvZXMgbm90IHNob3cgdGhlIHZpYSBpZiB0aGUgNTMyMi5mcm9tIGRvbWFpbiBhbmQgNTMyMS5t YWlsZnJvbSBkb21haW5zIGFyZSB0aGUgc2FtZSB3aGljaCBpcyB3aHkgdGhlcmUgaXMgYSByZWNv bW1lbmRhdGlvbiB0byBhdXRoZW50aWNhdGUNCiB3aXRoIFNQRiBhbmQgREtJTS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5OZWl0aGVyIEdtYWlsIG5vciBIb3RtYWlsIHNob3cgdGhlIFNlbmRlcjogaGVhZGVy IGF0IGFsbC4gT3V0bG9vayBkZXNrdG9wIHNob3dzIOKAnCZsdDtzZW5kZXImZ3Q7IG9uIGJlaGFs ZiBvZiAmbHQ7ZnJvbSZndDsu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgaGF2ZW7igJl0IGRvbmUgYSBsYXJnZSBtYXRy aXggb2YgdGVzdGluZyBidXQgSSBoYXZlIHBsYXllZCBhcm91bmQgd2l0aCBkaWZmZXJlbnQgcmVu ZGVyaW5nOyBvYnZpb3VzbHksIHNwYW0gZmlsdGVyaW5nIGFuZCBzZWFyY2hpbmcgZm9yIGNvbnZl cnNhdGlvbmFsIGhpc3RvcnkNCiBtYXkgaGF2ZSBzb21ldGhpbmcgdG8gZG8gd2l0aCBpdCwgdG9v LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4tLSBUZXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gZG1hcmMgW21haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5CcmFuZG9uIExvbmc8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyMiwg MjAxNSA1OjI5IFBNPGJyPg0KPGI+VG86PC9iPiBEb3VnbGFzIE90aXM8YnI+DQo8Yj5DYzo8L2I+ IGRtYXJjIGlldGY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBEbWFyYy1l c2NhcGUgZHJhZnQgYXZhaWxhYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+R21haWwgd2lsbCBkaXNwbGF5IHRoZSBTZW5kZXIgaW5mb3JtYXRpb24gd2l0aCBhIG9uIGJl aGFsZiBvZiBvciBzaW1pbGFyIGluIGNlcnRhaW4gY2lyY3Vtc3RhbmNlcyB3aGVuIHdlIHRoaW5r IGl0cyBuZWNlc3NhcnkgdG8gZ2l2ZSB0aGUgdXNlciBtb3JlIGluZm9ybWF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OTklIG9mIHVzZXJzIHdvbid0 IHVzZSB0aGUgbW9yZSBpbmZvcm1hdGlvbiBmb3IgYW55dGhpbmcgdXNlZnVsIG9yIGV2ZW4gcmVh bGx5IG5vdGljZSBpdCBvciBhdCBiZXN0IGdldCBjb25mdXNlZCwgYnV0IGVoLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3JlIGluZm9ybWF0 aW9uOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vc3VwcG9ydC5nb29nbGUuY29tL21haWwvYW5zd2Vy LzEzMTExODI/aGw9ZW4iPmh0dHBzOi8vc3VwcG9ydC5nb29nbGUuY29tL21haWwvYW5zd2VyLzEz MTExODI/aGw9ZW48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNvLCB0aGUgbWVzc2FnZXMgb24gdGhpcyBsaXN0IGhhdmUgJnF1b3Q7dmlh IDxhIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyI+DQppZXRmLm9yZzwvYT4mcXVvdDsgbmV4dCB0byB0 aGUgYXV0aG9yLCBmb3IgZXhhbXBsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJhbmRvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciAyMiwgMjAxNSBhdCAxMDo1OCBB TSwgRG91Z2xhcyBPdGlzICZsdDs8YSBocmVmPSJtYWlsdG86ZG91Zy5tdHZpZXdAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZG91Zy5tdHZpZXdAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KT24gNC8yMS8xNSA0OjIwIFBNLCBUZXJyeSBaaW5rIHdyb3RlOjxicj4NCiZndDsgU29tZSBx dWljayBjb21tZW50czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIFNlY3Rpb24gMyBpcyByZWFsbHkg c2hvcnQuIFNvbWUgZXhhbXBsZXMgb2YgaG93IGl0IHdvdWxkIHdvcmsgd291bGQgYmUgbmljZS48 YnI+DQomZ3Q7IC0gUmVnYXJkaW5nIHRoaXMgZnJvbSBzZWN0aW9uIDM6PGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIG1ha2VzIGFuIGFzc3VtcHRpb24g dXNlcnMgZW1wbG95IE1haWwgVXNlciBBZ2VudHMgdGhhdCBkaXNwbGF5IHRoZTxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpZGVudGl0eSBjb250YWluZWQgaW4gdGhlIFNlbmRl ciBoZWFkZXIgZmllbGQgd2hlbiB1c2VkIGFzIGEgYmFzaXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Zm9yIGFjY2VwdGFuY2UuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7SSd2ZSB0ZXN0ZWQgSG90bWFpbCBhbmQgR21haWwgYW5kIGJvdGggc3VwcHJlc3MgdGhl IFNlbmRlcjogaGVhZGVyIGluIGZhdm9yIG9mIHRoZSA1MzIyLkZyb20gYWRkcmVzcy4gQ29udmVy c2VseSwgT3V0bG9vayBhbmQgT3V0bG9vayBXZWIgQWNjZXNzIChPV0EpIHNob3cgaXQgYXMgJnF1 b3Q7Jmx0O3NlbmRlciZndDsgb24gYmVoYWxmIG9mICZsdDtmcm9tJmd0OyZxdW90Oy48YnI+DQom Z3Q7PGJyPg0KJmd0OyAtLSBUZXJyeTxicj4NCiZndDs8YnI+DQo8YnI+DQpPbiA0LzIxLzE1IDQ6 MjAgUE0sIFRlcnJ5IFppbmsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBTb21lIHF1aWNrIGNvbW1l bnRzOjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gU2VjdGlvbiAzIGlzIHJlYWxseSBzaG9ydC4gU29t ZSBleGFtcGxlcyBvZiBob3cgaXQgd291bGQgd29yayB3b3VsZCBiZSBuaWNlLjxicj4NCiZndDsg LSBSZWdhcmRpbmcgdGhpcyBmcm9tIHNlY3Rpb24gMzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgbWFrZXMgYW4gYXNzdW1wdGlvbiB1c2VycyBlbXBs b3kgTWFpbCBVc2VyIEFnZW50cyB0aGF0IGRpc3BsYXkgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2lkZW50aXR5IGNvbnRhaW5lZCBpbiB0aGUgU2VuZGVyIGhlYWRlciBm aWVsZCB3aGVuIHVzZWQgYXMgYSBiYXNpczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtmb3IgYWNjZXB0YW5jZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtJJ3Zl IHRlc3RlZCBIb3RtYWlsIGFuZCBHbWFpbCBhbmQgYm90aCBzdXBwcmVzcyB0aGUgU2VuZGVyOiBo ZWFkZXIgaW4gZmF2b3Igb2YgdGhlIDUzMjIuRnJvbSBhZGRyZXNzLiBDb252ZXJzZWx5LCBPdXRs b29rIGFuZCBPdXRsb29rIFdlYiBBY2Nlc3MgKE9XQSkgc2hvdyBpdCBhcyAmcXVvdDsmbHQ7c2Vu ZGVyJmd0OyBvbiBiZWhhbGYgb2YgJmx0O2Zyb20mZ3Q7JnF1b3Q7Ljxicj4NCiZndDs8YnI+DQom Z3Q7IC0tIFRlcnJ5PGJyPg0KPGJyPg0KRGVhciBUZXJyeSw8YnI+DQo8YnI+DQpZb3UgbWFrZSBh IGdvb2QgcG9pbnQuIEkgY29uc2lkZXIgJmx0O3NlbmRlciZndDsgb24gYmVoYWxmIG9mPGJyPg0K Jmx0O2Zyb20mZ3Q7IGEgcmVhc29uYWJsZSBhcHByb2FjaC4gSXQgdGFrZXMgc2Vjb25kcyB1c2lu ZyBPUyBYPGJyPg0KTWFpbCAoTWFpbCwgUHJlZmVyZW5jZXMsIFZpZXdpbmcsIFNob3cgbWVzc2Fn ZSBoZWFkZXJzOjxicj4NCmN1c3RvbSwgdHlwZSBTZW5kZXIpIHRvIGRpc3BsYXkgdGhlIFNlbmRl ciBoZWFkZXIuJm5ic3A7IEl0IGlzPGJyPg0Kbm90IGRpc3BsYXllZCB3aGVuIGl0IGlzIG5vdCB0 aGVyZSBvZiBjb3Vyc2UsIG5vciBpcyB0aGlzPGJyPg0Kc2V0dGluZyB0aGUgZGVmYXVsdC48YnI+ DQo8YnI+DQpGb3IgVGh1bmRlcmJpcmQsIHVzZXJzIHdpbGwgbmVlZCB0byBhY2Nlc3MgUHJlZmVy ZW5jZXMsPGJyPg0KQWR2YW5jZWQsIEdlbmVyYWwgdGFiLCBjbGljayBDb25maWcgRWRpdG9yLCBF bnRlcjxicj4NCm1haWwuY29tcG9zZS5vdGhlci5oZWFkZXIgYW5kIGRvdWJsZSBjbGljazxicj4N Cm1haWwuY29tcG9zZS5vdGhlci5oZWFkZXIgZW50cnkgYW5kIHR5cGUgdGhlIGRlc2lyZWQgaGVh ZGVyczxicj4NCmluIHRoZSBzdHJpbmcgZGlhbG9nLiZuYnNwOyBGb3Igb3RoZXIgTVVBcyBiZXlv bmQgT3V0bG9vaywgTWFpbCw8YnI+DQphbmQgVGh1bmRlcmJpcmQsIHRoaXMgbWF5IHJlcXVpcmUg cGx1Z2lucyBvciBzaW1pbGFyPGJyPg0KdGlua2VyaW5nLiZuYnNwOyBOb25ldGhlbGVzcywgU2Vu ZGVyIGhlYWRlciBwcm90ZWN0aW9uIGlzPGJyPg0KYXZhaWxhYmxlIGFuZCBsaWtlbHkgc29tZXRo aW5nIGJldHRlciBjb25maWd1cmVkIHVzaW5nIGE8YnI+DQpzY3JpcHQgb2ZmZXJlZCBieSB0aGUg cHJvdmlkZXIuPGJyPg0KPGJyPg0KSW4gdGhlIGVhcmx5IGRheXMgd2hlbiB3b3JraW5nIHdpdGgg SWNvbml4LCB0aGV5IHdlcmUgYWJsZTxicj4NCnRvIG9mZmVyIGZhaXJseSBjb21wcmVoZW5zaXZl IGNvdmVyYWdlIGZvciB3ZWIgYWNjZXNzIGFuZDxicj4NCk1VQSB1c2luZyBqYXZhc2NyaXB0IG92 ZXJsYXlzIHdpdGggY29tcGFueSBpY29ucy4mbmJzcDsgVGhpczxicj4NCmltcHJvdmVkIHNvdXJj ZSB0cnVzdCBiYXNlZCBvbiB2ZXJpZmljYXRpb24gbWV0aG9kcyB0aGVuPGJyPg0KYXZhaWxhYmxl LiZuYnNwOyBJdCBzZWVtcyB0aGVzZSBNVUFzIG9mZmVyIHByb29mIGl0IGNhbiBiZSBkb25lPGJy Pg0KYW5kIEljb25peCBwcm92ZWQgcGVvcGxlIGNvdWxkIHVuZGVyc3RhbmQgdGhlIHJlc3VsdHMu Jm5ic3A7IFRoaXM8YnI+DQpzZWVtcyByYXRoZXIgaW1wb3J0YW50IHNpbmNlIGl0IGlzIHRoZSBT ZW5kZXIgYmVpbmcgdHJ1c3RlZDxicj4NCmluIG1vc3QgY2FzZXM7IHRoZSByZXN1bHQgb2YgbWFp bCdzIHN0b3JlIGFuZCBmb3J3YXJkaW5nPGJyPg0KcHJvdG9jb2wuIERLSU0gYW5kIFNQRiBvbmx5 IG9mZmVyIGFzc3VyYW5jZXMgYmV0d2VlbiBob3BzLjxicj4NClVzZSBvZiBJTS1Gcm9tIGJldHRl ciBwcm90ZWN0cyB0aGUgcm9sZSBvZiBhdXRob3IgYW5kPGJyPg0KZW5hYmxlcyBpbXByb3ZlZCBh dmFpbGFiaWxpdHkgZm9yIGRpcmVjdCBwYXRocyB3aGlsZSBhbHNvPGJyPg0Kb2ZmZXJpbmcgZ3Jl YXRlciBmbGV4aWJpbGl0eSBhdCBhZGRpbmcgZWFzaWx5IG5vdGljYWJsZTxicj4NCmluZm9ybWF0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vdGlzLWRtYXJj LWVzY2FwZS0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW90aXMtZG1hcmMtZXNjYXBlLTAwPC9hPjxicj4NCjxicj4NCjxicj4NClJlZ2FyZHMsPGJy Pg0KRG91Z2xhcyBPdGlzPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpkbWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86ZG1hcmNAaWV0Zi5vcmciPmRtYXJjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_BL2SR01MB6059E06DFC7F141EFF118B696ED0BL2SR01MB605namsdf_-- From nobody Thu Apr 23 10:46:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4C1AD05B for ; Thu, 23 Apr 2015 10:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.755 X-Spam-Level: *** X-Spam-Status: No, score=3.755 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_PROFIT1=3.858, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 CVZEoNHAgw5J for ; Thu, 23 Apr 2015 10:46:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925ED1B3023 for ; Thu, 23 Apr 2015 10:46:35 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 90AF1C402DE for ; Thu, 23 Apr 2015 12:46:34 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1429811194; bh=95rj68ek9TdWqujpr9XGJhP82VvmPrwDEHlv6x7vl80=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QbmbRxHH6pEmibN1neB0FD5oItP26yfxtr0oJTTsMj5jg1aVcUVkXJwehtl8VZlma QtFA0WmDwuaZRoG+2HpPFTPI6NZJB6Oa0648d0W1ZcsTbvxvVh3UatcI00mXZM1xH9 t5CfWSv2NM3Jfo+4z2CaKrg0c48j6+8JlN4ikI9k= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 23 Apr 2015 13:46:35 -0400 Message-ID: <2205755.CDbdbaXSto@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <5536D8D6.7080305@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:46:43 -0000 Since the core lookup key off of which everything in DMARC is based is = the=20 5322.From, if you change to use something different, is it even DMARC a= nymore? Scott K On Thursday, April 23, 2015 05:33:53 PM Terry Zink wrote: I=E2=80=99ve played around a bit with Gmail, Hotmail/outlook.com, and O= utlook desktop=20 client. Here=E2=80=99s what I have found so far. =20 Gmail and Hotmail have similar but not identical behavior: =20 1. If the 5322.From address is in your address book or you have a= =20 conversational history (implicit contact) or is on your safe senders (i= n=20 Hotmail), then Gmail, Hotmail, and Outlook show only the Friendly From=20= (display from) and not the 5322.From full address. If it isn=E2=80=99t = in your=20 contacts, then all show the display from + 5322.from email address. 2. If the 5321.mailfrom is different than the 5322.From, Gmail sh= ows=20 =E2=80=9CDisplay From via 5321.m= ailfrom=E2=80=9D=20 whereas outlook.com and Outlook desktop don=E2=80=99t show the discrepa= ncy at all=20 (i.e., no equivalent of =E2=80=98via=E2=80=99 in Hotmail or Outlook des= ktop). Gmail does not=20 show the via if the 5322.from domain and 5321.mailfrom domains are the = same=20 which is why there is a recommendation to authenticate with SPF and DKI= M. 3. Neither Gmail nor Hotmail show the Sender: header at all. Outl= ook=20 desktop shows =E2=80=9C on behalf of .=E2=80=9D =20 I haven=E2=80=99t done a large matrix of testing but I have played arou= nd with=20 different rendering; obviously, spam filtering and searching for conver= sational=20 history may have something to do with it, too. =20 -- Terry =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Brandon Long Sent: Wednesday, April 22, 2015 5:29 PM To: Douglas Otis Cc: dmarc ietf Subject: Re: [dmarc-ietf] Dmarc-escape draft available =20 Gmail will display the Sender information with a on behalf of or simila= r in=20 certain circumstances when we think its necessary to give the user more= =20 information. =20 99% of users won't use the more information for anything useful or even= really=20 notice it or at best get confused, but eh. =20 More information: https://support.google.com/mail/answer/1311182?hl=3De= n =20 So, the messages on this list have "via ietf.org" next to the author, f= or=20 example. =20 Brandon =20 On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis = wrote: On 4/21/15 4:20 PM, Terry Zink wrote: > Some quick comments: > > - Section 3 is really short. Some examples of how it would work would= be=20 nice. > - Regarding this from section 3: > > This makes an assumption users employ Mail User Agents that dis= play=20 the > identity contained in the Sender header field when used as a ba= sis > for acceptance. > > I've tested Hotmail and Gmail and both suppress the Sender: header = in=20 favor of the 5322.From address. Conversely, Outlook and Outlook Web Acc= ess=20 (OWA) show it as " on behalf of ". > > -- Terry > On 4/21/15 4:20 PM, Terry Zink wrote: > Some quick comments: > > - Section 3 is really short. Some examples of how it would work would= be=20 nice. > - Regarding this from section 3: > > This makes an assumption users employ Mail User Agents that dis= play=20 the > identity contained in the Sender header field when used as a ba= sis > for acceptance. > > I've tested Hotmail and Gmail and both suppress the Sender: header = in=20 favor of the 5322.From address. Conversely, Outlook and Outlook Web Acc= ess=20 (OWA) show it as " on behalf of ". > > -- Terry Dear Terry, You make a good point. I consider on behalf of a reasonable approach. It takes seconds using OS X Mail (Mail, Preferences, Viewing, Show message headers: custom, type Sender) to display the Sender header. It is not displayed when it is not there of course, nor is this setting the default. For Thunderbird, users will need to access Preferences, Advanced, General tab, click Config Editor, Enter mail.compose.other.header and double click mail.compose.other.header entry and type the desired headers in the string dialog. For other MUAs beyond Outlook, Mail, and Thunderbird, this may require plugins or similar tinkering. Nonetheless, Sender header protection is available and likely something better configured using a script offered by the provider. In the early days when working with Iconix, they were able to offer fairly comprehensive coverage for web access and MUA using javascript overlays with company icons. This improved source trust based on verification methods then available. It seems these MUAs offer proof it can be done and Iconix proved people could understand the results. This seems rather important since it is the Sender being trusted in most cases; the result of mail's store and forwarding protocol. DKIM and SPF only offer assurances between hops. Use of IM-From better protects the role of author and enables improved availability for direct paths while also offering greater flexibility at adding easily noticable information. http://tools.ietf.org/html/draft-otis-dmarc-escape-00 Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc =20 From nobody Thu Apr 23 10:54:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313B61B29A3 for ; Thu, 23 Apr 2015 10:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.357 X-Spam-Level: *** X-Spam-Status: No, score=3.357 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_PROFIT1=3.858, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Na_RY7rPqHN1 for ; Thu, 23 Apr 2015 10:54:06 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0090.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49B71B310F for ; Thu, 23 Apr 2015 10:53:51 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.1.160.4; Thu, 23 Apr 2015 17:53:31 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) with mapi id 15.01.0160.000; Thu, 23 Apr 2015 17:53:31 +0000 From: Terry Zink To: dmarc ietf Thread-Topic: [dmarc-ietf] Dmarc-escape draft available Thread-Index: AQHQfIhiDokkbZdMr06f8XE7BXT8aZ1YGdwAgAE41ICAAG0oAIABHCLAgAAE5+A= Date: Thu, 23 Apr 2015 17:53:30 +0000 Message-ID: References: <5536D8D6.7080305@gmail.com> <5537E12B.6030607@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.107] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(51704005)(24454002)(199003)(377454003)(189002)(479174004)(105586002)(19609705001)(54356999)(106356001)(92566002)(450100001)(62966003)(101416001)(77156002)(5001860100001)(2656002)(19617315012)(87936001)(33656002)(68736005)(15975445007)(19625215002)(16236675004)(86362001)(4001540100001)(97736004)(81156007)(46102003)(107886001)(2900100001)(102836002)(93886004)(50986999)(76176999)(106116001)(110136001)(66066001)(64706001)(19300405004)(5001830100001)(2950100001)(19580395003)(19580405001)(16601075003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB605; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB605; x-forefront-prvs: 0555EC8317 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB60500247596CDBBFDD6688796ED0BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2015 17:53:31.1278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB605 Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:54:09 -0000 --_000_BL2SR01MB60500247596CDBBFDD6688796ED0BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG91ZywNCg0KPiBJdCB0YWtlcyBzZWNvbmRzIHVzaW5nIE9TIFggTWFpbCDigKYNCj4NCj4gRm9y IFRodW5kZXJiaXJkLCB1c2VycyB3aWxsIG5lZWQgdG8gYWNjZXNzIOKApg0KPg0KPiBGb3Igb3Ro ZXIgTVVBcyB0aGlzIG1heSByZXF1aXJlIHBsdWdpbnMgb3Igc2ltaWxhcg0KPiB0aW5rZXJpbmfi gKYNCj4NCj4gTm9uZXRoZWxlc3MsIFNlbmRlciBoZWFkZXIgcHJvdGVjdGlvbiBpcw0KPiBhdmFp bGFibGUgYW5kIGxpa2VseSBzb21ldGhpbmcgYmV0dGVyIGNvbmZpZ3VyZWQgdXNpbmcgYQ0KPiBz Y3JpcHQgb2ZmZXJlZCBieSB0aGUgcHJvdmlkZXIuDQoNClJlcXVpcmluZyB1c2VycyB0byBoYXZl IHRvIGRvIHNvbWV0aGluZyBpcyBub3QgYSBnb29kIHNvbHV0aW9uIGJlY2F1c2UgdGhlIGF2ZXJh Z2UgdXNlciBkb2VzbuKAmXQgdW5kZXJzdGFuZCBhbmQgd29u4oCZdCBkbyBpdC4gV2XigJlkIGhh dmUgdG8gY29udmluY2UgbWFpbCBjbGllbnRzIHRvIHNob3cgaXQgYnkgZGVmYXVsdCwgYW5kIGF0 IGxlYXN0IHR3byBsYXJnZSBwcm92aWRlcnMgKEhvdG1haWwgYW5kIEdtYWlsKSBkb27igJl0IGRv IGl0IHRvZGF5LCBhbmQgbW9zdCBsYXJnZWx5LWRlcGxveWVkIG1haWwgY2xpZW50cyBkb27igJl0 LCBlaXRoZXIgKE91dGxvb2sgYmVpbmcgYW4gZXhjZXB0aW9uKS4NCg0KSSBkb27igJl0IHVuZGVy c3RhbmQgdGhlIGZsb3cgb2YgdGhpbmdzIGZvciBhIFNlbmRlcjogaGVhZGVyIGFsaWdubWVudCB0 aGF0IHlvdSBwcm9wb3NlLiBJcyBpdCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQpNZXNzYWdlIDEN Cj09PT09PT09DQo1MzIxLk1haWxGcm9tOiA8dHppbmtAZXhhbXBsZS5jb20+DQpGcm9tOiBUZXJy eSBaaW5rIDx0emlua0BleGFtcGxlLmNvbT4NClNlbmRlcjogVGVycnkgWmluayA8dHppbmtAZXhh bXBsZS5jb20+DQpUbzogbWFpbGluZyBsaXN0IDxtYWlsaW5nLWxpc3RAbWFpbGluZy1saXN0LmNv bT4NClN1YmplY3Q6IEhlcmUgaXMgYSBtZXNzYWdlDQpES0lNLVNpZ25hdHVyZTogZD1leGFtcGxl LmNvbSBbU2lnbmF0dXJlIGlzIGludGFjdF0NCg0KTWVzc2FnZSAyIGFmdGVyIHJlcGxheWluZw0K PT09PT09PT09PT09PT09PT09PQ0KDQo1MzIxLk1haWxGcm9tOiA8bWFpbGluZy1saXN0QG1haWxp bmctbGlzdC5jb20+DQpGcm9tOiBUZXJyeSBaaW5rIDx0emlua0BleGFtcGxlLmNvbT4NClRvOiBE b3VnIE90aXMgPC4uPg0KU2VuZGVyOiBUZXJyeSBaaW5rIDx0emlua0BleGFtcGxlLmNvbQ0KU3Vi amVjdDogW01BSUxJTkcgTElTVF0gSGVyZSBpcyBhIG1lc3NhZ2UNCkRLSU0tU2lnbmF0dXJlOiBk PWV4YW1wbGUuY29tIFtTaWduYXR1cmUgYnJva2VuXQ0KREtJTS1TaWduYXR1cmU6IGQ9bWFpbGlu Zy1saXN0LmNvbSBbU2lnbmF0dXJlIGludGFjdF0NCg0KV2hhdOKAmXMgc3VwcG9zZWQgdG8gaGFw cGVuIG5leHQ/DQoNCi0tIFRlcnJ5DQoNCkZyb206IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlcnJ5IFppbmsNClNlbnQ6IFRodXJzZGF5LCBBcHJp bCAyMywgMjAxNSAxMDozNCBBTQ0KVG86IEJyYW5kb24gTG9uZzsgRG91Z2xhcyBPdGlzDQpDYzog ZG1hcmMgaWV0Zg0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBEbWFyYy1lc2NhcGUgZHJhZnQg YXZhaWxhYmxlDQoNCknigJl2ZSBwbGF5ZWQgYXJvdW5kIGEgYml0IHdpdGggR21haWwsIEhvdG1h aWwvb3V0bG9vay5jb20sIGFuZCBPdXRsb29rIGRlc2t0b3AgY2xpZW50LiBIZXJl4oCZcyB3aGF0 IEkgaGF2ZSBmb3VuZCBzbyBmYXIuDQoNCkdtYWlsIGFuZCBIb3RtYWlsIGhhdmUgc2ltaWxhciBi dXQgbm90IGlkZW50aWNhbCBiZWhhdmlvcjoNCg0KDQoxLiAgICAgICBJZiB0aGUgNTMyMi5Gcm9t IGFkZHJlc3MgaXMgaW4geW91ciBhZGRyZXNzIGJvb2sgb3IgeW91IGhhdmUgYSBjb252ZXJzYXRp b25hbCBoaXN0b3J5IChpbXBsaWNpdCBjb250YWN0KSBvciBpcyBvbiB5b3VyIHNhZmUgc2VuZGVy cyAoaW4gSG90bWFpbCksIHRoZW4gR21haWwsIEhvdG1haWwsIGFuZCBPdXRsb29rIHNob3cgb25s eSB0aGUgRnJpZW5kbHkgRnJvbSAoZGlzcGxheSBmcm9tKSBhbmQgbm90IHRoZSA1MzIyLkZyb20g ZnVsbCBhZGRyZXNzLiBJZiBpdCBpc27igJl0IGluIHlvdXIgY29udGFjdHMsIHRoZW4gYWxsIHNo b3cgdGhlIGRpc3BsYXkgZnJvbSArIDUzMjIuZnJvbSBlbWFpbCBhZGRyZXNzLg0KDQoyLiAgICAg ICBJZiB0aGUgNTMyMS5tYWlsZnJvbSBpcyBkaWZmZXJlbnQgdGhhbiB0aGUgNTMyMi5Gcm9tLCBH bWFpbCBzaG93cyDigJxEaXNwbGF5IEZyb20gPGFuZCA1MzIyLkZyb20gaWYgbm90IGluIGFkZHJl c3MgYm9vaz4gdmlhIDUzMjEubWFpbGZyb23igJ0gd2hlcmVhcyBvdXRsb29rLmNvbSBhbmQgT3V0 bG9vayBkZXNrdG9wIGRvbuKAmXQgc2hvdyB0aGUgZGlzY3JlcGFuY3kgYXQgYWxsIChpLmUuLCBu byBlcXVpdmFsZW50IG9mIOKAmHZpYeKAmSBpbiBIb3RtYWlsIG9yIE91dGxvb2sgZGVza3RvcCku IEdtYWlsIGRvZXMgbm90IHNob3cgdGhlIHZpYSBpZiB0aGUgNTMyMi5mcm9tIGRvbWFpbiBhbmQg NTMyMS5tYWlsZnJvbSBkb21haW5zIGFyZSB0aGUgc2FtZSB3aGljaCBpcyB3aHkgdGhlcmUgaXMg YSByZWNvbW1lbmRhdGlvbiB0byBhdXRoZW50aWNhdGUgd2l0aCBTUEYgYW5kIERLSU0uDQoNCjMu ICAgICAgIE5laXRoZXIgR21haWwgbm9yIEhvdG1haWwgc2hvdyB0aGUgU2VuZGVyOiBoZWFkZXIg YXQgYWxsLiBPdXRsb29rIGRlc2t0b3Agc2hvd3Mg4oCcPHNlbmRlcj4gb24gYmVoYWxmIG9mIDxm cm9tPi7igJ0NCg0KSSBoYXZlbuKAmXQgZG9uZSBhIGxhcmdlIG1hdHJpeCBvZiB0ZXN0aW5nIGJ1 dCBJIGhhdmUgcGxheWVkIGFyb3VuZCB3aXRoIGRpZmZlcmVudCByZW5kZXJpbmc7IG9idmlvdXNs eSwgc3BhbSBmaWx0ZXJpbmcgYW5kIHNlYXJjaGluZyBmb3IgY29udmVyc2F0aW9uYWwgaGlzdG9y eSBtYXkgaGF2ZSBzb21ldGhpbmcgdG8gZG8gd2l0aCBpdCwgdG9vLg0KDQotLSBUZXJyeQ0KDQpG cm9tOiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmFuZG9uIExvbmcNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjIsIDIwMTUgNToyOSBQTQ0KVG86 IERvdWdsYXMgT3Rpcw0KQ2M6IGRtYXJjIGlldGYNClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0g RG1hcmMtZXNjYXBlIGRyYWZ0IGF2YWlsYWJsZQ0KDQpHbWFpbCB3aWxsIGRpc3BsYXkgdGhlIFNl bmRlciBpbmZvcm1hdGlvbiB3aXRoIGEgb24gYmVoYWxmIG9mIG9yIHNpbWlsYXIgaW4gY2VydGFp biBjaXJjdW1zdGFuY2VzIHdoZW4gd2UgdGhpbmsgaXRzIG5lY2Vzc2FyeSB0byBnaXZlIHRoZSB1 c2VyIG1vcmUgaW5mb3JtYXRpb24uDQoNCjk5JSBvZiB1c2VycyB3b24ndCB1c2UgdGhlIG1vcmUg aW5mb3JtYXRpb24gZm9yIGFueXRoaW5nIHVzZWZ1bCBvciBldmVuIHJlYWxseSBub3RpY2UgaXQg b3IgYXQgYmVzdCBnZXQgY29uZnVzZWQsIGJ1dCBlaC4NCg0KTW9yZSBpbmZvcm1hdGlvbjogaHR0 cHM6Ly9zdXBwb3J0Lmdvb2dsZS5jb20vbWFpbC9hbnN3ZXIvMTMxMTE4Mj9obD1lbg0KDQpTbywg dGhlIG1lc3NhZ2VzIG9uIHRoaXMgbGlzdCBoYXZlICJ2aWEgaWV0Zi5vcmc8aHR0cDovL2lldGYu b3JnPiIgbmV4dCB0byB0aGUgYXV0aG9yLCBmb3IgZXhhbXBsZS4NCg0KQnJhbmRvbg0KDQpPbiBX ZWQsIEFwciAyMiwgMjAxNSBhdCAxMDo1OCBBTSwgRG91Z2xhcyBPdGlzIDxkb3VnLm10dmlld0Bn bWFpbC5jb208bWFpbHRvOmRvdWcubXR2aWV3QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCk9uIDQv MjEvMTUgNDoyMCBQTSwgVGVycnkgWmluayB3cm90ZToNCj4gU29tZSBxdWljayBjb21tZW50czoN Cj4NCj4gLSBTZWN0aW9uIDMgaXMgcmVhbGx5IHNob3J0LiBTb21lIGV4YW1wbGVzIG9mIGhvdyBp dCB3b3VsZCB3b3JrIHdvdWxkIGJlIG5pY2UuDQo+IC0gUmVnYXJkaW5nIHRoaXMgZnJvbSBzZWN0 aW9uIDM6DQo+DQo+ICAgICAgIFRoaXMgbWFrZXMgYW4gYXNzdW1wdGlvbiB1c2VycyBlbXBsb3kg TWFpbCBVc2VyIEFnZW50cyB0aGF0IGRpc3BsYXkgdGhlDQo+ICAgICAgIGlkZW50aXR5IGNvbnRh aW5lZCBpbiB0aGUgU2VuZGVyIGhlYWRlciBmaWVsZCB3aGVuIHVzZWQgYXMgYSBiYXNpcw0KPiAg ICAgICBmb3IgYWNjZXB0YW5jZS4NCj4NCj4gICBJJ3ZlIHRlc3RlZCBIb3RtYWlsIGFuZCBHbWFp bCBhbmQgYm90aCBzdXBwcmVzcyB0aGUgU2VuZGVyOiBoZWFkZXIgaW4gZmF2b3Igb2YgdGhlIDUz MjIuRnJvbSBhZGRyZXNzLiBDb252ZXJzZWx5LCBPdXRsb29rIGFuZCBPdXRsb29rIFdlYiBBY2Nl c3MgKE9XQSkgc2hvdyBpdCBhcyAiPHNlbmRlcj4gb24gYmVoYWxmIG9mIDxmcm9tPiIuDQo+DQo+ IC0tIFRlcnJ5DQo+DQoNCk9uIDQvMjEvMTUgNDoyMCBQTSwgVGVycnkgWmluayB3cm90ZToNCg0K PiBTb21lIHF1aWNrIGNvbW1lbnRzOg0KPg0KPiAtIFNlY3Rpb24gMyBpcyByZWFsbHkgc2hvcnQu IFNvbWUgZXhhbXBsZXMgb2YgaG93IGl0IHdvdWxkIHdvcmsgd291bGQgYmUgbmljZS4NCj4gLSBS ZWdhcmRpbmcgdGhpcyBmcm9tIHNlY3Rpb24gMzoNCj4NCj4gICAgICAgVGhpcyBtYWtlcyBhbiBh c3N1bXB0aW9uIHVzZXJzIGVtcGxveSBNYWlsIFVzZXIgQWdlbnRzIHRoYXQgZGlzcGxheSB0aGUN Cj4gICAgICAgaWRlbnRpdHkgY29udGFpbmVkIGluIHRoZSBTZW5kZXIgaGVhZGVyIGZpZWxkIHdo ZW4gdXNlZCBhcyBhIGJhc2lzDQo+ICAgICAgIGZvciBhY2NlcHRhbmNlLg0KPg0KPiAgIEkndmUg dGVzdGVkIEhvdG1haWwgYW5kIEdtYWlsIGFuZCBib3RoIHN1cHByZXNzIHRoZSBTZW5kZXI6IGhl YWRlciBpbiBmYXZvciBvZiB0aGUgNTMyMi5Gcm9tIGFkZHJlc3MuIENvbnZlcnNlbHksIE91dGxv b2sgYW5kIE91dGxvb2sgV2ViIEFjY2VzcyAoT1dBKSBzaG93IGl0IGFzICI8c2VuZGVyPiBvbiBi ZWhhbGYgb2YgPGZyb20+Ii4NCj4NCj4gLS0gVGVycnkNCg0KRGVhciBUZXJyeSwNCg0KWW91IG1h a2UgYSBnb29kIHBvaW50LiBJIGNvbnNpZGVyIDxzZW5kZXI+IG9uIGJlaGFsZiBvZg0KPGZyb20+ IGEgcmVhc29uYWJsZSBhcHByb2FjaC4gSXQgdGFrZXMgc2Vjb25kcyB1c2luZyBPUyBYDQpNYWls IChNYWlsLCBQcmVmZXJlbmNlcywgVmlld2luZywgU2hvdyBtZXNzYWdlIGhlYWRlcnM6DQpjdXN0 b20sIHR5cGUgU2VuZGVyKSB0byBkaXNwbGF5IHRoZSBTZW5kZXIgaGVhZGVyLiAgSXQgaXMNCm5v dCBkaXNwbGF5ZWQgd2hlbiBpdCBpcyBub3QgdGhlcmUgb2YgY291cnNlLCBub3IgaXMgdGhpcw0K c2V0dGluZyB0aGUgZGVmYXVsdC4NCg0KRm9yIFRodW5kZXJiaXJkLCB1c2VycyB3aWxsIG5lZWQg dG8gYWNjZXNzIFByZWZlcmVuY2VzLA0KQWR2YW5jZWQsIEdlbmVyYWwgdGFiLCBjbGljayBDb25m aWcgRWRpdG9yLCBFbnRlcg0KbWFpbC5jb21wb3NlLm90aGVyLmhlYWRlciBhbmQgZG91YmxlIGNs aWNrDQptYWlsLmNvbXBvc2Uub3RoZXIuaGVhZGVyIGVudHJ5IGFuZCB0eXBlIHRoZSBkZXNpcmVk IGhlYWRlcnMNCmluIHRoZSBzdHJpbmcgZGlhbG9nLiAgRm9yIG90aGVyIE1VQXMgYmV5b25kIE91 dGxvb2ssIE1haWwsDQphbmQgVGh1bmRlcmJpcmQsIHRoaXMgbWF5IHJlcXVpcmUgcGx1Z2lucyBv ciBzaW1pbGFyDQp0aW5rZXJpbmcuICBOb25ldGhlbGVzcywgU2VuZGVyIGhlYWRlciBwcm90ZWN0 aW9uIGlzDQphdmFpbGFibGUgYW5kIGxpa2VseSBzb21ldGhpbmcgYmV0dGVyIGNvbmZpZ3VyZWQg dXNpbmcgYQ0Kc2NyaXB0IG9mZmVyZWQgYnkgdGhlIHByb3ZpZGVyLg0KDQpJbiB0aGUgZWFybHkg ZGF5cyB3aGVuIHdvcmtpbmcgd2l0aCBJY29uaXgsIHRoZXkgd2VyZSBhYmxlDQp0byBvZmZlciBm YWlybHkgY29tcHJlaGVuc2l2ZSBjb3ZlcmFnZSBmb3Igd2ViIGFjY2VzcyBhbmQNCk1VQSB1c2lu ZyBqYXZhc2NyaXB0IG92ZXJsYXlzIHdpdGggY29tcGFueSBpY29ucy4gIFRoaXMNCmltcHJvdmVk IHNvdXJjZSB0cnVzdCBiYXNlZCBvbiB2ZXJpZmljYXRpb24gbWV0aG9kcyB0aGVuDQphdmFpbGFi bGUuICBJdCBzZWVtcyB0aGVzZSBNVUFzIG9mZmVyIHByb29mIGl0IGNhbiBiZSBkb25lDQphbmQg SWNvbml4IHByb3ZlZCBwZW9wbGUgY291bGQgdW5kZXJzdGFuZCB0aGUgcmVzdWx0cy4gIFRoaXMN CnNlZW1zIHJhdGhlciBpbXBvcnRhbnQgc2luY2UgaXQgaXMgdGhlIFNlbmRlciBiZWluZyB0cnVz dGVkDQppbiBtb3N0IGNhc2VzOyB0aGUgcmVzdWx0IG9mIG1haWwncyBzdG9yZSBhbmQgZm9yd2Fy ZGluZw0KcHJvdG9jb2wuIERLSU0gYW5kIFNQRiBvbmx5IG9mZmVyIGFzc3VyYW5jZXMgYmV0d2Vl biBob3BzLg0KVXNlIG9mIElNLUZyb20gYmV0dGVyIHByb3RlY3RzIHRoZSByb2xlIG9mIGF1dGhv ciBhbmQNCmVuYWJsZXMgaW1wcm92ZWQgYXZhaWxhYmlsaXR5IGZvciBkaXJlY3QgcGF0aHMgd2hp bGUgYWxzbw0Kb2ZmZXJpbmcgZ3JlYXRlciBmbGV4aWJpbGl0eSBhdCBhZGRpbmcgZWFzaWx5IG5v dGljYWJsZQ0KaW5mb3JtYXRpb24uDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW90aXMtZG1hcmMtZXNjYXBlLTAwDQoNCg0KUmVnYXJkcywNCkRvdWdsYXMgT3Rpcw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFpbGlu ZyBsaXN0DQpkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjDQoNCg== --_000_BL2SR01MB60500247596CDBBFDD6688796ED0BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg3Mzg4MDI2MzsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTk1NjMwNjY4 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RG91Zyw8bzpwPjwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEl0IHRha2VzIHNlY29uZHMgdXNpbmcgT1MgWCBNYWls IOKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyA8YnI+DQomZ3Q7 IEZvciBUaHVuZGVyYmlyZCwgdXNlcnMgd2lsbCBuZWVkIHRvIGFjY2VzcyDigKY8YnI+DQomZ3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEZvciBvdGhlciBNVUFz IHRoaXMgbWF5IHJlcXVpcmUgcGx1Z2lucyBvciBzaW1pbGFyPGJyPg0KJmd0OyB0aW5rZXJpbmfi gKYmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE5vbmV0aGVsZXNzLCBT ZW5kZXIgaGVhZGVyIHByb3RlY3Rpb24gaXM8YnI+DQomZ3Q7IGF2YWlsYWJsZSBhbmQgbGlrZWx5 IHNvbWV0aGluZyBiZXR0ZXIgY29uZmlndXJlZCB1c2luZyBhPGJyPg0KJmd0OyBzY3JpcHQgb2Zm ZXJlZCBieSB0aGUgcHJvdmlkZXIuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5SZXF1aXJpbmcgdXNlcnMgdG8gaGF2ZSB0byBkbyBzb21ldGhpbmcg aXMgbm90IGEgZ29vZCBzb2x1dGlvbiBiZWNhdXNlIHRoZSBhdmVyYWdlIHVzZXIgZG9lc27igJl0 IHVuZGVyc3RhbmQgYW5kIHdvbuKAmXQgZG8gaXQuIFdl4oCZZCBoYXZlIHRvIGNvbnZpbmNlIG1h aWwgY2xpZW50cyB0byBzaG93IGl0IGJ5IGRlZmF1bHQsDQogYW5kIGF0IGxlYXN0IHR3byBsYXJn ZSBwcm92aWRlcnMgKEhvdG1haWwgYW5kIEdtYWlsKSBkb27igJl0IGRvIGl0IHRvZGF5LCBhbmQg bW9zdCBsYXJnZWx5LWRlcGxveWVkIG1haWwgY2xpZW50cyBkb27igJl0LCBlaXRoZXIgKE91dGxv b2sgYmVpbmcgYW4gZXhjZXB0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGZs b3cgb2YgdGhpbmdzIGZvciBhIFNlbmRlcjogaGVhZGVyIGFsaWdubWVudCB0aGF0IHlvdSBwcm9w b3NlLiBJcyBpdCBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PGJyPg0KTWVzc2FnZSAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj49PT09PT09PTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+NTMyMS5NYWlsRnJvbTogJmx0O3R6aW5rQGV4YW1w bGUuY29tJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTogVGVycnkgWmluayAm bHQ7dHppbmtAZXhhbXBsZS5jb20mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TZW5k ZXI6IFRlcnJ5IFppbmsgJmx0O3R6aW5rQGV4YW1wbGUuY29tJmd0Ozxicj4NClRvOiBtYWlsaW5n IGxpc3QgJmx0O21haWxpbmctbGlzdEBtYWlsaW5nLWxpc3QuY29tJmd0Ozxicj4NClN1YmplY3Q6 IEhlcmUgaXMgYSBtZXNzYWdlPGJyPg0KREtJTS1TaWduYXR1cmU6IGQ9ZXhhbXBsZS5jb20gW1Np Z25hdHVyZSBpcyBpbnRhY3RdPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5NZXNzYWdlIDIgYWZ0ZXIgcmVwbGF5aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj49 PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjUzMjEuTWFpbEZyb206ICZsdDttYWlsaW5nLWxpc3RA bWFpbGluZy1saXN0LmNvbSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206IFRl cnJ5IFppbmsgJmx0O3R6aW5rQGV4YW1wbGUuY29tJmd0Ozxicj4NClRvOiBEb3VnIE90aXMgJmx0 Oy4uJmd0Ozxicj4NClNlbmRlcjogVGVycnkgWmluayAmbHQ7dHppbmtAZXhhbXBsZS5jb208YnI+ DQpTdWJqZWN0OiBbTUFJTElORyBMSVNUXSBIZXJlIGlzIGEgbWVzc2FnZTxicj4NCkRLSU0tU2ln bmF0dXJlOiBkPWV4YW1wbGUuY29tIFtTaWduYXR1cmUgYnJva2VuXTxicj4NCkRLSU0tU2lnbmF0 dXJlOiBkPW1haWxpbmctbGlzdC5jb20gW1NpZ25hdHVyZSBpbnRhY3RdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldoYXTigJlz IHN1cHBvc2VkIHRvIGhhcHBlbiBuZXh0Pw0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRt YXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ VGVycnkgWmluazxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTA6 MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyYW5kb24gTG9uZzsgRG91Z2xhcyBPdGlzPGJyPg0KPGI+ Q2M6PC9iPiBkbWFyYyBpZXRmPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZG1hcmMtaWV0Zl0g RG1hcmMtZXNjYXBlIGRyYWZ0IGF2YWlsYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SeKAmXZlIHBsYXllZCBhcm91bmQgYSBiaXQgd2l0aCBHbWFpbCwgSG90bWFpbC9vdXRsb29r LmNvbSwgYW5kIE91dGxvb2sgZGVza3RvcCBjbGllbnQuIEhlcmXigJlzIHdoYXQgSSBoYXZlIGZv dW5kIHNvIGZhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+R21haWwgYW5kIEhvdG1haWwgaGF2ZSBzaW1pbGFyIGJ1dCBub3Qg aWRlbnRpY2FsIGJlaGF2aW9yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SWYgdGhlIDUzMjIuRnJvbSBhZGRyZXNzIGlzIGluIHlvdXIgYWRkcmVz cyBib29rIG9yIHlvdSBoYXZlIGEgY29udmVyc2F0aW9uYWwgaGlzdG9yeSAoaW1wbGljaXQgY29u dGFjdCkgb3IgaXMgb24geW91ciBzYWZlIHNlbmRlcnMgKGluIEhvdG1haWwpLCB0aGVuDQogR21h aWwsIEhvdG1haWwsIGFuZCBPdXRsb29rIHNob3cgb25seSB0aGUgRnJpZW5kbHkgRnJvbSAoZGlz cGxheSBmcm9tKSBhbmQgbm90IHRoZSA1MzIyLkZyb20gZnVsbCBhZGRyZXNzLiBJZiBpdCBpc27i gJl0IGluIHlvdXIgY29udGFjdHMsIHRoZW4gYWxsIHNob3cgdGhlIGRpc3BsYXkgZnJvbSAmIzQz OyA1MzIyLmZyb20gZW1haWwgYWRkcmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB0aGUgNTMyMS5t YWlsZnJvbSBpcyBkaWZmZXJlbnQgdGhhbiB0aGUgNTMyMi5Gcm9tLCBHbWFpbCBzaG93cyDigJxE aXNwbGF5IEZyb20gJmx0O2FuZCA1MzIyLkZyb20gaWYgbm90IGluIGFkZHJlc3MgYm9vayZndDsg dmlhIDUzMjEubWFpbGZyb23igJ0gd2hlcmVhcyBvdXRsb29rLmNvbQ0KIGFuZCBPdXRsb29rIGRl c2t0b3AgZG9u4oCZdCBzaG93IHRoZSBkaXNjcmVwYW5jeSBhdCBhbGwgKGkuZS4sIG5vIGVxdWl2 YWxlbnQgb2Yg4oCYdmlh4oCZIGluIEhvdG1haWwgb3IgT3V0bG9vayBkZXNrdG9wKS4gR21haWwg ZG9lcyBub3Qgc2hvdyB0aGUgdmlhIGlmIHRoZSA1MzIyLmZyb20gZG9tYWluIGFuZCA1MzIxLm1h aWxmcm9tIGRvbWFpbnMgYXJlIHRoZSBzYW1lIHdoaWNoIGlzIHdoeSB0aGVyZSBpcyBhIHJlY29t bWVuZGF0aW9uIHRvIGF1dGhlbnRpY2F0ZQ0KIHdpdGggU1BGIGFuZCBES0lNLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk5laXRoZXIgR21haWwgbm9yIEhvdG1haWwgc2hvdyB0aGUgU2VuZGVyOiBoZWFkZXIg YXQgYWxsLiBPdXRsb29rIGRlc2t0b3Agc2hvd3Mg4oCcJmx0O3NlbmRlciZndDsgb24gYmVoYWxm IG9mICZsdDtmcm9tJmd0Oy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSBoYXZlbuKAmXQgZG9uZSBhIGxhcmdlIG1hdHJp eCBvZiB0ZXN0aW5nIGJ1dCBJIGhhdmUgcGxheWVkIGFyb3VuZCB3aXRoIGRpZmZlcmVudCByZW5k ZXJpbmc7IG9idmlvdXNseSwgc3BhbSBmaWx0ZXJpbmcgYW5kIHNlYXJjaGluZyBmb3IgY29udmVy c2F0aW9uYWwgaGlzdG9yeQ0KIG1heSBoYXZlIHNvbWV0aGluZyB0byBkbyB3aXRoIGl0LCB0b28u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPi0tIFRlcnJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBkbWFyYyBbPGEgaHJlZj0ibWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpk bWFyYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJhbmRvbiBM b25nPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjIsIDIwMTUgNToyOSBQTTxi cj4NCjxiPlRvOjwvYj4gRG91Z2xhcyBPdGlzPGJyPg0KPGI+Q2M6PC9iPiBkbWFyYyBpZXRmPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZG1hcmMtaWV0Zl0gRG1hcmMtZXNjYXBlIGRyYWZ0IGF2 YWlsYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdtYWlsIHdpbGwg ZGlzcGxheSB0aGUgU2VuZGVyIGluZm9ybWF0aW9uIHdpdGggYSBvbiBiZWhhbGYgb2Ygb3Igc2lt aWxhciBpbiBjZXJ0YWluIGNpcmN1bXN0YW5jZXMgd2hlbiB3ZSB0aGluayBpdHMgbmVjZXNzYXJ5 IHRvIGdpdmUgdGhlIHVzZXIgbW9yZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjk5JSBvZiB1c2VycyB3b24ndCB1c2UgdGhlIG1vcmUg aW5mb3JtYXRpb24gZm9yIGFueXRoaW5nIHVzZWZ1bCBvciBldmVuIHJlYWxseSBub3RpY2UgaXQg b3IgYXQgYmVzdCBnZXQgY29uZnVzZWQsIGJ1dCBlaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9yZSBpbmZvcm1hdGlvbjombmJzcDs8YSBo cmVmPSJodHRwczovL3N1cHBvcnQuZ29vZ2xlLmNvbS9tYWlsL2Fuc3dlci8xMzExMTgyP2hsPWVu Ij5odHRwczovL3N1cHBvcnQuZ29vZ2xlLmNvbS9tYWlsL2Fuc3dlci8xMzExMTgyP2hsPWVuPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T bywgdGhlIG1lc3NhZ2VzIG9uIHRoaXMgbGlzdCBoYXZlICZxdW90O3ZpYSA8YSBocmVmPSJodHRw Oi8vaWV0Zi5vcmciPg0KaWV0Zi5vcmc8L2E+JnF1b3Q7IG5leHQgdG8gdGhlIGF1dGhvciwgZm9y IGV4YW1wbGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJyYW5kb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMjIsIDIwMTUgYXQgMTA6NTggQU0sIERvdWdsYXMgT3Rp cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRvdWcubXR2aWV3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmRvdWcubXR2aWV3QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiA0LzIxLzE1IDQ6MjAgUE0sIFRlcnJ5IFppbmsg d3JvdGU6PGJyPg0KJmd0OyBTb21lIHF1aWNrIGNvbW1lbnRzOjxicj4NCiZndDs8YnI+DQomZ3Q7 IC0gU2VjdGlvbiAzIGlzIHJlYWxseSBzaG9ydC4gU29tZSBleGFtcGxlcyBvZiBob3cgaXQgd291 bGQgd29yayB3b3VsZCBiZSBuaWNlLjxicj4NCiZndDsgLSBSZWdhcmRpbmcgdGhpcyBmcm9tIHNl Y3Rpb24gMzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Ro aXMgbWFrZXMgYW4gYXNzdW1wdGlvbiB1c2VycyBlbXBsb3kgTWFpbCBVc2VyIEFnZW50cyB0aGF0 IGRpc3BsYXkgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aXR5 IGNvbnRhaW5lZCBpbiB0aGUgU2VuZGVyIGhlYWRlciBmaWVsZCB3aGVuIHVzZWQgYXMgYSBiYXNp czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgYWNjZXB0YW5jZS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtJJ3ZlIHRlc3RlZCBIb3RtYWlsIGFuZCBHbWFp bCBhbmQgYm90aCBzdXBwcmVzcyB0aGUgU2VuZGVyOiBoZWFkZXIgaW4gZmF2b3Igb2YgdGhlIDUz MjIuRnJvbSBhZGRyZXNzLiBDb252ZXJzZWx5LCBPdXRsb29rIGFuZCBPdXRsb29rIFdlYiBBY2Nl c3MgKE9XQSkgc2hvdyBpdCBhcyAmcXVvdDsmbHQ7c2VuZGVyJmd0OyBvbiBiZWhhbGYgb2YgJmx0 O2Zyb20mZ3Q7JnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7IC0tIFRlcnJ5PGJyPg0KJmd0Ozxi cj4NCjxicj4NCk9uIDQvMjEvMTUgNDoyMCBQTSwgVGVycnkgWmluayB3cm90ZTo8YnI+DQo8YnI+ DQomZ3Q7IFNvbWUgcXVpY2sgY29tbWVudHM6PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBTZWN0aW9u IDMgaXMgcmVhbGx5IHNob3J0LiBTb21lIGV4YW1wbGVzIG9mIGhvdyBpdCB3b3VsZCB3b3JrIHdv dWxkIGJlIG5pY2UuPGJyPg0KJmd0OyAtIFJlZ2FyZGluZyB0aGlzIGZyb20gc2VjdGlvbiAzOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBtYWtlcyBh biBhc3N1bXB0aW9uIHVzZXJzIGVtcGxveSBNYWlsIFVzZXIgQWdlbnRzIHRoYXQgZGlzcGxheSB0 aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWRlbnRpdHkgY29udGFpbmVk IGluIHRoZSBTZW5kZXIgaGVhZGVyIGZpZWxkIHdoZW4gdXNlZCBhcyBhIGJhc2lzPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvciBhY2NlcHRhbmNlLjxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO0kndmUgdGVzdGVkIEhvdG1haWwgYW5kIEdtYWlsIGFuZCBib3Ro IHN1cHByZXNzIHRoZSBTZW5kZXI6IGhlYWRlciBpbiBmYXZvciBvZiB0aGUgNTMyMi5Gcm9tIGFk ZHJlc3MuIENvbnZlcnNlbHksIE91dGxvb2sgYW5kIE91dGxvb2sgV2ViIEFjY2VzcyAoT1dBKSBz aG93IGl0IGFzICZxdW90OyZsdDtzZW5kZXImZ3Q7IG9uIGJlaGFsZiBvZiAmbHQ7ZnJvbSZndDsm cXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0gVGVycnk8YnI+DQo8YnI+DQpEZWFyIFRlcnJ5 LDxicj4NCjxicj4NCllvdSBtYWtlIGEgZ29vZCBwb2ludC4gSSBjb25zaWRlciAmbHQ7c2VuZGVy Jmd0OyBvbiBiZWhhbGYgb2Y8YnI+DQombHQ7ZnJvbSZndDsgYSByZWFzb25hYmxlIGFwcHJvYWNo LiBJdCB0YWtlcyBzZWNvbmRzIHVzaW5nIE9TIFg8YnI+DQpNYWlsIChNYWlsLCBQcmVmZXJlbmNl cywgVmlld2luZywgU2hvdyBtZXNzYWdlIGhlYWRlcnM6PGJyPg0KY3VzdG9tLCB0eXBlIFNlbmRl cikgdG8gZGlzcGxheSB0aGUgU2VuZGVyIGhlYWRlci4mbmJzcDsgSXQgaXM8YnI+DQpub3QgZGlz cGxheWVkIHdoZW4gaXQgaXMgbm90IHRoZXJlIG9mIGNvdXJzZSwgbm9yIGlzIHRoaXM8YnI+DQpz ZXR0aW5nIHRoZSBkZWZhdWx0Ljxicj4NCjxicj4NCkZvciBUaHVuZGVyYmlyZCwgdXNlcnMgd2ls bCBuZWVkIHRvIGFjY2VzcyBQcmVmZXJlbmNlcyw8YnI+DQpBZHZhbmNlZCwgR2VuZXJhbCB0YWIs IGNsaWNrIENvbmZpZyBFZGl0b3IsIEVudGVyPGJyPg0KbWFpbC5jb21wb3NlLm90aGVyLmhlYWRl ciBhbmQgZG91YmxlIGNsaWNrPGJyPg0KbWFpbC5jb21wb3NlLm90aGVyLmhlYWRlciBlbnRyeSBh bmQgdHlwZSB0aGUgZGVzaXJlZCBoZWFkZXJzPGJyPg0KaW4gdGhlIHN0cmluZyBkaWFsb2cuJm5i c3A7IEZvciBvdGhlciBNVUFzIGJleW9uZCBPdXRsb29rLCBNYWlsLDxicj4NCmFuZCBUaHVuZGVy YmlyZCwgdGhpcyBtYXkgcmVxdWlyZSBwbHVnaW5zIG9yIHNpbWlsYXI8YnI+DQp0aW5rZXJpbmcu Jm5ic3A7IE5vbmV0aGVsZXNzLCBTZW5kZXIgaGVhZGVyIHByb3RlY3Rpb24gaXM8YnI+DQphdmFp bGFibGUgYW5kIGxpa2VseSBzb21ldGhpbmcgYmV0dGVyIGNvbmZpZ3VyZWQgdXNpbmcgYTxicj4N CnNjcmlwdCBvZmZlcmVkIGJ5IHRoZSBwcm92aWRlci48YnI+DQo8YnI+DQpJbiB0aGUgZWFybHkg ZGF5cyB3aGVuIHdvcmtpbmcgd2l0aCBJY29uaXgsIHRoZXkgd2VyZSBhYmxlPGJyPg0KdG8gb2Zm ZXIgZmFpcmx5IGNvbXByZWhlbnNpdmUgY292ZXJhZ2UgZm9yIHdlYiBhY2Nlc3MgYW5kPGJyPg0K TVVBIHVzaW5nIGphdmFzY3JpcHQgb3ZlcmxheXMgd2l0aCBjb21wYW55IGljb25zLiZuYnNwOyBU aGlzPGJyPg0KaW1wcm92ZWQgc291cmNlIHRydXN0IGJhc2VkIG9uIHZlcmlmaWNhdGlvbiBtZXRo b2RzIHRoZW48YnI+DQphdmFpbGFibGUuJm5ic3A7IEl0IHNlZW1zIHRoZXNlIE1VQXMgb2ZmZXIg cHJvb2YgaXQgY2FuIGJlIGRvbmU8YnI+DQphbmQgSWNvbml4IHByb3ZlZCBwZW9wbGUgY291bGQg dW5kZXJzdGFuZCB0aGUgcmVzdWx0cy4mbmJzcDsgVGhpczxicj4NCnNlZW1zIHJhdGhlciBpbXBv cnRhbnQgc2luY2UgaXQgaXMgdGhlIFNlbmRlciBiZWluZyB0cnVzdGVkPGJyPg0KaW4gbW9zdCBj YXNlczsgdGhlIHJlc3VsdCBvZiBtYWlsJ3Mgc3RvcmUgYW5kIGZvcndhcmRpbmc8YnI+DQpwcm90 b2NvbC4gREtJTSBhbmQgU1BGIG9ubHkgb2ZmZXIgYXNzdXJhbmNlcyBiZXR3ZWVuIGhvcHMuPGJy Pg0KVXNlIG9mIElNLUZyb20gYmV0dGVyIHByb3RlY3RzIHRoZSByb2xlIG9mIGF1dGhvciBhbmQ8 YnI+DQplbmFibGVzIGltcHJvdmVkIGF2YWlsYWJpbGl0eSBmb3IgZGlyZWN0IHBhdGhzIHdoaWxl IGFsc288YnI+DQpvZmZlcmluZyBncmVhdGVyIGZsZXhpYmlsaXR5IGF0IGFkZGluZyBlYXNpbHkg bm90aWNhYmxlPGJyPg0KaW5mb3JtYXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW90aXMtZG1hcmMtZXNjYXBlLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3Rpcy1kbWFyYy1lc2NhcGUtMDA8L2E+PGJyPg0K PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpEb3VnbGFzIE90aXM8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtYXJjIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbWFyYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG1hcmM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL2SR01MB60500247596CDBBFDD6688796ED0BL2SR01MB605namsdf_-- From nobody Thu Apr 23 12:34:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC11B29C7 for ; Thu, 23 Apr 2015 12:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.244 X-Spam-Level: X-Spam-Status: No, score=-96.244 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_PROFIT1=3.858, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 roVKJhTQrVj3 for ; Thu, 23 Apr 2015 12:34:18 -0700 (PDT) Received: from dkim.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3FC1B29C5 for ; Thu, 23 Apr 2015 12:34:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5652; t=1429817646; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=TBllhWHWNa1gfvnodaGT3nHTxt8=; b=mGYgaFUkEcWG0r1Xv5T7 TwUlmb++gVOF1f0I7vin4vUP3khElv8/EpqURWElCb27Mp4c2Pbox+DnQeMo2rjS 8mm/Q2l54AFtB7cZZlszYQT+ELnTMENcG+3X/k2dLFUDH6y2xzep//wYJV2v+Qpz jKTNZTBdiy0DDE/zgnz1jJs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 23 Apr 2015 15:34:06 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3527652864.11859.3840; Thu, 23 Apr 2015 15:34:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5652; t=1429817397; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JYm1KA0 7tkfhjzHGVjqKchgcOyi9U07KyPRewE681wY=; b=jB1KOtPvERCYasqM8BAqRIr IXOndS577ZpMAwK7t1GhJom8n9xnnwzVYVuUIMsEPz8uPmJYzbJQzw+ct4CmYXY1 n5IvBVwc2h97DPekoEzVwmE5GKww7q78iDRGcaQvSG/YShHqG4bEEXSo2kjj1i4p TcfZkcs+VOZMhkRXwMbo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 23 Apr 2015 15:29:57 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2119933441.9.8664; Thu, 23 Apr 2015 15:29:57 -0400 Message-ID: <5539492E.6090208@isdg.net> Date: Thu, 23 Apr 2015 15:34:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5536D8D6.7080305@gmail.com> <2205755.CDbdbaXSto@kitterma-e6430> In-Reply-To: <2205755.CDbdbaXSto@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 19:34:21 -0000 No. On 4/23/2015 1:46 PM, Scott Kitterman wrote: > Since the core lookup key off of which everything in DMARC is based is the > 5322.From, if you change to use something different, is it even DMARC anymore? > > Scott K > > On Thursday, April 23, 2015 05:33:53 PM Terry Zink wrote: > > I’ve played around a bit with Gmail, Hotmail/outlook.com, and Outlook desktop > client. Here’s what I have found so far. > > Gmail and Hotmail have similar but not identical behavior: > > 1. If the 5322.From address is in your address book or you have a > conversational history (implicit contact) or is on your safe senders (in > Hotmail), then Gmail, Hotmail, and Outlook show only the Friendly From > (display from) and not the 5322.From full address. If it isn’t in your > contacts, then all show the display from + 5322.from email address. > 2. If the 5321.mailfrom is different than the 5322.From, Gmail shows > “Display From via 5321.mailfrom†> whereas outlook.com and Outlook desktop don’t show the discrepancy at all > (i.e., no equivalent of ‘via’ in Hotmail or Outlook desktop). Gmail does not > show the via if the 5322.from domain and 5321.mailfrom domains are the same > which is why there is a recommendation to authenticate with SPF and DKIM. > 3. Neither Gmail nor Hotmail show the Sender: header at all. Outlook > desktop shows “ on behalf of .†> > I haven’t done a large matrix of testing but I have played around with > different rendering; obviously, spam filtering and searching for conversational > history may have something to do with it, too. > > -- Terry > > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Brandon Long > Sent: Wednesday, April 22, 2015 5:29 PM > To: Douglas Otis > Cc: dmarc ietf > Subject: Re: [dmarc-ietf] Dmarc-escape draft available > > Gmail will display the Sender information with a on behalf of or similar in > certain circumstances when we think its necessary to give the user more > information. > > 99% of users won't use the more information for anything useful or even really > notice it or at best get confused, but eh. > > More information: https://support.google.com/mail/answer/1311182?hl=en > > So, the messages on this list have "via ietf.org" next to the author, for > example. > > Brandon > > On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis wrote: > > > On 4/21/15 4:20 PM, Terry Zink wrote: >> Some quick comments: >> >> - Section 3 is really short. Some examples of how it would work would be > nice. >> - Regarding this from section 3: >> >> This makes an assumption users employ Mail User Agents that display > the >> identity contained in the Sender header field when used as a basis >> for acceptance. >> >> I've tested Hotmail and Gmail and both suppress the Sender: header in > favor of the 5322.From address. Conversely, Outlook and Outlook Web Access > (OWA) show it as " on behalf of ". >> >> -- Terry >> > > On 4/21/15 4:20 PM, Terry Zink wrote: > >> Some quick comments: >> >> - Section 3 is really short. Some examples of how it would work would be > nice. >> - Regarding this from section 3: >> >> This makes an assumption users employ Mail User Agents that display > the >> identity contained in the Sender header field when used as a basis >> for acceptance. >> >> I've tested Hotmail and Gmail and both suppress the Sender: header in > favor of the 5322.From address. Conversely, Outlook and Outlook Web Access > (OWA) show it as " on behalf of ". >> >> -- Terry > > Dear Terry, > > You make a good point. I consider on behalf of > a reasonable approach. It takes seconds using OS X > Mail (Mail, Preferences, Viewing, Show message headers: > custom, type Sender) to display the Sender header. It is > not displayed when it is not there of course, nor is this > setting the default. > > For Thunderbird, users will need to access Preferences, > Advanced, General tab, click Config Editor, Enter > mail.compose.other.header and double click > mail.compose.other.header entry and type the desired headers > in the string dialog. For other MUAs beyond Outlook, Mail, > and Thunderbird, this may require plugins or similar > tinkering. Nonetheless, Sender header protection is > available and likely something better configured using a > script offered by the provider. > > In the early days when working with Iconix, they were able > to offer fairly comprehensive coverage for web access and > MUA using javascript overlays with company icons. This > improved source trust based on verification methods then > available. It seems these MUAs offer proof it can be done > and Iconix proved people could understand the results. This > seems rather important since it is the Sender being trusted > in most cases; the result of mail's store and forwarding > protocol. DKIM and SPF only offer assurances between hops. > Use of IM-From better protects the role of author and > enables improved availability for direct paths while also > offering greater flexibility at adding easily noticable > information. > > http://tools.ietf.org/html/draft-otis-dmarc-escape-00 > > > Regards, > Douglas Otis > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- HLS From nobody Thu Apr 23 17:18:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F031B2A4B for ; Thu, 23 Apr 2015 17:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ntk5PUPfoeY6 for ; Thu, 23 Apr 2015 17:18:35 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 6A9BA1B2A46 for ; Thu, 23 Apr 2015 17:18:35 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so10045658pac.0 for ; Thu, 23 Apr 2015 17:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DjkxNe3os52oD9Cc5kvA+A8H0VFH1BBW4IJK3wiUcWI=; b=MQ7ionL6KPe/S5B6cn4SsK9YaFfq0RU0noD38CkWr0x6e1/fONzWvZJtBR9rWHIrpA B0ojB+dtgN9q6AWOD/O4IvguKlPj6/r7gPs1UTZwA4MxyvtgvFcVEgCKvN5Jc0AS+Lg8 tGs3TMshUtQJ2p9gLeY3f2qdTUWsQCjm23J5Q1XApwNORBkStneBnXSknLS/eN5/k18g btc1TCg2UWI1jk7Sij3Tj4UgSlBMN7zfmKf735WASFcDkezm1wpyb531B7LcVO9JRTRG FSqxOLocvNPKAHfW6VrZff1ZoWyttNNNqnkVGox5N2/Dr/YRVCjrQXeP4v07lMpIxJAX NwWw== X-Received: by 10.70.35.108 with SMTP id g12mr486502pdj.75.1429834714826; Thu, 23 Apr 2015 17:18:34 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id c8sm9211456pdj.65.2015.04.23.17.18.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 17:18:33 -0700 (PDT) Message-ID: <55398BD5.7090007@gmail.com> Date: Thu, 23 Apr 2015 17:18:29 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5536D8D6.7080305@gmail.com> <5537E12B.6030607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 00:18:38 -0000 On 4/23/15 10:53 AM, Terry Zink wrote: > Doug, > >> It takes seconds using OS X Mail … >> >> For Thunderbird, users will need to access … >> >> For other MUAs this may require plugins or similar >> tinkering… >> >> Nonetheless, Sender header protection is >> available and likely something better configured using a >> script offered by the provider. > Requiring users to have to do something is not a good solution because the average user doesn’t understand and won’t do it. We’d have to convince mail clients to show it by default, and at least two large providers (Hotmail and Gmail) don’t do it today, and most largely-deployed mail clients don’t, either (Outlook being an exception). > > I don’t understand the flow of things for a Sender: header alignment that you propose. Is it something like this: > > Message 1 > ======== > 5321.MailFrom: > From: Terry Zink > Sender: Terry Zink > To: mailing list > Subject: Here is a message > DKIM-Signature: d=example.com [Signature is intact] > > Message 2 after replaying > =================== > > 5321.MailFrom: > From: Terry Zink > To: Doug Otis <..> > Sender: Terry Zink > Subject: [MAILING LIST] Here is a message > DKIM-Signature: d=example.com [Signature broken] > DKIM-Signature: d=mailing-list.com [Signature intact] > > What’s supposed to happen next? If DMARC is not in the way and forgoing friendly names... Message 2 after replaying =================== 5321.MailFrom: mailing-list@mailing-list.com From: Terry Zink To: Doug Otis <..> Sender: mailing-list@mailing-list.com Subject: [MAILING LIST] Here is a message DKIM-Signature: d=example.com [Signature broken] DKIM-Signature: d=mailing-list.com [Signature intact] When DMARC is in the way... Message 2 after replaying =================== 5321.MailFrom: mailing-list@mailing-list.com From: mailing-list@mailing-list.com IM-From: [MAILING LIST]:Terry Zink To: Doug Otis <..> Sender: mailing-list@mailing-list.com Subject: [MAILING LIST] Here is a message DKIM-Signature: d=example.com [Signature broken] DKIM-Signature: d=mailing-list.com [Signature intact] Dear Terry, Which is why is seems proper for popular MUA configurations to be offered by the provider but we may need better hooks. What happens with a message depends on recognized trust establish with the sender, not just the from. TPA-Label via DMARC feedback can help assist in preventing the misapplication of trust. > -- Terry > > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Terry Zink > Sent: Thursday, April 23, 2015 10:34 AM > To: Brandon Long; Douglas Otis > Cc: dmarc ietf > Subject: Re: [dmarc-ietf] Dmarc-escape draft available > > I’ve played around a bit with Gmail, Hotmail/outlook.com, and Outlook desktop client. Here’s what I have found so far. > > Gmail and Hotmail have similar but not identical behavior: > > > 1. If the 5322.From address is in your address book or you have a conversational history (implicit contact) or is on your safe senders (in Hotmail), then Gmail, Hotmail, and Outlook show only the Friendly From (display from) and not the 5322.From full address. If it isn’t in your contacts, then all show the display from + 5322.from email address. > > 2. If the 5321.mailfrom is different than the 5322.From, Gmail shows “Display From via 5321.mailfrom” whereas outlook.com and Outlook desktop don’t show the discrepancy at all (i.e., no equivalent of ‘via’ in Hotmail or Outlook desktop). Gmail does not show the via if the 5322.from domain and 5321.mailfrom domains are the same which is why there is a recommendation to authenticate with SPF and DKIM. > > 3. Neither Gmail nor Hotmail show the Sender: header at all. Outlook desktop shows “ on behalf of .” > > I haven’t done a large matrix of testing but I have played around with different rendering; obviously, spam filtering and searching for conversational history may have something to do with it, too. Where possible, disable friendly email displays. Too many years offered plenty reasons not to trust its rules. Iconix is a good example for what is possible with Web email as well. They greatly increase user comprehension while affording better protection. Show recipients verified information when possible. on behalf of at least shows identities contained in both headers. DMARC will not prevent all spoofing, but a less disruptive scheme that does not require name munging helps more than hurts. People groping for messages in spam folders hurts more than helps. The 5321.mailfrom is not part of DKIM, only SPF which fails From header alignment beyond the first hop for most mediated messages. Our domain asserts a DMARC record without requesting either Reject or Quarantine and instead relies on administrative relationships or LE after determining malefactors. It took a fair amount of effort, but we made a difference in Turkey and Brazil, for example. With DMARC, it is increasingly common to only see From header fields or a munged From header field rather than a proper Sender. How does less verifiable information because of DMARC policies help anyone? Just as people are not better protected using Chip and Signature rather than Chip and Pin, the same can be said of email lacking proper Sender header fields replaced by munged Froms. Regards, Douglas Otis > -- Terry > > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Brandon Long > Sent: Wednesday, April 22, 2015 5:29 PM > To: Douglas Otis > Cc: dmarc ietf > Subject: Re: [dmarc-ietf] Dmarc-escape draft available > > Gmail will display the Sender information with a on behalf of or similar in certain circumstances when we think its necessary to give the user more information. > > 99% of users won't use the more information for anything useful or even really notice it or at best get confused, but eh. > > More information: https://support.google.com/mail/answer/1311182?hl=en > > So, the messages on this list have "via ietf.org" next to the author, for example. > > Brandon From nobody Sat Apr 25 01:47:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3C71A873B for ; Sat, 25 Apr 2015 01:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HP38wEvs_fsf for ; Sat, 25 Apr 2015 01:47:40 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09E1A8715 for ; Sat, 25 Apr 2015 01:47:40 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id DCAF18642 for ; Sat, 25 Apr 2015 10:47:38 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 25 Apr 2015 10:47:38 +0200 Message-ID: From: "J. Gomez" To: References: <5536D8D6.7080305@gmail.com> Date: Sat, 25 Apr 2015 10:47:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Dmarc-escape draft available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 08:47:41 -0000 On Wednesday, April 22, 2015 1:10 AM [GMT+1=3DCET], Douglas Otis wrote: > Dear WG, >=20 > A draft has been posted offering two alternatives not > requiring cooperation of disruptive ESPs. > (...snip...) >=20 > http://tools.ietf.org/html/draft-otis-dmarc-escape-00 I have dificulty parsing this paragraph: "[DMARC] section 10.5 offers feeble advice by stating although mediator transformations may conform with standards, this may not avoid message Reject or Quarantine handling nor does it allow provisions for alignment with verified Sender header fields likely preferable to diverted placement of valid and legitimate messages." I can, more or less, understand it, reading it like this ( are = additions I make to try to understand it): "[DMARC] section 10.5 offers feeble advice by stating although = mediator transformations may conform with standards, this <-strike = previous word-; they> may not avoid message Reject or Quarantine = handling nor does it <-strike previous 2 words-; do them> allow = provisions for alignment with verified Sender header fields <, which is> = likely preferable to diverted placement of valid and legitimate = messages." Or something. Regards, J.Gomez From nobody Sat Apr 25 02:50:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330CA1B2BCF for ; Sat, 25 Apr 2015 02:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 I12DSgg7fYao for ; Sat, 25 Apr 2015 02:50:32 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE47C1A90FE for ; Sat, 25 Apr 2015 02:50:32 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 9A99A84BC for ; Sat, 25 Apr 2015 11:50:31 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 25 Apr 2015 11:50:31 +0200 Message-ID: From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> Date: Sat, 25 Apr 2015 11:50:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 09:50:35 -0000 On Thursday, April 16, 2015 4:11 PM [GMT+1=3DCET], Scott Kitterman = wrote: > I will probably regret this, but since people are throwing around > things like Pareto to argue in favor or against specific solution > areas, I thought it might be useful to take a step back and look at > what might make a solution (or set=20 > of solutions) useful to pursue. >=20 > For indirect mail flows like mailing lists, there are three actors > involved:=20 >=20 > 1. Originator > 2. Mediator > 3. Receiver >=20 > For the purposes of this discussion I'll further categorize the > entities involved as big and small (yes, it's way more complex than > that, but I think that's sufficient). >=20 > That leads to six combinations: Originator/Big, Originator/Small, > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. >=20 > There have been solutions proposed that only require changes for one > of the three above, that require changes at two of the above, and > that require=20 > changes at all three. Nice framework. I'd like to note that it is the presence/existance of actor "Mediator" = which induces the DMARC compatibility problems with indirect flows. I.e., if you supress the Mediator, all is fine and dandy. That fact = should at leat put some pressure on Mediator regarding the searching for = a solution, and should induce Mediator to acknowledge that he will have = to assume certain costs for such a solution. I see Originator already assuming costs: deploying SPF in DNS and = keeping it current, deploying DKIM records and DKIM-signing outgoing = email, deploying DMARC records and being vigilant regarding Header-From = alignment in his outgoing email, etc. And I see Receiver already assuming costs: setting up systems to check = SPF, DKIM and DMARC for incoming email, dealing with the support costs = of false positives and phised users, sending out DMARC reports, etc. What costs are Mediators currently taking to improve = validation/authentication of the email system as a whole? Regards, J.Gomez From nobody Sat Apr 25 03:24:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5321B2C2A for ; Sat, 25 Apr 2015 03:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 OsRYgy-ybgT3 for ; Sat, 25 Apr 2015 03:24:18 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4F1B2C25 for ; Sat, 25 Apr 2015 03:24:18 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lYpPr59zDz1L8nH; Sat, 25 Apr 2015 12:24:16 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3lYpPr3vlSz1L8n8; Sat, 25 Apr 2015 12:24:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 64DFF1234D4; Sat, 25 Apr 2015 12:24:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aHd82nhIndLV; Sat, 25 Apr 2015 12:24:14 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 547BE123051; Sat, 25 Apr 2015 12:24:14 +0200 (CEST) Message-ID: <553B6B4E.5040607@sonnection.nl> Date: Sat, 25 Apr 2015 12:24:14 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "J. Gomez" , dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1429957456; bh=uQjnEHRTIsmK1XrpZkGRjzqzWrhCzj1hTX8BFBTvqCU=; h=Message-ID:Date:From:To:Subject:From; b=fVOIEfdhZ7pbnbQAGcqBMvl6tFcXLybqMBS7V1snm8TLLZlAS+VX/rekM6JKpU5q/ kFXcl+54/+MHzM6No1rZNpMLbC93PHyILB7Hu7Jli/a3Ez/ctpDIv6gTRbXouK/kDH uCxdbTYcACbTzJbLe3tOMjrA769+udBvmB/LD9Z0= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lYpPr59zDz1L8nH Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 10:24:21 -0000 On 04/25/2015 11:50 AM, J. Gomez wrote: > On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote: > >> I will probably regret this, but since people are throwing around >> things like Pareto to argue in favor or against specific solution >> areas, I thought it might be useful to take a step back and look at >> what might make a solution (or set >> of solutions) useful to pursue. >> >> For indirect mail flows like mailing lists, there are three actors >> involved: >> >> 1. Originator >> 2. Mediator >> 3. Receiver >> >> For the purposes of this discussion I'll further categorize the >> entities involved as big and small (yes, it's way more complex than >> that, but I think that's sufficient). >> >> That leads to six combinations: Originator/Big, Originator/Small, >> Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. >> >> There have been solutions proposed that only require changes for one >> of the three above, that require changes at two of the above, and >> that require >> changes at all three. > Nice framework. > > I'd like to note that it is the presence/existance of actor "Mediator" which induces the DMARC compatibility problems with indirect flows. > > I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution. > > I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc. > > And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc. > > What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? and what benefits do they get in return? /rolf From nobody Sat Apr 25 06:33:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FAB1A90B2 for ; Sat, 25 Apr 2015 06:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 I19Nu5BgCuiQ for ; Sat, 25 Apr 2015 06:33:02 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id E35D21A90A4 for ; Sat, 25 Apr 2015 06:33:01 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 27BF28642 for ; Sat, 25 Apr 2015 15:33:00 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 25 Apr 2015 15:32:59 +0200 Message-ID: <904AA847F3E248668AFE4F0C42A6A4E4@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> Date: Sat, 25 Apr 2015 15:32:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 13:33:04 -0000 On Saturday, April 25, 2015 12:24 PM [GMT+1=3DCET], Rolf E. Sonneveld = wrote: > On 04/25/2015 11:50 AM, J. Gomez wrote: > > On Thursday, April 16, 2015 4:11 PM [GMT+1=3DCET], Scott Kitterman > > wrote:=20 > >=20 > > > I will probably regret this, but since people are throwing around > > > things like Pareto to argue in favor or against specific solution > > > areas, I thought it might be useful to take a step back and look > > > at what might make a solution (or set > > > of solutions) useful to pursue. > > >=20 > > > For indirect mail flows like mailing lists, there are three actors > > > involved: > > >=20 > > > 1. Originator > > > 2. Mediator > > > 3. Receiver > > >=20 > > > For the purposes of this discussion I'll further categorize the > > > entities involved as big and small (yes, it's way more complex > > > than that, but I think that's sufficient). > > >=20 > > > That leads to six combinations: Originator/Big, Originator/Small, > > > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > >=20 > > > There have been solutions proposed that only require changes for > > > one of the three above, that require changes at two of the above, > > > and that require > > > changes at all three. > > Nice framework. > >=20 > > I'd like to note that it is the presence/existance of actor > > "Mediator" which induces the DMARC compatibility problems with > > indirect flows. =20 > >=20 > > I.e., if you supress the Mediator, all is fine and dandy. That fact > > should at leat put some pressure on Mediator regarding the > > searching for a solution, and should induce Mediator to acknowledge > > that he will have to assume certain costs for such a solution. =20 > >=20 > > I see Originator already assuming costs: deploying SPF in DNS and > > keeping it current, deploying DKIM records and DKIM-signing > > outgoing email, deploying DMARC records and being vigilant > > regarding Header-From alignment in his outgoing email, etc. =20 > >=20 > > And I see Receiver already assuming costs: setting up systems to > > check SPF, DKIM and DMARC for incoming email, dealing with the > > support costs of false positives and phised users, sending out > > DMARC reports, etc. =20 > >=20 > > What costs are Mediators currently taking to improve > > validation/authentication of the email system as a whole?=20 >=20 > and what benefits do they get in return? The benefit to Mediators is that they will avoid becoming an obsolete = artifact of the past, like open SMTP relays. Regards, J.Gomez From nobody Sat Apr 25 06:38:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43BA1A90FF for ; Sat, 25 Apr 2015 06:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 Hb4Yb1uLy13C for ; Sat, 25 Apr 2015 06:38:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45A81A90F2 for ; Sat, 25 Apr 2015 06:38:40 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3PDca6p003477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 25 Apr 2015 06:38:39 -0700 Message-ID: <553B98D8.6010903@dcrocker.net> Date: Sat, 25 Apr 2015 06:38:32 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "J. Gomez" References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <904AA847F3E248668AFE4F0C42A6A4E4@fgsr.local> In-Reply-To: <904AA847F3E248668AFE4F0C42A6A4E4@fgsr.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 25 Apr 2015 06:38:40 -0700 (PDT) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 13:38:41 -0000 On 4/25/2015 6:32 AM, J. Gomez wrote: >>> I.e., if you supress the Mediator, all is fine and dandy. ... >> > and what benefits do they get in return? > The benefit to Mediators is that they will avoid becoming an obsolete artifact of the past, like open SMTP relays. The word that is needed here is 'Procrustean'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 25 07:29:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DA31ACDBE for ; Sat, 25 Apr 2015 07:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 kouc1qERq8ma for ; Sat, 25 Apr 2015 07:29:50 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ABAD71A88E1 for ; Sat, 25 Apr 2015 07:29:50 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 6EA671C3936; Sat, 25 Apr 2015 23:29:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 410181A2CC0; Sat, 25 Apr 2015 23:29:49 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 25 Apr 2015 23:29:49 +0900 Message-ID: <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 14:29:52 -0000 J. Gomez writes: > What costs are Mediators currently taking to improve > validation/authentication of the email system as a whole? Isn't it obvious that Mediators bear all of the burden that *both* ends do? Of course, we perform both roles on each message. We verify signatures and filter messages on the way in, which potentially could reduce costs system-wide due to the multiplier effect of mailing lists (except of course nobody trusts us to do it well). We sign the version of the message that we send out. (These are functions of the MTA, of course, and we can't do a better or worse job than any Originator or Recipient. Except that to some extent Mediators may have information about the Originator that Recipient systems don't, which may improve filtering.) What else do you propose that we do? GNU Mailman has been working (desultorily) on lists which authenticate posters via personal digital signatures, but that isn't going to help much. From nobody Sat Apr 25 08:34:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041FF1A8880 for ; Sat, 25 Apr 2015 08:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 la0oUmL9lFMY for ; Sat, 25 Apr 2015 08:34:19 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DF6481A899F for ; Sat, 25 Apr 2015 08:34:18 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id D15FA1C3858; Sun, 26 Apr 2015 00:34:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AA9681A2CC0; Sun, 26 Apr 2015 00:34:16 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <6893A88ACFED4C20A46973509E902292@fgsr.local> References: <6893A88ACFED4C20A46973509E902292@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 26 Apr 2015 00:34:16 +0900 Message-ID: <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 15:34:21 -0000 J. Gomez writes: > Yes, the user did it to himself, but what does he know? Obviously too little to be trusted with an email account. Fire the corporate training department! > Please note this attack works successfully even if the user has no > administrative rights on his computer, and could potentially be > made to work equally well with Linux and MacOSX users too (if they > were a big enough demographic target to make it profitable vs cost > of development). AFAICS the cost of porting is very low compared to original development. I would guess that the real issue is that they don't have a good way to identify the executable format for the recipient system, and so send a payload that will work on well over 90% of recipients. I also doubt it would work as well on Mac OS X, where the user would be prompted for his password to confirm permission to execute an application received from an untrusted source. Surely some would type the password, but I suspect enough would be deterred to lower the click rate to unprofitable levels. > The lessons which I think we can learn from this are: ISTM we already knew the lessons you list, and they inform every discussion I've seen on this list. My personal opinion is that, on the contrary, people are already way too quick to discard proposals simply because they involve changes to MUAs. Of course, the reality that this is an IETF WG, and what we can do that has effect with high probability is change wire protocols. MUA presentation is outside of our bailiwick, and nobody really has a good way to get ideas for MUAs broadly implemented the way we can influence MTA implementations. > So I thought this could be of interest to keep in mind, when some > solution may be suggested to the DMARC indirect flows problems > which advocates some kind of MUA behavior regarding message > presentation. "No Silver Bullet". There are no "solutions" to these problems, only improvements. The fact that *some* users will dig a phish out of the spam bucket and cut/paste a disabled URL into their browsers so that they can be victimized despite the best efforts of their mail agents doesn't mean that others who *would* click if it were presented as valid mail would *not* go to such lengths for mail in their spam folders, or perhaps would be deterred at the "cut/paste" stage. From nobody Sat Apr 25 10:11:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6071B1B2D3B for ; Sat, 25 Apr 2015 10:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 VisdvvFX7Yo7 for ; Sat, 25 Apr 2015 10:11:14 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 717DD1B2D4F for ; Sat, 25 Apr 2015 10:11:02 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id AA33A8641 for ; Sat, 25 Apr 2015 19:11:01 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 25 Apr 2015 19:11:01 +0200 Message-ID: <67D5DE03069647D9AF7104742F4B627E@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 25 Apr 2015 19:11:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 17:11:16 -0000 On Saturday, April 25, 2015 4:29 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > What costs are Mediators currently taking to improve > > validation/authentication of the email system as a whole? >=20 > Isn't it obvious that Mediators bear all of the burden that *both* > ends do? Of course, we perform both roles on each message. We verify > signatures and filter messages on the way in, which potentially could > reduce costs system-wide due to the multiplier effect of mailing lists > (except of course nobody trusts us to do it well). We sign the > version of the message that we send out. (These are functions of the > MTA, of course, and we can't do a better or worse job than any > Originator or Recipient. Except that to some extent Mediators may > have information about the Originator that Recipient systems don't, > which may improve filtering.) >=20 > What else do you propose that we do? Well, if you ask... Mediators could take ownership of the Header-From = whenever their involvement results in the Originator's DKIM signature = being invalidated. Or some other change to their "entrenched" = traditional behavior, like stop adding subject tags and body footers and = being content with using some List-ID header to identify themselves, = etc. Everyone (Originators and Receivers) is changing their email usage = patterns/processes in order to take email to the next level (in reality, = just to keep it a viable communication option in an increasingly hostile = Internet environment), but Mediators seem totally unwilling to change = their email usage patterns/processes. Email is changing. We all have to change to accomodate the fact that = email is changing. Mediators don't seem willing to change at all. What I = see is that email is about to evolve to the next level, and Mediators = are at risk of being left behind if they refuse to change to accomodate = the fact that email is changing. Regards, J.Gomez From nobody Sat Apr 25 10:26:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F871B2DCF for ; Sat, 25 Apr 2015 10:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.798 X-Spam-Level: * X-Spam-Status: No, score=1.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_AFFORDABLE=1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 uW-a1hveBIuD for ; Sat, 25 Apr 2015 10:26:14 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 199321B2DCA for ; Sat, 25 Apr 2015 10:26:14 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id C77B18641 for ; Sat, 25 Apr 2015 19:26:09 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 25 Apr 2015 19:26:09 +0200 Message-ID: From: "J. Gomez" To: References: <6893A88ACFED4C20A46973509E902292@fgsr.local> <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 25 Apr 2015 19:26:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 17:26:15 -0000 On Saturday, April 25, 2015 5:34 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > Yes, the user did it to himself, but what does he know? >=20 > Obviously too little to be trusted with an email account. Fire the > corporate training department! Not an option. And sorry but it is not affordable to employ security = experts in everyday clerical tasks. So the affected user remains on the = payroll, and the company takes the hit in lost productivity because of = email being inherently insecure, and because the security experts cannot = agree to make it secure after 30 years of Internet email been invented. > I also doubt it would work as well on Mac OS X, where the user would > be prompted for his password to confirm permission to execute an > application received from an untrusted source. I am not so sure, but I cannot test it right now in OS X. From an = untrusted source came the ZIP file, but the EXE inside it is --when = opened from the ZIP-- temporarily extracted to a $TEMP folder in the = user's profile and run from there, so I guess the operating system has = no way of knowing whether that EXE running form the user's $TEMP folder = came from the untrusted Internet or not. Regards, J.Gomez From nobody Sat Apr 25 17:25:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84A71B32DB for ; Sat, 25 Apr 2015 17:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.909 X-Spam-Level: *** X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=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 IzyrNz3Nyr-T for ; Sat, 25 Apr 2015 17:25:38 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B0DDE1B32D4 for ; Sat, 25 Apr 2015 17:25:33 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 828D81C3944; Sun, 26 Apr 2015 09:25:31 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5769A1A2CC0; Sun, 26 Apr 2015 09:25:31 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <67D5DE03069647D9AF7104742F4B627E@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 26 Apr 2015 09:25:31 +0900 Message-ID: <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 00:25:40 -0000 J. Gomez writes: > > What else do you propose that we do? > > Well, if you ask... Mediators could take ownership of the > Header-From whenever their involvement results in the Originator's > DKIM signature being invalidated. The From header field is not in the public domain, and not available for appropriation. "Taking ownership" of something that isn't yours is properly called "theft", and as I understand it is it forbidden by all of the mail header RFCs since 733, which assign that field to the originator, and no role in editing it to other participants in the mail system. The fact that Message-ID changes not only are not performed, but actually cause annoyance (unfilterable duplicates for subscribing recipients and inability to search archives for non-subscribers) suggests that to recipients as well as to originators and mediators the two messages are the same. Therefore the authors of the original messages remain the authors for the purpose of "From ownership". We (MLMs in general, as exemplified by GNU Mailman) in fact *do* allow this (as a per-list option). Not only does it violate the RFCs according to our interpretation, not only is it ugly and inconvenient, but it even causes some users to identify our posts as spam. This is hardly a desirable change if other changes can be made to improve the situation. > Or some other change to their "entrenched" traditional behavior, > like stop adding subject tags and body footers and being content > with using some List-ID header to identify themselves, etc. My own Internet facing lists don't add any such, although the lists where I can effectively forbid use of DMARC-abusing mailbox providers do. In general, it's not the mediators who care. It's the recipient users, who have a conflict of interest with their mailbox providers, not with the mediators. > Everyone (Originators and Receivers) And Mediators. I don't understand why you refuse to admit that Mediators *must* perform the same functions as Receivers and Originators in order to safely accept and reinject messages. In the case of GNU Mailman, with the help of Franck Martin, we also released (publicly, as part of our normal development cycle) a version including DMARC mitigations 6 months *in advance* of the April Fiasco. I don't understand why you insist on attacking the mediators, when (1) the DMARC Originators who publish p=reject are in conflict with their own users, (2) the DMARC Originators are not only signing their own content, but unilaterally asserting that it is the only content permitted in any version of messages originated in their system, in violation of the expectations of their own users as originators and of mailing list subscribers as recipients, and (3) the particular "p=reject" use case causing issues was pre-deprecated in their own standard. In any case, your "burden-equalization" approach is purely political, and does not respect that fact that the technical opportunities to mitigate the problem are not equally distributed. Mediators have very little power to improve service unless the Originators participate; all we can do is watch the services we are allowed to provide be deprecated. > is changing their email usage patterns/processes in order to take > email to the next level (in reality, just to keep it a viable > communication option in an increasingly hostile Internet > environment), but Mediators seem totally unwilling to change their > email usage patterns/processes. Nonsense, and your insistence on this nonsense is getting very tiresome. The reality is that Mediators *have* changed their patterns and processes *already*, in fact some of the changes anticipated the issues we now are wrestling with. It's not the Mediators who are unwilling to change. It's the *users*. The agents who are blocking the changes needed to satisfy the users' requirements are the DMARC p=reject mailbox providers, in view of (1) and (2) above. Mediators such as mailing lists can adapt, *and already have done so*, but we also advocate our users' interests. Those interests continue to be harmed, to the profit of Yahoo! and AOL, and to the detriment of *everybody else* in the mail system. "Everybody else" includes those DMARC participating domains who respect the SHOULDs and SHOULD NOTs of DMARC! That's because a protocol that brings them benefit is now a dirty word all over the Internet. For example, are you aware that the Japanese government has deprecated use of *all* yahoo.* addresses for official business, despite the fact that only yahoo.com publishes p=reject? > Email is changing. We all have to change to accomodate the fact > that email is changing. Mediators don't seem willing to change at > all. What I see is that email is about to evolve to the next level, > and Mediators are at risk of being left behind if they refuse to > change to accomodate the fact that email is changing. Thank you for your concern. We Mediators can and will take care of our own interests, and ask you to desist with your efforts to help -- they are not helpful because they do not respect our users' requirements. From nobody Sun Apr 26 00:23:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706A91A1B45 for ; Sun, 26 Apr 2015 00:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.909 X-Spam-Level: **** X-Spam-Status: No, score=4.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_AFFORDABLE=1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=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 OO9wuDXuL7CM for ; Sun, 26 Apr 2015 00:23:07 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 61E161A1B3F for ; Sun, 26 Apr 2015 00:23:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id A11FD1C38D0; Sun, 26 Apr 2015 16:23:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 761CC1A2CC0; Sun, 26 Apr 2015 16:23:05 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: References: <6893A88ACFED4C20A46973509E902292@fgsr.local> <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 26 Apr 2015 16:23:05 +0900 Message-ID: <87h9s3qrom.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 07:23:09 -0000 J. Gomez writes: > Not an option. And sorry but it is not affordable to employ > security experts in everyday clerical tasks. It doesn't require *any* *security* expertise on the part of the clerks to deal with the exploit you described in a business context. Since it's direct mail, in a business context it's reasonable to suppose you have a database of qualified vendors including their email addresses, and one would hope an IT department capable of implementing DMARC and filtering out URLs not backed by a DMARC pass from a vendor registered with your company. Ie, you deal only with companies which always send DMARC-conforming mail and publish p=reject, and have IT configure the MTA to quarantine any other mail addressed to clerks which contains clickable links. So all the clerks need to learn is to report unclickable links so that threats can be forwarded to corporate security and unregistered but valid vendor addresses can be registered. We already have that exploit beat in the business context; it's now up to businesses to adopt safe practices. The problems we must still address are other problems. > because of email being inherently insecure, and because the > security experts cannot agree to make it secure after 30 years of > Internet email been invented. The exploit you described is indeed *inherent* in a mail system which allows mail to be sent from anyone to anyone without previous acquaintance. In that context, the mail-reading user is always going to be the biggest part of the attack surface. From nobody Sun Apr 26 02:34:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC951A88BA for ; Sun, 26 Apr 2015 02:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.398 X-Spam-Level: ** X-Spam-Status: No, score=2.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_AFFORDABLE=1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 xGI0hflqdo_C for ; Sun, 26 Apr 2015 02:34:05 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id A46471A88B9 for ; Sun, 26 Apr 2015 02:34:05 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 4777C8641 for ; Sun, 26 Apr 2015 11:34:03 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sun, 26 Apr 2015 11:34:02 +0200 Message-ID: <1A392EAC59D64AE1A3F7F2672FC16435@fgsr.local> From: "J. Gomez" To: References: <6893A88ACFED4C20A46973509E902292@fgsr.local><87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> <87h9s3qrom.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 26 Apr 2015 11:34:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 09:34:08 -0000 On Sunday, April 26, 2015 9:23 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > Not an option. And sorry but it is not affordable to employ > > security experts in everyday clerical tasks. >=20 > It doesn't require *any* *security* expertise on the part of the > clerks to deal with the exploit you described in a business context. >=20 > Since it's direct mail, in a business context it's reasonable to > suppose you have a database of qualified vendors including their email > addresses, and one would hope an IT department capable of implementing > DMARC and filtering out URLs not backed by a DMARC pass from a vendor > registered with your company. Ie, you deal only with companies which > always send DMARC-conforming mail and publish p=3Dreject, and have IT > configure the MTA to quarantine any other mail addressed to clerks > which contains clickable links. So before the clerks can arrange to do business with a new Courier = (because the old Courier happens to be on strike, or not service an = area, or is more expensive for certain kinds of packages), they should = have to first vet it through the IT dept. so that IT dept. can whitelist = their sending email addresses/domains? And the same for any other = provider/client the clerks are going to deal with through email? And the = same for the Sales dept., who when following leads by necessity have to = deal with not-yet-formally-engaged prospective clients/providers? Sorry, but real everyday business does not work like this (unless maybe = at IBM, some huge University, or the Cuban Government, perhaps). > So all the clerks need to learn is to report unclickable links so that > threats can be forwarded to corporate security and unregistered but > valid vendor addresses can be registered. One clerk (a.k.a. "information-age worker" nowadays) does the workload = of four clerks 20 years ago. They are over-worked, they work fast and = furious and when, for example, presenting on-line taxes and what-not = they usually go by the last day in the tax period. So now the = confirmation email to validate their account on the Government on-line = taxes web site (which recently moved from https://taxes.ministry.fr to = https://taxes.ministy.gouv.fr) is suddenly not clickable, in the last = day of the tax period, at 17:45h in the evening? The IT dept. could be = better, but they certainly are not suicidal. Regards, J.Gomez From nobody Sun Apr 26 03:21:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993911A8AD9 for ; Sun, 26 Apr 2015 03:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 3T85LtXmJDtI for ; Sun, 26 Apr 2015 03:21:08 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96C1A8AD0 for ; Sun, 26 Apr 2015 03:21:08 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 2D6E283D9 for ; Sun, 26 Apr 2015 12:21:07 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sun, 26 Apr 2015 12:21:06 +0200 Message-ID: <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430><87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp><67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 26 Apr 2015 12:21:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 10:21:09 -0000 On Sunday, April 26, 2015 2:25 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > > What else do you propose that we do? > >=20 > > Well, if you ask... Mediators could take ownership of the > > Header-From whenever their involvement results in the Originator's > > DKIM signature being invalidated. >=20 > The From header field is not in the public domain, and not available > for appropriation. "Taking ownership" of something that isn't yours > is properly called "theft" Is the message Subject in the public domain? Is the message Body in the = public domain? Why are many mailing lists taking liberties with them? = Sorry, but I think your analogy of email vs property does not compute. > and as I understand it is it forbidden by > all of the mail header RFCs since 733, which assign that field to the > originator, and no role in editing it to other participants in the > mail system. I think that point was settled as "it is debatable". That field contains = the Author, and if the Author signed with DKIM and the mediated message = breaks that signature, it can then be argued that Authorship has = suffered and therefore that the From: Header should reflect that fact. > > Everyone (Originators and Receivers) >=20 > And Mediators. I don't understand why you refuse to admit that > Mediators *must* perform the same functions as Receivers and > Originators in order to safely accept and reinject messages. Because the fact that Mediators also do the role of Originators and the = role of Receivers is not what makes them special, but the very fact that = they are the only ones doing the role of Mediators. So the role of Originator has had to change and adapt. The role of = Receiver has had to change and adapt. What changes have happened to the = role of Mediator, to improve validation/authentication of the email = system as a whole? None that I see, yet. > I don't understand why you insist on attacking the mediators, when (1) > the DMARC Originators who publish p=3Dreject are in conflict with = their > own users, (2) the DMARC Originators are not only signing their own > content, but unilaterally asserting that it is the only content > permitted in any version of messages originated in their system, in > violation of the expectations of their own users as originators and of > mailing list subscribers as recipients, and (3) the particular > "p=3Dreject" use case causing issues was pre-deprecated in their own > standard. Well, I don't "attack" anyone, I express my opinion about what I think = would be the easiest and lest painful --considering the email system as = a whole-- solution to the problem. If your feel that as an "attack", = what can I do? Yes, Mediators did not create the problem. It is not their fault. But = live systems change, and we have to adapt. The roles of Originator and = Receiver already are trying very hard to adapt. What is the role of = Mediator doing to adapt to such change? > In any case, your "burden-equalization" approach is purely political, > and does not respect that fact that the technical opportunities to > mitigate the problem are not equally distributed. Mediators have very > little power to improve service unless the Originators participate; > all we can do is watch the services we are allowed to provide be > deprecated. Yes, I see that danger of deprecation to mailing lists too (at least, to = mailing lists managed/configured old-style). Email is heavily used in = corporate settings; inter-domain mailing lists used as "discussion = groups many-to-many", not so much. Market is a powerful force... > Mediators such as mailing lists can adapt, *and already have done so*, > but we also advocate our users' interests. Those interests continue > to be harmed, to the profit of Yahoo! and AOL, and to the detriment of > *everybody else* in the mail system. I think we should get past the Yahoos and the AOLs. They pioneered the = misue of DMARC, but that misuse is here to stay and will certainly grow, = to the point it will become "common usage". So the problem space is now = bigger than just Yahoo and AOL. I also feel I am advocating my users's best interests. I am not mad at = you, don't be mad at me. :-) > > Email is changing. We all have to change to accomodate the fact > > that email is changing. Mediators don't seem willing to change at > > all. What I see is that email is about to evolve to the next level, > > and Mediators are at risk of being left behind if they refuse to > > change to accomodate the fact that email is changing. >=20 > Thank you for your concern. We Mediators can and will take care of > our own interests, and ask you to desist with your efforts to help -- > they are not helpful because they do not respect our users' > requirements. Well, I also have users whose interests I humbly try to present and = defend here. I don't see why I should desist from doing so. Regards, J.Gomez From nobody Sun Apr 26 17:34:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1222B1B2BBF for ; Sun, 26 Apr 2015 17:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.509 X-Spam-Level: **** X-Spam-Status: No, score=4.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6] autolearn=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 asGPxHCMw5X6 for ; Sun, 26 Apr 2015 17:34:04 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EE6F81B2BB1 for ; Sun, 26 Apr 2015 17:34:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 6959E1C3829; Mon, 27 Apr 2015 09:34:02 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F3A811A2CC0; Mon, 27 Apr 2015 09:34:01 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 27 Apr 2015 09:34:01 +0900 Message-ID: <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 00:34:06 -0000 J. Gomez writes: > Is the message Subject in the public domain? Is the message Body in > the public domain? Why are many mailing lists taking liberties with > them? Our interpretation is that no liberties are being taken: we have tacit permission from the authors. I've *never* seen an author object to those changes. The only people who interpret them as not consonant with the authors' wishes are spamfighters like you who aren't even subscribed to the lists whose policy they advocate changing. On the other hand, authors (and recipients) do object to lists falsely claiming authorship of posts, for several reasons. The cases are quite different in the minds of the users. Ask yours; you find the same, I'm sure. > Sorry, but I think your analogy of email vs property does not > compute. "Taking ownership" is your term, not mine. I simply pointed out that it has pretty wretched connotations of theft, forgery, and fraud. > That field contains the Author, and if the Author signed with DKIM > and the mediated message breaks that signature, it can then be > argued that Authorship has suffered and therefore that the From: > Header should reflect that fact. Anything can be argued. But I've never seen a *subscriber* ask for this change, except when directed to do so by the "customer placation" department at their provider. I conclude that "cure worse than the disease" spamfighters are the only advocates of this interpretation. > What changes have happened to the role of Mediator, to improve > validation/authentication of the email system as a whole? None that > I see, yet. You won't, because there are none possible. Currently, validation/ authentication is a protocol agreed between the originator and the recipient, and as currently formulated, it is the originator's option to deprecate *all* mediation unilaterally by signing the whole message -- and that's the common practice. Further, originators can use the DMARC protocol to *forbid* mediation by signing the whole message and publishing p=reject, again unilaterally. Several attempts to devise ways for Mediators to participate in these protocols are in the internet-draft stage, but all have strong detractors. And of course one option (of abstaining from mediation) is as old as mailing lists -- the earliest MLMs were simple exploders -- and is still availabie at the list owner's option. > Well, I don't "attack" anyone, I express my opinion about what I > think would be the easiest and lest painful --considering the email > system as a whole-- solution to the problem. It's already available, and already used when the actual participants in a mediated channel so prefer. Your expression of opinion therefore is useless -- *you* can already do what you claim is best on your own lists, and at least the MLM product I help develop provides the option, but experience shows that many subscribers and owners strongly dislike it and very few favor it. > I think we should get past the Yahoos and the AOLs. They pioneered > the misue of DMARC, but that misuse is here to stay and will > certainly grow, That's possible, but really, only yahoo.com and aol.com matter. No Yahoo! or AOL affiliate that I've checked other than those two publishes p=reject or even p=quarantine, and in fact I've never seen p=reject on a domain that posts to a mailing list other than those two. It's true that a great majority of mail is sent from domains that participate in the DMARC protocol, and many of them publish p=reject. But IME only yahoo.com and aol.com cause problems for mailing lists. he others either don't post to lists or don't publish p=reject. > problem space is now bigger than just Yahoo and AOL. Name some other domains whose actual interaction with Mediators is problematic. > I also feel I am advocating my users's best interests. I am not mad > at you, don't be mad at me. :-) Why is it in *your* users' interests to tell *me* how to run my lists? That's what I perceive as an attack, since I see no good reason. GNU Mailman, for example, provides several DMARC mitigations. The traditionally available "just forward" configuration is still available, but disliked strongly because users really like have unsubscribe and archive links in the footer. The "steal authorship" option is available since Oct 2013 (6 months before the April Fiasco). Encapsulation of the decorated message in a message/rfc822 MIME part was provided later in 2013 IIRC. The problem is that all are detested by some users, and none are actually liked by any user. Therefore we developers continue to seek alternatives -- but all desirable alternatives require cooperation of "p=reject" posting domains because of the nature of current validation/ authentication protocols as Originator-Receiver agreements. From nobody Sun Apr 26 17:57:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C180B1B2CA9 for ; Sun, 26 Apr 2015 17:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.89 X-Spam-Level: * X-Spam-Status: No, score=1.89 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yt3H6lcIbZ_a for ; Sun, 26 Apr 2015 17:57:38 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 190CF1B2CA8 for ; Sun, 26 Apr 2015 17:57:38 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id BAD8B804D5 for ; Sun, 26 Apr 2015 17:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1430096257; bh=8CT84OG1AGP5k5BOpz4dUBr/5lGLHqNqj/px64GyVKA=; h=Subject:From:In-Reply-To:Date:References:To:From; b=KfpnnavoI41pBQqd6dxslNsT/ZaEzUjJA09yQDlFEbKSOPXs2IpI+5ELtlvx6yM4R aP54MSDVi6kUTsKqCXutbs24MwUvFr09uuKisFq2BLL7ybUIlzUgVp2BeAeAGs6Mi9 wXabp/bk5SSE/qrE88CsrDvfs4bQGyIF8l8U18Fw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 26 Apr 2015 17:57:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 00:57:38 -0000 On Apr 26, 2015, at 5:34 PM, Stephen J. Turnbull wrote: > > That's possible, but really, only yahoo.com and aol.com matter. No > Yahoo! or AOL affiliate that I've checked other than those two > publishes p=reject or even p=quarantine, and in fact I've never seen > p=reject on a domain that posts to a mailing list other than those two. > > It's true that a great majority of mail is sent from domains that > participate in the DMARC protocol, and many of them publish p=reject. > But IME only yahoo.com and aol.com cause problems for mailing lists. > he others either don't post to lists or don't publish p=reject. They're the vast majority of breakage today, for sure. There's also linkedin.com and one or two other corporates that use the same domain for both their bulk mail and some of their employee mail. And libero.it went to p=quarantine last month, which will also break mailing list interaction, though with less damage to bystanders than p=reject. Cheers, Steve From nobody Sun Apr 26 22:09:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4A1B2E31 for ; Sun, 26 Apr 2015 22:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.503 X-Spam-Level: X-Spam-Status: No, score=-99.503 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 Pbey5Qz8d_rT for ; Sun, 26 Apr 2015 22:09:25 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A28D51B2E30 for ; Sun, 26 Apr 2015 22:09:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1408; t=1430111359; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=49p7A3ac2CKO5r85GV65wUvBD+g=; b=IGbwH8PofmDDzZuUiyzM MFnLuzVypHNvMA8x+cBj7tsglCreNf4WzhxH6mUUlKiSHxr3b8QTkIHxxw3ZVwYv x0eJnO3eZwFdhN3wkgoBl/QTebqnvGRpwOO4+HzmLPaFJruLdZH2vdvMuS0PC7e2 NnF5wex8aWJZwwOEINO1rIM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 01:09:19 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3821361406.73.1156; Mon, 27 Apr 2015 01:09:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1408; t=1430111103; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WInhSXP UYCYxvO1EEBJG+PjvzxEUQZfuVVTG0ZntLSQ=; b=zSewuViC4wIBKORlXmq5KXp Wb16uYD7G/gW7RutJAyquOXPKiBy2CsYB98ykd8ag7Bnyx9ovJmq7adCqC5hojG6 80oFEx4h27vMNiQODKGT7raqopVGq60002zzOkt3BtnajnrVCj49THU8HjMWT2m3 LJS2IlwksSz5XLkyuzjg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 01:05:03 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2413638660.9.8024; Mon, 27 Apr 2015 01:05:02 -0400 Message-ID: <553DC479.8050304@isdg.net> Date: Mon, 27 Apr 2015 01:09:13 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, "J. Gomez" , dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> In-Reply-To: <553B6B4E.5040607@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 05:09:28 -0000 On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote: >> >> I'd like to note that it is the presence/existance of actor >> "Mediator" which induces the DMARC compatibility problems with >> indirect flows. >> >> I.e., if you supress the Mediator, all is fine and dandy. That fact >> should at leat put some pressure on Mediator regarding the searching >> for a solution, and should induce Mediator to acknowledge that he >> will have to assume certain costs for such a solution. >> >> I see Originator already assuming costs: deploying SPF in DNS and >> keeping it current, deploying DKIM records and DKIM-signing outgoing >> email, deploying DMARC records and being vigilant regarding >> Header-From alignment in his outgoing email, etc. >> >> And I see Receiver already assuming costs: setting up systems to >> check SPF, DKIM and DMARC for incoming email, dealing with the >> support costs of false positives and phised users, sending out DMARC >> reports, etc. >> >> What costs are Mediators currently taking to improve >> validation/authentication of the email system as a whole? > > and what benefits do they get in return? Smooth operation? Mediators don't really need to change, but their entry points need to support DKIM+POLICY. For example, the Mediator receiver can simply support honoring restrictive policies and it doesn't need to bother with much else. -- HLS From nobody Mon Apr 27 04:17:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6511B30D1 for ; Mon, 27 Apr 2015 04:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AwLQfc8XQIQd for ; Mon, 27 Apr 2015 04:17:07 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id A33D81B30CB for ; Mon, 27 Apr 2015 04:17:07 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3RBH5Sd025736 for ; Mon, 27 Apr 2015 07:17:05 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3RBH508018510 for ; Mon, 27 Apr 2015 07:17:05 -0400 Message-Id: <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: dmarc@ietf.org From: Michael Jack Assels In-reply-to: <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430><87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp><67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> Comments: In-reply-to "J. Gomez" message dated "Sun, 26 Apr 2015 12:21:04 +0200." Date: Mon, 27 Apr 2015 07:17:05 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-27 07:17:05 EDT Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 11:17:14 -0000 On Sun, 26 Apr 2015 12:21:04 +0200, "J. Gomez" wrote: > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > The From header field is not in the public domain, and not available > > for appropriation. "Taking ownership" of something that isn't yours is > > properly called "theft" > > Is the message Subject in the public domain? Is the message Body in the > public domain? Why are many mailing lists taking liberties with them? > Sorry, but I think your analogy of email vs property does not compute. Whether any header field is in the public domain is a legal question on which I won't venture an opinion, but the From header stands out as one that is treated specially by RFC5332, section 3.6.2: [...] The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. [...] In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. [...] It seems clear to me that, at the very least, the mailbox of the message's author ought not to be and replaced by the mailbox of an automaton that added a subject tag and a list trailer. If the mailing list software has made DKIM-breaking changes, it may make sense for it to *add* its own mailbox to the From header (as a "coauthor"), and make itself the Sender. MUAs may have widely varying methods of dealing with multiple mailbox From headers, but in my experience, MTAs have no trouble with them, and they're generally the ones handling DMARC issues. RFC7489 has this to say (in Section 6.6.1) about multiple-mailbox From headers: o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format; [...] The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. The first paragraph seems to imply that DMARC admits the validity of a multimailbox From field, but simply doesn't plan to support it. The second paragraph makes clear how the nonsupport is to be accomplished. I understand that a ne'er-do-well might craft a spammy message with From: "Need enhancement? See http://bad-example.com" , Sender: DKIM-Signature: [...]i=bad-example.com[...] DKIM-Signature: [...]i=example.org[...] among the headers; hence the second quoted paragraph of RFC7489 above. However, given an opportunity by DKIM, e.g., implementing Murray's draft-kucherawy-dkim-transform-00, with some extra detail to accommodate reversible From and Subject transformations, a mailing list could fairly easily get away with something like From: , Sender: Subject: [list] Original subject DKIM-Signature: [...]i=example.com; ftf=2; stf=[list]; [...] DKIM-Signature: [...]i=example.org[...] where "ftf=2" means "the second mailbox in the From header was added", and "stf=[list]" means "the tag '[list]' in the Subject header was added. Both transformations are easily reversed. MTAs implementing draft-kucherawy-dkim-transform-00 supplemented with ftf and stf transformations should be able to reconstruct the original message and verify its DKIM-Signature. This adds plenty of work for Mediators -- possibly more than they can handle if the MLM has no direct access to DKIM -- and only a little extra for Receivers. RFC 7489's paragraph dealing with multimailbox From headers would have to be change to something like The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. However, if one DKIM-Signature fails on its own but passes under the reversal of transformations specified by another passing DKIM-Signature, then the first DKIM-Signature is deemed to have passed. > I think that point was settled as "it is debatable". That field contains > the Author, and if the Author signed with DKIM and the mediated message > breaks that signature, it can then be argued that Authorship has suffered > and therefore that the From: Header should reflect that fact. The Authorship certainly hasn't suffered to the extent that the content has been significantly changed. At worst, the Authorship has been augmented by the addition of content by another Author, which, I think, merits the addition of a mailbox to the From header, not the replacement of the principle Author with a minor contributor, which would be tantamount to replacing a book's author with its publisher, who added the binding and the copyright notice. If MUAs do unpredictable things with multimailbox From headers, it may be because they don't see them often enough. I'm sure they'll fix their errors if list mail begins to arrive with heretofore unusual but RFC5322-compliant headers. MJA (regretting that this turned out to be so long) From nobody Mon Apr 27 05:32:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357191B3128 for ; Mon, 27 Apr 2015 05:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 U29qOnHbJH3M for ; Mon, 27 Apr 2015 05:32:29 -0700 (PDT) Received: from pop3.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2401B3127 for ; Mon, 27 Apr 2015 05:32:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=966; t=1430137934; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=JIV6BVyslvlTCg8h0yt3CbrsWR8=; b=Ec03StEhyxgYwGMhNynV qEl9rRqmcNurUKGZ/0V/+325TQrGSQO3F9k/L0QvteqHh1huWnOx1CKyOJMq1grf TT57CVHTQhpbQKzTfqHiXWmCjHmra+Nf1RUxfBb4kzqvoVAqpHW4RMWGb26hLT+i noOHbmhb4yWFIKy6YMWsRHY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 08:32:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3847936988.1461.1292; Mon, 27 Apr 2015 08:32:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=966; t=1430137681; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YwLGgTX rDOdHYJuSqb9Yn9vNP8zQHcXCmEVilMSZfDw=; b=wjqDsgbSfoEBkhfR+KmEM5A GuW3lpLhmN/XctTHMlxWsQIWp+DhWK2rWqXOCHPrFmgyGh1dHfEEFPJ1GIBSWkQA nDWrglqyfKy86C/X6w/HRDZrg7mDHF9+0VxGBtFi6+IUqEaFjHDkXFGKTEucGZ5X 3ti27v/UcoPe8IQZ6rzg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 08:28:01 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2440217020.9.8244; Mon, 27 Apr 2015 08:28:00 -0400 Message-ID: <553E2C4C.8060202@isdg.net> Date: Mon, 27 Apr 2015 08:32:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 12:32:32 -0000 On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: > > GNU Mailman, for example, provides several DMARC mitigations. The > traditionally available "just forward" configuration is still > available, but disliked strongly because users really like have > unsubscribe and archive links in the footer. The "steal authorship" > option is available since Oct 2013 (6 months before the April > Fiasco). Encapsulation of the decorated message in a message/rfc822 > MIME part was provided later in 2013 IIRC. > > The problem is that all are detested by some users, and none are > actually liked by any user. Therefore we developers continue to seek > alternatives -- but all desirable alternatives require cooperation of > "p=reject" posting domains because of the nature of current validation/ > authentication protocols as Originator-Receiver agreements. The mediator has a receiver. Doesn't it have the same Originator-Receiver agreements? -- HLS From nobody Mon Apr 27 09:45:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7552D1A8752 for ; Mon, 27 Apr 2015 09:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 F_hhGvNWESv7 for ; Mon, 27 Apr 2015 09:45:40 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id D0D591A873A for ; Mon, 27 Apr 2015 09:45:39 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3RGjcZp019573; Mon, 27 Apr 2015 12:45:38 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3RGjc8Y020909; Mon, 27 Apr 2015 12:45:38 -0400 Message-Id: <201504271645.t3RGjc8Y020909@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: Michael Jack Assels From: Michael Jack Assels In-reply-to: <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> References: <5719430.pnL5xihlrb@kitterma-e6430><87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp><67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> Comments: In-reply-to Michael Jack Assels message dated "Mon, 27 Apr 2015 07:17:05 -0400." Date: Mon, 27 Apr 2015 12:45:38 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-27 12:45:38 EDT Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:45:41 -0000 On Mon, 27 Apr 2015 07:17:05 EDT, Michael Jack Assels wrote: > [...] > From: "Need enhancement? See http://bad-example.com" > , > Sender: > DKIM-Signature: [...]i=bad-example.com[...] > DKIM-Signature: [...]i=example.org[...] > [...] Sigh. All instances of "i=" were intended to be "d=", passim. MJA From nobody Mon Apr 27 11:44:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6821A923D for ; Mon, 27 Apr 2015 11:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 BxY_TodZ6yyA for ; Mon, 27 Apr 2015 11:44:40 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 B71EF1A92E4 for ; Mon, 27 Apr 2015 11:44:39 -0700 (PDT) Received: by wgso17 with SMTP id o17so126181248wgs.1 for ; Mon, 27 Apr 2015 11:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qJ34IJPIWjtIEKE2ZmN1VFL5R1pThDeVy6mWbUKbv34=; b=rKHJEYCf97/EvGWBSAPsUq47neaxZNCn7jHCBoL65yKvqmpIwU5GAJft1hDUdiNOgM 8ZN/4+bF+Q+K6J7nC7xTvQ5bZZfLRDesP5fLV8mYpIxKGgV8LcAZIMfqyJqKIgsQDBY5 VOHsO6G/25GVQMto+7FIhaKm08pTeeoIYLDMA9x53vGDvmx/h2tNu+xozttQVCdmPqjF w2gQVLYiUO2TzIVGcBiedO+d1P1tIZw59vgkrouWtshaz8e0u5FxdF9RfnjFyT/B2m9w nzR3Es4WQTQNs2NkRUq3ykElgEWNs52rpAxlqRmseaQmj8GVoxT9NJapMz+jzuViSMu+ aK3g== MIME-Version: 1.0 X-Received: by 10.180.106.73 with SMTP id gs9mr23625920wib.52.1430160278394; Mon, 27 Apr 2015 11:44:38 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Mon, 27 Apr 2015 11:44:38 -0700 (PDT) In-Reply-To: <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> Date: Mon, 27 Apr 2015 11:44:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Michael Jack Assels Content-Type: multipart/alternative; boundary=f46d04428fce5d9cca0514b923ae Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 18:44:42 -0000 --f46d04428fce5d9cca0514b923ae Content-Type: text/plain; charset=UTF-8 On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < mjassels@encs.concordia.ca> wrote: > On Sun, 26 Apr 2015 12:21:04 +0200, > "J. Gomez" wrote: > > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > > > The From header field is not in the public domain, and not available > > > for appropriation. "Taking ownership" of something that isn't yours is > > > properly called "theft" > > > > Is the message Subject in the public domain? Is the message Body in the > > public domain? Why are many mailing lists taking liberties with them? > > Sorry, but I think your analogy of email vs property does not compute. > > Whether any header field is in the public domain is a legal question on > which I won't venture an opinion, but the From header stands out as one > that is treated specially by RFC5332, section 3.6.2: > > [...] The "From:" field specifies the author(s) of the message, > that is, the mailbox(es) of the person(s) or system(s) responsible > for the writing of the message. The "Sender:" field specifies the > mailbox of the agent responsible for the actual transmission of the > message. For example, if a secretary were to send a message for > another person, the mailbox of the secretary would appear in the > "Sender:" field and the mailbox of the actual author would appear in > the "From:" field. If the originator of the message can be indicated > by a single mailbox and the author and transmitter are identical, the > "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD > appear. > > [...] > > In all cases, the "From:" field SHOULD NOT contain any mailbox that > does not belong to the author(s) of the message. [...] > > It seems clear to me that, at the very least, the mailbox of the message's > author ought not to be and replaced by the mailbox of an automaton that > added a subject tag and a list trailer. If the mailing list software has > made DKIM-breaking changes, it may make sense for it to *add* its own > mailbox to the From header (as a "coauthor"), and make itself the > Sender. > The question to me is whether the message that the MLM software emits is the same as the original message. If it is, then the Author ought to be preserved across the MLM. If it is not, then the MLM emits a new message, and it actually SHOULD NOT keep the Author the same, as described above. So we get to argue about "same", and of course the specs aren't particularly rigorous about this. RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it doesn't change From, from which I infer it doesn't change Author, although it does say it's a "new" message that's emitted. That document is not a proposed standard and merely documents current use (as I understand it), so it's merely recording the fact that MLMs technically violate the SHOULD NOT. So it seems to me the points of contention here are: 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation that we accept based on how "SHOULD NOT" is defined in RFC2119? It seems to me that it is, especially given how long they've been doing it without objection (until now). One could argue they've been "getting away with it" for too long, but we can't change history. 2) Is the MLM emitting a new message? I would agree with Michael and contend that it is if there have been any content changes at all, in the same way that someone making a compilation of a series of independent works (a "mix tape") owns the copyright on the mix, though not on the original material. Now, MLMs do that with digests already -- who else could one legitimately put in the From of a digest? -- but typically not for resent messages. To the point of Message-IDs, I would say that should follow the same rule as the From change: If the content changes, it's a new message, and it gets a new Message-ID. Might it be sufficient to declare an "Original-Message-ID" or "Author-Message-ID" or "List-Original-Message-ID" field that contains the author-generated Message-ID, allowing for the duplicate suppression that's done now? If MUAs do unpredictable things with multimailbox From headers, it > may be because they don't see them often enough. I'm sure they'll fix > their errors if list mail begins to arrive with heretofore unusual but > RFC5322-compliant headers. > I would far rather have MUA developers work with us directly, but the IETF has a persistent allergy to us tampering in user space. As I understand it, our desire in general tends to be to create well-defined interfaces (not APIs, mind you) at which MUAs can "meet" us on their own, and let them take it from there. Thus, the best we can do is be very clear about what information is presented by a multi-From message and perhaps why, and hope they'll adapt. The sad legacy is that different mail operators have historically done different things, which has led to MUAs doing different things, which has in turn led to a global system that interoperates enough to be useful but not enough to be able to lock down certain undesirable things without a great deal of pain. -MSK --f46d04428fce5d9cca0514b923ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels <mjassels@encs.concordia.ca> wrote:
On Sun, 26 Apr 2015 12:21:04 +0200,
"J. Gomez" <jgomez@sery= rich.com> wrote:

> On Sunday, April 26, 2015 2:25 AM [GMT+1=3DCET], Stephen J. Turnbull w= rote:
>
> > The From header field is not in the publi= c domain, and not available
> > for appropriation.=C2=A0 "Taking ownership" of somethin= g that isn't yours is
> > properly called "theft"
>
> Is the message Subject in the public domain? Is the message Body in th= e
> public domain? Why are many mailing lists taking liberties with them?<= br> > Sorry, but I think your analogy of email vs property does not compute.=

Whether any header field is in the public domain is a legal question= on
which I won't venture an opinion, but the From header stands out as one=
that is treated specially by RFC5332, section 3.6.2:

=C2=A0 =C2=A0[...] The "From:" field specifies the author(s) of t= he message,
=C2=A0 =C2=A0that is, the mailbox(es) of the person(s) or system(s) respons= ible
=C2=A0 =C2=A0for the writing of the message.=C2=A0 The "Sender:" = field specifies the
=C2=A0 =C2=A0mailbox of the agent responsible for the actual transmission o= f the
=C2=A0 =C2=A0message.=C2=A0 For example, if a secretary were to send a mess= age for
=C2=A0 =C2=A0another person, the mailbox of the secretary would appear in t= he
=C2=A0 =C2=A0"Sender:" field and the mailbox of the actual author= would appear in
=C2=A0 =C2=A0the "From:" field.=C2=A0 If the originator of the me= ssage can be indicated
=C2=A0 =C2=A0by a single mailbox and the author and transmitter are identic= al, the
=C2=A0 =C2=A0"Sender:" field SHOULD NOT be used.=C2=A0 Otherwise,= both fields SHOULD
=C2=A0 =C2=A0appear.

=C2=A0 =C2=A0[...]

=C2=A0 =C2=A0In all cases, the "From:" field SHOULD NOT contain a= ny mailbox that
=C2=A0 =C2=A0does not belong to the author(s) of the message. [...]

It seems clear to me that, at the very least, the mailbox of the message= 9;s
author ought not to be and replaced by the mailbox of an automaton that
added a subject tag and a list trailer.=C2=A0 If the mailing list software = has
made DKIM-breaking changes, it may make sense for it to *add* its own
mailbox to the From header (as a "coauthor"), and make itself the=
Sender.

The question to me is whether t= he message that the MLM software emits is the same as the original message.= =C2=A0 If it is, then the Author ought to be preserved across the MLM.=C2= =A0 If it is not, then the MLM emits a new message, and it actually SHOULD = NOT keep the Author the same, as described above.=C2=A0 So we get to argue = about "same", and of course the specs aren't particularly rig= orous about this.

RFC5598's definitions, in Section 5.3 (and ind= irectly 5.2) say that it doesn't change From, from which I infer it doe= sn't change Author, although it does say it's a "new" mes= sage that's emitted.=C2=A0 That document is not a proposed standard and= merely documents current use (as I understand it), so it's merely reco= rding the fact that MLMs technically violate the SHOULD NOT.

<= div>So it seems to me the points of contention here are:

= 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation= that we accept based on how "SHOULD NOT" is defined in RFC2119?= =C2=A0 It seems to me that it is, especially given how long they've bee= n doing it without objection (until now).=C2=A0 One could argue they've= been "getting away with it" for too long, but we can't chang= e history.

2) Is the MLM emitting a new message?=C2=A0 I = would agree with Michael and contend that it is if there have been any cont= ent changes at all, in the same way that someone making a compilation of a = series of independent works (a "mix tape") owns the copyright on = the mix, though not on the original material.=C2=A0 Now, MLMs do that with = digests already -- who else could one legitimately put in the From of a dig= est? -- but typically not for resent messages.

To the poi= nt of Message-IDs, I would say that should follow the same rule as the From= change: If the content changes, it's a new message, and it gets a new = Message-ID.

Might it be sufficient to declare = an "Original-Message-ID" or "Author-Message-ID" or &quo= t;List-Original-Message-ID" field that contains the author-generated M= essage-ID, allowing for the duplicate suppression that's done now?
<= br>
If MUAs do unpredictable things with multimailbox From headers, it
may be because they don't see them often enough.=C2=A0 I'm sure the= y'll fix
their errors if list mail begins to arrive with heretofore unusual but
RFC5322-compliant headers.

I would far = rather have MUA developers work with us directly, but the IETF has a persis= tent allergy to us tampering in user space.=C2=A0 As I understand it, our d= esire in general tends to be to create well-defined interfaces (not APIs, m= ind you) at which MUAs can "meet" us on their own, and let them t= ake it from there.=C2=A0 Thus, the best we can do is be very clear about wh= at information is presented by a multi-From message and perhaps why, and ho= pe they'll adapt.

The sad legacy is that different ma= il operators have historically done different things, which has led to MUAs= doing different things, which has in turn led to a global system that inte= roperates enough to be useful but not enough to be able to lock down certai= n undesirable things without a great deal of pain.

-MSK
--f46d04428fce5d9cca0514b923ae-- From nobody Mon Apr 27 11:55:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE11AC41A for ; Mon, 27 Apr 2015 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2mtXQhwvtErL for ; Mon, 27 Apr 2015 11:55:43 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 679551AC412 for ; Mon, 27 Apr 2015 11:55:43 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id ECF1E83D9 for ; Mon, 27 Apr 2015 20:55:38 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 27 Apr 2015 20:55:37 +0200 Message-ID: <5DFE7A7AA33A4063AD46E3D1EC8DC508@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430><87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp><67D5DE03069647D9AF7104742F4B627E@fgsr.local><87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp><4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 27 Apr 2015 20:55:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 18:55:52 -0000 On Monday, April 27, 2015 2:34 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > > Well, I don't "attack" anyone, I express my opinion about what I > > think would be the easiest and lest painful --considering the email > > system as a whole-- solution to the problem. >=20 > It's already available, and already used when the actual participants > in a mediated channel so prefer. Your expression of opinion therefore > is useless I am sorry my opinion is useless to you. It does not intent to have an = utility per se, but to express my point of view as an actor in the email = system. > > I also feel I am advocating my users's best interests. I am not mad > > at you, don't be mad at me. :-) >=20 > Why is it in *your* users' interests to tell *me* how to run my lists? > That's what I perceive as an attack, since I see no good reason. You asked "What else do you propose that we do?". I obliged. Again, I am sorry you didn't like it. Regards, J.Gomez From nobody Mon Apr 27 12:27:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37FF1ACD14 for ; Mon, 27 Apr 2015 12:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Rmc8loiRkeWg for ; Mon, 27 Apr 2015 12:27:51 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id A2F911A1A8A for ; Mon, 27 Apr 2015 12:27:51 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id A939A83D9 for ; Mon, 27 Apr 2015 21:27:49 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 27 Apr 2015 21:27:49 +0200 Message-ID: From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> Date: Mon, 27 Apr 2015 21:27:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 19:27:53 -0000 Original Message from: Murray S. Kucherawy > The question to me is whether the message that the MLM software emits > is the same as the original message. If it is, then the Author ought > to be preserved across the MLM. If it is not, then the MLM emits a > new message, and it actually SHOULD NOT keep the Author the same, as > described above. So we get to argue about "same", and of course the > specs aren't particularly rigorous about this. =20 >=20 > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that > it doesn't change From, from which I infer it doesn't change Author, > although it does say it's a "new" message that's emitted.=20 It seems RFC5598 says 3 things: 1. That the Author and only the Author goes in the Header-From. Period. 2. That mailing lists keep the "original Author" (sic) in the = Header-From. 3. That mailing lists also become an Author when they retransmit a = message (Section 5.3: "Because a Mailing List can modify the content of = a message in any way, it is responsible for that content; that is, it is = an Author."). I see point 1 as normative, point 3 as an arrived conclusion (logical = deduction) and therefore also normative as long as it is logically = valid, and point 2 as documenting customary practice at the time that = document was written. So it seems, as per RFC5598, that a message mediated by a mailing list = which alters its content has, at least, to Authors: the "original = Author", and the mailing list itself. Hmm, I see several ways to go from here. Regards, J.Gomez From nobody Mon Apr 27 12:38:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253F91ACD62 for ; Mon, 27 Apr 2015 12:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 PNHzbqrqGKra for ; Mon, 27 Apr 2015 12:38:17 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 EC1931ACD60 for ; Mon, 27 Apr 2015 12:38:16 -0700 (PDT) Received: by wiun10 with SMTP id n10so3198815wiu.1 for ; Mon, 27 Apr 2015 12:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Oc+n2/Qy6a57DT++hBAdFINoaV1j7ViGCsv+9J6cWrk=; b=k1E2A4xcPZuONdWSifhaH3SQgwhN9rTtQKp9yI0YcRWbVg61TTS6lypnozqEkaE2BG lwWq/gMlAm4zIrVda44xxsMo3NE6Rz0XDbAj8HE2ivBdEe/1Spf3b2+0eltnsRS0zu7N YkIgRQGQTMtc0768gZ7LUqCGP4LDWt66y2ebdvrtScDv507Q+ECWOqbG7A4jjzcAXZfB i8dvPfXVZby6fbXR19VXvWkeYCDOZ7o1WcEqu2vf4joNtcjYjo1v2f5w/di+J07TsW8g b+FXPDFjAvfJMsAkJ1TccCzq3pJxTHDoBInkwEEzxsmWMVjN6boVri71UzBddYp8MYM4 z/Vg== MIME-Version: 1.0 X-Received: by 10.180.78.199 with SMTP id d7mr23234548wix.94.1430163495749; Mon, 27 Apr 2015 12:38:15 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Mon, 27 Apr 2015 12:38:15 -0700 (PDT) In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> Date: Mon, 27 Apr 2015 12:38:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d0435c02e228eb30514b9e352 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 19:38:19 -0000 --f46d0435c02e228eb30514b9e352 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez wrote: > > The question to me is whether the message that the MLM software emits > > is the same as the original message. If it is, then the Author ought > > to be preserved across the MLM. If it is not, then the MLM emits a > > new message, and it actually SHOULD NOT keep the Author the same, as > > described above. So we get to argue about "same", and of course the > > specs aren't particularly rigorous about this. > > > > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that > > it doesn't change From, from which I infer it doesn't change Author, > > although it does say it's a "new" message that's emitted. > > It seems RFC5598 says 3 things: > > 1. That the Author and only the Author goes in the Header-From. Period. > 2. That mailing lists keep the "original Author" (sic) in the Header-From. > 3. That mailing lists also become an Author when they retransmit a message > (Section 5.3: "Because a Mailing List can modify the content of a message > in any way, it is responsible for that content; that is, it is an > Author."). > > I see point 1 as normative, point 3 as an arrived conclusion (logical > deduction) and therefore also normative as long as it is logically valid, > and point 2 as documenting customary practice at the time that document was > written. > > So it seems, as per RFC5598, that a message mediated by a mailing list > which alters its content has, at least, to Authors: the "original Author", > and the mailing list itself. > Keep in mind that RFC5598 is Informational. It doesn't prescribe or proscribe anything. It just describes the "current" (at the time) email architecture. RFC5322 and its ilk are Standards track, and thus normative. Even if we were all to concur that altering the From by adding the list is the right way forward here (an intriguing idea at the moment), the question of ordering would need to be addressed, and then how that applies to all the standards we're talking about, and how MUAs need to be nudged to make use of such things. -MSK --f46d0435c02e228eb30514b9e352 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez <jgomez@sery= rich.com> wrote:
> The quest= ion to me is whether the message that the MLM software emits
> is the same as the original message.=C2=A0 If it is, then the Author o= ught
> to be preserved across the MLM.=C2=A0 If it is not, then the MLM emits= a
> new message, and it actually SHOULD NOT keep the Author the same, as > described above.=C2=A0 So we get to argue about "same", and = of course the
> specs aren't particularly rigorous about this.
>
> RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say tha= t
> it doesn't change From, from which I infer it doesn't change A= uthor,
> although it does say it's a "new" message that's emi= tted.

It seems RFC5598 says 3 things:

1. That the Author and only the Author goes in the Header-From. Period.=C2= =A0
2. That mailing lists keep the "original Author" (sic) in the Hea= der-From.
3. That mailing lists also become an Author when they retransmit a message = (Section 5.3: "Because a Mailing List can modify the content of a mess= age in any way, it is responsible for that content; that is, it is an Autho= r.").=C2=A0

I see point 1 as normative, point 3 as an arrived conclusion (logical deduc= tion) and therefore also normative as long as it is logically valid, and po= int 2 as documenting customary practice at the time that document was writt= en.

So it seems, as per RFC5598, that a message mediated by a mailing list whic= h alters its content has, at least, to Authors: the "original Author&q= uot;, and the mailing list itself.

Keep= in mind that RFC5598 is Informational.=C2=A0 It doesn't prescribe or p= roscribe anything.=C2=A0 It just describes the "current" (at the = time) email architecture.=C2=A0 RFC5322 and its ilk are Standards track, an= d thus normative.

Even if we were all to concur that alte= ring the From by adding the list is the right way forward here (an intrigui= ng idea at the moment), the question of ordering would need to be addressed= , and then how that applies to all the standards we're talking about, a= nd how MUAs need to be nudged to make use of such things.
-MSK
--f46d0435c02e228eb30514b9e352-- From nobody Mon Apr 27 13:23:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97051A0210 for ; Mon, 27 Apr 2015 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.197 X-Spam-Level: * X-Spam-Status: No, score=1.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 z2mbZt5iVyef for ; Mon, 27 Apr 2015 13:23:23 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 78EDA1A01D5 for ; Mon, 27 Apr 2015 13:23:23 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 0CC4483D9 for ; Mon, 27 Apr 2015 22:23:22 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 27 Apr 2015 22:23:21 +0200 Message-ID: <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> Date: Mon, 27 Apr 2015 22:23:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 20:23:25 -0000 On Monday, April 27, 2015 7:09 AM [GMT+1=3DCET], Hector Santos wrote: > On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote: > > >=20 > > > I'd like to note that it is the presence/existance of actor > > > "Mediator" which induces the DMARC compatibility problems with > > > indirect flows. > > >=20 > > > I.e., if you supress the Mediator, all is fine and dandy. That > > > fact should at leat put some pressure on Mediator regarding the > > > searching for a solution, and should induce Mediator to > > > acknowledge that he will have to assume certain costs for such a > > > solution.=20 > > >=20 > > > I see Originator already assuming costs: deploying SPF in DNS and > > > keeping it current, deploying DKIM records and DKIM-signing > > > outgoing email, deploying DMARC records and being vigilant > > > regarding Header-From alignment in his outgoing email, etc. > > >=20 > > > And I see Receiver already assuming costs: setting up systems to > > > check SPF, DKIM and DMARC for incoming email, dealing with the > > > support costs of false positives and phised users, sending out > > > DMARC reports, etc. > > >=20 > > > What costs are Mediators currently taking to improve > > > validation/authentication of the email system as a whole? > >=20 > > and what benefits do they get in return? >=20 > Smooth operation? >=20 > Mediators don't really need to change, but their entry points need to > support DKIM+POLICY. For example, the Mediator receiver can simply > support honoring restrictive policies and it doesn't need to bother > with much else. That is interesting. Couldn't the DMARC specification spell out that Receivers claiming to be = DMARC-compliant, when choosing to *accept* incoming messages from = Senders publishing p=3Dreject (irrespective of whether such accepted = messages passed or not the DMARC checks), CANNOT after-the-fact reinject = such received messages into the public email infrastructure in any way = that could render them (or reveal them to be) DMARC-rejectable? So that if any Receiver-turned-Originator (i.e., Mediator) does = otherwise, they CANNOT claim to be DMARC-compliant? That would force DMARC-compliant Mediators to reject (or accept but not = resend) incoming email from p=3Dreject domains, irrespective of whether = such mail passes or not the initial incoming DMARC checks. Then, if the market deems DMARC valuable by itself, pressure would be = applied by the "invisible hand" there were it needs to be applied (so = that reputable actors in the email ecosystem could claim to be = DMARC-compatible). Regards, J.Gomez From nobody Mon Apr 27 13:31:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7F71A1A28 for ; Mon, 27 Apr 2015 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.601 X-Spam-Level: X-Spam-Status: No, score=-100.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 3CPe6TRClsTp for ; Mon, 27 Apr 2015 13:31:48 -0700 (PDT) Received: from secure.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2771A0203 for ; Mon, 27 Apr 2015 13:31:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2980; t=1430166705; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=kn5CrmDTwjYF1zRA0+rlSVDEKWE=; b=hqEK8fZNIjxJ/GyDuJRR mXt4h/JMRzZp5RYvVW1jzuEDw1Ij1kTKd7IVu2OjmQp5LK50iUJfe9Ix/pqCjqmy jF3WiCq8Hz5igl2JA6ZdRAnIVAJpxMFs/dWPLrviQu29yhNnMbVVMG9RxIhD4Pf2 dtAI/oRBJNru2/DIngJ36xg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 16:31:45 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3876707379.1.1472; Mon, 27 Apr 2015 16:31:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2980; t=1430166448; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LPFEOVD KHxnEq5qxmuYsFJRNDQJ1pippJgj1cY23Ukk=; b=OQ5UzM06ujymprAvr7TWArk DIr7dwdp+c+ywjN6js5/ftZTAnLLmKs5cz6aAGKnuSzThl2AEYZcULeuCZ6b25pA 1mlcDBhIOFJNW16EKS68b8uFZ9ybGPI+Mv65bJV8XtXsfDFFvy9/9sf5lwmFxMAs l6dKw3XZKQjPnSCYdZjA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 16:27:28 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2468983691.9.4108; Mon, 27 Apr 2015 16:27:27 -0400 Message-ID: <553E9CAC.7070609@isdg.net> Date: Mon, 27 Apr 2015 16:31:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <6893A88ACFED4C20A46973509E902292@fgsr.local> <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 20:31:51 -0000 On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote: > > My personal opinion is that, on the contrary, people are already way > too quick to discard proposals simply because they involve changes to > MUAs. Of course, the reality that this is an IETF WG, and what we can > do that has effect with high probability is change wire protocols. > MUA presentation is outside of our bailiwick, ...... Stephen, we (SSI) have the following MUA and/or interface points that is still supported: o Telnet/Dialup console/text-based, 80x25 Vt10x/ANSI interfaces, the display fields are generally fixed length and short, WCX P-code language. o Web-based mail Client. WCX P-Code Language. o Native GUI Mail Client. MFC C/C++ o RFC-based POP3 server interface. MFC C/C++ o RFC-based NNTP server Interface. MFC C/C++ and a RPC-based client/server MAIL API with multiple languages support, like sysop editor tools written by us and 3rd party developers. It contains a fixed TMsgHeader structure that allows for any other client to be written but more importantly represents a commonality between all integrated parts and among heterogeneous mail network systems. All systems have a common denominator: From: Date: To: Subject: ------- BODY Today, there are only two requirements in the RFC 2822/5322 format; From: and Date: It was relaxed from RFC822 requiring the To: field as well. Lets not assume that all systems are RFC x822/5322 based. Local policy can transform the message and as long as it is not a passthru and it has reached its final destination, the backend does have a lot of security conscious controls. That has been the design rule of thumb since I wrote Silver Xpress (and offline MUA for Fidonet/Internet) in the early 80s. In our Wildcat! Mail Hosting package, Preserving MIME is an SYSOP option, not a requirement for users. The only reason it is now enabled more, is because users are more multi-media ready. MUA display rendering was lost in the regeneration of RFCx822/5322 messages so preserving MIME helps with the WYSIWYG (WIZ-ee-wig) concept. Also consider that RFC message overhead is getting whack, over bloated and wasteful. I have sysops who will pull the MIME and HTML and provide a pure text transformation. If the special user has a Preserve MIME need, a request a made to the operator who will decide to set it or not. 3rd party developers have written WCX tools to help operators to make it more as a default today. > ...... and nobody really has a > good way to get ideas for MUAs broadly implemented the way we can > influence MTA implementations. Its far easier to single source the solution at the backend threat entry points. Lets not forget that the Receiver (including the Mediator receiver, not just the end-user receiver) also benefits by reducing the fraudulent mail and blocking them at the door. Its not about just protecting the originator or the end-users. -- HLS From nobody Mon Apr 27 13:58:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74A81A8A7F for ; Mon, 27 Apr 2015 13:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 JHq3uV72XqST for ; Mon, 27 Apr 2015 13:58:29 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 7BBE41A88FE for ; Mon, 27 Apr 2015 13:58:29 -0700 (PDT) Received: by wgen6 with SMTP id n6so129426321wge.3 for ; Mon, 27 Apr 2015 13:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CQna7lqywp3KyskOtzRRSOMY1DL7zK0CFo/fK77AlU8=; b=njNBHFEMnMyDUXAv1xUNPOBmG+vMjpJP6dLSHQvL3DKtT6/HxobDTMQC8e5inNyxCt bdISK0Mf0R1PsPkwEaMTujHlEzUvCaImGAQZW++O37fx0doVjytOf2Zylczek+J090X9 sCu5kRYlshlfRLE3Ux26O/Z8haCkw+2jhxyxzj32dO7rVhlDZNxQaUKyBOPskl6tgyz/ Zq05ILJa/VOgeKETBZV/plE8uzdJMnryTAMu4mu8dbfZdJzejaJYfgFgon2Xy4BFfIkw XQ9udPefCmKvshm0g+6dNLikkP3Af0AYOClzX4teQBgchq8nq4eyexa+EF983JKiz/nu 8dCA== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr26478704wjr.135.1430168308282; Mon, 27 Apr 2015 13:58:28 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Mon, 27 Apr 2015 13:58:28 -0700 (PDT) In-Reply-To: <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> Date: Mon, 27 Apr 2015 13:58:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7b86d3e6fbfab80514bb014c Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 20:58:30 -0000 --047d7b86d3e6fbfab80514bb014c Content-Type: text/plain; charset=UTF-8 On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote: > Couldn't the DMARC specification spell out that Receivers claiming to be > DMARC-compliant, when choosing to *accept* incoming messages from Senders > publishing p=reject (irrespective of whether such accepted messages passed > or not the DMARC checks), CANNOT after-the-fact reinject such received > messages into the public email infrastructure in any way that could render > them (or reveal them to be) DMARC-rejectable? > > So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, > they CANNOT claim to be DMARC-compliant? > > That would force DMARC-compliant Mediators to reject (or accept but not > resend) incoming email from p=reject domains, irrespective of whether such > mail passes or not the initial incoming DMARC checks. > > Then, if the market deems DMARC valuable by itself, pressure would be > applied by the "invisible hand" there were it needs to be applied (so that > reputable actors in the email ecosystem could claim to be DMARC-compatible). > Apart from the CANNOT bit, is that different from where we are today? -MSK --047d7b86d3e6fbfab80514bb014c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
Couldn't the DMARC specifica= tion spell out that Receivers claiming to be DMARC-compliant, when choosing= to *accept* incoming messages from Senders publishing p=3Dreject (irrespec= tive of whether such accepted messages passed or not the DMARC checks), CAN= NOT after-the-fact reinject such received messages into the public email in= frastructure in any way that could render them (or reveal them to be) DMARC= -rejectable?

So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, = they CANNOT claim to be DMARC-compliant?

That would force DMARC-compliant Mediators to reject (or accept but not res= end) incoming email from p=3Dreject domains, irrespective of whether such m= ail passes or not the initial incoming DMARC checks.

Then, if the market deems DMARC valuable by itself, pressure would be appli= ed by the "invisible hand" there were it needs to be applied (so = that reputable actors in the email ecosystem could claim to be DMARC-compat= ible).

Apart from the CANNOT bit, is th= at different from where we are today?

-MSK
--047d7b86d3e6fbfab80514bb014c-- From nobody Mon Apr 27 14:26:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890A41A8A95 for ; Mon, 27 Apr 2015 14:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 XFk5KrRAvIsl for ; Mon, 27 Apr 2015 14:26:01 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489CC1A8A9D for ; Mon, 27 Apr 2015 14:26:01 -0700 (PDT) Received: (qmail 33958 invoked from network); 27 Apr 2015 21:26:01 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Apr 2015 21:26:01 -0000 Date: 27 Apr 2015 21:25:38 -0000 Message-ID: <20150427212538.8291.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:26:02 -0000 >Couldn't the DMARC specification spell out that Receivers claiming to be >DMARC-compliant, when choosing to *accept* incoming messages from Senders >publishing p=reject (irrespective of whether such accepted messages passed >or not the DMARC checks), CANNOT after-the-fact reinject such received >messages into the public email infrastructure in any way that could render >them (or reveal them to be) DMARC-rejectable? Since there is no spec for "Receivers claiming to be DMARC-compliant" and there never will be, of course not. R's, John From nobody Mon Apr 27 14:31:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E711A907E for ; Mon, 27 Apr 2015 14:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 QxwafIrohuwR for ; Mon, 27 Apr 2015 14:31:26 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21701A913E for ; Mon, 27 Apr 2015 14:30:14 -0700 (PDT) Received: (qmail 34953 invoked from network); 27 Apr 2015 21:30:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Apr 2015 21:30:14 -0000 Date: 27 Apr 2015 21:29:51 -0000 Message-ID: <20150427212951.8319.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:31:27 -0000 >Even if we were all to concur that altering the From by adding the list is >the right way forward here (an intriguing idea at the moment), ... Just for the record, I haven't been responding to arguments about rewriting the From: line because I don't any way they will lead to anything useful, and I suspect I am far from the only one. But in this case, silence definitely does not mean consent. R's, John From nobody Mon Apr 27 14:34:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669711A802A for ; Mon, 27 Apr 2015 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 pzmS6CxpmhmA for ; Mon, 27 Apr 2015 14:33:58 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 59F561A1A28 for ; Mon, 27 Apr 2015 14:33:58 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id CB56B83D9 for ; Mon, 27 Apr 2015 23:33:56 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 27 Apr 2015 23:33:56 +0200 Message-ID: <13F8E99794B54E97A3B0A6466A75870C@fgsr.local> From: "J. Gomez" To: References: <20150427212538.8291.qmail@ary.lan> Date: Mon, 27 Apr 2015 23:33:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:34:00 -0000 On Monday, April 27, 2015 11:25 PM [GMT+1=3DCET], John Levine wrote: > > Couldn't the DMARC specification spell out that Receivers claiming > > to be DMARC-compliant, when choosing to *accept* incoming messages > > from Senders publishing p=3Dreject (irrespective of whether such > > accepted messages passed or not the DMARC checks), CANNOT > > after-the-fact reinject such received messages into the public > > email infrastructure in any way that could render them (or reveal > > them to be) DMARC-rejectable?=20 >=20 > Since there is no spec for "Receivers claiming to be DMARC-compliant" > and there never will be, of course not. What? There is an spec for DMARC. With the current DMARC specification, = anyone can do almost anything and still claim to be DMARC-compliant. = What about if to claim being DMARC-compliant, Receivers could not = reinject alien messages into the email infrastructure if the original = Sender is publishing p=3Dreject and said reinjected messages would fail = a DMARC check when performed by its ultimate Recipient(s)? Regards, J.Gomez From nobody Mon Apr 27 14:37:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48C1A1A28 for ; Mon, 27 Apr 2015 14:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 R9LpBWqg24sO for ; Mon, 27 Apr 2015 14:37:50 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE11A88A3 for ; Mon, 27 Apr 2015 14:37:38 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 56B8783D9 for ; Mon, 27 Apr 2015 23:37:37 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 27 Apr 2015 23:37:37 +0200 Message-ID: <1A3319524161475D81DCAC46BC16CB49@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430><553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net><3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> Date: Mon, 27 Apr 2015 23:37:31 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01D08143.214BEBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:37:51 -0000 ------=_NextPart_000_001D_01D08143.214BEBC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Original Message From: Murray S. Kucherawy On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote: Couldn't the DMARC specification spell out that Receivers claiming = to be DMARC-compliant, when choosing to *accept* incoming messages from = Senders publishing p=3Dreject (irrespective of whether such accepted = messages passed or not the DMARC checks), CANNOT after-the-fact reinject = such received messages into the public email infrastructure in any way = that could render them (or reveal them to be) DMARC-rejectable? So that if any Receiver-turned-Originator (i.e., Mediator) does = otherwise, they CANNOT claim to be DMARC-compliant? That would force DMARC-compliant Mediators to reject (or accept but = not resend) incoming email from p=3Dreject domains, irrespective of = whether such mail passes or not the initial incoming DMARC checks. Then, if the market deems DMARC valuable by itself, pressure would = be applied by the "invisible hand" there were it needs to be applied (so = that reputable actors in the email ecosystem could claim to be = DMARC-compatible). Apart from the CANNOT bit, is that different from where we are today? Well, the CANNOT part would impede the whole lot of problems we are = trying to solve, wouldn't it so? Regards, J.Gomez ------=_NextPart_000_001D_01D08143.214BEBC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Original Message From: Murray S. Kucherawy
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez <jgomez@seryrich.com> wrote:
Couldn't the DMARC specification spell = out that=20 Receivers claiming to be DMARC-compliant, when choosing to *accept* = incoming=20 messages from Senders publishing p=3Dreject (irrespective of whether = such=20 accepted messages passed or not the DMARC checks), CANNOT = after-the-fact=20 reinject such received messages into the public email infrastructure = in any=20 way that could render them (or reveal them to be)=20 DMARC-rejectable?

So that if any Receiver-turned-Originator = (i.e.,=20 Mediator) does otherwise, they CANNOT claim to be=20 DMARC-compliant?

That would force DMARC-compliant Mediators = to reject=20 (or accept but not resend) incoming email from p=3Dreject domains,=20 irrespective of whether such mail passes or not the initial incoming = DMARC=20 checks.

Then, if the market deems DMARC valuable by itself, = pressure=20 would be applied by the "invisible hand" there were it needs to be = applied=20 (so that reputable actors in the email ecosystem could claim to be=20 DMARC-compatible).

Apart from the CANNOT bit, is that = different=20 from where we are today?
Well, the=20 CANNOT part would impede the whole lot of problems we are trying to = solve,=20 wouldn't it so?
 
Regards,
J.Gomez
 
 
 
------=_NextPart_000_001D_01D08143.214BEBC0-- From nobody Mon Apr 27 14:51:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E372E1A8A4C for ; Mon, 27 Apr 2015 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 UlYev6-dasHp for ; Mon, 27 Apr 2015 14:51:01 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97A01A88A3 for ; Mon, 27 Apr 2015 14:51:01 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CDC66C4016C for ; Mon, 27 Apr 2015 16:51:00 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430171460; bh=ixiQLVB04INGvUORGPHWVxQrEPP9HB38kULyou+A35s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nQoW3zg63xw98JtHy2mzvlBxyUGUahyU3+qGzpnPKCIZ1NS0liocX4hJFCLvD+tqc 4bWuODnG4U0gU9tNgRwuN+gF5XrMJIHMsAyP+w7t5M1YitEsEX4/iL+q5ReVFn3h4l ucbjXCoPuCTctpPHnZJcl2SD2g30vpaZBuDrCYMM= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 27 Apr 2015 17:51 -0400 Message-ID: <10675578.mWgmD9TIe1@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <13F8E99794B54E97A3B0A6466A75870C@fgsr.local> References: <20150427212538.8291.qmail@ary.lan> <13F8E99794B54E97A3B0A6466A75870C@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:51:03 -0000 On Monday, April 27, 2015 11:33:50 PM J. Gomez wrote: > On Monday, April 27, 2015 11:25 PM [GMT+1=CET], John Levine wrote: > > > Couldn't the DMARC specification spell out that Receivers claiming > > > to be DMARC-compliant, when choosing to *accept* incoming messages > > > from Senders publishing p=reject (irrespective of whether such > > > accepted messages passed or not the DMARC checks), CANNOT > > > after-the-fact reinject such received messages into the public > > > email infrastructure in any way that could render them (or reveal > > > them to be) DMARC-rejectable? > > > > Since there is no spec for "Receivers claiming to be DMARC-compliant" > > and there never will be, of course not. > > What? There is an spec for DMARC. With the current DMARC specification, > anyone can do almost anything and still claim to be DMARC-compliant. What > about if to claim being DMARC-compliant, Receivers could not reinject alien > messages into the email infrastructure if the original Sender is publishing > p=reject and said reinjected messages would fail a DMARC check when > performed by its ultimate Recipient(s)? Why would a mailing list care to claim spec conformance? All they care about is getting the mail delivered, managing subscriber lists, etc. Since there are no internet police, can not doesn't mean anything. Scott K From nobody Mon Apr 27 14:56:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED931A88A3 for ; Mon, 27 Apr 2015 14:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 rkYoYGN5B5ZV for ; Mon, 27 Apr 2015 14:56:47 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (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 DF5851A1B7F for ; Mon, 27 Apr 2015 14:56:46 -0700 (PDT) Received: by wgyo15 with SMTP id o15so130906939wgy.2 for ; Mon, 27 Apr 2015 14:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dMD2jjud7zyN846eQxwormwveQ5/FsrB95xe/PYIYtc=; b=YfWba/Vjtet7nyUM9qnQpb/ENknT9I8NWctTDq/y30Z1Lszv98SDEY3SyU23tWbq5f WDGSONoM55A3fvj1knIoLFcng3MLzSSI8/IJXx+QdiJPFjtw4FWOCtBn9HgeH7LMvVzS IAW2qI6ElR98Pf6H3eTO0uoAoKXYOKTg69AYQOEPAZcUVXzbTk5E/MPyIf3WBR98M0v+ ne2HPBmzRRkUb35hp1jl4tiQppwoQt4kb+eMprXL4fBkTeU4x7POeNp63RWJlA57Lx3j ZyxX0G9J0gxW/T2Rgh6CzITB1sGgKGh+2aKTv1k6SmYlikqIaTpxKdTqdWdcPvr9A8bp D8cA== MIME-Version: 1.0 X-Received: by 10.180.106.73 with SMTP id gs9mr24841114wib.52.1430171805618; Mon, 27 Apr 2015 14:56:45 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Mon, 27 Apr 2015 14:56:45 -0700 (PDT) In-Reply-To: <1A3319524161475D81DCAC46BC16CB49@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> Date: Mon, 27 Apr 2015 14:56:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d04428fce7118c80514bbd20d Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:56:48 -0000 --f46d04428fce7118c80514bbd20d Content-Type: text/plain; charset=UTF-8 On Mon, Apr 27, 2015 at 2:37 PM, J. Gomez wrote: > Apart from the CANNOT bit, is that different from where we are today? > > Well, the CANNOT part would impede the whole lot of problems we are trying > to solve, wouldn't it so? > Maybe. I was just confirming that that's the only part that's different in your proposal. I think there's a concern with this approach though. I don't believe we can just come up with something new on the standards track and then go hit operators over the head with it telling them they're non-compliant. That tends not to be well-received, to put it lightly. -MSK --f46d04428fce7118c80514bbd20d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 27, 2015 at 2:37 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
Apart from the CANNOT bit, is that dif= ferent=20 from where we are today?
Well, the=20 CANNOT part would impede the whole lot of problems we are trying to solve,= =20 wouldn't it so?

Maybe.=C2=A0 I was just confirming t= hat that's the only part that's different in your proposal.

=
I think there's a concern with this approach though.=C2=A0 I= don't believe we can just come up with something new on the standards = track and then go hit operators over the head with it telling them they'= ;re non-compliant.=C2=A0 That tends not to be well-received, to put it ligh= tly.

-MSK
--f46d04428fce7118c80514bbd20d-- From nobody Mon Apr 27 14:56:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC971A8AB8 for ; Mon, 27 Apr 2015 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 j6SsWm2QNvxy for ; Mon, 27 Apr 2015 14:56:49 -0700 (PDT) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3041A1B7F for ; Mon, 27 Apr 2015 14:56:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1799; t=1430171805; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NC7mDA1WOseBdM8dWhDhKpGB5h0=; b=wwadHvAjsqi4SYwnCccn xAc5pNib1fLzlQHRzug2y3MawwF+6A0AE1gAQ5E0mFaXAJkJvVZYuJjBp0f0RtO6 nYLbaT5SsU5PLW0xQuyUyjFpwnHW/NBLHNGrcFVhbgbS8vVAmAq0jqZz7WI9LbV7 W/NiaESxZ1YSyvrqjLZXSDA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 17:56:45 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3881807457.1.3100; Mon, 27 Apr 2015 17:56:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1799; t=1430171552; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LZnNWnv 2ZihAB93QpQQwQ2gyQNNTF9KZKK+VfZmcBlg=; b=P1ysVRzKXauYQpkt/9cQzKC MgDUeo0bcF/CdyPId9f6ORKP7pBfjDiAyICSYup3qIKMqKXBajWHHdw6C8O/xttZ bj38L9Ru4Z+N/60FS/CagBzoLfhcZkBYvkswiRBGPEFDmi5ucGoE2t+TvtFry67C 2E22ep+PPZM/laqrUu3M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 17:52:32 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2474087832.9.2836; Mon, 27 Apr 2015 17:52:31 -0400 Message-ID: <553EB09C.3070807@isdg.net> Date: Mon, 27 Apr 2015 17:56:44 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> In-Reply-To: <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:56:51 -0000 On 4/27/2015 4:23 PM, J. Gomez wrote: >> Smooth operation? >> >> Mediators don't really need to change, but their entry points need to >> support DKIM+POLICY. For example, the Mediator receiver can simply >> support honoring restrictive policies and it doesn't need to bother >> with much else. > > That is interesting. > > Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received messages into the public email infrastructure in any way that could render them (or reveal them to be) DMARC-rejectable? > Yes. To be protocol Z-ORDER correct, yes. > So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant? > It would be violation of he protocol engine -- causing potential grief. > That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC checks. > As DMARC is written yes, this is why we need the 3rd party authorization. It is incomplete otherwise. > Then, if the market deems DMARC valuable by itself, pressure would be applied by the "invisible hand" there were it needs to be applied (so that reputable actors in the email ecosystem could claim to be DMARC-compatible). > Can't have it both ways. If a MLM has resigning and touching based with DKIM, it needs to filter the unauthorized DMARC mail at the MLM receiver just like their is a presumption the distribution end-user MDA receivers will also apply DMARC. -- HLS From nobody Mon Apr 27 15:12:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605231A1C02 for ; Mon, 27 Apr 2015 15:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 RDwUeIyYYiGW for ; Mon, 27 Apr 2015 15:12:08 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7171A0173 for ; Mon, 27 Apr 2015 15:12:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1546; t=1430172721; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Bmj1oj8XxLZd7cwH3mPS5khBG9I=; b=qLde2KhMYiGY7Lob7XAI Na2Zrqy9PjOwTlMS+ZP2aUWx8MLKGujbTLq+IJZeIT/ArbeHm9olkRlSwrXNasnQ py9ZDD7bjQJ/6mIIdBgBzLaaQpZQU7CeFc8HTbk7zXUYhbOTUfxmqGLCDRiU2/Rk jG11KFDVWFikz8d9c8bD2Ng= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 18:12:01 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3882722684.1.5736; Mon, 27 Apr 2015 18:12:00 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1546; t=1430172465; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CBYvQFQ C0EZHsfWltlG5t+60qpVoB1vLY5ZZVyyRIls=; b=xqGmU1uSfmHq/JMMGR80yXT dp97pav3MEYHFvkJMMC2VGk9s99/nqhXOWyvgf5J4XKrxHrmESwtkUdm5PHeytGn hj/nN6wb3+Eqf2p8sH1qpERllHuePWKYjM0lQ9CfMWkHXi3e8CGTW+clTgXNf2Tw wIuhR0f6EHRYmxASiCNw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 18:07:45 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2475000863.9.480; Mon, 27 Apr 2015 18:07:44 -0400 Message-ID: <553EB42D.2040102@isdg.net> Date: Mon, 27 Apr 2015 18:11:57 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150427212538.8291.qmail@ary.lan> <13F8E99794B54E97A3B0A6466A75870C@fgsr.local> <10675578.mWgmD9TIe1@kitterma-e6430> In-Reply-To: <10675578.mWgmD9TIe1@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 22:12:09 -0000 On 4/27/2015 5:51 PM, Scott Kitterman wrote: >> >> What? There is an spec for DMARC. With the current DMARC specification, >> anyone can do almost anything and still claim to be DMARC-compliant. What >> about if to claim being DMARC-compliant, Receivers could not reinject alien >> messages into the email infrastructure if the original Sender is publishing >> p=reject and said reinjected messages would fail a DMARC check when >> performed by its ultimate Recipient(s)? > > Why would a mailing list care to claim spec conformance? > > All they care about is getting the mail delivered, managing subscriber lists, > etc. Since there are no internet police, can not doesn't mean anything. Lets not lump "mailing list" into the same kind or group of MLM operations. I care. I have a product to market. As a side note, there is a legal argument to make when a MLM has intentionally ignored a security protocol designed to protect a domain and end-users. Claims of MalPractice and Intentional Neglect can easily be made. There is most certainly, product liability issues. Can't have it both ways. The point is not what the MLM does, but what the MLM RECEIVER does. It MUST also be a DMARC compliant system too as a protocol design presumption. So as I always said, the first rule of thumb is to follow the honor protocol first. And if that doesn't make sense, then its broken. DMARC is an incomplete protocol until it offers support for ADID != SDID conditions whether its deemed feasible or not by some. -- HLS From nobody Mon Apr 27 15:20:55 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE851A9123 for ; Mon, 27 Apr 2015 15:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Qtn02kL8b4Tx for ; Mon, 27 Apr 2015 15:20:52 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826701A9111 for ; Mon, 27 Apr 2015 15:20:52 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A3E6CC40020 for ; Mon, 27 Apr 2015 17:20:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430173251; bh=HgjQsfyxU+CgG0vTg9U2YJT6ln+6TitjxpPCnqXZbP8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QuGTRIYGZPRgkwmILA6qR6HDlZznM+EdeO98bXscbq1YHqTPPAMcEa++rd2Lz/cDs CKEJrrD81pVcIKFSqeKAVcipihX4C7Q/6ASUyOYLbCJwxS1OPDS7fhYarjrLEFYpjZ 7KikRJaalCsi3FRr4RJS32rnAoRhlzkiOz7Xqxag= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 27 Apr 2015 18:20:51 -0400 Message-ID: <2675878.ClLBlkcuOx@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <553EB42D.2040102@isdg.net> References: <20150427212538.8291.qmail@ary.lan> <10675578.mWgmD9TIe1@kitterma-e6430> <553EB42D.2040102@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 22:20:53 -0000 On Monday, April 27, 2015 06:11:57 PM Hector Santos wrote: > On 4/27/2015 5:51 PM, Scott Kitterman wrote: > >> What? There is an spec for DMARC. With the current DMARC specification, > >> anyone can do almost anything and still claim to be DMARC-compliant. What > >> about if to claim being DMARC-compliant, Receivers could not reinject > >> alien > >> messages into the email infrastructure if the original Sender is > >> publishing > >> p=reject and said reinjected messages would fail a DMARC check when > >> performed by its ultimate Recipient(s)? > > > > Why would a mailing list care to claim spec conformance? > > > > All they care about is getting the mail delivered, managing subscriber > > lists, etc. Since there are no internet police, can not doesn't mean > > anything. > Lets not lump "mailing list" into the same kind or group of MLM > operations. I care. I have a product to market. As a side note, > there is a legal argument to make when a MLM has intentionally ignored > a security protocol designed to protect a domain and end-users. > Claims of MalPractice and Intentional Neglect can easily be made. > There is most certainly, product liability issues. Can't have it both > ways. I'm not aware of any cases where someone was successfully sued for not implementing something that's optional. > The point is not what the MLM does, but what the MLM RECEIVER does. > It MUST also be a DMARC compliant system too as a protocol design > presumption. > > So as I always said, the first rule of thumb is to follow the honor > protocol first. And if that doesn't make sense, then its broken. > DMARC is an incomplete protocol until it offers support for ADID != > SDID conditions whether its deemed feasible or not by some. As a mail receiver, they can accept or reject mail based on DMARC policies and be compliant as a receiver. That helps not at all when the mediator later modifies the message so a DKIM signature breaks. DMARC may be incomplete, but it's sufficiently complete for large scale deployment. Scott K From nobody Mon Apr 27 15:36:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBACF1ABD37 for ; Mon, 27 Apr 2015 15:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 dudNVorIxVCv for ; Mon, 27 Apr 2015 15:36:14 -0700 (PDT) Received: from mail.santronics.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 886C61AC3B3 for ; Mon, 27 Apr 2015 15:36:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2515; t=1430174166; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=c6VS10aArtt/aaWnvOLm41aZ1Ao=; b=s8R59juahAc8VWZkE+da eC+UfoVykwwd+B+tr3TJ/P0t2OZfJUMqdq4uO8smdgmdUaLyq6wiu/M6jjmmwH44 8DLdjepXIsVJJMnlvBN4jV+OK+kkUpNdVjM8JcvHXfTvZpYVz8HX/4cd+G7ICYM2 9n8tW/kmaFj3NhlTW93IWmc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 18:36:06 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3884167627.1.2864; Mon, 27 Apr 2015 18:36:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2515; t=1430173909; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=cvZTia/ t5CylVoKe5VdR62hYziK/OED6K6WyH/v4ArI=; b=Hgiz3Q4uJuqDITaKvhDkTQC dx6WCJtE4sbjTU4fZLmQ1ldv1PwjH0U79g+2x3OCIZoPFpF9Gr3K/7z+jqvgUr3l Oo5u5Sl6H1znljSkSI6yhB8NeRdvhYo6tzzwGEyzqbdqfnZ+mJgbaa7/cVBWQ7KG QTbsxvMm+PhqC5e6fj3A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 27 Apr 2015 18:31:49 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2476445113.9.9284; Mon, 27 Apr 2015 18:31:48 -0400 Message-ID: <553EB9D1.1050200@isdg.net> Date: Mon, 27 Apr 2015 18:36:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150427212538.8291.qmail@ary.lan> <10675578.mWgmD9TIe1@kitterma-e6430> <553EB42D.2040102@isdg.net> <2675878.ClLBlkcuOx@kitterma-e6430> In-Reply-To: <2675878.ClLBlkcuOx@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 22:36:17 -0000 On 4/27/2015 6:20 PM, Scott Kitterman wrote: >> Lets not lump "mailing list" into the same kind or group of MLM >> operations. I care. I have a product to market. As a side note, >> there is a legal argument to make when a MLM has intentionally ignored >> a security protocol designed to protect a domain and end-users. >> Claims of MalPractice and Intentional Neglect can easily be made. >> There is most certainly, product liability issues. Can't have it both >> ways. > > I'm not aware of any cases where someone was successfully sued for not > implementing something that's optional. > Reread what I said. There is most certainly product liability concerns. You don't have to wait until a lawsuit occurs to know what is the ethical, common sense engineering thing to do that will minimize both technical and legal contention. The dilemma with this is the same as it was ADSP -- the MLM receiver can not skip a DKIM policy protocol and also do resigning. With a 3rd authorization scheme in place, the MLM SHOULD only work on the relaxed policies. >> The point is not what the MLM does, but what the MLM RECEIVER does. >> It MUST also be a DMARC compliant system too as a protocol design >> presumption. >> >> So as I always said, the first rule of thumb is to follow the honor >> protocol first. And if that doesn't make sense, then its broken. >> DMARC is an incomplete protocol until it offers support for ADID != >> SDID conditions whether its deemed feasible or not by some. > > As a mail receiver, they can accept or reject mail based on DMARC policies and > be compliant as a receiver. That helps not at all when the mediator later > modifies the message so a DKIM signature breaks. If the policy is relaxed, then it doesn't matter. > DMARC may be incomplete, but it's sufficiently complete for large scale > deployment. Dimensional Analysis -- what works for the smallest dimension will in theory work at any dimension. Anyway, we have been saying that since day one -- DKIM POLICY highest benefit is the direct 1st party signature polices and that satisfies MOST domains. But we still have the indirect problem because both ADSP and DMARC lacks the ADID != SDID protocol semantics. ADSP punted on it. DMARC tries to punt on it and we should not be surprise we are finding they can't. If they want to punt on it, then they MUST honor the restrictive policies at the MLM receiver, at the entry point. That is all the point was. -- HLS From nobody Mon Apr 27 17:52:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C101ACDD4 for ; Mon, 27 Apr 2015 17:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham 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 rvtAMaspBm_I for ; Mon, 27 Apr 2015 17:52:29 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 07D801ACDD2 for ; Mon, 27 Apr 2015 17:52:29 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 88B07563DDD; Mon, 27 Apr 2015 19:52:28 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 75FDCA03B6; Mon, 27 Apr 2015 19:52:28 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hMJNzd6EAxI; Mon, 27 Apr 2015 19:52:28 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B6758A03DB; Mon, 27 Apr 2015 19:52:27 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com B6758A03DB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430182348; bh=CXxWEKrtmL21mIPOGSDtoB5bUxisyLrQyS2G0CqkQ0M=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=k4fHWbFgIVpFku0qgjHnx/QSiQVdXStY0hov9PEmp4iWb4o4RCqgdDXlCY4RSPada Gxis2wrbV6/103R6v0biqboFxeciB+2txkmykeWVua0FDsAM8uRgBVCNgRGJEq9Shv EHSAV+zR21TulZiZFjhDJmLoWQ9l5U+vILkYf2vQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8B447A03C9; Mon, 27 Apr 2015 19:52:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lg_Vun58ByDr; Mon, 27 Apr 2015 19:52:27 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 491EFA03B6; Mon, 27 Apr 2015 19:52:27 -0500 (CDT) Date: Mon, 27 Apr 2015 19:52:26 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <120984049.22938.1430182346164.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <905729822.12380.1427120800921.JavaMail.zimbra@peachymango.org> <341743611.12421.1427120848801.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22937_1935898478.1430182346163" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-01.txt Thread-Index: CZ1dWzeUuO9h88Itduhmx8MuSpdynQ== Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 00:52:32 -0000 ------=_Part_22937_1935898478.1430182346163 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sorry for delay, Elizabeth did more fixing and I'm going through the reviews now. See comments inline. ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "dmarc" > Sent: Tuesday, March 31, 2015 1:01:15 PM > Subject: Re: [dmarc-ietf] New Version Notification for > draft-ietf-dmarc-interoperability-01.txt > On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin < franck@peachymango.org > > wrote: > > Looking better... > > > Special thanks to Elizabeth for improving the document after I integrated > > (all?) previous comments. Please see this revision and post > > comments/reviews > > against it. > > It sure seems better. :-) > A few comments on this version: > Section 1 and the Abstract use an impersonal writing style (this document > does this, this section does that) while in Section 2 it changes to using > "we". I suggest sticking with the former style. > OLD: > What do we mean by "interoperability issues"? We say that DMARC > introduces interoperability issues or problems, when conformance to > the DMARC specification leads an implementation to reject a message > that is both compliant with the architecture as specified in > [ RFC5598 ] and would have been viewed as legitimate in the eyes of the > intended recipient. Therefore, we can already conclude that DMARC > poses no interoperability problems when legitimate messages properly > validate through its specified processes. The rest of this section > delves into how legitimate messages may get rejected. > NEW: > Interoperability issues are introduced when conformance to the DMARC > specification leads an implementation to reject a message that is both > compliant with the architecture as specified in [RFC5598] and would > have been viewed as legitimate in the eyes of the intended recipient. > Therefore, it can already be concluded that DMARC poses no interoperability > problems when legitimate messages properly validate through its specified > processes. The rest of this section delves into how legitimate messages can > be rejected. > ...etc. fixed > The last paragraph of Section 2.1 opens with a run-on sentence. Also, since > that chapter is entirely about SPF, all of the [RFC7208] references can be > omitted; they make an already-long sentence rather cluttered. fixed > Also, this paragraph (and I think the one before it as well) talk about > alignment being defined as the two identifiers sharing the same > Organizational Domain, but in fact that depends on whether relaxed or strict > mode is active, right? > It also has this: > Even when an SPF record exists for the domain in RFC5322 .From, SPF > will not authenticate it unless it is also the domain SPF checks. > I'm confused. When is the SPF record for the RFC5322.From domain ever > checked? Shouldn't that be the DMARC policy, not the SPF policy? fixed > In Section 2.3, the "RFC6376 [RFC6376]" is redundant and can be cleaned up. fixed > What does "Furthermore, the use of the length flag is by no means universal." > mean? Does that mean not everyone uses it, or not all software implements > it? fixed > "DKIM has two canonicalizations: simple and relaxed." ...is true for both the > header and the body. fixed > "The relaxed canonicalization used to be computing intensive and may not have > been preferred in the early deployment of DKIM." It's still true that > relaxed requires more processing than strict, but I've never heard that used > as a basis for not using it. It's not a heavyweight process. true, but early implementation may not have been that great too > Section 3.1.1: > "marked by an inherent difficulty in modifying" -- It's not modifying that's > hard, it's establishing alignment that's hard. fixed > A pure syntax point: All the entries in that bullet list end in periods, but > are not capitalized; either make them phrases (drop the period) or make them > sentences (capitalize) fixed > Section 3.1.2.1 : > Should "8-bit mail" be "8-bit MIME"? I don't know what a "mail section" is. fixed > Also, I think RFC6376 has some discussion about this. Might be useful to > refer to it. > Section 3.1.2.2 : > "In addition, group syntax will remove the ability for the DMARC mechanism to > find an Organizational Domain that aligns with any authenticated domain > identifier from SPF or DKIM." Is that strictly true? Didn't we say in > DMARC (I forget now) that a receiver could evaluate all such domains? Or am > I thinking of the wrong problem? group syntax does not give you a domain. From: undisclosed-sender; > Section 3.1.3 talks about application of SIEVE, but wouldn't that sort of > thing happen after SPF and DKIM have already been evaluated? sure but "SIEVE may become an issue when the email is reintroduced in the transport infrastructure." > Section 3.2.3, same earlier syntax point about the bullet list. Also, > RFC6377 contains a more detailed description of the third-party bounce > problem and how it can be destructive. this is the problem section, solutions are later > Would it be worth pointing out that the typical MLM changes are not only > common, but perfectly valid within the context of email? Or that declaring > those things as no-longer-permitted is not likely to succeed? > Section 3.2.4: "acquired companies domains" should be "acquired company's > domains". Also "To: header" should be "RFC5322.To header field". added but differently > Section 3.2.5 should mention that whether a boundary filter introduces an > interop problem depends on where the DKIM and SPF evaluations are done. If > they're inside a modifying filter, there's a problem, but not otherwise. fixed > Section 4: "proper handling multiple DKIM signatures" should be "proper > handling of multiple DKIM signatures" fixed > Also Section 4: What are "the DMARC headers"? just DMARC, fixed > Section 4.1: Should we list potential side effects of each of these? > Changing the From: to something aligned affects what the end user will see > as the author, for example. added some and your point > Section 4.2: "email headers" should be "email header fields", "preferring > preserving" should be "preferring to preserve" fixed > Section 4.3: Another "header" that should be "header field", and > "yet-another" shouldn't have a hyphen. fixed > Section 4.4.1.2 : "email headers" to "email header fields" fixed > Section 4.4.1.3 : "at the appreciation of the postmaster"? I'm not familiar > with that expression. Perhaps "at the discretion of the mail > administrator"? gone > Section 4.5.1: "depending if" -> "depending on whether". Also the bullet > starting "Finally" is (a) comma-spliced, and (b) not the final item in the > list. And the reference to RFC7372 is correct, but it might be worth saying > that it's not widely deployed yet. fixed > Section 4.6: Misspelling of "alignment". More generally, I'm confused by > what this section is saying. How is the message store involved in DMARC? fixed > That's it for this pass. > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ------=_Part_22937_1935898478.1430182346163 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sorry for delay, Elizabeth did more fixing an= d I'm going through the reviews now. See comments inline.
From: "Murray S. Kucherawy" <superuser@gmail.com>
<= b>To: "Franck Martin" <franck@peachymango.org>
Cc: "dma= rc" <dmarc@ietf.org>
Sent: Tuesday, March 31, 2015 1:01:15 = PM
Subject: Re: [dmarc-ietf] New Version Notification for draft-i= etf-dmarc-interoperability-01.txt

On Mon= , Mar 23, 2015 at 7:27 AM, Franck Martin <franck@peachymango.org&= gt; wrote:
=
Looking better...

Special thanks to Elizabeth for improving the document after I integrated (= all?) previous comments. Please see this revision and post comments/reviews= against it.

It sure seems better. = ; :-)

A few comments on this version:
=
Section 1 and the Abstract use an impersonal writing s= tyle (this document does this, this section does that) while in Section 2 i= t changes to using "we".  I suggest sticking with the former style.

OLD:

   What do we mean b=
y "interoperability issues"?  We say that DMARC
   introduces interoperability issues or problems, when conformance to
   the DMARC specification leads an implementation to reject a message
   that is both compliant with the architecture as specified in
   [RFC5598] and would have been=
 viewed as legitimate in the eyes of the
   intended recipient.  Therefore, we can already conclude that DMARC
   poses no interoperability problems when legitimate messages properly
   validate through its specified processes.  The rest of this section
   delves into how legitimate messages may get rejected.

=

NEW:

Interoperability issues are int=
roduced when conformance to the DMARC
specification leads an implementat=
ion to reject a message that is both
compliant with the architecture as =
specified in [RFC5598] and would
have been viewed as legitimate in the e=
yes of the intended recipient.
Therefore, it can already be concluded th=
at DMARC poses no interoperability
problems when legitimate messages pro=
perly validate through its specified
processes.  The rest of this sectio=
n delves into how legitimate messages can
be rejected.

...etc.
fixed


The last paragraph of Sec=
tion 2.1 opens with a run-on sentence.  Also, since that chapter is entirel=
y about SPF, all of the [RFC7208] references can be omitted; they make an a=
lready-long sentence rather cluttered.
fixed
Also, this paragraph (and I think the one b=
efore it as well) talk about alignment being defined as the two identifiers=
 sharing the same Organizational Domain, but in fact that depends on whethe=
r relaxed or strict mode is active, right?

<= pre>It also has this:


Even when an SPF r= ecord exists for the domain in RFC5322.From, SPF will not authenticate it unless it is also the domain SPF checks. 
I'm c=
onfused.  When is the SPF record for the RFC5322.From domain ever checked? =
Shouldn't that be the DMARC policy, not the SPF policy?
<= /div>
fixed

In Section 2.3, the "RFC6376 [RFC6376]" is redundant =
and can be cleaned up.
fixed

What does "=
Furthermore, the use of the length flag is by no means universal." mean?  D=
oes that mean not everyone uses it, or not all software implements it?
fixed


"DKIM has two canonicalizations: simple and r=
elaxed." ...is true for both the header and the body.
fixed


"The relaxed canonicalization used to =
be computing intensive and may not have been preferred in the early deploym=
ent of DKIM." It's still true that relaxed requires more processing than st=
rict, but I've never heard that used as a basis for not using it.  It's not=
 a heavyweight process.
true, but early implementation may not have been that great too
Section 3.1.1:

"marked by an inherent difficulty in modifying" -- It's not modifying t=
hat's hard, it's establishing alignment that's hard.
fixed
= 

A pure syntax point: All the entries in that bullet list=
 end in periods, but are not capitalized; either make them phrases (drop th=
e period) or make them sentences (capitalize)
<= /div>
fixed
Also, I=
 think RFC6376 has some discussion about this.  Might be useful to refer to=
 it.

Section 3=
.1.2.2:

"In addition, group syntax will remove the ab=
ility for the DMARC mechanism to find an Organizational Domain that aligns =
with any authenticated domain identifier from SPF or DKIM."  Is that strict=
ly true?  Didn't we say in DMARC (I forget now) that a receiver could evalu=
ate all such domains?  Or am I thinking of the wrong problem?
group syntax does not give you= a domain.

From: undisclosed-sender;
Section 3.1.3 talks about application of SIEVE, but woul=
dn't that sort of thing happen after SPF and DKIM have already been evaluat=
ed?
sure but "SIE= VE may become an issue when the email is reintroduced in the transport infr= astructure."
Section 3.2.=
3, same earlier syntax point about the bullet list.  Also, RFC6377 contains=
 a more detailed description of the third-party bounce problem and how it c=
an be destructive.
this is the problem section, solutions are later
Would it be worth pointing out that the typical=
 MLM changes are not only common, but perfectly valid within the context of=
 email?  Or that declaring those things as no-longer-permitted is not likel=
y to succeed?
Section 3.2.4: "acquired companies domains" should be "acqui=
red company's domains".  Also "To: header" should be "RFC5322.To header fie=
ld".
added but di= fferently
<= div dir=3D"ltr">
= 
Section 3.2.5 s=
hould mention that whether a boundary filter introduces an interop problem =
depends on where the DKIM and SPF evaluations are done.  If they're inside =
a modifying filter, there's a problem, but not otherwise.
<= /div>
fixed
Section 4: "proper handling multiple DKIM signa=
tures" should be "proper handling of multiple DKIM signatures"
fixed
Also Section 4: What are "the DMARC headers"=
?
just DMARC, fix= ed
Section 4.1: Shoul= d we list potential side effects of each of these? Changing the From: to s= omething aligned affects what the end user will see as the author, for exam= ple.
added some a= nd your point
Section=
 4.2: "email headers" should be "email header fields", "preferring preservi=
ng" should be "preferring to preserve"
fixed
Section 4.3: Another "header" that should be "header field", and "ye=
t-another" shouldn't have a hyphen.
fixed
Section 4.4.1.2: "emai=
l headers" to "email header fields"
fixed
Section 4.4.1.3: "at t=
he appreciation of the postmaster"?  I'm not familiar with that expression.=
  Perhaps "at the discretion of the mail administrator"?
gone
Section 4.5.1: "depending if" -> "depending on w=
hether".  Also the bullet starting "Finally" is (a) comma-spliced, and (b) =
not the final item in the list.  And the reference to RFC7372 is correct, b=
ut it might be worth saying that it's not widely deployed yet.
fixed
Section 4.6: Misspelling of "alignment".  Mo=
re generally, I'm confused by what this section is saying.  How is the mess=
age store involved in DMARC?
fixed
Tha=
t's it for this pass.
-MSK

___= ____________________________________________
dmarc mailing list
dmarc= @ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

------=_Part_22937_1935898478.1430182346163-- From nobody Mon Apr 27 18:22:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1330B1ACDE2 for ; Mon, 27 Apr 2015 18:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 kpNstBySjfm0 for ; Mon, 27 Apr 2015 18:22:29 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E2D751ACDE1 for ; Mon, 27 Apr 2015 18:22:28 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 998CC1C38A2; Tue, 28 Apr 2015 10:22:27 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 749A31A2CC0; Tue, 28 Apr 2015 10:22:27 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <553E9CAC.7070609@isdg.net> References: <6893A88ACFED4C20A46973509E902292@fgsr.local> <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> <553E9CAC.7070609@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Apr 2015 10:22:27 +0900 Message-ID: <874mo1qc6k.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 01:22:31 -0000 Hector Santos writes: > On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote: > > > > My personal opinion is that, on the contrary, people are already way > > too quick to discard proposals simply because they involve changes to > > MUAs. Of course, the reality that this is an IETF WG, and what we can > > do that has effect with high probability is change wire protocols. > > MUA presentation is outside of our bailiwick, ...... > > Stephen, we (SSI) have the following MUA and/or interface points that > is still supported: Knowing what your product *does* is useless to me, unless you provide it to one or more of the following: AOL, Yahoo!, GMail, Hotmail, and the Outlook family. I'm far more interesting in *rationale* (defined as "arguments more detailed than writing POLICY in all caps") *for design*. > Today, there are only two requirements in the RFC 2822/5322 format; > From: and Date: It was relaxed from RFC822 requiring the To: field as > well. > > Lets not assume that all systems are RFC x822/5322 based. The Internet is, and that's what we're here to discuss and improve, no? If the MDA/MUA functions transform the message, tracking the information that used to be in the header is their problem. But to the extent that MDAs and MUAs preserve and handle the RFC 822 format, some techniques we consider here may be appropriately recommended to MUA developers (eg, in a BCP), and may be useful in design of non- Internet message processors. > Also consider that RFC message overhead is getting whack, over > bloated and wasteful. Redundancy is the fundamental constituent of robustness. In any case, in my INBOX, the median size Internet message is about 20KB, of which about 4KB is header (20%). However because of spam and attachments (before saving and stripping attachments) header content of non-spam is less than 2%, on heavy spam days, well under 1%. By contrast, spam, unnecessary office attachments, and quote bloat probably account for an order of magnitude more "bloat" than headers. If this "header bloat" causes a real problem in processing, tell us about the real problem. > I have sysops who will pull the MIME and HTML and provide a pure > text transformation. If the special user has a Preserve MIME need, > a request a made to the operator who will decide to set it or not. > 3rd party developers have written WCX tools to help operators to > make it more as a default today. Obviously users of your product account for a tiny minority of Internet mail, then, as I personally don't know anybody who would consider "MIME is more of a default" as adequate for handling their mail streams.[1] Even my Emacs-MUA-using colleagues get pictures of their babies from their spouses and send them to the grandparents. > Lets not forget that the Receiver (including the Mediator receiver, > not just the end-user receiver) also benefits by reducing the > fraudulent mail and blocking them at the door. Its not about just > protecting the originator or the end-users. The problem I'm trying to solve at the moment is not that too little "bad" mail gets blocked (though that is still a problem). It's that current protocols block 100% of "good" mail of certain classes (where "class" is sufficiently detailed as to include the DMARC policies of Originator and Receiver). Perhaps others are more interested in blocking more bad mail than I am, but AFAICS DMARC has gone as far as possible in blocking bad mail based on author domain alignment (I really don't think Doug Otis's proposal to use Sender instead or in addition can help). I haven't seen any suggestions to improve bad mail blocking here, except for your advocacy of stricter "policy", but as a Mediator developer, I can't be happy about going in that direction without third-party authorization, and we don't have a consensus on that here, let alone uptake from DMARC participating Author Domains. From nobody Mon Apr 27 18:40:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4C31ACE00 for ; Mon, 27 Apr 2015 18:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=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 mvy2pBgyKfJM for ; Mon, 27 Apr 2015 18:39:54 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A90001ACDDE for ; Mon, 27 Apr 2015 18:39:54 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 176271C3880; Tue, 28 Apr 2015 10:39:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E6DE21A2CC0; Tue, 28 Apr 2015 10:39:53 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <553E2C4C.8060202@isdg.net> References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> <553E2C4C.8060202@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Apr 2015 10:39:53 +0900 Message-ID: <871tj5qbdi.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 01:39:58 -0000 Hector Santos writes: > On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: > > The problem is that all are detested by some users, and none are > > actually liked by any user. Therefore we developers continue to seek > > alternatives -- but all desirable alternatives require cooperation of > > "p=reject" posting domains because of the nature of current validation/ > > authentication protocols as Originator-Receiver agreements. > > The mediator has a receiver. Doesn't it have the same > Originator-Receiver agreements? The effects are different. According to DMARC, a message which passes at the Mediator, will fail at the next Receiver. From nobody Mon Apr 27 18:44:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE71ACE0B for ; Mon, 27 Apr 2015 18:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lrJLyRcDt7py for ; Mon, 27 Apr 2015 18:44:39 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id A8D861ACE02 for ; Mon, 27 Apr 2015 18:44:39 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 5BCE18052E for ; Mon, 27 Apr 2015 18:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1430185479; bh=o0vgEY6xdRC0CWOEj7S3QeuHau2gO9t/etLBWLq6FbQ=; h=Subject:From:In-Reply-To:Date:References:To:From; b=UjHNlaTkQa4036DxKfMWkULz3y3DpR3RhfA0ZIar5SB/n5apVtUIZ9TaTs+xFpeaR MbnxD0lph9OD3iijyJQeX1Oq7iCsv/lPtK5xrm9UPnaEsy0klI9fEl7r/LL69sCRL/ p/oketavZV06iPEQmmDgayiFbx+sQn6X9dj4ZvGE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <20150427212951.8319.qmail@ary.lan> Date: Mon, 27 Apr 2015 18:44:38 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20150427212951.8319.qmail@ary.lan> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 01:44:40 -0000 On Apr 27, 2015, at 2:29 PM, John Levine wrote: >> Even if we were all to concur that altering the From by adding the list is >> the right way forward here (an intriguing idea at the moment), ... > > Just for the record, I haven't been responding to arguments about > rewriting the From: line because I don't any way they will lead to > anything useful, and I suspect I am far from the only one. > > But in this case, silence definitely does not mean consent. +1. Cheers, Steve From nobody Mon Apr 27 19:16:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2801B1ACDDA for ; Mon, 27 Apr 2015 19:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 sdR98fsIXIkx for ; Mon, 27 Apr 2015 19:16:12 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 D09431ACE15 for ; Mon, 27 Apr 2015 19:16:12 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so148829113pab.3 for ; Mon, 27 Apr 2015 19:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=P2KGfb69zxKhdDK7RleIBQcYA0QrdsCgpiofzprBoqY=; b=HAEpsvhyx8DxN/IQCibmg08eNPsIuxj7ynBnXoEtQmCpkfa4Bae0tpOhqIpEnEsDr3 sD6itrsx15tWe39OQnXGtZ91bYgt/Jv/QkApCrOO4A9sxuEzD122AJL16GVtOoanoA1f FOPLimToViwJusNl5LaE/MULyBKsYYMvOXEWcxzEUh5V1aBKFrAVjv5zWi2dKtlre+OF NMMSS3ZsQYSdv+vLISwVcuRc7+z1kGepMg1RweS7dKD+iJNi9xAsq+CvI9Qet04znLZj mmS15WGPdNRycMvgau9Gg7PRuVeOuH/TCrg4XdHOgTf2DQ8LC8vE3EtgY4FHlbOiJZGt K2HA== X-Received: by 10.66.156.225 with SMTP id wh1mr28202502pab.100.1430187372458; Mon, 27 Apr 2015 19:16:12 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ol3sm11754015pbb.70.2015.04.27.19.16.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 19:16:11 -0700 (PDT) Message-ID: <553EED67.3060407@gmail.com> Date: Mon, 27 Apr 2015 19:16:07 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc ietf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Update of draft-otis-dmarc-escape-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 02:16:14 -0000 Dear Dmarc WG, https://tools.ietf.org/html/draft-otis-dmarc-escape-01 Made a few changes in response to several comments. Sorry for not taking time to respond to comments individually. Regards, Douglas Otis From nobody Mon Apr 27 21:11:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABBC1ACE65 for ; Mon, 27 Apr 2015 21:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.909 X-Spam-Level: *** X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=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 DoPr1567F4eP for ; Mon, 27 Apr 2015 21:11:35 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7240B1ACE64 for ; Mon, 27 Apr 2015 21:11:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 272461C3898; Tue, 28 Apr 2015 13:11:34 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 09F661A2CC0; Tue, 28 Apr 2015 13:11:34 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <1A3319524161475D81DCAC46BC16CB49@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Apr 2015 13:11:33 +0900 Message-ID: <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 04:11:37 -0000 J. Gomez writes: > That would force DMARC-compliant Mediators to reject (or accept > but not resend) incoming email from p=reject domains, > irrespective of whether such mail passes or not the initial > incoming DMARC checks. Yahoo! and AOL are bigger than MLMs. MLMs would bear the brunt of user rage at that treatment. Really. We now have a couple of decades of experience. The big mailbox providers have our subscribers by the short hairs -- their Internet reputations are intimately tied to those email addresses. If the big provider won't change (and historically they've followed the principle of throw the garbage in their neighbor's yard and protest innocence loudly when users question them), then the subscriber/poster screams at the list owner. They're typically much less attached to their ML subscriptions than to their email addresses, and list owners tend to be much more responsive to their subscribers than big mailbox providers are. We have to jump through their hoops, or at least our list owner constituency thinks they do. I'm an economist even before I'm an MLM developer, I'm willing to go with the market if there is no market failure. But here there is a failure: email address lock-in. On many lists, the AOL and Yahoo! users are a small minority. If "customer is always right" considerations mandate catering to their mailbox providers' DMARC policies, the great majority loses MLM features they value -- but they are unlikely to kick up a corresponding fuss. I'm quite sure that the market test will give the answer "knuckle under", regardless of whether the majority of AOL and Yahoo! users would prefer to keep the current MLM features or not. They don't pay for AOL/Yahoo!/GMail/Hotmail MUA dev costs, so those providers have very little incentive to respond positively to their requests to support MLM features better. And, in fact, they WONTFIX them regularly (dunno about Hotmail, but GMail is as bad as the others in this respect). From nobody Mon Apr 27 21:33:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87E1ACE78 for ; Mon, 27 Apr 2015 21:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.619 X-Spam-Level: X-Spam-Status: No, score=0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 Dk2ha4UgjfKo for ; Mon, 27 Apr 2015 21:33:25 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E0A641ACE74 for ; Mon, 27 Apr 2015 21:33:24 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 41F281C38D6; Tue, 28 Apr 2015 13:33:24 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 17E751A2CC0; Tue, 28 Apr 2015 13:33:24 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Apr 2015 13:33:23 +0900 Message-ID: <87y4lcq3cc.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 04:33:27 -0000 Murray S. Kucherawy writes: > The question to me is whether the message that the MLM software emits is > the same as the original message. If it is, then the Author ought to be > preserved across the MLM. If it is not, then the MLM emits a new message, > and it actually SHOULD NOT keep the Author the same, as described above. > So we get to argue about "same", and of course the specs aren't > particularly rigorous about this. > > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it > doesn't change From, from which I infer it doesn't change Author, although > it does say it's a "new" message that's emitted. That document is not a > proposed standard and merely documents current use (as I understand it), so > it's merely recording the fact that MLMs technically violate the SHOULD NOT. AFAICS the "new message" referred to there is from the point of view of the SMTP protocol, not the higher level of RFC 5322. In particular, RFC 5322 says that it the message is a "new message" at this level, Message-Id should change too. That would clearly screw up list traffic processing for many users. RFC 5598 itself says: In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list-specific comments. Mailing Lists also archive messages posted by Authors. Still the message retains characteristics of being from the original Author. In particular, RFC5322.From: Set by - original Author Names and email addresses for the original Author of the message content are retained. > > So it seems to me the points of contention here are: > > 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation > that we accept based on how "SHOULD NOT" is defined in RFC2119? It's not a violation IMO. See below. > 2) Is the MLM emitting a new message? I would agree with Michael See the discussion in RFC 5322 about when a new Message-Id should be assigned. Specifically, from sec. 3.6.4: In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. Here, sender refers to the MLM, and in most cases (not all!) the MLM intends that the distributed message be considered the same as the received message. Further more, human recipients rarely have any trouble distinguishing the MLM decorations and extracting the original message. MLMs which delete MIME parts and translate HTML to plain text are another matter, but even there I believe that both senders and recipients agree that it is the "same message". If (human) sender and recipient agree on this, I see *zero space* for the interpretation that it's a new message, unless you deprecate RFC 5322 at the same time. As I wrote elsewhere, the only people who ever claim that list messages as distributed are new messages in the sense of RFC 5322, sec. 3.6.4, are non-participants in almost all of the mailing lists on which they want to impose this interpretation. > and contend that it is if there have been any content changes at > all, in the same way that someone making a compilation of a series > of independent works (a "mix tape") owns the copyright on the mix, > though not on the original material. Now, MLMs do that with > digests already -- who else could one legitimately put in the From > of a digest? -- but typically not for resent messages. As long as you mention copyright, it's likely that the material typically appended by MLMs is not copyrightable, it's mostly determined by the MLM's interface (eg, unsubscription and archive URLs), and the rest is hardly an original work of expression. So the copyright analogy says there is no ground for claiming the MLM is an author. Not even in the case of deletion or transformation of MIME parts -- when automated, these are also not "expressive works". > Might it be sufficient to declare an "Original-Message-ID" or > "Author-Message-ID" or "List-Original-Message-ID" field that > contains the author-generated Message-ID, allowing for the > duplicate suppression that's done now? It's not just duplicate suppression, it's also threading, because some people have mixed sources for messages in the thread. That screws all existing MUAs in processing dupes and threading messages when some are received via and some off- list. Even once they are taught recognize Original-Message-ID, the threading algorithm will become *much* more complex. Somebody, perhaps this WG or more likely an appropriate WG with input from us, just needs to decide this issue one way or the other. If it's decided that MLM decorations create "new messages", and that therefore MLMs must provide new From and Message-ID values, I suspect we can expect widespread violation from existing lists indefinitely. From nobody Mon Apr 27 23:13:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554C91A0125 for ; Mon, 27 Apr 2015 23:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Zp6y2rxd6UpB for ; Mon, 27 Apr 2015 23:13:05 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BD1A0174 for ; Mon, 27 Apr 2015 23:13:04 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 89E1C8643 for ; Tue, 28 Apr 2015 08:12:59 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 28 Apr 2015 08:12:59 +0200 Message-ID: <5B90A5A7FEB94B4CAE75F0C52E115D39@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <87fv7mquiu.fsf@uwakimon.sk.tsukuba.ac.jp> <553E2C4C.8060202@isdg.net> <871tj5qbdi.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 28 Apr 2015 08:12:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 06:13:07 -0000 On Tuesday, April 28, 2015 3:39 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > Hector Santos writes: > > On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: >=20 > > > The problem is that all are detested by some users, and none are > > > actually liked by any user. Therefore we developers continue to > seek > > alternatives -- but all desirable alternatives require > cooperation of > > "p=3Dreject" posting domains because of the nature > of current validation/ > > authentication protocols as > Originator-Receiver agreements. > > > The mediator has a receiver. Doesn't it have the same > > Originator-Receiver agreements? >=20 > The effects are different. According to DMARC, a message which passes > at the Mediator, will fail at the next Receiver. That is why it would be appropriate for the DMARC spec to explicitely = say that a "DMARC-compliant Operator" CANNOT accept messages from = p=3Dreject domains AND then reinject them into the public email = infrastructure in any why that would make them (or reveal them to be) = susceptible to fail a DMARC check performed by the next-hop Recipient. = The DMARC spec should declare that if any email operator did that, he = could not be termed as "DMARC-compliant". Because if any email operator = does that, he is in fact polluting the global email traffic stream with = non-authorized email according to the public policies declared by = DMARC-compliant original Senders. So that: to be a "DMARC-compliant Operator", it would be required to be = (1) DMARC-compliant when performing the role of Receiver, and also to be = (2) DMARC compliant when performing the role of Sender. So that lacking = (1) or (2) it would render the email operator as non compliant with = DMARC. DMARC-compliant Operator =3D=3D DMARC-compliant in the role of Receiver = + DMARC-compliant in the role of Sender Regards, J.Gomez From nobody Tue Apr 28 06:00:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFED1A9104 for ; Tue, 28 Apr 2015 06:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FzczlT2TQtzt for ; Tue, 28 Apr 2015 06:00:55 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id B2BA81A90AD for ; Tue, 28 Apr 2015 06:00:55 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3SD0qZb020873; Tue, 28 Apr 2015 09:00:52 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3SD0qPA017009; Tue, 28 Apr 2015 09:00:52 -0400 Message-Id: <201504281300.t3SD0qPA017009@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Murray S. Kucherawy" From: Michael Jack Assels In-reply-to: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> Comments: In-reply-to "Murray S. Kucherawy" message dated "Mon, 27 Apr 2015 11:44:38 -0700." Date: Tue, 28 Apr 2015 09:00:52 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-28 09:00:53 EDT Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:00:58 -0000 On Mon, 27 Apr 2015 11:44:38 PDT, "Murray S. Kucherawy" wrote: > On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < > mjassels@encs.concordia.ca> wrote: > > > On Sun, 26 Apr 2015 12:21:04 +0200, > > "J. Gomez" wrote: > > > > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > > > > > The From header field is not in the public domain, and not available > > > > for appropriation. "Taking ownership" of something that isn't yours is > > > > properly called "theft" > > > > > > Is the message Subject in the public domain? Is the message Body in the > > > public domain? Why are many mailing lists taking liberties with them? > > > Sorry, but I think your analogy of email vs property does not compute. > > > > Whether any header field is in the public domain is a legal question on > > which I won't venture an opinion, but the From header stands out as one > > that is treated specially by RFC5332, section 3.6.2: > > > > [...] The "From:" field specifies the author(s) of the message, > > that is, the mailbox(es) of the person(s) or system(s) responsible > > for the writing of the message. The "Sender:" field specifies the > > mailbox of the agent responsible for the actual transmission of the > > message. For example, if a secretary were to send a message for > > another person, the mailbox of the secretary would appear in the > > "Sender:" field and the mailbox of the actual author would appear in > > the "From:" field. If the originator of the message can be indicated > > by a single mailbox and the author and transmitter are identical, the > > "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD > > appear. > > > > [...] > > > > In all cases, the "From:" field SHOULD NOT contain any mailbox that > > does not belong to the author(s) of the message. [...] > > > > It seems clear to me that, at the very least, the mailbox of the message's > > author ought not to be and replaced by the mailbox of an automaton that > > added a subject tag and a list trailer. If the mailing list software has > > made DKIM-breaking changes, it may make sense for it to *add* its own > > mailbox to the From header (as a "coauthor"), and make itself the > > Sender. > > > > The question to me is whether the message that the MLM software emits is > the same as the original message. If it is, then the Author ought to be > preserved across the MLM. If it is not, then the MLM emits a new message, > and it actually SHOULD NOT keep the Author the same, as described above. > So we get to argue about "same", and of course the specs aren't > particularly rigorous about this. In the context I was considering -- one in which the message had been reversibly transformed as indicated in draft-kucherawy-dkim-transform-00 and reversibly transformed by adding tags "ftf=" (From TransFormed) and "stf=" (Subject TransFormed) -- the initial Author's message is entirely contained in the "new" message, and it's easily reconstructed from the "new" message. A downstream Receiver can reconstruct the original message such that the reconstructed message passes the original DKIM test and aligns as required by DMARC. By hypothesis, since the transformed message has changed enough to invalidate the original DKIM signature, the MLM has also signed the transformed message (with its mailbox appended to the 5322.From header.) Given that the message has been transformed, the question arises whether it's "the same" as the original or not. Obviously it's not strictly identical, but equally obviously (at least in the case of normal mailing list decorations) it's not significantly different; it lies somewhere in the continuum between strictly identical and significantly different. According to RFC 5322, section 3.6.4: [...] In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. I can't see a reading of that sentence that would require a new Message-ID on a single message as transformed automatically by an ordinary mailing list. > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it > doesn't change From, from which I infer it doesn't change Author, although > it does say it's a "new" message that's emitted. That document is not a > proposed standard and merely documents current use (as I understand it), so > it's merely recording the fact that MLMs technically violate the SHOULD NOT. Right, although that had already been a long-standing and widely accepted practice long before RFC5598 was published in July 2009. Adherence to the normative RFC5322 counts for more, I'd say. > So it seems to me the points of contention here are: > > 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation > that we accept based on how "SHOULD NOT" is defined in RFC2119? It seems > to me that it is, especially given how long they've been doing it without > objection (until now). One could argue they've been "getting away with it" > for too long, but we can't change history. Yup. > 2) Is the MLM emitting a new message? I would agree with Michael and > contend that it is if there have been any content changes at all, in the > same way that someone making a compilation of a series of independent works > (a "mix tape") owns the copyright on the mix, though not on the original > material. Now, MLMs do that with digests already -- who else could one > legitimately put in the From of a digest? -- but typically not for resent > messages. My view is that it's a "new" message in the sense that it breaks a DKIM signature, but not RFC5322's sense of changing the meaning of the original author's message, so the Message-ID should stay the same. Of course, this is assuming normal mailing list handling. Ne'er-do-wells might take advantage by making the standard reversible transformations but adding large chunks of spam. In such a case, it would at least be clear that the original author's domain was only responsible for the original message, and the ne'er-do-wells' domain for the rest. Normal spam/phishing filtering can still be deployed, and who knows; maybe MUAs might even help out by marking the differences for the human recipients. > To the point of Message-IDs, I would say that should follow the same rule > as the From change: If the content changes, it's a new message, and it gets > a new Message-ID. I think that's too strong, but I wouldn't go to the wall defending that position. > Might it be sufficient to declare an "Original-Message-ID" or > "Author-Message-ID" or "List-Original-Message-ID" field that contains the > author-generated Message-ID, allowing for the duplicate suppression that's > done now? That could work, too. > If MUAs do unpredictable things with multimailbox From headers, it > > may be because they don't see them often enough. I'm sure they'll fix > > their errors if list mail begins to arrive with heretofore unusual but > > RFC5322-compliant headers. > > I would far rather have MUA developers work with us directly, but the IETF > has a persistent allergy to us tampering in user space. As I understand > it, our desire in general tends to be to create well-defined interfaces > (not APIs, mind you) at which MUAs can "meet" us on their own, and let them > take it from there. Thus, the best we can do is be very clear about what > information is presented by a multi-From message and perhaps why, and hope > they'll adapt. Agreed. I really wouldn't even contemplate dictating standards for MUAs. MJA From nobody Tue Apr 28 06:39:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C121A1A34 for ; Tue, 28 Apr 2015 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XJLInUycas11 for ; Tue, 28 Apr 2015 06:39:34 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFAE1A1A14 for ; Tue, 28 Apr 2015 06:39:34 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3SDdXbg005459 for ; Tue, 28 Apr 2015 09:39:33 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3SDdXJG017279 for ; Tue, 28 Apr 2015 09:39:33 -0400 Message-Id: <201504281339.t3SDdXJG017279@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "dmarc@ietf.org" From: Michael Jack Assels In-reply-to: References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> Comments: In-reply-to "Murray S. Kucherawy" message dated "Mon, 27 Apr 2015 12:38:15 -0700." Date: Tue, 28 Apr 2015 09:39:33 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-28 09:39:33 EDT Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:39:35 -0000 On Mon, 27 Apr 2015 12:38:15 PDT, "Murray S. Kucherawy" wrote: > Even if we were all to concur that altering the From by adding the list is > the right way forward here (an intriguing idea at the moment), the question > of ordering would need to be addressed, and then how that applies to all > the standards we're talking about, and how MUAs need to be nudged to make > use of such things. We're not all going to concur, but let me chime in anyhow: The ordering of "Authors" in the From ought to be fairly easy. In any applicable case, there will be at least two DKIM-Signatures, of which one (the list's) will be valid, and the other (the original Author's) will be invalid by itself. The list's valid signature includes (e.g.) "fsf=2", indicating that the From-transformation added the second From mailbox, so that the first is the original Author's. Reconstruction the original message my reversing all reversible transformations should result in a message for which the original Author's DKIM signature is valid, confirming that the first mailbox in the "new" message is the original Author's. (Here, I'm assuming that the consensus that we won't reach would want the From order to match the temporal order of mailbox addition.) Some gentle suggestions for MUAs: 1. Display the whole 5322.From header, as well as the Sender. 2. In the absence of "Reply-To", replies should go to the first 5322.From mailbox, and reply-to-all to everybody. MJA From nobody Tue Apr 28 06:44:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39651AC3FC for ; Tue, 28 Apr 2015 06:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 K-RCuC4EHRgz for ; Tue, 28 Apr 2015 06:44:53 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 826631A1A24 for ; Tue, 28 Apr 2015 06:44:53 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so165068442pac.1 for ; Tue, 28 Apr 2015 06:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DadAq1y39g+iO1gMexq9iPEpS6R1bQPW/LEQtwAqemY=; b=OKesrEj6ohZPHHVD+gj3MFpgwhe1nuesrjtrCNGtLUObUaA7wbG17Vc190M/n3jRju u81sXPCSyuXDhnUmHSjAW217o+sPvelznVBLcRzAp38K5lsJh5DTLEDcTFmKtRBcaQds Do8dZbrb95hJU6epF8op0twY95Tnbhe6Ny/ZkdYfauiqojxezWDLqpq5W0/DR3SwMiz7 S48yzRge/5NUbMM4epBlqsQnRuNxXA3Ip9r0QhQj9CJkNr5PvjWcosd3UHCBq2nIClIP Tc8WeClXy5aBso8P8J9y3hYZge1NaZM3XMIR7kIwUlL0gksm9CtHjp48FOuCb8vcyXmW 86+A== X-Received: by 10.70.129.133 with SMTP id nw5mr31915414pdb.155.1430228693216; Tue, 28 Apr 2015 06:44:53 -0700 (PDT) Received: from [50.95.215.116] ([50.95.215.116]) by mx.google.com with ESMTPSA id y4sm22597013pdm.9.2015.04.28.06.44.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 06:44:52 -0700 (PDT) Message-ID: <553F8ED2.9000203@gmail.com> Date: Tue, 28 Apr 2015 06:44:50 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <6893A88ACFED4C20A46973509E902292@fgsr.local> <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:44:54 -0000 On 4/25/2015 8:34 AM, Stephen J. Turnbull wrote: > Of course, the reality that this is an IETF WG, and what we can > do that has effect with high probability is change wire protocols. > MUA presentation is outside of our bailiwick, Exactly. Which means that an extended thread discussing user behavior is a distraction from the working group's focus, especially absent careful, and objective documentation of UCD/UX-related efficacy experiments. d/ From nobody Tue Apr 28 06:50:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04821AC44A for ; Tue, 28 Apr 2015 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 FuKt773kLb67 for ; Tue, 28 Apr 2015 06:49:56 -0700 (PDT) Received: from catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 553371AC446 for ; Tue, 28 Apr 2015 06:49:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1905; t=1430228991; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=m3u2zJG+b7IceF8kXQoYW3dacUs=; b=txxvazxcFCBz1CP0YvhE QeZEiI7NrnwQe5hUGPQ7xs8ASCm/AKO/B19fwcDazMHMch/ww2tcCrlFS7eA3MM3 bioURiQlyF44vepPap/8OE4WeXlVv06RbUEyCeNg0xye3+PbMUGBZUY6amAMvcgW +Ez4y046ux5iEK6jHNnmEcw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Apr 2015 09:49:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3938993258.644.5440; Tue, 28 Apr 2015 09:49:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1905; t=1430228736; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WAiEMJE QKal68KWu2hWD0rkGWfSlc2ZGS6a2+YrXqIM=; b=3aUZxXpX/FH4MwPpsFwRmzh n+yXbRi8eLJ6VKcXr+BBFjZ4kx9oP5voyciDhlinoLyGj5rkmERsAi7c6PvIz8bQ IBkITo2LW5+4CD8FIYY1wQp3H2vCsiZgUq18fDvFpiDgjmA34Y6MQ5QzmYWqh+sU hxG0/Hykk/l0hWsAHQkA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Apr 2015 09:45:36 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2531272176.9.9152; Tue, 28 Apr 2015 09:45:35 -0400 Message-ID: <553F8FFE.4040201@isdg.net> Date: Tue, 28 Apr 2015 09:49:50 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <87mw1wqo0y.fsf@uwakimon.sk.tsukuba.ac.jp> <67D5DE03069647D9AF7104742F4B627E@fgsr.local> <87iocjrb0k.fsf@uwakimon.sk.tsukuba.ac.jp> <4467A2F538FC48D685D3D53F655F8D0B@fgsr.local> <201504271117.t3RBH508018510@shadrach.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:50:01 -0000 On 4/27/2015 2:44 PM, Murray S. Kucherawy wrote: > So it seems to me the points of contention here are: > > 1) Is the MLM violation of the SHOULD NOT cited above the kind of > violation that we accept based on how "SHOULD NOT" is defined in > RFC2119? It seems to me that it is, especially given how long they've > been doing it without objection (until now). One could argue they've > been "getting away with it" for too long, but we can't change history. For the record, there was objection in DKIM-WG and in particular cited with the deployment guide and also with the requirement guide where the integration conflicts was obvious. > > 2) Is the MLM emitting a new message? I would agree with Michael and > contend that it is if there have been any content changes at all, in > the same way that someone making a compilation of a series of > independent works (a "mix tape") owns the copyright on the mix, though > not on the original material. Now, MLMs do that with digests already > -- who else could one legitimately put in the From of a digest? -- but > typically not for resent messages. Its not a new author message. It is how the MLM massages the submission for redistribute for an One to Many groupware logic. MLM is technically an Email Kludge for an electronic messaging conferencing system. It is at best a "repackaged" message. But its not a "new" message per se that would warrant any kind of idea for rewriting the Mail Infrastructure persistent and consistent "From" field. Reply-ID is already on "iffy" grounds but it was done, pointing the mail back to the list in the name of reducing unintentional direct messages in legacy MUAs with layman users doing the most naturally thing. List-ID were still not widely adopted or around the time. A Digest would be a new message -- because not one list author created it. The MLM created it. -- HLS From nobody Tue Apr 28 07:12:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ACB1A1A9E for ; Tue, 28 Apr 2015 07:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GQvnHNkG1u-g for ; Tue, 28 Apr 2015 07:12:21 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC01A1A87 for ; Tue, 28 Apr 2015 07:12:21 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3SECJMO012465; Tue, 28 Apr 2015 10:12:19 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3SECJ23017537; Tue, 28 Apr 2015 10:12:19 -0400 Message-Id: <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John Levine" From: Michael Jack Assels In-reply-to: <20150427212951.8319.qmail@ary.lan> References: <20150427212951.8319.qmail@ary.lan> Comments: In-reply-to "John Levine" message dated "27 Apr 2015 21:29:51 -0000." Date: Tue, 28 Apr 2015 10:12:19 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-28 10:12:19 EDT Archived-At: Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 14:12:22 -0000 On 27 Apr 2015 21:29:51 -0000, "John Levine" wrote: > >Even if we were all to concur that altering the From by adding the list is > >the right way forward here (an intriguing idea at the moment), ... > > Just for the record, I haven't been responding to arguments about > rewriting the From: line because I don't any way they will lead to > anything useful, and I suspect I am far from the only one. This is merely an attempt to find a mechanism whereby DMARC and MLMs could cooperate, up to the point where subscriber Recipient validators could honour an Author domain's p=reject, without removing the original author's mailbox from the From header. > But in this case, silence definitely does not mean consent. Fair enough. For my own part, I'd be happy enough to see the list mailbox stripped from the From header after validation, but I can already hear a deafening silence from people not consenting to that. MJA From nobody Tue Apr 28 09:51:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559231B2A5C for ; Tue, 28 Apr 2015 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 D5jVsLK-uYBn for ; Tue, 28 Apr 2015 09:51:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F6A1B2A6A for ; Tue, 28 Apr 2015 09:51:43 -0700 (PDT) Received: (qmail 96127 invoked from network); 28 Apr 2015 16:51:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1777e.553fbaa0.k1504; bh=RfuJdr8WqLRpjmUHd1OYplOK6QXU0DHUiEfFvHtWbE8=; b=L2Dis6soFWDPLHllO6XKtjAfNaiPMRsrqvYtUlDp3/lFnLt71qYOSYTNs6fnSzn/yyWgdPk8wM2wpX4FG5KCmwxF8IBiU90Bzmt0+H5xhrVMG459bjRMbsUFFxnkxFjmJVYEi5g2kVc54WG7+mFuRgLBhLSJP0RsVAzv4M05kH5t3T0ytDOWbQ7E18eJ0bwm5rAxtjaOwc6xBIHKF6ov8R9ec7ob62yYo8U7Z31keoWieg2r56jV2o5J6J2gLmRa DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1777e.553fbaa0.k1504; bh=RfuJdr8WqLRpjmUHd1OYplOK6QXU0DHUiEfFvHtWbE8=; b=09/wc/4ufXgdK4ZOMBxPe8PdsyQ4nwb3oHPsC6YreIh80JeR0eiu9ZnVJtRIO3OY4XVltrv97UNHHtJiOkz+9m+PbYeGYjZgbnpbH0dfjG/1yDRv0i/g4XkvnCWeXbGh5fyYWAEZwcMz/nJjeqmxVkWHUAAov1mu4gJj1sYMJPewhsoh4cN1YOchRH6ETdLuarJf/+w2ZB1uzZHAsezHBdr85/gBMlGUGFg5IiV1oA/QlLIlzwrVArX/VNSWTBzt Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 28 Apr 2015 16:51:44 -0000 Date: 28 Apr 2015 12:51:42 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 16:51:48 -0000 > This is merely an attempt to find a mechanism whereby DMARC and MLMs could > cooperate, up to the point where subscriber Recipient validators could > honour an Author domain's p=reject, without removing the original author's > mailbox from the From header. Unless I've missed something, I don't see how this solves any of the well known problems. Bad guys can do whatever lists do, so you need to know whether to trust the list, at which point you might as well just trust the list and not mess around with the headers. Also, if you want to go down the sender + list route, how about that double DKIM signing hack? It has the advantage that it's invisible to MUAs and doesn't affect reciepient MTAs beyond the DKIM validation code which probably comes from a library that Murray wrote. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Apr 28 10:10:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCC1B2A6C for ; Tue, 28 Apr 2015 10:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 wM6kG5LPIbDT for ; Tue, 28 Apr 2015 10:10:12 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2681A8A29 for ; Tue, 28 Apr 2015 10:10:12 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id AFC4C564343; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A760B60247; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNbWKrj2EpMC; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6BE9D602A7; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 6BE9D602A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430241011; bh=bcB8QIsgfXm1Uy5HsShdmHqEPuC3dj0VJtsb8H6yrYE=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=JzdCzNE/Xv6X+3wfPqk9ipFEaHJBP3bW4u0aRomsnejydjWiRr5qwSn6JqCccGD2d rcwidl9/iG4Tk6/ejMqgxCZPqZDhsswRwcx+QIpQPzzxau9OCVU4Ex7Q/3XHrPrus4 wRrlnFCA1nIyyfJqvBI4f2Dh8YGFwTET8Zj1GK34= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 54F346029D; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5DAN0CXNZgYP; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 3119560247; Tue, 28 Apr 2015 12:10:11 -0500 (CDT) Date: Tue, 28 Apr 2015 12:10:10 -0500 (CDT) From: Franck Martin To: John Levine Message-ID: <908326843.35087.1430241010677.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150401181114.966.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: Third Party Sender DMARC Adaptations Thread-Index: yLEU6Y8kgzqFdnlN2ZbfqAlXnwItvQ== Archived-At: Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:10:13 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: superuser@gmail.com > Sent: Wednesday, April 1, 2015 11:11:14 AM > Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations > > >As I recall this was considered during the development of DKIM originally, > >exactly for this reason. We rejected it because we couldn't come up with a > >safe description of what a tag should look like. > > Yeah, that's what I recall, we couldn't figure out a way to allow benign > modifications without also allowing spammy ones. > > Has anyone looked at my double signing draft? Added in dmarc-interoperability From nobody Tue Apr 28 10:36:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441ED1B2AFB for ; Tue, 28 Apr 2015 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 YF0BDTa8V9Ko for ; Tue, 28 Apr 2015 10:36:38 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id F18B41A894C for ; Tue, 28 Apr 2015 10:36:37 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 946B05642D8; Tue, 28 Apr 2015 12:36:37 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8D3BEA041C; Tue, 28 Apr 2015 12:36:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX9T82VIeSr4; Tue, 28 Apr 2015 12:36:37 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 81335A0429; Tue, 28 Apr 2015 12:36:35 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 81335A0429 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430242597; bh=SlABYGEqCURunwHKojGwVZO3KpGDlavaYYKteusQMAQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=Qz5U9eAYupZUOS8VdrzhMt40ZA1ZK0S4hVfW5BMvrWHSO9JuxPMxA+vcPron2y5sx 72FR6BwQrvD7huvA8i0EMSr20acuOOa9alsnj0CzqdNxXH8Lk2edwpnf/vKGK7WvXh BQk8Cyh43FZoK9QcxSx47F6X/J7oXrz+99g8jSpU= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 54502A0425; Tue, 28 Apr 2015 12:36:35 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5OUvkbNTaiRL; Tue, 28 Apr 2015 12:36:35 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id D4357A041C; Tue, 28 Apr 2015 12:36:34 -0500 (CDT) Date: Tue, 28 Apr 2015 12:36:34 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <303904576.35885.1430242594607.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35884_1097972921.1430242594607" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: Ideas for list handling Thread-Index: O6Bm7PP7SReg4owHMmdd1oRWZEYjlw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Ideas for list handling X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:36:44 -0000 ------=_Part_35884_1097972921.1430242594607 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Sunday, April 5, 2015 6:33:52 PM > Subject: [dmarc-ietf] Ideas for list handling > Also, I've posted a new one that proposes a way to include in the signature > some information about message transformations that happened at a Mediator, > allowing the Verifier to undo said changes and re-try the author signature. > Something else to consider: > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ This one was not in the dmarc-interoperability draft, added. ------=_Part_35884_1097972921.1430242594607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: dmarc@ietf.org
Sent: Sunday, April 5,= 2015 6:33:52 PM
Subject: [dmarc-ietf] Ideas for list handling


Also, I've posted a ne= w one that proposes a way to include in the signature some information abou= t message transformations that happened at a Mediator, allowing the Verifie= r to undo said changes and re-try the author signature.  Something els= e to consider:

https://datatracker.ie= tf.org/doc/draft-kucherawy-dkim-transform/

This one was not in the dmarc-interoperability draft, a= dded.

------=_Part_35884_1097972921.1430242594607-- From nobody Tue Apr 28 11:13:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9691B2BC2 for ; Tue, 28 Apr 2015 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 K1PlWfQ5UK5d for ; Tue, 28 Apr 2015 11:12:59 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id B719D1B2BBC for ; Tue, 28 Apr 2015 11:12:59 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 50569563F9A; Tue, 28 Apr 2015 13:12:59 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 36C0BA042D; Tue, 28 Apr 2015 13:12:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c59XTqYgGweg; Tue, 28 Apr 2015 13:12:59 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DC0DDA0430; Tue, 28 Apr 2015 13:12:58 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com DC0DDA0430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430244778; bh=ko2o79hJbN0dmGlTReuUQ86sNwIUwRxMOe0M0Zp4Qp8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=NAj+Mwy3JthYtBQsaXGkPXwQ+8aeBH7zt6Fb6wMIuByoyW9wCVJH1ylRPzRNmGxpA ycM72B4yiGc9D458KDATKq7oG3YwAkJTLTlspSDD1WCCxoSc2s7DbiDJ4KBN9ozbg9 NjAIeYov8Ti1kMpSqN+8vV7THRfbxFEYcjeXEMR8= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BC65AA042E; Tue, 28 Apr 2015 13:12:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OWQTidUgjm3r; Tue, 28 Apr 2015 13:12:58 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id A4A5AA042D; Tue, 28 Apr 2015 13:12:58 -0500 (CDT) Date: Tue, 28 Apr 2015 13:12:58 -0500 (CDT) From: Franck Martin To: Scott Kitterman Message-ID: <2032884760.37010.1430244778192.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect Mail Flow Solution Utility Analysis Thread-Index: aFtNNox+EH2pWS/KwC2M3Sn7Q5qCJw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 18:13:02 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Thursday, April 16, 2015 7:11:14 AM > Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > Another example of a potential solution is receivers amalgamating data from > across their user base to identify forwarders and utilize a local policy > override to not reject DMARC fail messages assessed to be sent via an > indirect > mail flow. This is supported by the DMARC specification, but it's not > something > that Receiver/Small is going to be able to do. It's only really useful for > Receiver/Big. It should be included in the family of solutions, but it could > not be said to 'solve' the indirect mail flow problem since it doesn't scale > down. Was not in dmarc-interoperability, surprisingly, added From nobody Tue Apr 28 11:19:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7D51B2B78 for ; Tue, 28 Apr 2015 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 KBEaxtk-vNwT for ; Tue, 28 Apr 2015 11:18:57 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA821A89C6 for ; Tue, 28 Apr 2015 11:18:57 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 7BCA4859D for ; Tue, 28 Apr 2015 20:18:53 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 28 Apr 2015 20:18:53 +0200 Message-ID: <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430><553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net><3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local><1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 28 Apr 2015 20:18:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 18:18:59 -0000 On Tuesday, April 28, 2015 6:11 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > That would force DMARC-compliant Mediators to reject (or accept > > but not resend) incoming email from p=3Dreject domains, > > irrespective of whether such mail passes or not the initial > > incoming DMARC checks. >=20 > Yahoo! and AOL are bigger than MLMs. MLMs would bear the brunt of > user rage at that treatment. So do you think it is proper for an email actor to knowingly inject = DMARC-rejectable messages into the public email infrastructure? Because = that is exactly what mailing lists are doing when: (a) they check DMARC = for incoming email (therefore, they are DMARC-aware), and (b) they then = reinject into the public email infrastructure messages whose original = Author's domain has declared p=3Dreject. That case I think looks like utter disregard for a standard they know = about (DMARC), in the name of convenience. If a mailing list was = DMARC-agnostic, i.e. it didn't care about DMARC and didn't check it for = incoming email, I would have no problem with such mailing list also = disregarding DMARC when reinjecting messages. However, if a mailing list = cared about DMARC when receiving, I think it SHOULD also care for DMARC = when sending (and therefore NEVER reinject DMARC-rejectable messages = into the public email infrastructure). > I'm quite sure that the market test will give the answer "knuckle > under", regardless of whether the majority of AOL and Yahoo! users > would prefer to keep the current MLM features or not. They don't pay > for AOL/Yahoo!/GMail/Hotmail MUA dev costs, so those providers have > very little incentive to respond positively to their requests to > support MLM features better. And, in fact, they WONTFIX them > regularly (dunno about Hotmail, but GMail is as bad as the others in > this respect). Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they = kept publishing p=3Dreject and MLMs decided to be DMARC-compliant when = reinjecting messages. Regards, J.Gomez From nobody Tue Apr 28 11:26:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BA51B29AE for ; Tue, 28 Apr 2015 11:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 uBTnhI0nW4oO for ; Tue, 28 Apr 2015 11:26:04 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14571AD375 for ; Tue, 28 Apr 2015 11:26:03 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.160.4; Tue, 28 Apr 2015 18:26:02 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.46]) with mapi id 15.01.0160.000; Tue, 28 Apr 2015 18:26:02 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis Thread-Index: AQHQeE95P7LoJfOK4EKySgSFdY+rqJ1digBcgAAJVQCAAsymgIAA/3eLgAAJwACAAAsLTIAAbfaAgADszgWAAAD2UA== Date: Tue, 28 Apr 2015 18:26:00 +0000 Message-ID: References: <5719430.pnL5xihlrb@kitterma-e6430><553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net><3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local><1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> In-Reply-To: <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.110] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(2950100001)(2900100001)(93886004)(92566002)(81156007)(5001830100001)(4001540100001)(5001860100001)(87936001)(97736004)(110136001)(2656002)(19580395003)(46102003)(101416001)(102836002)(68736005)(33656002)(450100001)(66066001)(86362001)(2501003)(64706001)(62966003)(77156002)(106116001)(76176999)(54356999)(50986999)(106356001)(105586002)(107886001)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0560A2214D received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2015 18:26:00.1892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 18:26:05 -0000 > Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they > kept publishing p=3Dreject and MLMs decided to be DMARC-compliant when=20 > reinjecting messages. I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo= and AOL pushed their problems onto everyone else", etc. I don't think it's= useful to blame Yahoo and AOL for everything. What happens when Hotmail.co= m, outlook.com, and gmail.com start publishing p=3Dreject? Are we going to = say "The big four email providers pushed their problems onto everyone else"= ? Then, if other big email providers in non-American markets (mail.ru, orange= .fr, etc.) start doing it, are we going to say "Everyone but me pushes thei= r problems onto the smaller providers" ? -- Terry From nobody Tue Apr 28 11:36:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F386C1B29AF for ; Tue, 28 Apr 2015 11:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 Y_Du2GQ6Yhjb for ; Tue, 28 Apr 2015 11:36:06 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49481B29B7 for ; Tue, 28 Apr 2015 11:35:59 -0700 (PDT) Received: (qmail 13807 invoked from network); 28 Apr 2015 18:35:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 28 Apr 2015 18:35:59 -0000 Date: 28 Apr 2015 18:35:36 -0000 Message-ID: <20150428183536.12927.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 18:36:07 -0000 > Are we going to say "The big four email providers pushed their problems onto >everyone else" ? Yes, of course. But as we've seen, we have little ability to push back. R's, John From nobody Tue Apr 28 13:37:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA711A87AF for ; Tue, 28 Apr 2015 13:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qFJdvuKOHCxj for ; Tue, 28 Apr 2015 13:36:57 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 71EFB1A87ED for ; Tue, 28 Apr 2015 13:36:57 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so6094689pab.3 for ; Tue, 28 Apr 2015 13:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Vi7ti+F+CwgKAtfjOR/X44I6vlgqpcH6OXJJkdXh0As=; b=cHbKfcJCWuAKNsE0qMV4I8YKlKmdLKGKFzJhwoPo1vuXRjRXVscO2/TVdXgTTF8UVL TNlOhBcCGeY/JrtGHU/GQohz70jmGMq+uj9dObNUt/lUDGaDa+PD/c50t1XGEXctEP04 Oo/aX4Bzcjb+6DpmK0NJcPtgTq/4H57kALD+zCbWy8rRHa2bVE8HlZ6d8+8gJVizynl9 Xiq4wahIivBv9zCoQk2gyN7J73Zb4gDHotxanXzj6SqRsnQ3JyqvCItAOralhLlcwXOu IwC+ymS5a/E41qD5V4RYqmyLwcL1ztJHq+K+7aP0zrwERldCSULU5qCp9wFQFtuXkfr4 ik6w== X-Received: by 10.68.219.1 with SMTP id pk1mr35240767pbc.18.1430253417139; Tue, 28 Apr 2015 13:36:57 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id bn4sm23379133pad.2.2015.04.28.13.36.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 13:36:56 -0700 (PDT) Message-ID: <553FEF64.8020103@gmail.com> Date: Tue, 28 Apr 2015 13:36:52 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <6893A88ACFED4C20A46973509E902292@fgsr.local> <87lhhgql1j.fsf@uwakimon.sk.tsukuba.ac.jp> <553F8ED2.9000203@gmail.com> In-Reply-To: <553F8ED2.9000203@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 20:37:02 -0000 On 4/28/15 6:44 AM, Dave Crocker wrote: > On 4/25/2015 8:34 AM, Stephen J. Turnbull wrote: >> Of course, the reality that this is an IETF WG, and what we can >> do that has effect with high probability is change wire protocols. >> MUA presentation is outside of our bailiwick, > Exactly. > > Which means that an extended thread discussing user behavior is a > distraction from the working group's focus, especially absent careful, > and objective documentation of UCD/UX-related efficacy experiments. Dear Dave, One of the early versions of DMARC included considerations related to the delivery of messages that fall into the category of "reject". ,-- Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy. Mail Receivers SHOULD make a best effort not to increase the likelihood of phishing if it chooses not to reject, against policy. '-- One of the later versions of DMARC cautioned about applying DMARC policy against user email. It seems DMARC now expects to transform SMTP where the identity of the author becomes less deterministic by being the only identity considered. The various transformation schemes afford less security by allowing more ways to obscure the true source of a message when all that is seen is the From. When a few domains decide to publish "reject" policies disruptive for valid and legitimate mediated services do so by ignoring the role assigned the From and that of the Sender. It should not matter how the identity responsible for actually sending the message is displayed. It should be validated where possible and enter into considerations about whether the message should be rejected and even that the actual sender be conveyed to recipients when it is not. At least early on, some recognized a need to mitigate such disruption where of course, a best effort should not increase the likelihood of phishing where the actual sender identity be confirmed. Something that DMARC currently fails to provide. In addition, moving valid messages into Quarantine folders causes an increasing number of users dangerously wading through this folder as well. In this respect, DMARC is making the problem worse and not better when DMARC policy abuses valid and legitimate messages by ignoring the valid role of the Sender for non-transactional email exchanges. Regards, Douglas Otis From nobody Tue Apr 28 13:56:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9501A8943 for ; Tue, 28 Apr 2015 13:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 t2i1q-o2YYFm for ; Tue, 28 Apr 2015 13:56:28 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAFD1A8948 for ; Tue, 28 Apr 2015 13:54:15 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3SKsENp021630; Tue, 28 Apr 2015 16:54:14 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3SKsEqn020908; Tue, 28 Apr 2015 16:54:14 -0400 Message-Id: <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John R Levine" From: Michael Jack Assels In-reply-to: References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> Comments: In-reply-to "John R Levine" message dated "28 Apr 2015 12:51:42 -0400." Date: Tue, 28 Apr 2015 16:54:14 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-28 16:54:14 EDT Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 20:56:32 -0000 On 28 Apr 2015 12:51:42 EDT, "John R Levine" wrote: > > This is merely an attempt to find a mechanism whereby DMARC and MLMs could > > cooperate, up to the point where subscriber Recipient validators could > > honour an Author domain's p=reject, without removing the original author's > > mailbox from the From header. > > Unless I've missed something, I don't see how this solves any of the well > known problems. Bad guys can do whatever lists do, so you need to know > whether to trust the list, at which point you might as well just trust the > list and not mess around with the headers. The main difference is that the original Author's message, including 5322.From, is precisely reproducible (modulo canonicalization changes) from the message sent to the list, and will match the original DKIM-Signature with the required 5322.From alignment. If it doesn't, the final Receiver should do what RFC7489 says it should do: "[A]pply the most strict policy selected among the checks that fail." Yes, bad guys can do whatever lists do, but in this case, they'll need to piggy-back on a recent DMARC-passing message sent legitimately to them from the originating domain with a p=reject policy, and they'll have to include that message in its entirety, including all the signed headers, in their spam/phishing message; they can't simply replace the original message with their own. It seems much easier just to open a disposable account at a p=reject ESP and send the spam directly from there. > Also, if you want to go down the sender + list route, how about that > double DKIM signing hack? It has the advantage that it's invisible to > MUAs and doesn't affect reciepient MTAs beyond the DKIM validation code > which probably comes from a library that Murray wrote. I'll grant the advantage of invisibility to MUAs, but double signing has the disadvantage that the originating signer has to know when to add a weak signature with an fs=lists-r-us.com tag. What I'm suggesting doesn't need the originating signer to have any special knowledge. There's another, slightly labour-intensive approach (still dependent on Murray's draft-kucherawy-dkim-transform-00, and an extra "stf=" tag for subject tagging) that doesn't modify 5322.From: 1. The list keeps the original author's mailbox alone in the From header, but makes the reversible transformations described, and adds a DKIM signature with d=list.domain and tf= and stf= tags. 2. The "decorated" message is sent to list members with list-domain address as Sender. 3. Recipient validators find an Author Domain signature that fails, and a Sender Domain signature that is valid but doesn't align with the From Domain. 4. Because the Sender Domain signature is valid and contains tf= and stf= tags, Recipient validators reconstruct the original message and check it against the Author Domain DKIM signature. If it passes, the message is deemed to pass DMARC; otherwise it fails. I'm not sure if that's an improvement on the multimailbox From approach, but at least it leaves no burden for MUAs (unless they happen to be validators). MJA From nobody Tue Apr 28 14:04:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F201A8938 for ; Tue, 28 Apr 2015 14:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 F4UGO8peSerk for ; Tue, 28 Apr 2015 14:04:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6551A88E9 for ; Tue, 28 Apr 2015 14:04:33 -0700 (PDT) Received: (qmail 38714 invoked from network); 28 Apr 2015 21:04:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9739.553ff5e2.k1504; bh=uG+zBzgj+Y8tTNlzmGPn1/cqdJ4rMQBGPCX+lvjKTz4=; b=MLd3ls4JL8AAk736S6mY+bsGeY5EIrVGbRDW0jrbLrD1sTAgA/gNqVOkOm5MLyO41r89bZpQoUgYWV7sdjxnDhJdVQpwLY4Bsxok0j0Vk6gFvlt6Xcg5zaC/B41SHJnKqrJznS8wtpv5WaG98iVsu62DJpRGefepydPlHXmKQCuYTvm1ZjBGbXIGTqT+oH3VR08kn23bD2h3hvFiXiqswB2DobkkvD2WT+XeIlDBUCpAYd2WR5lYHPMg5xDfRYfA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9739.553ff5e2.k1504; bh=uG+zBzgj+Y8tTNlzmGPn1/cqdJ4rMQBGPCX+lvjKTz4=; b=qLf5B37+16Iq0hAfEsi/xz1OL5MlSkHi+BuPoQ8nh4S7pmspYqGTgz6AfCDytk2fnOBMHWDL2WbjF/s0hm1t6xbQo6c2nsFpNosO4zaDHDDtVk5uYkum7Q85/HNCM+tLAQYvpK82+OGAkwH3iDflkVIueivlggj6hnfUKvk+lVyn5YmvE9/y8lbA7VrfRErSLDD/ivLxT2Yi3JlVdbAwUQME5jqEiLzJ+AUulNAWgbWoASTxENRTxyUEgEsDNdsz Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 28 Apr 2015 21:04:34 -0000 Date: 28 Apr 2015 17:04:31 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:04:48 -0000 > 4. Because the Sender Domain signature is valid and contains tf= and stf= > tags, Recipient validators reconstruct the original message ... Oh, it's message wrapping. There are easier ways to do that without changing DKIM: have the list send the message as a single entry MIME digest. Mailman already knows how do to that, and in the extremely implausible event that you can persuade MUAs to do message reconstruction, it's easy to unwrap using existing tools. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Apr 28 14:05:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888A51A891B for ; Tue, 28 Apr 2015 14:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham 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 geX-A9RQ5eVz for ; Tue, 28 Apr 2015 14:05:00 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 36D2E1A01EA for ; Tue, 28 Apr 2015 14:04:54 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id A66F856435E; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9E04D6030A; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0leMyWbSzf7; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6892E6030C; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 6892E6030C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430255093; bh=CP48eEoJBPNCTX2MvwhNTpHbShDRdT82NFIRnWNgcnM=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=iwCS+KV2LZhdg6t6qd6BfTyxADf8tvy9KlYhPuUtskyO/0a/dSwE9fjXtoQsIhm18 1unW97OJ7i+CTNU1YVJK34yXx5jGgXFwNOr3DYpzo7IAQgzQTxIHcmHAjjKZWuC3hq 2bS8aL8sqsUwZP6s2ZxLpm4mGpnW44CBrM7eEobw= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 530066030B; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id whiwMoyjjxia; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 2B27F6030A; Tue, 28 Apr 2015 16:04:53 -0500 (CDT) Date: Tue, 28 Apr 2015 16:04:52 -0500 (CDT) From: Franck Martin To: R E Sonneveld Message-ID: <1200227554.42787.1430255092993.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150416212038.929.qmail@ary.lan> <553035ED.7040708@sonnection.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect Mail Flow Solution Utility Analysis Thread-Index: YdaJ0moovHnM2rLTCq/R4leLwjc3Dw== Archived-At: Cc: superuser@gmail.com, dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:05:01 -0000 ----- Original Message ----- > From: "Rolf E. Sonneveld" > To: "John Levine" , dmarc@ietf.org > Cc: superuser@gmail.com > Sent: Thursday, April 16, 2015 3:21:33 PM > Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > Now I think Scott is right that we need to make a step back and his > analysis might help us to know on which solutions we'd best spend most > of our time. However, having said that, I'm afraid that we're biased by > our discussions around the 'DMARC/Mailing List problem'. Let's not > forget the other use cases of draft-ietf-dmarc-interoperability. > > I believe a number of the Mediators, described in par. 3.2 of > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot > easily be changed. To give an example: recently when I was working for > company A, I forwarded an invitation I got from company B to one of my > addresses at ESP C. I just used the Exchange/Outlook forward function at > company A and discovered that the mail client I used at ESP C showed the > address of company B, no the address I have with company A. Company A is > using Exchange/Outlook 2010 and has no plans to upgrade for the next > couple of years. Should Microsoft update Exchange to support some > mediator 'change' for DMARC, then this probably won't be 'retrofitted' > into Exchange 2010. So it may take many years before I can use a version > that supports DMARC 'mediation'. > Personally, I consider this a bug, because it looks like to C that B invited him/her, while it was A that did. This bug is on the wiki, but it falls under the "Message Forwarding" section, not sure we need to spell it out there, but it is not uncommon. From nobody Tue Apr 28 14:08:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A481A8967 for ; Tue, 28 Apr 2015 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jDtwS91tqSnF for ; Tue, 28 Apr 2015 14:08:52 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 6E5251A8961 for ; Tue, 28 Apr 2015 14:08:52 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so6821776pab.3 for ; Tue, 28 Apr 2015 14:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mugxSg0qcZ/wTaVT0BPlRjh9DFE7vHVFAesUt8eHj9w=; b=b6J67iIE8ckj3mz78aq2cD07MNS4uhHw4KobmZwEP2dEeXkdMaEdajFvsaOeKlTGyy NmetAaj7u3fBhzqVRE4xXn28D/vr+RsgB4l9P0ku721sZXHe51VsOZx4drUkAxfADhEo 9wsSci0DwuZ8IojEyGwV7qCERfL8HnpqxJysRXXTZC2PqoXX33KUFtj51l0xzXPOJFa0 r4YGWOoPELHIrrHWP5IeeXlxI/aBzzW730KnDgPxyaaWstF5J93u+WsT6rQpHJL5PknT MyY+8X0PFBNvPpyOwLREKAOB+sWY9iBydBiQQXGtA9cIy0i1Yyjr+wmfUSgd0FsfY2Wn 4b3w== X-Received: by 10.70.43.10 with SMTP id s10mr35903999pdl.57.1430255332179; Tue, 28 Apr 2015 14:08:52 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id gy3sm23237232pbb.42.2015.04.28.14.08.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 14:08:51 -0700 (PDT) Message-ID: <553FF6DF.1090603@gmail.com> Date: Tue, 28 Apr 2015 14:08:47 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150428183536.12927.qmail@ary.lan> In-Reply-To: <20150428183536.12927.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:08:54 -0000 On 4/28/15 11:35 AM, John Levine wrote: >> Are we going to say "The big four email providers pushed their problems onto >> everyone else" ? > Yes, of course. But as we've seen, we have little ability to push > back. Dear John, Standing up to abusive domains requires a fallback policy compatible with SMTP. https://tools.ietf.org/html/draft-otis-dmarc-escape-01 Describes a safer and SMTP compatible policy as "Public". By ignoring the role of Sender DMARC is not compatible with SMTP which leads to dangerous practices when handling email exchanges serving the general public. Hacks aimed at transforming the From header into playing this role, such as the dubious double signing or proposed reversible transformation are solutions making the problem worse. Why make the source of a message more confusing? A role clearly defined by the Sender header field when present. The efficiency hack used by DMARC for applying policy against transactional messaging fails badly when misapplied against mediated and valid third-party services. Regards, Douglas Otis From nobody Tue Apr 28 14:34:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96451A8998 for ; Tue, 28 Apr 2015 14:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 ig6IMLIvFCJK for ; Tue, 28 Apr 2015 14:34:30 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id C99AD1A8025 for ; Tue, 28 Apr 2015 14:34:29 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 6DE6D564345; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 64AC5602C5; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOASeQL0ju1x; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 36C1F602D0; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 36C1F602D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430256869; bh=ZEgpxDFC2jxohh8zWmuFHTvmw0cZFZA+/MAVUW140tQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=L76PjWjbn/EjQfzRDnBnAvl7KsM1u2/NrdhLuF+4BHnDEHVfzF9aC73OxFcDirETG 1hWn1aTLo5DoccAN+jZcIOqrZWYyCTuHzD5QbYJsqW8aahx9jDFaEhr9PAq07pyxmP MEw0SNzIW88sI8qWG955+k1Yf5wjXPva7uvjIcGI= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 26A4C602CD; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Vh7ZcGofa85k; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 0C463602C5; Tue, 28 Apr 2015 16:34:29 -0500 (CDT) Date: Tue, 28 Apr 2015 16:34:28 -0500 (CDT) From: Franck Martin To: Terry Zink Message-ID: <1406056764.43385.1430256868864.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis Thread-Index: AQHQeE95P7LoJfOK4EKySgSFdY+rqJ1digBcgAAJVQCAAsymgIAA/3eLgAAJwACAAAsLTIAAbfaAgADszgWAAAD2UJZ4FK2L Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:34:30 -0000 ----- Original Message ----- > From: "Terry Zink" > To: dmarc@ietf.org > Sent: Tuesday, April 28, 2015 11:26:00 AM > Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > > Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they > > kept publishing p=reject and MLMs decided to be DMARC-compliant when > > reinjecting messages. > > I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo > and AOL pushed their problems onto everyone else", etc. I don't think it's > useful to blame Yahoo and AOL for everything. What happens when Hotmail.com, > outlook.com, and gmail.com start publishing p=reject? Are we going to say > "The big four email providers pushed their problems onto everyone else" ? > > Then, if other big email providers in non-American markets (mail.ru, > orange.fr, etc.) start doing it, are we going to say "Everyone but me pushes > their problems onto the smaller providers" ? I think we should refrain to blame anything or anyone. It is what it is, and we should just note it, technically describe it, and see if better solutions can be provided. This atmosphere is not conducive for group work. From nobody Tue Apr 28 14:35:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC6D1A89AF for ; Tue, 28 Apr 2015 14:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham 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 mAtcrD92yOzW for ; Tue, 28 Apr 2015 14:35:27 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D61A8998 for ; Tue, 28 Apr 2015 14:35:27 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id CCE86563DC0; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id BA15B602CD; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUDYOjcK2QB4; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 81E2C602D6; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 81E2C602D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430256926; bh=fHtJJ6UCpGpAe8J/aniIRgx2iEBhc+WwneFHKNS2j/A=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=qYPuutPdhvjhpsFNYYSOVtf5TwdV6HdJ5K0DvAERywMXx15ceKLpJTbimlIoSjX1Q O6/U3o4Bo/zoo2wwZNWaEKniJ59s5nLq09/99MvEHV34ymWXodS+qLRrmU8OWGvIG/ Zn09VsAvXPBljDkyOso/SZNxdrmd2pJCNyJdrrxY= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6C306602D0; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4_14ShBLQ9XQ; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 40C9F602CD; Tue, 28 Apr 2015 16:35:26 -0500 (CDT) Date: Tue, 28 Apr 2015 16:35:26 -0500 (CDT) From: Franck Martin To: R E Sonneveld Message-ID: <1616044531.43396.1430256926210.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150416212038.929.qmail@ary.lan> <553035ED.7040708@sonnection.nl> <1200227554.42787.1430255092993.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect Mail Flow Solution Utility Analysis Thread-Index: YdaJ0moovHnM2rLTCq/R4leLwjc3D7HZrNiZ Archived-At: Cc: John Levine , dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:35:31 -0000 ----- Original Message ----- > From: "Franck Martin" > To: "R E Sonneveld" > > I believe a number of the Mediators, described in par. 3.2 of > > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot > > easily be changed. To give an example: recently when I was working for > > company A, I forwarded an invitation I got from company B to one of my > > addresses at ESP C. I just used the Exchange/Outlook forward function at > > company A and discovered that the mail client I used at ESP C showed the > > address of company B, no the address I have with company A. Company A is > > using Exchange/Outlook 2010 and has no plans to upgrade for the next > > couple of years. Should Microsoft update Exchange to support some > > mediator 'change' for DMARC, then this probably won't be 'retrofitted' > > into Exchange 2010. So it may take many years before I can use a version > > that supports DMARC 'mediation'. > > > Personally, I consider this a bug, because it looks like to C that B invited > him/her, while it was A that did. > > This bug is on the wiki, but it falls under the "Message Forwarding" section, > not sure we need to spell it out there, but it is not uncommon. > Correction it is described in the draft and still is... From nobody Tue Apr 28 15:56:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8BD1A8F4E for ; Tue, 28 Apr 2015 15:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BBs14UlCUFpY for ; Tue, 28 Apr 2015 15:56:26 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C21A8AE6 for ; Tue, 28 Apr 2015 15:56:26 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3SMuOUa009822; Tue, 28 Apr 2015 18:56:24 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3SMuOEB021609; Tue, 28 Apr 2015 18:56:24 -0400 Message-Id: <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John R Levine" From: Michael Jack Assels In-reply-to: References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> Comments: In-reply-to "John R Levine" message dated "28 Apr 2015 17:04:31 -0400." Date: Tue, 28 Apr 2015 18:56:24 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-28 18:56:24 EDT Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 22:56:28 -0000 On 28 Apr 2015 17:04:31 EDT, "John R Levine" wrote: > > 4. Because the Sender Domain signature is valid and contains tf= and stf= > > tags, Recipient validators reconstruct the original message ... > > Oh, it's message wrapping. There are easier ways to do that without > changing DKIM: have the list send the message as a single entry MIME > digest. Mailman already knows how do to that, and in the extremely > implausible event that you can persuade MUAs to do message reconstruction, > it's easy to unwrap using existing tools. I think I've failed to communicate. Yes, the pristine original message will be appropriately MIME-wrapped, with the list decorations becoming separate MIME parts, but the MUA is not expected to do anything except to present the MIME message to the final recipient. The message reconstruction is to be done by the validator at the recipient's end, which will presumably be an MTA because it has the job of accepting or rejecting messages. The only reason for reconstructing the original message is to let DKIM check the validity of the From-aligned signature against the original message. Apart from the addition of tags, there isn't much change for DKIM. What changes is the algorithm used by DMARC in the special case where there exists a From-aligned but invalid signature and a Sender-aligned valid signature specifying the tf= tag and (if there's a consensus) an stf= tag. MJA From nobody Tue Apr 28 16:25:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555D1A8A0E for ; Tue, 28 Apr 2015 16:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 0XrW5K_wDLMe for ; Tue, 28 Apr 2015 16:25:39 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54191A8A0C for ; Tue, 28 Apr 2015 16:25:38 -0700 (PDT) Received: (qmail 55593 invoked from network); 28 Apr 2015 23:25:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d928.554016f2.k1504; bh=xNf1XRfCt4W8BPygc3OdHTu78G5SdzYEnEP8NPrTaww=; b=Q5Cu7/chIteBI0nL+TV4lF7r3Mj0xmRqIhPT87ED1AZQCj0uR5JKqmJIjYektRi3iVMUnh33fJ7QDBeGKXTsuU0FvUIjga6nvIgfu5LSlq4blsP1gsGxXuI31Bc5btwhYOgnwXZicDu24e7XCNHzkZn8/oNzTKboGxvCNXpYJz1lGmjaGF6VZ6XIZzVJOgAf+5Yo1dFzn5N/uNP2Nv52D89D50sp7YA+QZQVOdwiVtUEsq1OwDffDb2mUNZcXTGY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d928.554016f2.k1504; bh=xNf1XRfCt4W8BPygc3OdHTu78G5SdzYEnEP8NPrTaww=; b=LvzkipSJ9zheDBSwXhM8VnVm2/aAbEdQxhMM69IewmUQlHIq/n7uJ/6ThvTTGuTFYIYVidlySIiZqCRamzDn39R/PR4yX874rg5KnFTFU0mLZZugy6B65j+r6ZODSQjIA29WTHhRFMlgbhjQ8gorisqDTks/YfLdBC6bsZts+bNCvynH5FJ4H9cNxW8vda0HkoYUgktm+l/YZfVGCU+Qmy6iGRntaDqALYiP1XSDIU11RGlFWNaCKMJJFvSVqvVy Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 28 Apr 2015 23:25:38 -0000 Date: 28 Apr 2015 19:25:36 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 23:25:40 -0000 > I think I've failed to communicate. Yes, the pristine original message > will be appropriately MIME-wrapped, with the list decorations becoming > separate MIME parts, but the MUA is not expected to do anything except > to present the MIME message to the final recipient. Discussions on the Mailman list say that users hate wrapped messages, because in most MUAs they look really ugly. > Apart from the addition of tags, there isn't much change for DKIM. What > changes is the algorithm used by DMARC in the special case where there > exists a From-aligned but invalid signature and a Sender-aligned valid > signature specifying the tf= tag and (if there's a consensus) an stf= > tag. I still don't see what the advantage is compared to a single message digest which requires no changes to DKIM, no changes to DMARC, and has already been implemented in a widely used list manager. The only downside is that it looks awful in most MUAs so users hate it, which I expect would also apply to your proposal. R's, John From nobody Tue Apr 28 16:49:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0B31A904A for ; Tue, 28 Apr 2015 16:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 9MrkAzEOOpyh for ; Tue, 28 Apr 2015 16:49:45 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id F34A51A9046 for ; Tue, 28 Apr 2015 16:49:44 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 8BC0E56437C for ; Tue, 28 Apr 2015 18:49:44 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 753DEA0417 for ; Tue, 28 Apr 2015 18:49:44 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJFQ09XmYsbz for ; Tue, 28 Apr 2015 18:49:44 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0BB46A042E for ; Tue, 28 Apr 2015 18:49:44 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 0BB46A042E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430264984; bh=nHmjeElZW/xiklKxwBLTR5RHw7zgzWpmgHgPPBwHHWA=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=HLRnUvJpmYv8cNGcadZwaDqvSzVUZfk2K/L+DVZGg6+64OUEWzPlC1kvfalxgFPoL Bj/Ub7BCAeh96yG0Zt0qTWohllLSCFCGSnfFmNfBxnJSalS8sAxoqb9ewxwXHzeNUm W5rjuymW0gsbjD1H4rlm/g4mzrCwwV6b0nVyv4JI= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E1733A042B for ; Tue, 28 Apr 2015 18:49:43 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MCMKOacLk904 for ; Tue, 28 Apr 2015 18:49:43 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id C1E7BA0417 for ; Tue, 28 Apr 2015 18:49:43 -0500 (CDT) Date: Tue, 28 Apr 2015 18:49:43 -0500 (CDT) From: Franck Martin To: dmarc@ietf.org Message-ID: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> In-Reply-To: <246357292.45499.1430264919058.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: WX8Xdu56yAz45YYeDwoZXhT/2ZvCUQ== Archived-At: Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 23:49:46 -0000 FYI Please post more reviews... ----------------- A new version of I-D, draft-ietf-dmarc-interoperability-02.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Name: draft-ietf-dmarc-interoperability Revision: 02 Title: Interoperability Issues Between DMARC and Indirect Email Flows Document date: 2015-04-28 Group: dmarc Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperability-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-02 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Apr 28 21:02:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E02D1A9040; Tue, 28 Apr 2015 16:41:22 -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 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 uG8i7xMgTT8d; Tue, 28 Apr 2015 16:41:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0F61A8A76; Tue, 28 Apr 2015 16:41:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428234120.26106.30484.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 16:41:20 -0700 Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 21:02:44 -0700 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 23:41:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Filename : draft-ietf-dmarc-interoperability-02.txt Pages : 20 Date : 2015-04-28 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-02 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 28 21:36:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8B1AC3D2 for ; Tue, 28 Apr 2015 21:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.098 X-Spam-Level: *** X-Spam-Status: No, score=3.098 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 J9LS0_d0lTXu for ; Tue, 28 Apr 2015 21:36:40 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D60F51AC3E1 for ; Tue, 28 Apr 2015 21:36:39 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E35D91C38E2; Wed, 29 Apr 2015 13:36:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C36131A2CC0; Wed, 29 Apr 2015 13:36:37 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 29 Apr 2015 13:36:37 +0900 Message-ID: <87mw1rpn3e.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, Michael Jack Assels Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 04:36:42 -0000 John R Levine writes: > Discussions on the Mailman list say that users hate wrapped > messages, because in most MUAs they look really ugly. It's worse than that. As of 6 months ago, it was impossible to read wrapped messages (as implemented by Mailman, anyway) in Apple Mail for iOS. As for "really ugly", in MUAs that can read it but do nothing special (all MUAs that can read it AFAIK) it looks like a bare digest of a single message. My feeling is that users think it looks *stupid*, not ugly, and posters at p=reject domains (the recommended configuration for Mailman does the DNS lookup so only p=reject domains are wrapped) complain about discrimination. From nobody Wed Apr 29 00:09:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B7E1ACF57 for ; Wed, 29 Apr 2015 00:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.899 X-Spam-Level: * X-Spam-Status: No, score=1.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 fitul8UzgeOa for ; Wed, 29 Apr 2015 00:09:20 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 834A21A0302 for ; Wed, 29 Apr 2015 00:09:20 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 0DE2B1C3837; Wed, 29 Apr 2015 16:09:19 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D8EBC1A2CC0; Wed, 29 Apr 2015 16:09:18 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1406056764.43385.1430256868864.JavaMail.zimbra@peachymango.org> References: <5719430.pnL5xihlrb@kitterma-e6430> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <1406056764.43385.1430256868864.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 29 Apr 2015 16:09:18 +0900 Message-ID: <87lhhbpg0x.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, Terry Zink Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 07:09:22 -0000 Franck Martin writes: > I think we should refrain to blame anything or anyone. I think that there is no solution attractive to email users possible without naming names. AFAIK[1], it is a fact that the problems that have made "DMARC" a four-letter word across the Internet are almost entirely due to the unilateral decisions to publish "p=reject" by *two* domains. Call that "blaming" if you like, but that fact matters because any *good* mitigation[2] involves their participation. The only alternative I can see to participation by those specific domains (and any domains producing similar mailflows that may publish p=reject in the future) is a general agreement among DMARC receivers to treat "p=reject" as purely advisory (say, -2 spam points if alignment is verified in SpamAssassin). I know you don't like that weakening of the protocol, and I don't think it's a good idea, either. DMARC is a great protocol for direct mail streams, proven in practice. Two? Yes, *two*. Bank of America? No problem, it's all direct mail. LinkedIn? Who cares? Pretty clearly linkedin.com employees have figured out that posting to MLs from that domain is not good for their ability to communicate, and LinkedIn itself primarily uses *direct* mail to collect traffic to their website. Accidental leakage from either kind of domain is no big deal and self-correcting. Why single those two out? Because they've already demonstrated that they place their own security issues over the general functionality of the mail system, so it's questionable whether they will buy in to any solutions we come up with. We already know that there may be security issues (DKIM delegation-style proposals) or significant costs (TPA via DNS-style proposals) to implementing those solutions. The best way to get an answer about what *they* want in a solution is to ask them. For that, we need to say their names. And if those two buy in, I think there will be huge pressure on any future p=reject-niks to participate in the mitigation protocols, even if not 6-sigma secure or involving additional nameservers or other costs. > It is what it is, Indeed, and what it is, is a purely private protocol whose own specification deprecates the controversial use case. Don't forget that fact. > and we should just note it, technically describe it, It had better not stay what it is! One thing that is easy to forget and to ignore is that, without a practical third-party authorization protocol, "p=reject" from even one large group of mail users has a chilling effect on all *new* third- party mail services. A large service with an established user base such as Intuit's invoicing service can weather even something like what happened in April 2014, but I wonder how many new 3rd-party services rolled out in first quarter of 2014 just died without even a whimper because of how "unreliable" they were for ordinary mail users at p=reject domains after April. I wonder how many 3rd-party services won't ever be implemented commercially for that reason. Yes, as written those stillborn services are just FUD, but economists have ample evidence that removal of apparently minor hindrances can invigorate innovation and the general business climate.[3] Don't deprecate the potential for innovation just because I'm unable to provide figures for the case of 3rd-party email offhand -- these things are essential impossible to measure in advance. > and see if better solutions can be provided. They can only be "provided" if the unblameable domains implement, because as DMARC is currently specified "p=reject" is a unilateral decision by the Author Domain. Otherwise, the solutions aren't worth the paper they won't be printed on. > This atmosphere is not conducive for group work. The deafening silence of the "p=reject" domains which originate large general-use mail streams as to how they will contribute to mitigation of the bad effects of their DMARC policies isn't conducive to group work, either. I've observed that posters here consistently categorically reject potential solutions as unworkable based on FUD about DNS costs and insecurity and inability to scale user profiles that specify per-user "trusted 3rd party" lists, despite the fact that representatives of these two domains haven't even commented on them. That fact matters because nobody who doesn't (1) originate general-use mail streams and (2) publish "p=reject" has to pay those costs, and at present they are only ones that satisfy both criteria! Footnotes: [1] If I am ignorant of relevant facts, please inform me. [2] Conforming to existing normative RFCs and meeting the requirements of *email users* as expressed to the providers of services they use. Eg, "author appears in From on mailing list posts". [3] Two cases in point. 1. Relaxation of airline regulation. Air travel in the U.S. today is much cheaper, more flexible, and (remarkably) safer than it was up to the 1970s. 2. Relaxation of postal and transport regulation, without which the amazing progress in logistics that makes Amazon.com a dominating presence in the book- selling industry could not have occurred. From nobody Wed Apr 29 04:54:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE01A887A for ; Wed, 29 Apr 2015 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KPzF8d0vXFCg for ; Wed, 29 Apr 2015 04:54:42 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id AB5301A8853 for ; Wed, 29 Apr 2015 04:54:42 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3TBsfe7011463; Wed, 29 Apr 2015 07:54:41 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3TBseAl025474; Wed, 29 Apr 2015 07:54:40 -0400 Message-Id: <201504291154.t3TBseAl025474@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John R Levine" From: Michael Jack Assels In-reply-to: References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> Comments: In-reply-to "John R Levine" message dated "28 Apr 2015 19:25:36 -0400." Date: Wed, 29 Apr 2015 07:54:40 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-29 07:54:41 EDT Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 11:54:44 -0000 On 28 Apr 2015 19:25:36 EDT, "John R Levine" wrote: > Discussions on the Mailman list say that users hate wrapped messages, > because in most MUAs they look really ugly. OK, I'll concede that. They don't bother me, but I don't count for much. > I still don't see what the advantage is compared to a single message > digest which requires no changes to DKIM, no changes to DMARC, and has > already been implemented in a widely used list manager. Do single message digests get sent with the original Author's mailbox in the From header? If so, there's no advantage at all, but I have the impression that digests in general are sent "From" the list. > The only downside is that it looks awful in most MUAs so users hate it, > which I expect would also apply to your proposal. I'm still hoping for something that users will like, so I guess it's back to the drawing board. MJA From nobody Wed Apr 29 05:04:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD11A88E3 for ; Wed, 29 Apr 2015 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.599 X-Spam-Level: ** X-Spam-Status: No, score=2.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 85m0O7VK2H_C for ; Wed, 29 Apr 2015 05:04:39 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B71A88D2 for ; Wed, 29 Apr 2015 05:04:39 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 885211C3891 for ; Wed, 29 Apr 2015 21:04:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5ADD61A2CC0; Wed, 29 Apr 2015 21:04:37 +0900 (JST) From: "Stephen J. Turnbull" To: In-Reply-To: <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 29 Apr 2015 21:04:37 +0900 Message-ID: <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Subject: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 12:04:42 -0000 J. Gomez suggests: > > > That would force DMARC-compliant Mediators to reject (or accept > > > but not resend) incoming email from p=reject domains, > > > irrespective of whether such mail passes or not the initial > > > incoming DMARC checks. Something about having mediators (ie, non-MTAs) implement this check was bothering me. I realized that the nagging thought was the *Mediator* doesn't have to do it. Variation A: The *outgoing MTA* can do this check; it has the same information (the "From" field, the DKIM signature, and the DNS) that the mediator does. This outgoing check is just a variation on the spamfighting theme of "if pretty much anybody can send from your system, you have to check outgoing mail as well as incoming mail." Having the outgoing MTA do the check has the following advantages: - MTAs already have to implement DMARC logic; Mediators would not have to. - Where the outgoing MTA is also the incoming MTA (or they can communicate), the DMARC policy can be cached, possibly avoiding a DNS check. - When the outgoing MTA rejects based on next-hop DMARC rejection, it can inform the Mediator of the reason for rejection (which SMTP servers often fail to provide to the SMTP client). This is actually important to MLMs, at least, which often count bounces and disable or cancel subscriptions based on the result. Disadvantages: - Naive MLMs (and perhaps other Mediators) can generate many copies of a single message, and present them individually to the MTA. It would be better to do the detection at addressee generation time in the MLM. Note: this may not be as expensive as it seems at first glance, as given the Message-Id and the addressee, the result is known without doing any further checks. Many MTAs do parse out the Message-Id, for reporting in logs if nothing else. I'm not a big fan of rejecting mail in this way, but it also led to the thought that it would be nice to be able to avoid the somewhat finicky DNS checks in Mediators that want to be DMARC-aware. Thus variation B. Variation B: When the incoming MTA knows the local recipient is a Mediator, it could perform the policy lookup even for From-aligned messages, and communicate that (perhaps in the Authorization-Results field). I doubt that this could be more efficient, but again the implementation would be done in MTAs, which have to do it anyway. From nobody Wed Apr 29 06:12:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C5B1B2CAD for ; Wed, 29 Apr 2015 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 6BP-E2DO9KkJ for ; Wed, 29 Apr 2015 06:11:59 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0FA1B2CAE for ; Wed, 29 Apr 2015 06:11:59 -0700 (PDT) Received: (qmail 72708 invoked from network); 29 Apr 2015 13:11:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11c03.5540d89f.k1504; bh=8Agf6BVWAoIYw5BpeI9PP7zOosMBOeG4OXhUsL9bgg4=; b=VtuN7GyTFU8nNczu0XQIxNm5JS8seZ24jKEh2Affiw87z7KLPD43ZKPE/iw+QYeJPUxgEhaIvaLbLgyD0F3KGrjEVrQt3pZqRIG0Q/2JLJHzkJ6tkQ8aWxjIKwJWhnACyRhNz5W1s7PccWnoO2rzZyH4sOOzCjIXUC1SJN1Il4K53wsnvjsVOpr6WZj5Ux1uQWY701Mc68ohIvm472IrfXJyeVb/z6rQIEuUifjm1Kb2JmHsjrxCqOPZhhNtMi93 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11c03.5540d89f.k1504; bh=8Agf6BVWAoIYw5BpeI9PP7zOosMBOeG4OXhUsL9bgg4=; b=vA2OgzwRh/z3b9UqBz6sUkEZBGefLTwyVTeNsuOW2IA1tHmtVUrY36S6PmO2GlsYmuY7S4X/ClC+LcQdwzHfRDWa8TgZ63aWPHehXjLALTgevPdkYwR7IRhacR3af57UokR1766z/aPS5YTOcQN9DUEgTIYsrLRGysFYZWEJYmJzEDnhgVAOTv32ySYNFdcHKgW3rWSUA6Y5DLoV6LgVOYWUZKq2HhKmbHBAk24QFnvhjEykhakRb2aaPxsEXhLX Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 Apr 2015 13:11:59 -0000 Date: 29 Apr 2015 09:11:57 -0400 Message-ID: From: "John R Levine" To: "Michael Jack Assels" In-Reply-To: <201504291154.t3TBseAl025474@shadrach.encs.concordia.ca> References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> <201504291154.t3TBseAl025474@shadrach.encs.concordia.ca> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 13:12:01 -0000 > I'm still hoping for something that users will like, so I guess it's back > to the drawing board. The usual next step is to write up the proposal as an I-D and send it in, so we have a concrete description. Even if we decide not to use it, having a spec to refer to is often useful when looking at future proposals. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 29 06:27:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26E1A913A for ; Wed, 29 Apr 2015 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 I418EDdGnS4z for ; Wed, 29 Apr 2015 06:26:59 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8810A1A9139 for ; Wed, 29 Apr 2015 06:26:59 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t3TDQwEr032619; Wed, 29 Apr 2015 09:26:58 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t3TDQwiC026041; Wed, 29 Apr 2015 09:26:58 -0400 Message-Id: <201504291326.t3TDQwiC026041@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John R Levine" From: Michael Jack Assels In-reply-to: References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> <201504291154.t3TBseAl025474@shadrach.encs.concordia.ca> Comments: In-reply-to "John R Levine" message dated "29 Apr 2015 09:11:57 -0400." Date: Wed, 29 Apr 2015 09:26:58 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-04-29 09:26:58 EDT Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 13:27:01 -0000 On 29 Apr 2015 09:11:57 EDT, "John R Levine" wrote: > > I'm still hoping for something that users will like, so I guess it's back > > to the drawing board. > > The usual next step is to write up the proposal as an I-D and send it in, > so we have a concrete description. Even if we decide not to use it, > having a spec to refer to is often useful when looking at future > proposals. Right. I'd been avoiding that because I saw this as a relatively minor change to Murray's draft-kucherawy-dkim-transform-00, but if message wrapping is considered a nonstarter, a new I-D is in order, assuming that there's a simple, secure, and palatable way to divide any arbitrary message body into its "original Author part" and "list decoration part(s)", irrespective of the Author's part being good-ol' text or MIME. MJA From nobody Wed Apr 29 08:28:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F23D1A1BC0 for ; Wed, 29 Apr 2015 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 AxpH7n4YXxZN for ; Wed, 29 Apr 2015 08:28:15 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 903FF1A1B5F for ; Wed, 29 Apr 2015 08:28:15 -0700 (PDT) Received: by widdi4 with SMTP id di4so70293970wid.0 for ; Wed, 29 Apr 2015 08:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lk1M7sBg1qJ1zOGhId8o2B5jNc6EcWZt/cMd70Wln1Y=; b=IHdCZWEW8mfvRzA6rfmTFw0D8m2qNEkDogIhFbEvhE33xWDRBZ9AlTW1sKJ3030ruM v6nNMLRcLvvo7oocbv/af6sjzO/6xVYHIr3JgvHpudUeuhQFECnvt3sOxyK8AAs9qK9H iU5hs3x6Hwpay8ypqfGPpEuenz5dUE0QQpPsxPDRdd943M+8lkrSAAcoVV8plgL85AKQ gJCG+mHLXntYGCW60HTXFeQIx7DPbgXHsyvCM/FlKQrja3hh7VMzHnryghXkthpx4zeU gYKNnhGMsw5s0jMXG4vwkRelvZdHgRzNCuEbeUAuCZB3goKZPU4vI3vb4D4xiyLcJtTe Zt9w== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr44171105wjr.135.1430321294261; Wed, 29 Apr 2015 08:28:14 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Wed, 29 Apr 2015 08:28:13 -0700 (PDT) In-Reply-To: <201504291326.t3TDQwiC026041@shadrach.encs.concordia.ca> References: <20150427212951.8319.qmail@ary.lan> <201504281412.t3SECJ23017537@shadrach.encs.concordia.ca> <201504282054.t3SKsEqn020908@shadrach.encs.concordia.ca> <201504282256.t3SMuOEB021609@shadrach.encs.concordia.ca> <201504291154.t3TBseAl025474@shadrach.encs.concordia.ca> <201504291326.t3TDQwiC026041@shadrach.encs.concordia.ca> Date: Wed, 29 Apr 2015 08:28:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Michael Jack Assels Content-Type: multipart/alternative; boundary=047d7b86d3e6a8c51d0514dea028 Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 15:28:17 -0000 --047d7b86d3e6a8c51d0514dea028 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 29, 2015 at 6:26 AM, Michael Jack Assels < mjassels@encs.concordia.ca> wrote: > Right. I'd been avoiding that because I saw this as a relatively minor > change to Murray's draft-kucherawy-dkim-transform-00, but if message > wrapping is considered a nonstarter, a new I-D is in order, assuming that > there's a simple, secure, and palatable way to divide any arbitrary message > body into its "original Author part" and "list decoration part(s)", > irrespective of the Author's part being good-ol' text or MIME. Since we're just throwing out ideas, I don't mind adding your "stf" idea to the transform draft. Just send me some text. -MSK --047d7b86d3e6a8c51d0514dea028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 29, 2015 at 6:26 AM, Michael Jack Assels <mjassels@encs.concordia.ca> wrote:
Right.= =C2=A0 I'd been avoiding that because I saw this as a relatively minor<= br> change to Murray's draft-kucherawy-dkim-transform-00, but if message wrapping is considered a nonstarter, a new I-D is in order, assuming that there's a simple, secure, and palatable way to divide any arbitrary mes= sage
body into its "original Author part" and "list decoration pa= rt(s)",
irrespective of the Author's part being good-ol' text or MIME.

Since we're just throwing out ideas, I don&= #39;t mind adding your "stf" idea to the transform draft.=C2=A0 J= ust send me some text.

-MSK
--047d7b86d3e6a8c51d0514dea028-- From nobody Wed Apr 29 09:14:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D7C1A8871 for ; Wed, 29 Apr 2015 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 mAJT9E4iAcYR for ; Wed, 29 Apr 2015 09:14:52 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C31A8729 for ; Wed, 29 Apr 2015 09:14:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=99342; t=1430324084; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5NNl0Bb0BSm4DzN8H3iaumUfmp8=; b=VjR0bIluCsyniZBtvP04 GZw8qWE5du3ZLTArPjDpNuLnJD3Ic9e79a3BFQcTyEkhzykbPQHG2xU+6/gJkQza VEbnX2+xur2Y1/kBGSxKWY3YDYODlEZl6TmakGPFYSLppycaS9t7P2Hy3XlxYMGU M6kINaKHMDtoS5FDCQlF86c= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 12:14:44 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4034084432.2434.2132; Wed, 29 Apr 2015 12:14:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=99342; t=1430323826; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=C6f8Yxc wDibJmbl/7iAdBCS0hgUYjKt4P14xUOUXjF0=; b=F7mKlLhv5FHE8JR2fndxlyQ Rb5WzI+yYeAWc7EyYk/MiccvxZHp5cd9XNDbNPjqBSkoV858BT9LmUZQF4DXDo4X AJ6KIBjE4EPdv/wn7E6H3T3LktwK+5FspeqGL5mhWT1qf42hnAr5MXNw2ij97gcc +yml6rD4bU0mZf5Ij7uk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 12:10:26 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2626361926.9.10008; Wed, 29 Apr 2015 12:10:25 -0400 Message-ID: <55410374.2040107@isdg.net> Date: Wed, 29 Apr 2015 12:14:44 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: multipart/mixed; boundary="------------050607020303030608040006" Archived-At: Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 16:14:55 -0000 This is a multi-part message in MIME format. --------------050607020303030608040006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Side note: DMARC is not a BCP, nor a Proposed Standard. It has an Informational Status. DMARC is very much incomplete. On 4/29/2015 8:04 AM, Stephen J. Turnbull wrote: > J. Gomez suggests: > > > > > That would force DMARC-compliant Mediators to reject (or accept > > > > but not resend) incoming email from p=reject domains, > > > > irrespective of whether such mail passes or not the initial > > > > incoming DMARC checks. > > Something about having mediators (ie, non-MTAs) implement this check > was bothering me. I realized that the nagging thought was the > *Mediator* doesn't have to do it. In the SMTP world, all receivers are expected to play by the same "interop" rules. We have "standard" expectations and best practices among SMTP mail systems. A SMTP receiver is a SMTP receiver. It is really all mechanical. The "Mediator" is just one or many types of "mail services" that is a post SMTP operation. There is no such thing as a MLM receiver unless its behaving like an "open relay." The goal with any SMTP level deterministic policy protocol is to: 1) Protect Receivers from Abuse 2) Protect Originator Domain from abuse 3) Protect End-Users from Abuse All three have benefits when everyone is expected to follow the "protocol standard" and its really in the above order. In other words, I'm adding support not to just protect domains or the end-user, its controlling and helping to reduce the tremendous abuse the receiver sees on a constant basis. We are looking for a persistent, consistent protocol that ALL SMTP receivers can run and the end results is expected to be the same from node to node. Like SPF, the DNS published rules, when applied corrected per specification, the result is the same at Receiver Nodes X, Y and Z. > Variation A: Outgoing Checking... > Variation B: Incoming Checking.... These are specific vendor implementation design details. It generally does not apply to IETF Protocol design because it wouldn't be applicable to all systems, including small guys. Look at our integrated design (attached!) Very complicated due to the history. In other words, it doesn't matter how its done, whether you can do it or not or where, but from a functional protocol specification standpoint, that it is done, and that mean all nodes in the mail network, otherwise there are loopholes. -- HLS --------------050607020303030608040006 Content-Type: image/png; name="wcdkim-ssi.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="wcdkim-ssi.png" iVBORw0KGgoAAAANSUhEUgAAA6cAAALKCAIAAABBY7AXAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA /45JREFUeF7s/QuUHWWZ9g/3N++MZNSBjA7Yoxx6OLbDqZWDARNsRDEqkUZFI4o0IjEgaH+S kWRwaOSQRgVaMBqijM2YIRFlEhPUJsp/GkTIi2RWI4PTZCmrFT5oZuS1X8mfNy/jzMp3xSve PKmqXV177zo8VXXtVatX7drP8Xqeqv7te9/P/fx/duzY0dHS63/+z//5f//v//3l718tFdB0 pr/4i7/o7Ox89NFHmfP5559/2cte1nQpyiAFpICXCsyePbunpwdNmzNnzqxZs7xsoxolBaSA FJACZVYA1JvwNT09vXbt2nedceafvGQP9Pg1Bx2136HHHnTMOw964zn5HDf+/fonn/4163r1 kfNftucrBvWSAlKgKgoMDAz0/v5F5AX7Dg8PT05OJnxAKZkUkAJSQApIgXgFOpIIND4+Dtj9 05fteWDPW49619+95ZJNp146lv+xZNX4yjt/znqP/cDwn/9FZ5LGK40UkAJlVGDz5s3g4K6u ru7ubnzfLmMX1GYpIAWkgBTwSoEZqBeGFvBu5/7dgN38MTemRlGvV9NIjZEC2SkwMTGxcOFC OD+Mjo5mV4tKlgJSQApIgcorEEe9X7zpy6/Y+zW+8a5svZWflOqgFAgrgF+c5s+fD/zdvn27 9JECUkAKSAEp0IICDan3Q+d8tPuEd3tl3139w8lnfrNd1NvCMCuLFKiGAnB1gL/v1NRUNbqj XkgBKSAFpECeCkRQL1atHfuGua877RKvkBeNkV9vnjNDdUkBPxWA0RfeDvjrZ/PUKikgBaSA FPBWgSD14tfDE+ad8vozP+cb8gbaI79eb6eUGiYFslYAtl6Ar8I7ZK2zypcCUkAKVEyBIPXC scFDK28YwctLvU8//fQ111xzxhlnzP39a8mSJatXr67YrErSnbGxMeiA14oVK5KkTz0NG8BR wAvnuJJKLRhQji/+othUylQhAQWwxA2uDvhhSspIASkgBaSAFEiowG7Ue+3nr3/t3Pd7a+Wt gF/veeedd8ghh4TjO+NibuwL7EYztmzZknCKZJQMOEgdQIcZVdGo2K1bt6LSyCjbuN6mMiBd t2SMrDWDNJxzZytcHUI6YH1bhTuorkkBKSAFpEC6CrxIvfCTQ4Qyb5G3An69YM34/UxyAF+w JrG7TbZrfxYWSL2NkJejA32Axa11EBltiFEOrcgoClZkVpo/4rfWkbLkQkBf7GRRltaqnVJA CkgBKVCsAi9S71vnn9bz7qt8pl63baXzcHB5iKZWvgz+yFuZzgZUZ0xWOPUW5eEAhwoTAeLb QLjfSVq2yKJThs7btm2z0TTOFvWmO8Pp4KuQDumqqtKkgBSQAlVVYBf1Yhsk7DBcFuQt495s RrdhtHXBN1MY9Yp6i7qjDECBuYE2mHNCy18/Go2yqDe74YatFxbf7MpXyVJACkgBKVAZBXZR 75FHH/uGs7/sOfWW2q/X5SHXCoiZBDMw13XhFfgIhkkAEyCML5yD1eCY684/XOEv6SiHPruW 3l1KxWRm5mQWriRjLSwcZGw1btiwwSoKlIw04XVa9JdlOcgIhw0rCkAZWCvmVhq4nZAS6d1e h30/kMbtKRIji9vgRreoiRA26CK7DUQ4O5e+WasCA8G+u07bNijudQ4iqjatAs2w0XQX+UF8 loaXzRC01lWJCgREtkWTqA7rJtl4t8ZAIeHZ5f+TDmFnsGuxzL3+j5RaKAWkgBQoXIGd1IsA QNiDzXPkLbtfr/32TU8GIMiMZt3AuijXYdR1PDWMAyeFl8oZ4rjI6/7Ejwnguti6JRhr4qTR Ijy3F2ZLJviGnZhdJmvk19vI+9k1zaI9jTykIWz8TYUELvpDtBm9eNGvGdcgunZ0t22R12lL Zpn4636NsYqgoXXEvDLsovv7QEAK9xuClebOJSskUmpkSfLlofAnl9uAxYsXr1y50qsmqTFS QApIASngoQI7qRf/MA46vs9/6i21Xy90DnMnDW9gmoD5loZSoxnQCYOduVdsMlmxtOQhMa16 lpisSbugi854S3ttAKHMnMkqwEDhFVpWlAttAcKjPTiStwKobX1xW4Ls6IgrmlmXrXYqg5cL cPEUC6nDCEvdIlcTuulpqQ3YdMmIJOOwwmFiZjKOCIU1s27gq1F4iJnSbRKDo7mxQVg4X4Ge smoz8NuwshB3IoUnpIcPL2sSdOvt7fW5hWqbFJACUkAK+KDATurFTmxYHCbqzWE8Ig2uZv11 G0DgMzDlR2andA2BLqyY5dUFI4PFRn69Adbkb+hml7Xy3Z/XXZgzK6xbvmuaNSR1gSzS1uvi rKlh2dlr16LsKoZkpLeWbbcciED8YLfxJi8kcmUJU7vbU3wamdi+2Jg93rVDozFWHWWxLxjg bM6NgK+CLaSLpF4yPSYGx9ekDrjBsJAZTeY53CzJq4CTQ2dnp2L3JldMKaWAFJAC9VRgJ/X+ yUv2eMslm/yn3lL79dr0Mm/X8G/0LstGTsd46g14iBppNUW9AWR0QTbgM2rYaoTnJnbLcSMb hAHRem3ZXfsx0oPSUJchoBsNg+bkGX1FIsVExrDRN8x8kXTIbwUBazouhjVh1ZHUa+hpAjJZ oEarKH56GENH2noDc8OV2hWn0XX/H459fX3r16/3v51qoRSQAlJAChSoQEdZnHrL7tcbGGOY 3IAp7g/TRKjAj+xMZnZf1yHVCgzTbYC0klNvwEIZg3H4yKVPcmdTLBW29TZCxvDt0chXpIWA x+gFjLth9w/+xN+I49mkMBA3S73WEX6jYIHWGGKuGZvDm9jZ9nIBzwpTrBGyu+2kiwhf9rUq PBMKfEglqVqBe5OopDRSQApIgZor0FG6mGW0SZcuXm/MPMMP1kYnrj0vwMR0yiT4Rno4uD9V o7oWbL0x1BtpaLT25Ey96F2jpX5oZxKf1Mg0rqcHxYy3fYYVbpZ6bZkaN6a2bz7sHeSFnTvg 3sCJFDBUu3Mj0tYbmBtuT8O/OfDKjI4iXj06h4aGli5d6lWT1BgpIAWkgBTwTYGOtWvXHtjz Vv/dGwItLB31kkvwirRHhn8Bd91JgUS0BUb6wtbQ1su7iNG4AmvLaCttdJshiw1EJPgGjKNZ 23rN/Rr1csRxQgM/0dOw2GXZwEpHvEWWSEBv1tbr2n0DQfR8e3IF2jMyMtLf3+95I9U8KSAF pIAUKFaBDsR4P3jO+0pBvaX2640009rYh6nX0rthpNqkXlQXsM6a4TC8EIofxWBf2JG0TQ+H Rn69RENIBMY1FMPFgOuwu6qv0U3lLvILL9gywyrUMOOoKRZwMHCLMo/nRrbeSIdsNtJ8ec2m i4suDYddja2nbheaot7y+u82GlmFcSj2H4lqlwJSQAqUQoGOwcHBg954Timod8mq8ZV3/ryk Hg7ub8qBvQDcqFuELddl1l1DZj/rt+bh0AL1ulmSx3AIeEpEMlYkwRtixoSA4I/7fLn3WORy rvBN6LpGuL/7cyeI8AI1S4/qWo7hENlZts3dIRm1W8dNirC/gX3kUm8kcDey9brD6opgG3/E 2Mv9fK6Jev0cF7VKCkgBKeCVAmWi3rLH63U5xrgtcNEmh12nUwS3KzMmc4EvuYeDyzq0npJ4 Glkow1jGXK5TAX+RZ8o2bb1uS/hbP+uyXrO1rpEVn4IaUa/r5xrwYQ3cb27sBdZiL6vIZT46 RZgtPNB9XI80xgeI3P3OwxKsVe43HJRmDjDud6FAaS6Io2R0P5DYRiSGegNfw/DWLSS8cs6r x1a4MaJezwdIzZMCUkAK+KCAqDe/UQhvWOAuJHJNiWETIFPa6v6WqTewCIzGwnjqZYKA6dEo 0I0a1j71oq6Ee7NFtgetilx1FxjjRlvNsVPhEtzlhoEhC3hpN1IyjNpuk1yqtutuloAzhgvi 1h73q4j9PhBDvQmlzu/2aK8mUW97+im3FJACUqAWCpSJekvt12uzCVY0Aoq9zOYamHG2GQGt ngQsQCGNhUY2diW8vQJTutcBTERnvohTbBJeMb9rw3xoP38zb9ikisIjy4m8bpW6zgxUwEIa syLru6tPuD2BnsbfvsjOHewCAxET+wz9dQcu4KbC6mKUdB0zUI67lo4l4xWQAsPB6+FwCoFx NJs909vQWAmNbLdJpC7Fg1DUW4phUiOlgBSQAsUqUCbqLbVfb7HDrNqlQLUVEPVWe3zVOykg BaRAKgqUiXrL7tebyoCpECkgBcIKiHo1K6SAFJACUmBGBUS9M0qkBFJACviugKjX9xFS+6SA FJACHihQJuqthl+vB4OuJkiBqikg6q3aiKo/UkAKSIEMFCgT9cqvN4MJoCKlQBUUEPVWYRTV BykgBaRAxgqUiXrl15vxZFDxUqCsCoh6yzpyarcUkAJSIEcFRL05iq2qpIAUyEYBUW82uqpU KSAFpEClFCgT9cqvt1JTT52RAukpIOpNT0uVJAWkgBSorAJlol759VZ2GqpjUqA9BUS97emn 3FJACkiBWihQJuqVX28tpqQ6KQWaV0DU27xmyiEFpIAUqJ0CJabel7xkjzfpJQXyVWDevHnn n3/+oF6eKXDOOecce+yxtXt+q8NSQApIASnQjAJlol7Xr/eQkz7a2dnp2X9eNaf6CvT19e27 777V72fZegjqPeKII5p59CmtFJACUkAK1E6BMlGv69d72Ckff93rXle74VKHi1ZgZGREdFX0 IETULw8HDwdFTZICUkAK+KZAmajX9esV9fo2k2rSHlGvnwMt6vVzXNQqKSAFpIBXCoh6vRoO NcZ3BUS9fo6QqNfPcVGrpIAUkAJeKVAm6nX9emXr9Woa1acxol4/x1rU6+e4qFVSQApIAa8U KBP1yq/Xq6lTz8aIev0cd1Gvn+OiVkkBKSAFvFKgTNQrv16vpk49GyPq9XPcRb1+jotaJQWk gBTwSgFRr1fDocb4roCo188REvX6OS5qlRSQAlLAKwXKRL3y6/Vq6tSzMaJeP8dd1OvnuKhV UkAKSAGvFCgT9cqv16upU8/GiHr9HHdRr5/jolZJASkgBbxSoEzUK79er6ZOPRsj6vVz3EW9 fo6LWiUFpIAU8EoBUW/0cGzZsuWQ3V9z58695ppr3NRn/P7lXmEuu4hzy4KLeHveeeeF62M9 yBv+KFxFo9mzevXq3CbW008/vWHDBlbn9jG3BqRbEaRDLxKWmRH1QlLOELww00xetMr9KHL+ IA3yBiYnKBDlsMDAR4GexpSPOWmFLFmyJEaimPZbrq1btzaa5wnFj0km6m1fQ5UgBaSAFKi8 AmWi3jz9evH/vqOjA//pQQx8AThIJDYncO6+JfK6V1zgwHUUGKarFStW4CI+iqTeQBWNpiOa l5zb2p/TAZpHF9ovs6gSgGtEw4QNyIh6OdCYA3hhNDEfDHztI1xxv1NZgzEzkd5FW3YK11Ea RifwaaCnjconpLIQMnTgO55bTkz73ful0TxPKL6ot32hVIIUkAJSoM4KlIl68/TrJfUGSBT/ +12AcJE0jLyYVQHqJV2hkAAukFpKSr1lv3kIc8VSL43NQNXwFyp+tG3bNn7EGQgetbe0xQa4 FjPK/fYV86Uopnx+zbMmkaQDs5efxrTfsuMLJHWOnOftzyLZetvXUCVIASkgBSqvQJmotym/ XoAC/vHbP2mAgvuWtivCBExo4d+CI6kXiV1CMuqNRN4w9RKw3B+pSRJoQBLqRUbY7UgwtPmR fsxajPLN7EpkwcvttdtZXAesuIUgC9CEWZAShdtv7gHjLo3WtPzhr1UKPSPrRQJcN51RvvsL fgv3GKVwnUbc1uI6CRJ/A93nNDC+hJi0sBZLvdAtYC+3qRXg1/CkQgJkdwcokAZvG01mfBRT PtoQcKgI1GIDF9N+o3PklYdDC1NdWaSAFJACUiBFBTqGhoYOPvGDLlCW4jzJjsTuv23wHFjN /ovjLdmOxAn6ARnQZEX/xUagQOgkNtmvuuTL8Ki4lMDEARdSsA6pKwn1Es35i7P7YzeYg7SK 6+R41gWyxxViKPmYlkKWwJZYvewXctGdg+TElPabO12HyYiokUa7cB+tXhTObx1WOD9iR9qZ xCyBzqyQwv1Bn+VzcCmFi24u5LEjUKZw6g1Iwe5wFNy+WI/MmcFswPHUy2FK+GMC5wCrDrg0 2Dei+LFz229tJtY3akY7k4F5ZettX0OVIAWkgBSovAIda9euPbDnraUg3Wb9et0fdkkPBls4 4b/hABUhC//TNyJR9zoL5MsIz50xYSLkP36zQJODm6JeK9/tnXse/rnZlsThxHAQ5bg2ZvqS 2k/naFKYeAy23H7ZOU3O7s/0Vl248Db9OwPcHPgtnrZPji9bZaLZdQ490/hGvQFqdx12IzmY k8pNFobLQAITxBjXvcJJwkllrIx5hVFz50+jh2OA1DE69sUjO+rFc2zhwoWVf16rg1JACkgB KdCOAjutcfsdemwpqLdZv14wnJEc/t3SPgos4y+t5DOcREY/aESiXBtEFMB/d5pO6U0RBoJI 6jUnB5rEYgg7gDiBKlxWc6mXdl+abPkyr4ww+hiFuCXYfEILUQu6TEt5PPUGkNqwyT1x6TNs eqRdOfIVmOIBKQjBbpfx1obDhhhT3QgYo2ZY7w/12kSyrx/oRSB4QuB7GpUJU2/AAddEcOXl BIspn8JSbXtxxtrLHZpw+wN+w9lR7/Dw8MDAQDuPQuWVAlJACkiByivQMTk5+Yq9X1MK6m3K r9doANBmfgX832/2PxoFI3/5bUS9ZEoW7rKXLXh3Z0wk9Vpj6JmaOvVGkgoraop63UBaRtJh xrIyw9xvJB1G6kjZcbHRK556mSsAZ2ZfNMA1mze/DuE6Qdl6lyQYRUYxHDgNXFgPz7FIwG1E va7pl9+vyKmuwoE5HFkUXcnthxEisluI3T6R7UdKOqLwhbeMi5L6g3Xp0qVw1kq9WBUoBaSA FJACVVKgY/v27X/ykj2qSr1cOW6/sfLctW/h37DLOuAD/ktuRL38Lx5JJMgIlnJLi6ReQgOX 05mnbEK/Xtec3MjWG0ZM8zpAveG1dKSWQC6+db8PuH2JPA+4GbhlJqTe5PdV2NYb8MdwHS1o 4uXXElpAuabNffG3+8Dircj2ZES9HM1wA8wB3RqDZOFfJwLfZwIWXCrgamKlxZSP74RmcjYg bhQWulH7+QuAvahzYLCSj3tMSrg3wMkhlaJUiBSQAlJAClRVgQ507Mijj33D2V/2H3yb9etF 1/j/3nCHdlYyEEfU7H98a6udIqkXn7r+u2HrJu2jBouNqJeV4lNW2oiw8ZFbRaC6RtTLJWsu nRhnBFiW3YmkXrd5lHFGDwf6fbo/rAfqdW+hAFI3e3cFpAj0K7yait9VTPBAdYV7ONhqvLAO VN5UDTtPG4+6BlQKYmvdwoEarKKY8lmXFRLpA8NyYtof6FGb4x4zT7q6uvCzVbMTSemlgBSQ AlKgVgrspN6rr1l+2NwP+U+9zfr1GhAY7oS3JKAJkD/C0lrJoFokUbNRkZUDZrYw9bJ8s8g2 ol4CoutX2qatl+yCemlpJs7yF3w6PLh+omwhX0YhAabhQjeWQAcAvMwSyYxhrwkKyJ+wmYb2 xaxtvfx6YFW7Q8A5QL/kRruLFU69HK+A+dn10GDXAt7VgW8RAbcBlmazOjLOLkuwUQuXTyVZ SOCrlFt7fPsD7Yx0KGrzmTs+Pt7T09NmIcouBaSAFJAClVdgJ/VOTEzs/eq/8p96W/DrRe8A gq7XgTkp2tDSqwH/3fHP2+gQJi5zRuRJ+LfdQMksEHiBxCwHJ66VLtCMQF1mVHPnnFtFoDq2 0BLT/9KqQ2tp4cPFwE/b+IjdMXdPa7ZbNcCXJbDZeGvVoeXUJNBHvLV63c5SE7dwvI3sb8L7 LVJ5+knjFXbP5RBH/sSPGgNKxrchCw8Hjl3g5fYC5zScN4pz7A69tZ/eC+6sbtS1RuVDMSsk hptnbL/V2+a4N2r/4O9fCSePkkkBKSAFpEBtFdhJvXjt/1eHvPGj/1Ai8E0Sr7e2g9qo4wAg 195pQS0kVHIFsqDe5LUrZaQC3d3d+OoucaSAFJACUkAKxCuwi3rXr1//V0f2ek69Lfj1avhd BehZAXsbfmWm12YW64qqrbmo17fxxbOrr6/Pt1apPVJACkgBKeChAruoFy07pPuIE879ms/g 25pfr4eiF9gkgK/5jwa8DgpsVYmqFvV6NVgIQTNnzhz49XrVKjVGCkgBKSAF/FTgReothbnX oFweDn7Op8q3StTr1RBrcwqvhkONkQJSQAp4rsCL1IuGnnb6e19/xuU+m3tFvZ7Pp8o3T9Tr zxAjVBlCN0xPT/vTJLVECkgBKSAFfFZgN+rFz4WvO+6N3sbulV+vzzOpJm0T9Xoy0HhYAXm1 iM2T4VAzpIAUkAKlUGA36kWLp6amDvnr181bvNZDi6/8eksxpardSFGvJ+OLFWxwyvKkMWqG FJACUkAKlEKBIPWi0Vgasv9Bf+35yjb59ZZielWvkaLewscULg1AXgxE4S1RA6SAFJACUqBc CkRQLy2+f33UMT77+Ip6yzXPKtNaUW+xQwmXBgRtkJW32FFQ7VJACkiBkioQTb3oDNzmsLjt oGPe6Y+3g/x6SzrJqtRsUW9Ro4kn0tDQEJBXvrxFDYHqlQJSQAqUXYGG1MuO4X/8vgccfOiJ 73/TRf9UuKev/HrLPtsq0H5RbyGDuHLlyq6urqVLlypiQyH6q1IpIAWkQDUUmIF6afS97vob /vyV+2Dzttee+v/1AX/B3/JwqMb8K10vRL15Dhk8Gfr7+zs7OxcvXgy3qzyrVl1SQApIASlQ PQVmpl7rM/4DnXveIuDvaw46ar9Djz34xA8e9MZzijpeeeDxnZ1/OaiXFMhXAayj2nffffOt s3a1zZ8/v7e3d9asWVy1Jt6t3j8e9UgKSAEpUIgCTVCvtW/z5s1jY2PwsSvwv/HAwMDhhx/+ Jr2kQL4KvOENb3jb295W4MyvQ9Wjo6N4wuBXpkKeiapUCkgBKSAFqqpAK9RbVS3ULykgBaSA FJACUkAKSIGqKiDqrerIql9SQApIASkgBaSAFJACLyog6tVskAJSQApIASkgBaSAFKi+AqLe 6o+xeigFpIAUkAJSQApIASkg6tUckAJSQApIASkgBaSAFKi+AqLe6o+xeigFpIAUkAJSQApI ASkg6tUckAJSQApIASkgBaSAFKi+AqLe6o+xeigFpIAUkAJSQApIASkg6tUckAJSQApIASkg BaSAFKi+AqLe6o+xeigFpIAUkAJSQApIASkg6tUckAJSQApIgSorgN2tscd1o9fExESVO6++ SQEp4Cgg6tV0kAJSQApIgeooAIpduXLl4OBgX19fb29vR7JXZ2cnEiMLMm7evLk6cqgnUkAK iHo1B6SAFJACUqAyCkxNTa1du7a/v7+rqysZ5c6QatasWfPnzx8aGhofH6+MSuqIFJACsvVq DkgBKSAFpEBbCkxPT9N/YHh4GLbS8Gv9+vVZOBLAdQFm3e7u7lRIt1Ehs2fPXrx4cRbtb0t0 ZZYCUqB5BUS9zWumHFJACkiB2isAChwZGQEOJodOGFDhRTAwMICMbUIkjLtga/Boct49ce5J 4SN5dqRE42FRrv3ISwApUGIFRL0lHjw1XQpIASmQswKTk5PAzVQcCYDLsA2DX5vqAhoATwYA dAyw7rXXXm8+5dQll15244qvrtu4aevkM8/8Znuj41dT00gzsvpbSH/OuecffMhh8SiMvoPa m2qzEksBKeCJAqJeTwZCzZACUkAKeK0AUC/54rCmbKjwoE1oQ4WjbSPe3WOPWSDdyy6/6u57 H4xh3CQfPfLYL2++5RvvP+vs/fY/oFFHenp64LbR7IBhnRx6iq8NMHhDzPBr4cKF+BRuG3AX afb7QLONUXopUEMFRL01HHR1WQpIASnQhAKjo6NJ3BjAiHQhAC/Cboq/5lEQg4+GlXPmzIkJ noCPAJqRDArYhaU2Cc62kOahhx+7eGDJPvu8KrJqQCp8muOlBLziCwNSNuWPwerQZfAx9IcH cxMDpqRSQAo0UEDUq6khBaSAFJAC0QrA+zbGvgsW7Hv3mVde84Xv/eDeGYESbgZwJIAtFlka QSQ4D47CARsngG/p0qVh6IRxF2D94wcfnrHqVBLA+gu8DjcD3wcaxXkA7ALlmzJ7xySGX4cC SuhGlQJtKiDqbVNAZZcCUkAKVFMB/BYf6U4Ar1ngZhLSjcHNNd/egEJArmHOg03UHB5gSY00 8cL+Cj+EVHC2qUIA7scce3ygzVAJPgk2CeB5DExHAOC0eNctB19CWvCsqOYEVa+kQPMKiHqb 10w5pIAUkAJVVwDepWFow0ovmDyx/KspUoxfSYYFZ0cceVS4Lix0i0ReQGdu9t1GLYcIQP9A m6FYI7O0mxJ2bjh+vP2dC+AEAjM5MNoOGMJxERZlJIj8PmDl4JuAttKo+i2o/mWigKg3E1lV qBSQAlKgvArACTWAdIA8IFpasBsu53PX3xTmyIC5FCAILsyuDU2VDEtz2OjbyL4Lt2YYtsH3 8BJOXguW5aG/4VpsaODzMKNXcXknoVouBbJQQNSbhaoqUwpIASlQVgWwfCqAvIjnFR/8KznJ xaREFaiokVcAwLFwE2+48XC0iHdjgBMzfDna1AfKAH8jnaHhVQyHirJONbVbCuSugKg3d8lV oRSQAlLAVwXgMxrAuExNvGEcBN6FORLI25SVtE3KbCo7LLiRK+0AxKm3OdIbBG7QWuXm6/2k dnmngKjXuyFRg6SAFJAChSiAiA1udC14FLRvp2yKIJk4wJE+I29kg7P2PMb3kIA3CEatzb3u CplvqlQK5K+AqDd/zVWjFJACUsBHBfr6+lyzZc5WXpePAb4EOyx0S91i2gKIz5gF69vggYDV fmj5jInbTwCv4sASQOwYp10tfLyp1CbPFBD1ejYgao4UkAJSIAMFsNcXoiJgmRr3AyPdIpos 3yL+QCBOGRxS24ezdkpApIj2d1lrpwGe54U+gfjB2OIO4IuBRpxgDGjghfHFR4r8kMG9pSLL pICot0yjpbZKASkgBZIrgEBaYB2QbqNdfButxIJvQw7L1zzHSv+bB/CNifAQs8wO33awGwjg WH4Rye8mpayGAqLeaoyjeiEFpIAUeFEBBLSCqa+FLXCJSosuuMh/5lMLoQC+nMRsdJdkmwxE gcCPAPKO0OOjJgqIemsy0OqmFJACdVEANryWeZecJNeCEiE1XIqT0O2MaeDVrVgQdXlG1Lif ot4aD766LgWkQLUUgEsDdi5oxDfY8QtGXOz+NbL6W7YfGJascT8wMxnmsx6rRFjpf1MxrO6g w+0BYx04IjfAC08VsW+1HgnqTVABUa/mhBSQAlKgCgoAeeGvGeYYEC1AVn66/sNrOy1EpAt8 k5lxlOEKjGQIiozVijGuEUuXLsV0qsJdoT5Igd0VEPVqRkgBKSAFqqBAeBvht79zgXwV2kHJ yueF1R9bJWPxYvjLEvx9tdatCs8F9UHUqzkgBaSAFKiYAitXrnTBBRwDd8/KQ5s6mIoCMADD 0SVs+kXoj9HR0YrdKepOzRWQrbfmE0DdlwJSoPQK4Mfozs5Oo14gr0y8qeBgrQoB+8LzIWD3 FfiW/umgDsjWqzkgBaSAFKiSAgjK6xp68bN16XDtB//8wIEHHYxj2Wc+21Tjm03fVOHJEz/+ 5K89aUnyNkem/PGDD2OHOXc6AXyxvUWV7hf1pc4KyNZb59Evvu94mH5y4JPzeufZcebCMxF3 CdFGi2+cWiAFSqKA69GL9fttck8h2UG9JK3k7IhVWW+YcyJAuZAGu5WizWgGGlN4S1JpAIy+ cPZ1wRfbHZfkVlAzpcAMCoh6NUWKUeArK7+yT+c+x/ce/6nhT60aW2XH8rXLT+8/fc/Ze35i 4BMKnF7M2KjWsinQ09NjjFLSuGMtUC9YE732gXrBu2hJZaiX6BwAX5l7y/ZUUHujFRD1ambk rcDk5OSRPUe+b/H7Nk1t2rJjS6NjyfCSg7sPXrd+Xd7tU31SoGwKuBsOf+8H96Zi8Mu5kDD1 4goOeA6gJStu/joYF8f9Dz3ChuHkwosGSL1MaQ3GR0yM46cTk25HrEzYifHp0OeHWRSus2Re x4GTgAKNikVeo14rJ2f1MqrODfGLHYzLdluovVIgQgFRr6ZFrgrAYHB4z+FrxtfE8K59NDY9 dkrfKVcPXZ1rE1WZFCibAggyZbbeMjr1AtrC1AucRaeAtmRKe4GAkT5w0Sy+RGF74TrT82CZ Z32onyd4gWWNWXHdzYu3ljGmWCuKeatk8cXiNhMEc6xst4XaKwVEvZoDhSqwefPmnjk9YNkk yGtpzh44W+Bb6Lipct8VmD9/vtEJtunKyPKXabGNqJf+sjC+GncScF1yRYJ3nPYumoSpA94i i1GsGW6NUFksCdUAGhdRC510aUWmqTi+WNRl6VGUy8qZKpZD4fgGZfNKrr2+PwXUvmQKyNab TCelalsBOOkeM+eYjZMbm0JeJp43f973R7/fdhNUgBSopgKDg4NGJ4g8hW26ckCidKuIoV46 OeAAXxJG+Tbs1xv2r+UVMrHZeg1nedGo1+AYng/Uk44TMxZbSb9edHzNtzeIeqv5yKhxr0S9 NR78fLt+dv/ZV4xc0QLyIgs8gPfr2k87ZOY7YqqtNArgK6Xr2ovIUzPuTJsus7ZfWiPqdR0G Apgbpl5zYKD/Lg6aew2UmSDghEBmdVfFWWNIvTMWW1XqXXLpZUa9vb29pbkf1FAp0FgBUa9m Rx4KjI+Pv7bnta0hL3MtHlz8d4N/l0dbVYcUKKECAwMDrk8q1iGVy+LbPvVaCa4OPG+HepMU W0nqRfwyd7c2TLAS3hZqshQIKiDq1ZzIQ4EP9394cGQwknrXbV138hkn73/I/vgbg8Uw9yLS WR5tVR1SoIQKIMS1u6YNqLfXXnuVKIpZ+9QbaZQ1o6/r4QDnXdc43YKtN1BsJanXXcqG6aTI ZSV8KqjJEQqIejUt8lAAwNooThlgt2duzw0bbpgRfBHcV0/ePEZLdZRTAcQEdPclppkTRl+w r/8ODylSb8ApAo4QFteMvgqBjTASUm9MsdWjXrg4u1sTIyB0Oe8JtVoKyNarOZC7AhMTEwd1 H9TIjrt6y2qYe/Ep2Dfe3Hvu0nOHhoZyb74qlAKlUQDgG7D42s/9fe8+85HHftm+A25GJbRM veggbLc039LTFy+486JAW5RmcRVao94ZizVuZqzfjCTKrViEbsAPBa6jyOjoaGnuATVUCsQq IFuvJkjmCsBACzNtvFMvkBe2XhBwTDLs4obtizNvriqQAqVVAN8wAw6+LrtglVtu5NRsRS1Q L+yR1jvz3GWcB/fl2mhbo14LH9GoWMPi8FK5ZnUoNj18ed0VbOyvPHpL+zxQw+XhoDlQhAIj IyPYZDgGZ3+07UdXrr4S4IsjJhk8g+EfXEQPVKcU8FoBhDdZuXKluy9xeEUXr3jr6oDwZIFN 0fiW26fxsI3T7Mo/3PZtYC4D+tpFhNeFcZdBfN0tKmgMDu+7hioCNlprjAVNQ96YYvEpCmGN boOLRdhma4cnjLt8jROmr6/P66mvxkmBJhWQrbdJwZS8eQXw6xgC7jbCWbg3gHrx6YXXXIiH LL0dIo9lK5ctWryo+fqVQwpUWYH169djB4FGmOteh5NDsySk9JVX4McPPoydTcK8i5mzcOFC xYus8rOjln0T9dZy2PPtdHzYMjg2nH7e6fBtwF+cx9h6Fw0uQjT+fNuu2qSAvwogbgNMcTG8 C5eGE+eeBKbBz9Yl3am48tBZbAdh33VXrblzaXh42N+pr5ZJgVYVEPW2qpzyJVYA1oI9Z+/5 wPYHIokWvg2AXTxt8RfnMdR7St8pMGslrlYJpUCVFcD+3pEmXhjtzjn3fDgDeOvMUCznqXZX gUgTLxZEYnZV+eZR32qsgKi3xoOfY9cX9C24bv11MUR719N3xS93AzQDnfVzW46Dpqr8VQC/ n7ibsdFEhyBlN9/yDVGdFEiuwDHHHh/5W8HixYux4Z+/N4BaJgVaVUDU26pyyteMArDRwlLb zt5s2M0Yexo3U6fSSoFqKoDwZLNnz3ZhBXGmPnf9TclZRymlABWAUy/cYCLBF3Ns7dq11byF 1KsaKyDqrfHg59v14+YcN7J5pDXwhaF33659ZXvId8RUm6cKBGI1wFzncyBe8aX/CnzvB/e+ /6yzAzF6icIKke7pU0DNalUBUW+ryilfkwrgN9nXzXldI+/eeBo+b+l5Vw9d3WSFSi4FKqgA 4gC6lrk3n3IqYqz6z1Vqof8KYCJdec0Xwuzb399fwRtJXaqrAqLeuo58Ef3++sjX3/retzZr 7r1+/fVwCy6ivapTCvilAPza3T2H8du0kNd/mixXC7EIEqshAz4Piufg14NArWlDAVFvG+Ip a5MKIHBvzzE9p5x+ytj0WEL2XTK85C3z36JFbE0qreTVVADbHLo4Up9gZNxFotHh7iWRImLa phgsP7yPRop1+VYUjL7uTMPSSUV1qOYzpX69EvXWb8wL6jGQF7FFwa/r1q87vOfw5WuXx4Pv mvE12Nvi4oGLC2qvqpUC3imAeNXGIj5vL5w6w3En4UYv7Gaceo0o0PYZZvnhPZOzqNSfMvGd yhUcYfJkffDuiaAGNa+AqLd5zZSjeQUMeZkVi9DPXHjmQd0HfWzwY6BbF383TW3CzsMI+HBk z5HI1XxVyiEFKqvA/PnzDUSw94Q/hJR1S4x6setv+Lj/oUeyaAA3GcbB8utGvegyNjdxwVfh 0iv7ZKlTx0S9dRrtgvoaQF5rxcTExOWDl4Nu3QfrPp37fLj/w3q8FjRWqtZrBXp7e+1mAZFk gXp+lknqxd8Cm1dD6oXaCAJtU27OnDle3x5qnBRIoICoN4FIStKGAo2Qt40ilVUK1FSBhQsX inobgS9Ns2d9qB+m2Xec9i4gMg6cIP0/3PZtfMQrSOCWgLe87qZnAtl6IULAzwE/09X03lO3 q6KAqLcqI+llP4S8Xg6LGlVWBbBjllEvwvQWaPjMuWqz9cLgGjjMvYFuuC7CUivwrl3nlQsv GmD7wcS8wlw8JyjLr9eGeI89Ztmsk9dZWZ8davcfFBD1ai5kpYCQNytlVW5dFYDnj+sOdPe9 D+ZMn0VVF7OaDVAbgFRacxFywXIFrjDLTycmCbuw6bIEJHP9KGq+ms3G2t28beXKlXW9+dTv iigg6q3IQPrWDSGvbyOi9lRAgdrG6zV+dU25AZ8Eg1Sz/pqVF4BLhrMrYXxHGtiARb1hZU6c e5J910IUkQrcR+pCnRUQ9dZ59LPqu5A3K2VVbu0VGBjYSWb2wkayRdlf86w3yWo283CwhoUZ N3xlxc1fNydg83aQh4M7uPvs8yqbb1pnXPsnUOkFEPWWfgh964CQ17cRUXuqpADMvd3d3S74 9r37zMrv0JYR9RoE4wSGXnk4hL/JPPLYL93JhsA7Vbqb1JcaKiDqreGgZ9hlIW+G4qpoKfB7 BbBLFvbKclkEnpff+8G9eRpfc64rC+qFOy/9GWyTi4C1WH69GGX8mGAzbfbs2boFpUDZFRD1 ln0EPWq/kNejwVBTKq0AfmgOgC/QBEbfHz/4cM48mk91MTEcwKzcMbhZDwdLb16/DOlgUYFF vfgq5X65gndNpe8qda4WCoh6azHMOXRSyJuDyKpCCpgCY2NjsL25UMJzRDS78povVCy8Q/yO xMDTFqgXHr3myGtRe3mF1t+aUy98G/bb/wCbYPiWNTU1pRtQCpRdAVFv2UfQi/YLeb0YBjWi ZgqMj4/39PSEwZdXEGYVq+/xCzV2cfvc9Tc99PBj+dhls6glHLrBvWLUy4vWAFum1ugKfHnN igzX3nUbN7mxzFAs3xKC8ZdvWV21j62Tz7i7smE6LV26tGa3l7pbTQVEvdUc1zx7JeTNU23V JQUCCgwNDUUafcM0DBtwtVmttd4BZ83JobUSKpYLjg1u3AZMJOxFjGWUuvWkQAUUEPVWYBCL 7IKQt0j1VbcU+L0C+OkZ7NvV1dXI7svr+MG6Ynym7qSrALwaFl1wUWAWYV5NT0/rVpMC1VBA 1FuNcSymF0LeYnRXrVKggQK4Jfv7+wOhzQxi9tprr3QhSaVVRgE4wIB33c2HOW2AvJOTk7rh pEBlFBD1VmYo8+6IkDdvxVWfFEisAKy/a9euxU5a8+fPN+rFQrfKUJo6kooCcGaA30vAhdcm TF9fn6y8ie85JSyHAqLecoyTb60U8vo2ImqPFIhUAOBrEIPFbamgkgrxVoEbV3yV9lquZTzn 3POxlhEHrmOt3s23fINvcR1fgWL8YRCxYeXKlbqnpED1FBD1Vm9MM++RkDdziVWBFEhJAVGv t4SaesPWfHtDvGN3wk8Rl1dBylK6/1SMdwqIer0bEs8bJOT1fIDUPCngKgCLnbGOVrOlDpr+ FAjHXPhtJ+TayGSdnZ2LFy+WF68eINVWQNRb7fFNuXdC3pQFVXFSIGMFENPXRZxSR+31BzF9 awnC62JX6taQFyGfAbvY9CTjmajipYAXCoh6vRiGUjRCyFuKYVIjpUBAATea78UDS3wjNrWn fQXe/s4FLvIuXLgQFDs8PAyc7Q29sEYNfi/4VKSrZ0UNFRD11nDQW+mykLcV1ZRHCnigANDH kAi7D8Au2D5mqQRPFMBoBpBXO0p4cM+pCf4qIOr1d2z8aZmQ15+xUEukQLMKBJwc+t59pifE pma0qcCPH3w44NiA8LpaiNbsDaL0tVJA1Fur4W6ls0LeVlRTHingkwL4Udv9Bfxz19/UJm8p e+EKIGJDYPkaXFnwDceneae2SAHvFBD1ejckXjVIyOvVcKgxUqA1BbAwHxFYXfAFMxXObWpA awo02jdYyNva3aFctVJA1Fur4W6us0Le5vRSaingsQIjIyMu9WIXg/wtvnff+yD2R7js8qvk W9wa70I37DER3jcYK9a0iZrHN5+a5pECol6PBsOrpgh5vRoONUYKtK+Au2MFCfj9Z52dD4D+ amoa4SMMu/HTfP7M3RpoepILAmLr4MiIvNhUov25oRKkQE0UEPXWZKCb66aQtzm9lFoKlESB /v7+QFRXRHXARrWZst33fnBvZDTZI448Ch9lWnUFCqeBHMMUDscLr5W1a9eWZOqpmVLACwVE vV4Mg1eNEPJ6NRxqjBRIV4GwxRc4BQC9ccVXYVBMFxPB0yfOPSl+9wTYm+Gomm69mZY2svpb cDOArTrTLT9QOGqJ2XsCAekUriHdW0Ol1UEBUW8dRrmJPgp5mxBLSaVAORVYv369u3WFG80X fggwLrZJjYioBeddbICccLcw/HCPn+9TZ+42exHIjuaBdAOdApVCMXBwKgQM+idS40tIjHSI yKF9g8t556nVxSsg6i1+DPxpgZDXn7FQS6RApgoAm+bPn98IrYChCOvblDkTxAZrMQy3kb/F syIsupqYmNi8eTN2wQ1XjUrxUz6IOV1abb80dA1oG+lTG1ggCMP2ogsugg7rNm6a8csD0vAA 5r75lFNjdLNaIKACNWR6X6jwyisg6i1siPHon9fb68/x+mOPfeVf/MUbTzrJnyZ9ZeXKwoZH FUuBGigAo293d/eMFllYNMlz4DP3AAvierxhkoV3dnYiiISrKHbEjbQ3I/Exxx6fhbtFC/gL cgXHz6hPkgQwEkOr5PZvt0zsPYEla/jCUIMpqS5KgWwVEPVmq29M6fgfMHf+/FVjY/4cKzZt 8qcx/UuXfri/v7DhUcVSoDYKjI2NLVy4MAm6tZAGG+QGeNd0RbAtd7fkQOE0/cIUmrPnA4Ja wB0ZsBtDqPiqABJtQY2msuBbAVYfYnRqMxPVUSmQuQKi3swlblQB/hOc3t+/ZccOHZEKDI6M iHoLm52quH4KYGnU0qVL04I5GHdBbPhFa0Yh8ZM9UgY20QjQIay/sDTD5zW7OGuIJgHTNSqK B1P41BqGwvg6NDQERxF0timcjUkM0kWBWHEIf7MZpVMCKSAFmlVA1NusYqmlF/XG476oN7Wp poKkQDMKwOUXTyeQaLMEDHIFscF1oQXfU9h9V65cmdDdAjZgrH6jU2wLfgvIAtcFOtSiKDge hPd9CIApugazdMwaMrQfNAxahdU80mu5EenCVRcvfN+At4nWqDUzT5VWCrSigKi3FdVSySPq FfWmMpFUiBTIVIGxf/qn0T//88GOjgEsRzviCFIaXyBjcB5CxgL40tobDObhGU2/YYKk5zFW 4AU8j8NeyM161sKOC4Nua73bvn07lIl8ZTpkKlwKSIFGCoh6C5sbol5Rb2GTTxVLgeQKYOuv jo6dR29v8kxtpqTpFz7BaXkONFsOjNaA3RaM1m12XNmlgBTIVAFRb6byxhUu6hX1Fjb5VLEU SKjA+PiOWbN2US/Oi3jRcwCm5Xjf3yRc+z9e+pKYZPCvQKgEeBrARltER1WnFJACmSsg6s1c 4kYViHpFvYVNPlUsBRIq0Ne3C3kXL06YI9Nk8H+ACRZLygDBSTDXTfNHf/I/upf24S8vwmsZ hQBzuXRMPrWZDpwKlwKeKCDqLWwgRL2i3sImnyqWAkkUWL9+F/LC3Ds1lSRH/mkQSAHGYBho Aa94EYjxYiQE93XB8qXHrFr0N9/+ovwW8h8m1SgFPFFA1FvYQIh6Rb2FTT5VLAWSKNDTs4t6 h4eTJPc8zbK7vwbqxbHlqa2eN1XNkwJSICMFRL0ZCTtzsaJeUe/Ms0QppEBRCoB0uYitq2tH +f1cX/iv/zzhlo+TehesWYa3RemqeqWAFChQAVFvYeKLekW9hU0+VSwF4hWYnt7R2bmLeuHn UP7Xpl/8hMjL44p7bi1/n9QDKSAFmlZA1Nu0ZGllEPWKetOaSypHCqSsQBHRylLuwu7FmXuD ge/9TzyaaY0qXApIAQ8VEPUWNiiiXlFvYZNPFUuBGAUmJgqPVpbu+LjuDUa9p65e8uzzv023 IpUmBaSA5wqIegsbIFGvqLewyaeKpUCMAp5FK2t/rALuDQa+MAC3X7hKkAJSoEQKiHoLGyxR r6i3sMmniqVAIwVGR/2PVtbs6F38/Rtdp173HEDcbGlKLwWkQHkVEPUWNnaiXlFvYZNPFUuB RgpUK1oZevncC89b9IYw+/aODMjPQXeDFKiPAqLewsZa1CvqLWzyqWIpEKnAypVVilbGLm58 7P5Ghl5ehyVY00EKSIGaKCDqLWygRb2i3sImnyqWAmEFEJS3WtHK2MVI94Z33HbpojuvX7Vl 422P3I1NKxS+VzeEFKiJAqLewgZa1CvqLWzyqWIpEFagctHK0EXgLKgXq9YAuDD6fnfrZtp3 P3DHVZoCUkAK1FABUW9hgy7qFfUWNvlUsRQIKDA1VbFoZY1GGBuzEXzlzqubQArUUAFRb2GD LuoV9RY2+VSxFAgoYIZehC2r9Gv5fbeRemH6rXRH1TkpIAUiFBD1FjYtRL2i3sImnyqWAq4C tTH0otNjk+OkXgXr1U0gBWqogKi3sEEX9Yp6C5t8qlgKuArUxtCLTts+bYhZplkgBaRA3RQQ 9RY24qJeUW9hk08VSwFToE6GXnYa0Rto7kX0Bk0EKSAFaqWAqLew4Y6n3guvuebTK1aQC3GC tz/atg3n+IvzdVu34vyup5/GOY5VY2NMiU9Xb9kSoEk3AVIyC0uwt7zoVnrl6tV8i1qsXkvG j9gYawOr5kVrEq7csGED2+9md+uKxN/BkZEP9/cXNjyqWArURAEz9OKkHi9EKyP1funBdfXo sXopBaTALgVEvYVNhXjq7Zk7d/9DDiEO4qSjo4MQjL84B7OCSnGdB66cft55+BQoifMA+CIB ruNTpMGnLBknhFErgScnn3EGUjIN/+IA+KJMZLEamTJwkYWzwTyx9uNtZAmRvHvXc89efM+t 87568eu/dN5b/uFTX/uX7xU2SKpYClRbgfHxXaEbZs3aAaNvPV6T01OKX1aPoVYvpUBQAVFv YXNiRlsvqReAC5rEizwKciWG4i9JF8fZS5bwYjz1Ig1S0hwLDGWBOMijJGN7CybmOaE5kCYy Iwonc1sjrf1g9MgSwtS75qmt80YGAnspXaTNkwqbp6q40gogYkNHx86jNoZeDqfFL3vquWcr PcDqnBSQArspIOotbELEUy8ZEX4CMO6SVgnBNLICIsM23RltvbTdoigUS3+JSHglUiMxYddN g7y4wiOMywa7JHUap63l7FGghAD1/s//+s933n555Pah3936QGFDpYqlQCUVgKGXyFsnQy9H UvHLKjmj1SkpMKMCot4ZJcoqwYyr2WhkpVEWnErMxUW6+bZAvYBRFEX3BvwFOkdSLy7C0GuO EDhBxrB/Atk34PZgBmNzcjCvicgSAtR76xOPRiIvLr71G0uwu9IdP7sHC1B4PPLM41mNjcqV AnVQoK6GXoytxS+7ZNNX6jDU6qMUkAJUQNRb2EyYkXqBm0RPGk2Jj3TqpXevGWJhuOXqtHgP B6bBAYZ2/YbDvgcsGUZfeg+bC69BbcAADEo2unWdLnCdFuuwYTjs24Ar1/5hlUkU+36sERDz ev93rsXSbB4w5GDBynMvPF/Y6KpiKeC5AjU29GJk3PhlOPd8rNQ8KSAF0lJA1JuWkk2XMyP1 0k2WmAsiBKfSsEoedf16CbtIFkO9RFuLC0FvhEhbL5e4GVLTajujXy8Bl37D1kKufmtkUQ6D 7y1/CCAfD7gJPwX7zjgq8OpDMhwwJG/6xU9gQtY+pTOKpgRVUKDGhl4On8Uvg923CgOqPkgB KZBAAVFvApGySTIj9dKrwaiRRGtL0MjEtAfjxI3hwIs8gML0lDButixGqAGiJVITdukOAaI1 /wQrGTUGMjJGhMUscxtmtl4Wy8NW4xn+/vPzv33DLR+PhNo3fO2CwPVTV//NeRs//4E7rmoE wTD3zjh0V9xza2T299x+OW3GouEZNVSC8ilQb0MvxwvfchXJoXxTVy2WAu0pIOptT782cs9I vfRYMOssQzS4cXBxDnIFO5qHbjj+biB6LkpDeuSyLKglHGGXdYGwrcbIaLvhjEgfaIy5VSSM 1xvp5HDSyCehNDwW7n/iUXgyGKeeunoJrriDYF6/W599IsngbHzs/oSWYyYL03CSWpRGCvil QG9vPUM3uKMAxwY8QHhfy9zr1/xUa6RAZgqIejOTdqaCk1BvpPNr5S9ePT7qBi9bsOZvn972 rCvnyPjoCY5JGPbadlx44eQAVkaZMOte/P0bYeJ1C5+RiZF+pqHW51LAJwXWr9+FvJ2dO6an fWpZ3m2x7Sq0pi1v6VWfFChIAVFvQcLv2CHqjcF3hDC76O9vfNvHPvDov/8ycoQQZz5g9E1o 3E0+3ogREaDhSAIGIidZDcPS2qHz5C1XSikQp0BPzy7qHR6uuVCuuTf1B0jNtVX3pYCfCoh6 CxsXUW+80TrJjsSu0Rc/VuazEI1OFDAM44CJCN6BM84hIK8RM8LjIxfyauXcjLopQfoKmEcv DL3bt6dfftlKvP6B23lvytxbtqFTe6VAKwqIeltRLZU8ot72qRcDAaOvbbME628Ss2sqw9dU IRYcNGwtBqzDrQIQDAflfKi9qZYrcdUUsNANg4NV61pL/cFNZx5NugFbklCZpECZFBD1FjZa ot5UqBfjh58m7f/Wsru/VtiIxlaMZXNoGxbDxTsK944MwFEYEAxQ1l6pfg5liVul0A1Rg2fm XpyUeHDVdCkgBRIoIOpNIFI2SUS9aVEvxsc1pnq+HBvWaLoLYxFeTNg1wjFoHhD8pQfXwaSd zTRUqXVSYPFihW4IjzduLrvdZO6t0/2gvtZRAVFvYaMu6k2RejGK4Ej+68KuxYUNaksVA4Kx lhwQ7K7PC5iEE66Za6l+ZaqHAlNTO2bN2kW9ONfLUQBOvbzj8DOLhJECUqDCCoh6CxtcUW+6 1EuLL5DXT9fe5PMMS9/QC2yQYXtH4Z8x3H8V/yG5hkoZocDAwC7khWuvXrsrAC8pUi9utLI/ QDS2UkAKxCgg6i1seoh6U6fewsYyy4rx/xjG4IQeDow6DG5u1KItW7YcEnpl2fwZyl69evXW rVsLbEBdqka4htmzd1EvvHv1CilgXzKT7Oko/aSAFCipAqLewgZO1CvqTXfyWch9OgTjR1tc CeDytm3brvn9i+jL83Sbkby0FStWYAtrgHjyLErZogIIzdvRsfOQobeBgrY2AObeFkVWNikg BbxXQNRb2BCJekW96U4+mIQjd5XDf3E4DSOIhLtSB8g7d+5cNgDWVpwvWbIEf3G+YcMGnOB1 xhln4C0/hVGWF/Eps+BT98p5f3jhopG0JcOHrIupkBd/kRLUy0rTlUKl7aYADL2IzkvqxcZs ejVQwFaX4maRSFJAClRSAVFvYcMq6hX1pj75YNmFfRcBgBvFR1vx4C7ocakX1lbSJ8AXxmB8 BCQF3fLEPgX40kKMZgNbcYKPCK/IRYSl8ZgnTz/9NNIgJc7Jx8jIZKgIhl58xHNkT10KFfii AiMju5AXu7Lp1VgBM/cigKCCOWimSIFKKiDqLWxYRb2i3kwnH7a9QMizQHC0K8ZuZaVh6h0b G+NHYFCc0wsCkErq5ae8SOolKJNuibNmPOa5JcanyE5nBjcZ+VgeDplOg52F2xbERRt6R0dH Fy1eNK933pE9R+4xaw+c4BgeHp6YmMhchGQVmHevtmpLJphSSYGSKSDqLWzARL2i3nwmH4I/ YNtkODlgE7sY6iV9moEWtlgSKqmXn7ogywS0/iJXPPVaIaLefAb9xVpAuvRtgJNDca+1a9fu 07nPvPnzlq1ctmps1ZrxNQ9sfwAnOD448MGDug966/y3+sC++LXE3ISSbDZenKKqWQpIgVYU EPW2oloqeUS9ot5UJlJThfz6+f/N9GFbL7mWeAr3Bro6NKJe2HrhmYD0SGlGXKSHTZdhIuD5 QPsu4BjJ8JZGYpd6uZoNjhNNdUGJm1Ogt3cX9WJBWxGvqamp4+Yc9/aFb980tWkL5leD46bR m8C+fzf4d0W0cbc6LfK3wgUWPhZqgBRIXQFRb+qSJi1Q1CvqTTpXMkhHj1sWTE41TwNacPGX 69XcT83Waz6+BFziLHO5PG3BInCRy+BQptWLRWw0FcvJIYMR/n2RtgUxDL1Y05b7a3x8/PCe w0c2j8TwrvvR4sHFC/oWbC+iqaYN4vWaXxB+IcldM1UoBaRAhgqIejMUN75oUa+ot7DJl0HF rhE3g+JVZEsKIE4Z3RsGB1vK31amycnJ1895/cbJjQmRl8muGLnizIVntlVx25lt0wqsCoV/ fNvlqQApIAV8UUDUW9hIiHrzoV7808K/rvfcfrkWZWc610W9mcrbSuG2BTE2Is59C2LYa+f2 zk1u5XXJ+OyBs68fvr6VLqeXBytBGQgF3vDarS09XVWSFChYAVFvYQMg6s2HerFXGf97Xf/A 7YUNdg0qZmTfGnS0PF0cGtpl6O3vz7/R1wxd85GlH2nKymuJsdBt36594RCcf7OtRpAuvirr 0VHgEKhqKZCFAqLeLFRNVKaoNx/qtR8rsTQ74b6+icZPiaSA5wp0de2i3s2bc24pgBXYCnht jXqR67r118HBN+dmB6rDti8W9zpml+9iG6napYAUaEoBUW9TcqWZWNSbD/VizJbd/TX+91p+ 321pDqHKkgLeKjA6WuDOFAjBi3hkMch75eor9z9k/3gm3nP2ntPT08UKjCcGHx1Y31YfPwfI fsqp80+Y16tDCrSmwEcXLS72zo2pXdRb2NCIenOjXnj08l8XzL31+dfV8szmvmsWtgzlWCgG lmkBHBjeIfCyi/T0tb2IW26PMraigK1jKyJgGfaeQCDeRlBL5J2Rek/vPx0PyVb6nl4exLpG /DI+PeArlV7BXpeEZYiv2LvzklVjOqRACwp8dPna1+zf5e0UF/UWNjSi3tyoF2Nsm/RufOz+ woa8DBUTecG1RFtut8ZN1GyvCgbf5VtuQUzw5Tkj/nIjYsT0xbnAN++Rd9exFWEu3Tk3GsTl vfCaC8G7PXN7ZqRe7GeBjdzyli5Un21TjO/McJcqvD05NADU27lvF7616JACLSiwfOOkqDeH +7R8VYh686RebLNEgw12HC3fXMmxxQy4y02GuS+x2XrxEXemYKxfdzNhN0YvqZcZ8VJshxxH 7w9VFbqODU69e3fu3Yh6121dd9fTd5F94z0csG8FNmwrQL1QleYi1f+da+vwY5GotwXUUxZT QNTrw1PLxzaIevOkXvyvsl8qtaYt5n7AXhLmsQAbLfGX1lwgLxCWWxZzWzXbXSJMvUhMSzDt vj7egRVuU3f3LqfesbFAL3t6emi2z/Q1+y9mxxNtEuqFjwQ8JXwYJbhI9Y4M1GdtgKhXCNuO AqJeH55aPrZB1Jsn9WIGIHIZ/28hEqePE8KbNoFrQas0+uJl1EsgBu9yN7V46jV0FvLmPbAg Xe5MAfYt4hVv6yUNJ6Fef2y9UNF+LMID5LZH7i5C1/zqTEi9f7t6y5Xrthoe4S2ORm8/f9fT H/j0ir4Lr4GfaICoUEjkRyzwph9tC5TJSvGXCdyDHwUutgBwKAFNxeH2KFyyNQ+NDDfVxAk0 FVK4TQr3wroc+CiQMSCLJQ73Fw2I7A5TxgxNYIgTKinqze9eLVdNa9eu3buz8/jeXo+OU072 pzEHdncvWpzmOlALYQajb7mmSp6thX0XXMsagbnmvAuK3bZtG2263KY4oYdDno1XXTsVWLhw F/UWsY6NQxDj15ucegdHBj/c/2F/xtT2raj8hm0JqXef/Q/BQRL6yJWr+euBYSI+OrhnLj89 9ewleGs/L9h1fsTrTICPyHYoh9dfd/IZgSqYHX/Dv1fwI7culozmJSQ2JEONzMVyrAHWJLde 0CSy4K+bkm2wbgaaio/Qa7YnpszwR8j4xtPPC3ckvr+B2vHW/a6CAt3sOL/whg1u29zBSqih qNefp5Z3LYHfpD+vv/n2F79052p/2oOWpB63COGHaO7VLqONbgaaeMG74FqubKPpl0ZffIqH uy1Zi/FwML9e7+66ajeo0P3YTNrj5hwXvytbElvvmYvPXLlypVfDdcmmr1g0mAqvbEtIveAh QBIhFfBEFiQFktjIdrDjEmdpjGRK0hvykg7JYe5HxnwG1sZn5DAzoBJPWTjLYZm8Qh61Qmbk NuI76kLbcBAZCc3WKdcES7ssa8ELnWUVAeq1FqIoUibhMqbMwEdIz4wus7p1RfaXBI/uuJ8a yLLZeAsDPBKwbTambICo16tHkBqTmgJcp1z53cvu+Nk9/KeF/16paVetggCy5tvAYA7on1Ev vHXp3sDwZC71micDPxL1FjMvYN+lewMsvsW9Lh+8/GODH2t5iwpmxD4XwK/iOhFRM5YHYEGb 7VRc1U3OE1IvmYkeC4Q8Q73ARwZSpDRAGDkSAOfad4mPLg4SOmk/RiFgOJcmjfkCUBtIw4bN yLtMQEY3kyp9A8xxwrA+UJpRLyoiB4ep17JAMaNJkiW/KgSO8EeuGm7iRv2lvIG+86uFjVpg aNh9fl0R9Xr18FFj0lQARgsE5WEk9jTL9a8sRN9kT/G3qv+x0lKd69jyf2E2YuUQNoNFjLk6 rJdPWeHG69hSrii2uGrszRbZRTw3FqxZRvCtakiHhNRLegMhka6AbqRSAJMLmmFOdYnN3AmQ hUXxUyIX7bvkTlbRLPWa/TIh9RJYCYtoEijQvGnZJF63gw0m9bq26hjqZRUUKqZMfgR96JLL vkfiu1uX21/arc2bwsV6lGaGdlcZ+x4i6s3zgam6clUAIGgPcTzHn3ru2Vyrz70yC0JU+SUp uUubToXYC8C2gQX+4veHys/JdIRDKbaODXsRF/36xMAnlgwvadnc+9qe146Pjxfdiej6EQTG QjrgeeJnI9tpVULqNYsmDYSgNJ6Aho3DktgLjefoJOC6ExjmWhUJqZd4Sn61Ml284/ozHgEg Bg663q4oxLX1slg7mJ3Ui3OaY10FAt8BAvZpo95wme5H7AUIOOze4GJ6oL9sVcCQbCbkRkPT 1NhFfpeQX287d5/yZq4A4tcaZOCk8ps4wKPXthjNXFxV0LwCYFwYet05SY8UuWLPrGV//y73 BsTrLfoFp/wjeo7YOLmxBfAFLl88cHHRPYir3x4jmJwj46M+N7WFtiWnXtp0zcRLS6Fr8nTt mkZILmiaJZWRBOwXeYMzAqgZjxNSLy3EPCJJ0fVJCKCbG3uBfeGCthhvBKNe2r+JsO5qtoCN NmDrjfdwIIVT2EjKZGnh/rIxgVwuCoeNxy4KJ/nGIupt4f5SliIVsGBeBhlX3HNrkQ3KpW6z bT/yzOO5VKhKmlYAVGHb6dnkxMDBMxu/TjRdXB0ybN++Y/bsXdSLNW0evCYmJv6656/Hpsea Al8ELPMkTG+8hLZIAPMTcc080Du1JiSnXovAYIEOzMJqYRPM/GmuC0aEwFzimsFTGActOgSr SEi9M67BAhEaJoY9Liy8musGkIR6UZRp0oh64bichKQD1VHGSD4Oa8IesfE43JBnLIdkz3ML 2oArxGuuyRP1pnZHqSBPFHAjULpg4UnzsmuG/Ya+/L7bsqtFJbevAOy++GJmvyZzluItBk5b jQTlNfeG3t72lU+rhO+Pfv91c153x8QdCcH3spWXze2dm3rwlrS6EyjHrAZYJ1Clr9DJqZfW ROMkwyaXtMz8CRykx4K5HBDL8JYfRRpWLQ1RLC3qjTRS4iKR1EynLmuGHW3RZrbKbL3mwIBC AtRLyKbpOuA14TrvWpkB6gWnhhHWqmtE+URwZKTC7I5Zf62zuEK3bLfZ5mJhXw9w4oZPbqSh PBwyeuCo2LYUsBVsgZ+S6+DaC5YyfmpLRGXORQGsaYNdLez2AGMwYo/k0oQyVILg1ozeUFyY 3kiZYPGFqwNCOjyw/YEY9gUZz5s/7/zF52+H0bo8L4tlhijglXFAT069Zk00rwCupgpAGOiK LgoGlAZMYGL3Izc4rpmBmcCiklmagI+sazAOpGnEZ5HXaYEmzZMXXSs10dMOVkSaN88NRhmz NtADxM1itmRkCRRoGfmRa9xlLeGuRV60rrlu0253mCAwNG7hkW0Lu0GHNRT1lucBVpuWusuQ w9RbeddejLN5M295amtthr30HcVg2WJE99cJOFbK7WFHZ+cu6vUs2hemHUAWscwQiez0/tOv W3+d6+yLsL7LVi4D7x7SfcjoaPkcZPGVzKKA46QaUUeSU29TNAlEjnSx5W/xSXCqqeraTMx4 wG0W4k/2GPGN6dNqrai39P9rK9YBPJcDK9gC4FsH115wEntdvZUoFZuu4e7AooZdsmBac+ct fmLGvK2v24O5N8yZ4+0EQDgzbMO+oG/B/l3705CGF/azWLR4URl513TGhLSlAvj9oQLgmxH1 pgVVKsdzBUS93j6Ea9owrBOyQOthQy+u4AleeWnwj4reoopfVtKxBlvgRwkzs9lMrti6oqSj Y+4NHkRvSNrmCqVzHcYqAL6iXs+x0vPmiXor9GyrVlfwezEsnW/8+4tq6NqLkYRdsEoLUDKd m3DN9G1vWOsvBhFW3loFIYkYawTopVOvf+4Nmc5MfwqHizl3wMFRdvAV9XqOlZ43T9Trz3NJ LQkqYOu6+tZ+Bk9tBDeA8wOe3XVw7dVsSK4AfpjuRyxYj19wVYfZHhO4MiuKmhB78+ZdyNvT 00QuJU1bAfyMZuCLXyHK62su6vUcKz1vnqg37UeLyktPAZAujRMBX97yPq/T00YlvaiA/9Rb 69FaunQX9Q4O1loHDzpfDfAV9XqOlZ43T9TrwaNITWiggMWbRGQoiSQFGikg6vV6bph7w8SE 1+2sR+PgOWYRpmHxxa8Qpeu3qNdzrPS8eaLe0t3yNWqwLWvDaowadVtdbVIBUW+TguWYfHx8 l6G3uzvHWlVVnAJ4nBr4YnFw6bxuRL2eY6XnzRP16vnoqQJYBU8vNDygPW2imuWHAlWiXi59 gxGuIjtcwKuB69jk3uDHzcJWlBp8Rb2eY6XnzRP1+vQoUlscBbD4nU69WMEmYaRAjAJVol53 j7cqsC9MvKRerGnTyycFECXG4vgivHSJfk8T9XqOlZ43T9Tr03NIbXEUwJp3Ui9WvksYKVAT 6gV8GItw/sPPp6xb9CFOGZEXrr16+aeAu4EFflIrC/iKej3HSs+bJ+r171GkFv1eAdtBviI/ 9WpYM1OgSrZeioTYfAH2xS8e5WPfkZFd1Ot3XLnMJmYJCg6AbylihIt6PcdKz5sn6i3Bg6me TbT/+opTVs8JkLzX1aNe9h2hSwI7G5eMfQG7tPUCf/XyVQGEcbBNBLGUAtHNfG3prnaJej3H Ss+bJ+r1/AavafNsfwq4OdZUAnU7sQJVpV4IgDWdcPUpK/tiWwptyZZ4GheYEJaFEoGvqNdz rPS8eaLeAh81qrqhAo32p6inZFADmzMDgOrZ/Rl7XWHqZd8bsa/Xv0dPT8upd8ap60+CAPj6 HCJd1Os5VnrePFGvP48dteRFBbQ/hWmB3x+5qulLD67TFIlUoPLUG8O+cH/3dBHS+vVy6i3X DYsvVxd//0Y+bXAsv+82P79pi3o9x0rPmyfqLddzqS6t1f4UYerFT5B1Gf4m+1kT6qUqsMkh qontMkBA8ZF9Bwbk1NvkRC4+OTDXlhEzbrSHe1iIej3HSs+bJ+ot/kGjFgQU0P4UAUG0sC/+ HqkV9cawLzyAPXqYmFMvtmfTq1QK4GuVWXzx/cq34CGiXs+x0vPmiXpL9TSqR2PxkNX+FO5Q m/XFt38/nszHGlJvJPt6tJ+LOfXOnu3JJFEzmlIAkRzc3xO8+kIl6vUcKz1vnqi3qUeBEueh gPanCKgsQWTrjVGAPg9+BTUbHd3l3tDXl8cjQ3VkoAB8GyywA71oPAkiKer1HCs9b56oN4On hYpsTwEzbfofObK9jibNbcZvKJM0T53S1dbW6+8gDw7uot7hYX8bqZbNpACczZbd/TXzdkAc SexjPFOmzD8X9XqOlZ43T9Sb+S2qCppVwKKTemJaaLb9qaeXo7NsvalPqmwL7O3dRb1y6s1W 6DxKt9+agL9weyh8s0xRr+dY6XnzRL15PDVUR3IFbH8KhSxwRbOfGj1cUp18cDNKKVtvRsK2 WOz27TtmzdpJvXLqbVFB77Lh5yZ3q5RioyiKej3HSs+bJ+r17vlS8wZt+sVP+IPaFffcWnMp 3O5bAOONj90vWQIKiHr9mhKw73JLtvnz/WqYWtOGAggcbgEl8XyGH3lRv8WJej3HSs+bJ+pt 4zGgrBkoILyLFBWwyy8D0CcD1ctdpKg3yfiBUeCXySmULa/Y/hSLFydpmNKURQG4WmHrCnPz RUTFQnZIEfV6jpWeN0/UW5YHTl3aaT/lF/I89VZlOX7EDI2oN8m8xfbFxiv4tTrDHw2GhrSU LcmIlDQNNis+4ZaPcy7hJMOJ1EAgUa/nWOl580S9JX3yVLPZWrYVM64WPtPPbUILnJGi3oTi u4Y6IAt+sM7ku2V//y7qhdFXryoqgG9QrptvznsXi3o9x0rPmyfqreIzqbR9shBd2A6+tJ3I quHaq6KRsqLe5HMOvOIGYc3E4WHOnF3UOzGRvGFKWS4F4CQD1143qBmmVj5d8J96v7Bp6ui5 bzv8uDfpgAKH9ZxwaM8b/UFhUW8+96lqSaSAtmOI+x1/fJT/Y7zaJynRuGacSNTbrMCYQu7O Wyk7PHR27qLeZpul9GVTwJZh8NGE2A45/BLlP/UuWDT44XPPX7dxkw4o8P4PfOhVf/maS1aN eQK+ot6yPWYq3V7tTxEzvNqrQrbeFO9+LMlHmBSz1aXm8GB7EXd3p9haFeWtAthLyPV2wIrJ rI2+nlPvige2d77mgEce++Uzv9mu41dT0/vtf8AXV3z1uDefLupNchd3JEmkNJVRQPtTxAwl flIko0Clyox4Kh2RrbdlGQEobjiqFBweNm9W2LKWh6OkGfFoCnyDytTo6zn1vv+S4Y987GLx LhW48povLLrgIpwcdvjRn1kz7gP4ytZb0udMBZutMAUzDqr2qoiUSNQ748yJT4BV+ak5PKxd u4t6BwbabJWyl0uB3Iy+nlPvvgd2//jBh0W9VODgQw6jGp+7/qY3v3exqHfGm1q23hklqk6C h56aWHTndThuffiu6vQq1Z7YGnzs5ZFqweUuTNTb/vjBXJdOhIelSxW2rP3hKGkJ+Rh9fabe C65b/5b57xLyUoGR1d96+zsX8ByuDn+57wFY51c4+MrWW9LHi5pdRwW0V4VsvZnO+2YdHuAc vMP2pMBmbL29O/bZZxf1HnXUzrc4wMErV2babBXulQJho2+6AfJ8pl6ELMD6LVEvFThx7kmu Gpd8+jKs8xP1xt+tsvV69TSLa8wZZ5xx3nnnuSmuueaaQw45pFEefOp+tGXLFiTGCye4/vTT T/NtIBmzMDH+2klpZGqvofjnQddeuDq0V1KlcsvWm+5w4suVuz4J51hJGa4CF3fNw66uXaTL jYjDhwL3pjtC3pcWMPpiM4uR8dG0Wu0t9cKQ+cq9O4W8VADr+fbZ51WuGnB1gPuHqFfUm9aj oOBygKFz5851GzE2NhbJrEgDRA4AMfi14/cvZlm9erX7NtC3bdu2IRn+MhdBuSYv+l9iL9Ca 9DdJN0W9SVRqKg2oxQ1KFY6fjQBVmISYivAJ3jE8HEe9PT1NVa3ElVEgYPTFusnJ6an2e+ct 9Z4zOPLehWeLeqnAjSu++v6zgmp0HXTYZ++YKBZ85eHQ/j2oEnYqEKbeFStWgG7x0datW3EC JsZrw4YNeIvEoFV+yhf5lcnwFmZjnJitF4zL7DQnowSc428NqRd2ONDGTtTQ6w8KiHozmgv4 bYERHsK7zpoTMCzBL/y/z+2wGL1hQ+9oaka+jLqpYrNTIAujr7fU2zP3bWu+vUHUSwXefMqp YTV8cHIQ9WZ3v9er5DD1mocDLbsgVLIsbLRh7wXyK7MwwZIlS0i9sBnjBAyNF9LADGywW0Pq rdesStZbUW8ynVJLZaGj6W8Dq/COwcFoc29fX2q1qqDSKpCu0ddP6kWY3pfvORtrtkS9XLu2 1157hdW4+94HD+w+WrbemFtZfr2lec7FUy9oFbwLhIXDLrpEO67bN/IrARdci788p8MDcuEi OJhkLOotzbTIpaGi3lxk3lWJ+TbYDhfw2nxi6093zJoVAb7j43m2TXV5q0CKRl8/qfejy9ee 1vc+IS8VuPmWb/S9+8xINRDJAdbWAsFXtl5vnxIla1gM9aInMNOSdPECwjaiXuAsPRnIxKRe OEXgBHZi0rCot2QzI/vminqz1/jFGrABgbujG8+xq+IOBOgNuDf09+fZMNXlvwLh8A640myz /aTeee/qhyerqJcKwKO3kRofXXzx+z41LOptNO1l6232gVBYelIv4yrgBadb18MBZlq0DPzK xWfm82DNNfMtDbr07iXjmtsDrL+y9RY2wB5XLOrNbXAQ2iyMvLyy5YFNu1EvTL9TKSxdyq1r qigfBcIxfbFWsqlVbn5SL364x8/3ol4qcMSRRzVSA2bgE+YvFPWKevN54GRYC+249gLXGvXS RssXl6PB9Mu3LvXiLdjXdWwg9fIKXlzrBiyubeSyDMevzEWLevMZPfg2vOf2yxtR784oZvDi NXOv9mbLZ1TKWcvY5DhjgNgB73AAcZLeeEi9cOp9yR6zhLy2IcUejdUo3LVXHg5J7jKlkQJS wF8FRL35jE2kb4MLLt//1qpd1IuQDtPT+bRKtZRUAXyJQhDfwFbYSaLTeEi9n1kzftjhR4t6 qQC4FrbeRmpgiRuW/eF7QlHmXlFvSZ8YarYUkAK7FBD15jAVYnwbDHwRxew/583dCb6I4KuX FEigALb3C2yFjR8NIndFscI8pF5F6nUZNzJSr5sA3xDwPUHUG3l/yK83wWNDSaRAvRUQ9eYz /mARHLDPrdqyEcvXFt15vbuFG9l3w7VLdsbu3b49nyaplmooEN4KGxPsqeeejeydh9T71rMG rrzmC7L1UoFFF1wUrwb28sD3BFGvqLcajy/1QgrkrYBv1Iv/ym+c13tCbY7jTpzbM+eEI44/ /tBjXnfIMa/7UM/r69P3QE8/c/lg3rO/QvVt+sVP3O9RiIiH71dwhAh00UPq1f4ULvFH7k/h JgAT43uCqFfUW/qnFxaZYYOJ5N1oKn1TiZO3QSkroIBv1Iv1lwe+tueSVWM6aqUA4jEBgitw QxXYBTAuSBe867rNgIbdJnlIvTkEcBj6/LALjitu/vqyz3zWLj7+5K/xdt3GTW4aXMF1pMGJ eyCZXcT5D/75gXSt1DEBHFgRXCAQ6E3UK+ot8FGTTtUMuZC8rKbSN5U4eRuUsgIKeEi9Rx7f W9QzXfUWpQAQX9SbyvMEzr7wcHAXSmJnbHhBIMgDmPjD377m9Td+pO+bNw6M3lPUWAfqfdVr uh56+LF02TFQ2jtOe5ddecOcE8/6UD9A9sKLBg486OCfTkyCXBHW000DLMYVXCfgMiXZF6SL EpCYb3GCtyk2fr/9D4hXY2T1t4578+lFjZ1Ws6Vyk6qQnQo0C6Yw33KrtiSvphInKbDUaWgR ifz5r9T9aq3xot6i/n+oXlcBUW9r92+jXHAix8o2l31P+vonAoHz3vetr/kwCRGUYOvkMymC Y7gowCtAFtcBsi6kAmfxES+Cay0jWBZvzY6LE/dTJAbvuhidosUXexHHqwHsPvy4NxU1cKLe dO/TapZmu6kxaC46abF4cY4rvMiNKty4vAysixi9vGiBexm11yiZm1YwO7a3YJmBK5aY+7dZ gdYYqwV7YUSWUKWx2frsk4vuvA7Hvb98uEr9aqEvExMTl1566fz58+FX0EL2LLKgJbL1FvUv rcB6Rb1Z3E2IZRZeNOmy77K7C4sGYJMNVtVMkReFw6AL+y5rodX2/ocesUpJvUhAMsaBtzgK od4Z1fjeD+499Og3FHWrinqzuE+rViYZFzwK4sQmEe6+a+gq9xA26gUiYxMKzHswLndcQxb4 +5JT8Sne4sSol2mQGGnwEZg1fMVFZJI30rAWEAaahxO8ReFE58gSqjYq9e4P7LtnLjxzj1l7 HNR9UM+JPUccf8TxvcdjGhzZc+TQ0NBUobuCNaLev129BYc96wNvr1y31f0UyT5y5eq+C6/B 38C/h8/f9bR9hPNAgSgncIXF3vSjbawxcOAjVm2HW2ZT/5kCJbstsXKAhujUBz69wmoJdxyJ URSzB9oWkMiKDfQusupI0cINC+SNbF6kLKLejJ5JcGz4/I+/2Wh7lHfcdm1TszT1xLltUWEO DCRgsC8OojCpFzZUpgH7wgAcT73ISzLmkRa1IxxvzBYVrAX+D/AJSX0gEhYo6s3oPq1UsSBR s7zSc9e19brUa369NM3aPsPGxG5epiGqmoUYb8NXAoiMYqkvSwg3JrIEr4bEumwn1qn82wlK o4G8FK/NmzcDbU/vP3352uUPbH9gyw7MhhePNeNrzl167sHdB18+ePn2guJnNaLeg3vm7rP/ IaQ9/MU5MB0IyIc1P+U5+Iyf8oVzo70Lb9jAj+wvrjCXXeFbq4LFoiIr0C2ZVbsfIf2pZy9J +C/ETea2mQWiZBfB3YqQmEAPAkZKt0Zcx5U3nn5euG3seBhqw7173clnWNVhPU12Enag5aza xgWVNqJtt/ui3uweIPB2aES9J95SWDQAjj4o6i/3PSAtaowpB4Dr2nfNAIzr5vZANwaybzz1 wjUCuXAEymyzIyBa+PXGFyLqjblTFK83u8dIcyXTggsjK62qjagXxlqXR5NQL9LDygtbL10U 6CwRvuJitP2W3Yh6I0torsMZpzZYty40Ff4ixdbBco8xbWoZYoq1N1vU9cPX98zpAdoGYDfw dmx67GODH5vbO3e6iB3CGlEvyYyoR7BzuRDgRUYE0uEcB3AWsMVcho+EY5IuedE+MnQjFLIK FoW3Zg0leuJTMzazTL41QIw0l8ajMLtgFl9WhEa6+Ii3Vgu/A5DOjfiRGMCKjIBI+zJgZYJH 8ZFLtCzctEVKZHSrxlvqwC7bp2ZEt68frIVVGPiyKFFvs7dquum3PvtEI+qd+/VWvqG18KWu UZYvbJp65d6dbcJikuyMvYDDXB3MymvUC5blArUZqdf1601Se8I0jzz2y332eZWot+X5L+pt Wbo0M5JHYQ6k0RfUS+8COzEPB3xKfsWn9IjACa2Y9D0I23rp7Iui6AQM6g1fMbMuTmhaRkvY KuB4GMEjS0hTkZTKooOyFYa+42sDLkINdJA9xUXzdUZP8RYXCam4zrcUBFf4zYSF0HmaL5y7 RTEZLvIvxohDkFK3sirmQ/0fOnvg7HjedT8d2TxyRM8RiHOUVYMalBvj4WBGTXAbGZG0B6iy j0hdrmMD7KDGjgREEiHBN/ARPqUhE+W4VcQYL10zMzMm5LwABxi4uyTKxrjmW/sUH4HFDXON s10IDrSNQrkmZLcuY1NWx6rJ0K6e/F7BQvjNwTXu4mKgAQnVkK03uxsN63cbefd+aN1tKSJs a0VhhiSEwhaSuXhKnKVjA0gXngww6P7Dbd826oXhFp/Suze5X28LrYrJMqMaP37w4X0P7G5N 6vZzycMhu/u0UiUTm/Ayay55C2/xEQGLvMXr4E5iGc4N2piMyMX0JC0wnBEeozqEr1hiJDDU o9HXCiTesZZwCR6OR4B66e0ADW0VIL9m2OI/fqmgxZ3IiytIzNGBtZguznhL7qfOrAUfud8T mIwmZ5wjpT+rwSJHClbeppCX+AvwhcU3Z1eHmNVsBls8IXKZQde1bjZ6uNtP+SgBrGb4S1Yj I5LncALgC1AjracBjHPToEDaPluz9ZK5ebAitpDNdlvrdtBlYp6bwwPbZmWSyF3/hDD1ouUk XX4fCBiSmd4ussBAw5idDC1brydPzo2P3R829/beuuyLm3/bPgm1WcJL9pgFf9Z02dFKc6nX rLy0+MKyyxi9jMvLLJYeV3CdFxnQ18rER4Hgvik2Hn698WoohkPMPSVbrycPHDUjEwXC1Gtf KoCwXKhnNnICMdphFnTiL02/9m3BjMdcNcjEMT4hTOC5hwPaj8Vqya28bsorRq44u//sTMav SVsvEYq+BEQ38BlPaPoNAFmj/8TgQpaDvK6dkrxLEy+rAPYlpF4kJggGymyKBpjdCkHV5nPs cmRkmYahTGnMTei0Ms2SHSiEVO12wXX8MG0tl8kSCbUsTdSb512TpK6xyXHX4nvamuuX3/dE U1M0o8Q5xOtNkUqzLmrGeL1rvr0Bu9llNBYzFitbb5J7TWmkQCYKhKmX9MnVeDRv0wqOi7TX utRLOzcLCTt7kJhdJxMrxPUJKQX1YvnajL68MUz82p7Xjo+PZzKEUYXG2HphwiSnGlSZgdbI jEDmBlIImF3pFYDDVrYxAYuirdTYMSH1uvbUSIssgTJwBLxdzcwccDg2W6/rZoBeuH1kg9kj 14HB2s+PCPThf2zkVMhLq7BbUVhP19bLEQkEynBRWLbe3G6chBVtGv/xAW98vSe8y6mI3+vx q33WNFmW8g8+5LB4NbQ3m2y9CW92JauaAo2olyQK9wZGfGtEvXQpgShIifTIRXcFoDAyurhs viW0+7rUy9VsjC7np77r168/pe+UeEPvp1d8GkejNNetv25B34LcehdDvbayyhiXtOeabMlh 7o/4pD1gIh1S3bVcYYAOhG5ITr3xNpJwyLMwfbrAyl5YU9nxQMuR3ozBTEDENE9ls44b5dOg a9xvbXats4GOUCI3RgShnI3hlwSXsxnSwf0SYl9R4iWSX28+t5iHOxJjz4XsHAbKArvWzhPn nhSvxueuv+nN7108o1E2owSy9eZzn6qWoAKT01OrttyJ454a77NAx1yTxqy5uEIg5hK0MPXS iGu7fpjvL3HW9vjgOkILPGflu9RLA7BbtW+TFcAKbI2hXjiOgkt65vbEpNlz9p65xXOI36WC P9Yb/1kwBzM3AumYBrhm3rGBkAL8iGRpfGbQ6VaRFvUm+Q8UNtO6ZlTyPf6i5STRwKI0Njtg 5w60PxBgIQn12tcAt2rUEnCiQEWUlM2w4SCImxWZwYYj1RD15vPo8JB6T5i/8OZbvlE6PM2o wX3vPjNejY8uvvh9nxpO8kjJIo2oN5/7VLUEFbj+gdu5NAFb70idtBQI4GxaxRZYDhaiAVjD cXldwAXvzki9iO+LjS3y6Ug89RLjjJwsblfApYGevqRAN8IAkrkfoTSzuZoZmK69rML1GOa/ EF5xLbXhNK39swnYobkwzqAcZbJh7BQqDXhu8NNAVLJA2/iVINB+elCEL1ovuL7NqnZFYxq3 YUjmOjwwo3uE46axEFFvPveXh9QLhgPJZQSRpSv2ymu+sOiCi2KaPe/kUz9x02hrD5n2c4l6 87lPVUtQAdtgHYEYpU5aClSPevEfbt+ufWOMuGcvOfvkM04G+MbbehcNLhocHExL5/hyUtyR OCZMLD5qeRO19v9ztFNCkti37ZQfkze+asBxO5KKevO5vzykXjAcSK50eJpRg7FY7c2nxKnx 8j1nD49NZ3SPz1isqDef+1S17KYAgi/S0Ns7MiBpUlQAvrkF7vGWYkesqPjoDTdsuGH/Q/a/ 6+m7ZqTewZHBD/d/OIsWhstMkXpnfIIrgT8KiHrzub88pF4wHEguI4gsXbFbJ5/Za6+9GjUb 21j8+d6dBd62ot587lPVspsCtr3kJZu+ImmkQIwC8dQL5AXvXnjNhTjB8fvIsLttUGxvRb0F /pupSdWi3nweZR5SL2Y4SA48VzpCzajB2J6tkRrFhi3DSIl687lPVctuCqzaspG2XpxIGlcB xCyDsZb7evCFt43Mt9z9zk3MLCykGkZfRBxD3LFGLEvYxcEwCMDfRik/NfypTw58Mp/JJltv TTA30E1Rbz73l5/UiwC04LmMILJ0xcLDoZEal11+1dv7lxb4iBD15nOfqpbdFLj4+zeSemH0 lTSmAPdOwwsAx7gNDGGGF6/bRnf4iFtUMDH3YOOLm1NYIWRfi91bOrWnpqb27tx7xv0pZvRw +ODAB4eHh/Ppvqi3wH9pBVYt6s3n/vKTet998dDHP/k3pcPTjBoMtL14YElk4cUuZZOtN5+b VLUEFYA7L5D3hFs+DgdfqUMFCLjcohl/ec6L3KOYAchsM2ecc9tnXiclM14v0sPcy+2gbfcK XC+p9fe4OcdhY+F24vUi70HdB01MTOQz2US9BaJngVWLevO5v/yk3s/eMdF10GEZQWTpisUu FdirItxsuPy+Yu/OFQ9sL/A+la03n/tUtbyoAII20NCLMA7SxRTgbhEw95JN8ZdL03DRtgvm xhPcuc32LjbYRQmGvywW+EV6Jg2XlHovH7z8Y4Mfm9HcG5Ng4+TG/bv2z22yiXoL/JdWYNWi 3nxuMT+pFxNPO7S5mBu5Q1uxu7Lx4SDqzec+VS0vKnDbI3eTehGyV7q4CtA5gX4L3E2N1Av7 LrCVLg20++KEhl7XTozrltE+4vYTpaZeODkgeFl8yN54Jn7f4vd9ZWV+6yZFvQWiZ4FVi3rz eZ57S70LFg1e8unLSmeXzajBSy69DEeg8MLdG0S9+dykqmU3BZbd/TVS79jkuKQJKAA7LnAW yGt2X0Iwrbw0+rq+EK5Nl9Tr+vji0wpQL3pxw/ANHxr4UGvm3jXja47sOTLPmSbqLRA9C6xa 1JvPXeYt9V46svmo178hI4gsXbHf+8G9xxx7vNtsH9wbRL353KSqZTcFFqxZRup97oXnJY0p AD8EECq8GniFmBvwcHAtuC7dchkciJl7EVsh9A8GRpfa1stez+udFxOYrBEQw0L81z1/nZtH r30JOfL43gLxS1UXooCoN5/nubfUi1n3qtd0PfTwY6Uj1IwavN/+B7hq+ODeIOrN5yZVLS8q 8NRzzxJ533P75dLFVYA+uDTo0taLk0bUS4ql5wMT083XLQRXLBaErXKjtwNeRsZlGYXp6ekj eo6A4Ta5xRfIO2/+vHXr1+XcR9l6C4HOwisV9eZzo/lMvYrk4AJ0IJIDDOEwhxd+n8qvN5/7 VLXsUmDjY/eTeq+451aJElAA0RgYdcGcGRiHgYEdAi9YcC2xmwDIRYsvPrUVb0hA47G9wlF+ /R8O/Lc7ds6xf7vyb5OA7x0Td7xuzuvWrF2Tf79EvYX/YyukAaLefO41n6n3C5um/nLfA341 NZ2R9bRcxWKjCph7qcbd9z54YPfRhdyYgUpFvfncp6pllwKAXVIv8FeiSIFmFdi+ffuixYuw b8VNozc1Yl9EbMDytUO6D8EOF82Wn0p6Ua8P/9vyb4OoN5XbZ8ZCfKZezLq3fXDgs9d8oVx4 ml1rF11w0ZW/V+Mt8991wXXr878rwzWKeme8xZQgTQUQrYzUC1eHNMtVWXVSADj71vlv3XP2 nqf3n75ocNGylcuuW38dTs5dei7i8iJIWZ4RG8LCi3p9+N+WfxtEvfk8hDynXkAVzL3ZcWS5 SoZfL7174fGc/y0ZWaOoN5/7VLXsVADL14i8p67e6YSqlxRoRwF4+o6MjAwODsL6u6BvAU6G hoZyXrgW2X5Rryf/3nJuhqi3nds5eV7PqRez7rg3nz6y+lvlwtPsWvv2dy445W3vfP8lwznf j42qE/Umv9eUsl0FEKqM1HvJpvyCp7bbaOWXAk0qIOr15N9bzs0Q9TZ5o7SY3H/q/cya8Vfu 3XnciScVdRx7wtyiqg7Xe/jRr5/10pcVux+b+ygQ9bZ44ylbCwpgWwpSLzaqaCG7skiBUigg 6s0ZNz2pTtSbz+3pP/ViQgJ8MR+KOhav+KeXnv+KroHjewc/fu4X/6GoZli9Q3f+0pObVJHL 8rlJVcsuBcypF5sSSxQpUFUFRL3+/IfLsyWi3nzu6FJQb54TL7KuSzaNdVzRweOVn+86aWTx RzeuHd48XXjDCm+AbL353KeqZccL//WfJ9zycRh6e0cGJIcUqLACot7C/7EV0gBRbz43tag3 4fR+37eGDXzt5MAb55zxzaHP/PN4wkKql0zUm899qlp2bHlqK90bLv7+jZJDClRYAVFv9f5T JumRqDefm1rUm2Q2Mk3PzX1h8OWVl14z+7ivLjxn/cgX7p9KXmAFUop687lPVQvuwI2kXpxI DilQYQVEvRX419hCF0S9+dzUot7kkxMuDXBvaAS+dn2/G3pO+cbAJ74/mrzk8qYU9eZzn6qW HYvuvJ7UC6Ov5JACFVagQOr9wJIbDj/uTTpMgcN6Tnj9yafn8x9a1JvPTS3qbWo+w5nhT66c NSP4IgGSLf/RZFOFlzGxqDef+1S17IA7L5AXrr1w8JUcqSuAqHCbfvGT1ItVgS0oUBT1cjfU dRs36TAFTnvXGft0vhoL6nP49yzqbeFmaSGLqLfZyQw3hiTU+8F/WtlsyWVML+pt4aZTlqYV QNAGGnph8W06szLMpIAFQsbJTGn1eeYKFEW92go1EGn/V1PT2BfqquXXzXtXfw7/nkW9md9a v69A1NvCZD7x7/vjwffQL/W2UGwZs4h687lP614LAvSSehGyt+5aZND/O352D+X90oPrMihe RTanQCHUiyDwr9i7c+vkM9ntsVS6kq+85guLLrgI7AsTOAzhWf+HFvU2d5+0mlrU28JMXvGT 7XDebQS+f3zlHnXwbaBuot5W7zzla0YBbMZGLJMxshnZkqa1+BjL7v5a0jxKl5kChVAvNvz8 yMcuLh2YZtpgGHofevgxVPHZa74AQ3gLrNBUFlFvZrfUbgWLepualpYYXIu4DZHg+z8++yc1 cW8Q9eZzk6qWXU69oN7nXnhecqSuwFPPPcsvFf3fuTb1wlVgswoUQr37Htj94wcfzhQiy1U4 XHtPnHsS2wwT+Mv3nN0aKyTPJept9k5pLb2oN/mcDKS84LvrY/wcEOasDttYyNbb2n2nXE0o YEyGvdmayKakiRXAAkFS74I1yxJnUsKsFMifevEcx4/45aLSrFt7zrnnf+76m6yW4048CVTa Mi4kySjqzeqO2r1cUW+S2dgoDSKUueD7p1fvecDwMe4ubpf+cHM75fufV9Sbz31a61o2Pna/ nHqzngGnrl5CkbOuSOXPqED+1Pvui4c+/sm/yZojy1X+Pvu86pHHfmltho/vW8/K1slB1Dvj rZFKAlFvm2SJhWuGuQjvgNJOWzPoojA2b2uzCp+zi3pTuQ1VSJwCV9xzK4EM+CulMlIAdnSK /Ozzv82oChWbUIH8qffQo9/wvR/cWy4qzbS1UOOYY493q4CD76te05XpP2NRb8IbpM1kot42 pzE2Y9tzqBOYe/hX5ltRl2wa40Ue+Kiqe7aJetu8AZV9ZgXwszuBDK4OM6dWipYUwD7PFBlB 4loqQJlSUyBn6kV0glfu3ZkpRJau8IsHllx2+VWBZncddNhn75hokxhisot6U7uFYgsS9bY/ h8G4WNkW4Fo49QJ2DXwBwZXcrU3Um899Wt9aYHqUy2kOw7/8vtuo8/1PPJpDdaoiRoGcqfeC 69a/Zf67SgemmTb4zaecuubbGwJVvHfh2ecM7vw9N6ND1JvPY0HUm8oEbmTKfd+3ht293Ob/ 49JUqvOnEFFvPvdpHWuBZRfRed/37c8es+pjoLFPbfpyHVXIq8+rtmwk9SJ2b151qp5oBXKm 3jMuGrpoYEmmEFm6wgNOvWx/1q69ot58ngii3qwJEpsYd17XbUbfA2+cU6VovqLefO7T2tWC 39m5BbF7yK83u3lgSwaBv9nVopKTKJAz9Z4wf+HNt3yjdGCaXYOxiA3UGy4fscwOP+5N2RGD qDfJ3dF+GlFvdnPYSsauFu52bnCH+OjGtTnUm0MVot7270GVEFQAgbQspEAAfOV1mtF0gWMD pcbawYyqULEJFciZeg/sPvruex/MDiKt5BU3f93Ol33msz+dmLS3Q58ffvzJXwMrcd09cJEf MSUS4G0gV+oth28DPBzCxWYdtVfUm/AGaTOZqDcHNGQViPDgbmxx0shi0HButWdUkai3zRtQ 2SMUsA1yA8iLt9qROKMZMzk9RbWxrC2jKlRsQgVypt6Ojo7UwTGyQAArsJUfHXjQwe847UVn 4jfMOfEH//wAeBfXA9R71of6jXRxjgSGyzjPouU3rvjq+886O7JkLPvLbmtiUW/CG6TNZKLe jHAwstjP3jMBDwfzdoDnA67k2YDU6xL1tnkD+p59+/btfQtO6Z3Xk+dx4sffGeZdXjn+yg/k 2ZJwXccf033xxRf6PmzNtw+b3lFhbQXSvHgp56gq9d7/0CPAVpd6DWeNenESwE1YiC0XPr3w ogHajEHJ4cSpQPCSSy/DEVkU9vLA/7zU/4+yQFFvyjdSg+JEvRlN4EbFwr6LNW0Gvljrxii/ JT1Evfncp4XVMnzDF/pP/9OxVR15Hn+3qqcR9X5w1dvzbEm4rhOO6tjnL16OLwOFDUlmFZ9w y8chO3xLMqtBBSdSIE/qzXlXNrPvwkwLCDbDbQz1wrJLukV6ZIe1mBAMk7Dr7ZAK77KQGOo9 7PCjP7NmPKP/1qLeRLdH24lEvRlN4PhiEcXMDeh73FcXlnT7YlFv27egxwWA7br2e8XUpo4d W3I9nrr/zxpR79jdXTk3xq1ufE1Hz6EdAx96Gb4MeDxuLTbtPbdfTtlbzK9sKSmQJ/UiAC3C 0KaIjPFFAVjpn0DnBGArOdioF+4W+MgOloZPkQuYSysv8+IiODiLlsO9AU4OkSVnui+xqDel G2iGYkS9hVAvKkWwM3dft1d+vquM2xeLevO5T4upZeXKlYvPfGkhlLl83bww+Pbf1ldIY6zS had2rF3ega8BnfvsWcyQZFnrojuv124gWQqctOw8qRekBZLLgh0jywS20kBrLrmgXlyJsfUi MbwaYOIl+xoiZ+TUi/JFvUlnajnTiXqLol7Wi/2KXW+H0m1fLOot532frNU9R/4VrJtFgeaX Nhx/wlfPM/a94p96X3jofxTVGNQL2O16dcf2B3YK0nfKXuvXr0+mYmlS2c7PjzzzeGkaXcWG 5km9l45sPur1b8iNelERjbvGrABZWna5mi3SVZdeDfYRKBlvzdk39caLeqt4V73YJ1FvsdSL 2mHihaG3pNsXi3or+3wA1YHtCqRMVP3cgy/ZMvZqHM9uLsbk7HZ/4KyO4U/t+g6w09XhyL+q 2Nh/6cF1/I4xNjlesa6Vqzt5Um8+fr1u9DHCq2upxadwbIiM4eDGfIDFl4BLh2A3Dlq64Lvo gouwIYU8HMp11yRvrai3cOpFA+DUC9ded/ti7HLsQ8NmbIOoN/m9VrKUC898B37NL5Z6vaq9 85U7zb3WpO6D9pyYmCjZoMY21wLG3fbI3VXqV+n6kif1Do9Nv3zP2elSY7g0l3pxDmyFWddN 1iher1Evc1kWZLcgvqk3XjEcSnfLNNVgUe+MYJdbAgRzsO2LcfLBf1qZW9UtVyTqbep2K01i rGPr3OfPpsdEvbsU2DzSMefI3dRYeu6soeVXlWZEEzQUJl7aerU9WwK1MkySJ/Xi0Z9bvN7U 8TSjAmHohbk3snBFLstw3udVtKi3ZeDLIiPC97rbF2MniyxqSbFMUW9ed2q+9YyOjs6fN9sr U2uxjVna3zF00W7Uu5ODj+vOd1iyre3Z53/L4GXa+TlboWcqPWfqha0Xu45lRJBlLBb7M/e9 +8zIlr9kj1krHshqcynFcJjpzkjnc1FvigiYSlEI6Ntzc595OyDOg89BzUS96dyHvpWyeNGH Vy6TodfxZ+jqmLgjKEjn3i+dmprybezaaQ82fMbWxO2UoLztK5Az9fbMfRv24C0jnmbUZuzP fMSRR4UL//GDD+97YHcq/+YjCxH1tn/vJClB1JvdHG6nZHcnC6x183YLN1FvkrusfGkQmSv/ ML3FWnNjagfvdndFfAdAWDcEdyvf6KrFfiuQM/W+9ayBRou3MsJKz4v91dT0Xnvthb+BdsIG fML8he38X4/PK+rN574U9WY3h9ss+aMb15qb70uvmY2NLdosMIvsot587tNca8EiLSzV8pZB 828YzN6L3xNBvVjthzV/uY6NKquBAjlT7weXrfxg//mek2jOzYOtFxbfQKUXDSw546KhLP6P skxRbz43t6g3uzncfsmf+edxdwu3931ruP0y0y1B1JvPfZprLWvXrl34dlHvi5gL5I3099hp Az7k1bmOjSqrgQI5Uy+22MVGuzljpefVwa8Xlt1AI+edfOonbsrQ+CTqzefmFvWmS4Gpl4Yt 3Pa7ocfcfE/8+344/qZeS8sFinrzuU9zrWXppUsCK7fyN696VSOiN2DtWmSTZu3xx4h3kevw qLKqK5Az9WJ51iv27tSCNpdxsSMx9qpwr8DhAcv+slvKJltvbre1qLdl4MstIzDXjeZ74I1z gMK51R5fkag3t1s1v4rmv3XO6E1ayvaiArNesmtLtjD4zumZvXnz5vzGRjXVQIGcqReP+Hnv 6gfneW5/zbN5+A4A1163Riz4w7K/TP/vytabz80t6s10GqdYuLt3Mda3wfkhxcJbLkrUm899 mmstWsrm0m2jpWxMowVtuU7NelSWP/Xih3v8fJ8nVvpf14lzT7I9MtBauD7DAbrl/5RJMop6 87m/Rb1JZqMnaS747np3Gwu8Lbxhot587tP8akEoLgTkasrBYNuPOq65sGNs1W7mYVzBdZaz +sqdCVZ8Omg/xpXI68iC6zy2rO54+q7dMqKiQFFb1+1KbG3AiZXAEzYGRbFSNClhH3cuWTu1 YWLsUTzwyQvyGx7VVAMF8qde/HCPn+/DUQv8Z9PsWvi5628659wXF/m9cu/OL2zK9jdWUW8+ N7eot3BwbKoBMPHC0GtuvqetGWwqe+qJRb353Kd51PLUc89ecc+tH7j9s6//8nnLvnXK/f/P fgm5EGCK1xknv4iGYEq8cB0lzO3pOO/0naC55OyOQ/bfhbAbbth5jit2HeTqVodPSavM5SI1 CsQVS8yimBgfIT2h2S4a9QJ5rVI0CYmTdHBksKN/QcOUOz/98HvzGB7VURsF8qde/GNATK7w +q3smNL/kh957Jf77X8Avwl87wf3Hnr0G1L/9xkoUNSbzy0u6s16JqdePjatgGuvgS9cfgtc 3ybqzec+zbwWbE/QOzLADWnt2HjXoUm4EHQbIFEQMPgS1/mRFQIkpZmWn9p1XCSt2uFyLbGV HwGOidFmrMVbgC8/hUGXGUnAgcaToe0iEgRQO7KzO625ZzWk3vXXdfQtODnz4VEFdVKgEOpV JIcwiL/9nQtGVn8L198y/10XXJf5T6ui3nzuclFv6lSaQ4HAXARzMPBFkIflP5rMod5wFaLe fO7TbGt54b/+M4y8ZN/JH8+eEXyJtgESxRVyLW2uLl8GUDiyfJd63ZJ5TvZlRgJu2L8iTL1I g2KRPeAyEd/BwUUdOBqlQZm983qyHR6VXjMFCqFePNxhzoRR038rbG4t5CZt+Htg99E5/H8V 9eZzo4t6c5jMGVWB8L0Gvgjre+kPN2dUUUyxot587tNsa9n0i58ErLz29ksbjk9IveA/OjkA K2G7NeoFYgJVgZs4cBIwxLoOuAFbL0rDQSuyQbPRsHsRNTKZ2X2BwnixUh4snI3kFbMfx3dw aX9HTBw3RDSbc1x35PDg2Qp8Wb9+/eDvX/Pnz6/Y9sXZTsoal14U9cKcCaNmbkxZioqwpu3t C979/kvyCJUv6s3nphf15k+KKdaIDduwbRvZFwvdsJ1bioUnKUrUm899mm0tX3pwXSPqveT2 UxNSL826+Ev2Neq17MRfHEBPM8SSeum828jDAQ4MTA+6RTLSsDG0m4sJUFGkh4Obkm1IsqYN Tr1w3m0kwuTGjn1f/ecjIyPg2qVLl/b+/jVr1qyd0L37a86cOdmOYkql3/bI3ZgM8PBOqTwV 07QCRVEvnvh/1X30cSeeVOzx+uNPLLYBbu0Hdx/+sj/bK9MwvfaPVtTb9K3SUgZYH16yx6wj j+/VUVIFDn3z8S+5dJYZff+if988O3JYz5yDDo02dbU0H1PO1JFyeRUtbtWWjalQL1enudQL oy/tuzzMtyHg14vrMdTLVWjkaXPhtYvEXNdbF6VFUi+yu5jrugvHkH2jjdmYBXHNDjmos7u7 O4y5gSsrV64sxfR5z+2XczKUorWVbGSB1IswBWCvAo8TTjtnz1d2nr98bYFtCFR95T9tTWIB aj+NqDe323l8fBx3mV7lVeDOH97Z88UX92+bu2IuruTWHfxckNtcbbYiUW8ixbCUrRH1bvrh QcltvfBDoOOsa+ulURYkSj8EYiuNsqBkXKc7hAvHNBtb6DFGZjDMtfaAYhmGjFZbFIVktAqH YzjAuEu/XkZDY6VJHHyT+PXiHujq6ooBX1h/y+Le0P+dazkZENMj0exRorQVKJB620e3dko4 bdEgb6JXvroLPyO2U1QZ84p6076TVF7FFVj83cVm8e25uWd6+3TFO5yge6LeBCL9PsnlYyNh 8F20ZsELD/2PGakXkRMsgK45y+KKxeulxRdI6q45ox8CyBV/A2vRiK128FMgdSBML66TsOkm QQg2/123BKvCrTQJ8qK0JNQLAXf6inV2NgLfY489NulIFJ3u4u/fyJmA70JFt6Wm9deTeg15 awu+ot6a3vDqdhsKrHxopcDX1U/Um3Q2Xf/A7QHqRcje5x58yYzIW/kEyeP14lez2bNnNwJf fLR48WKkSTokBaWDRy9nwpanthbUhLpXW0PqDSBvPcFX1Fv3O1/9b0mB0Z+Pzrp6l5svLL6T 05MtFVORTKLeRAOJ37JPuOXjZJ1b7vvOIW886Kn7/6zyOJuwg8mpF1oDaiOXsrkoDCfgoaEh bx0ebGnjxsfuTzR7lChtBepGvZHIW0PwFfWmfSepvLoo4IJv1xe76gy+ot5Ek/6STV8h8i6/ 77bt27fP3nPW9gcaRi1ICIuVSbYzIu8xDdVYeu4fA2FdlUdHRwPge+qppyKwQ8AGDD/g6enp RMOTb6KR8VFOBgRzyLdm1bZLgVpRbwzy1g18Rb16BEiBlhXY/OTm2dfuimhWZ/AV9c48hWwp G8y9zz7/W2ToOfKvxteIencpMD3WMfvPGqrRd8peiMgbUDkAvps3b0YCOP6Cj91oD36ae2Hi JfUissfMs0cpMlCgVtTrLjsD9pF0T1zQX8blaG22WdSbwc2kImukwPjUuIEvTvC2Rp3/Q1dF vTMP+qI7ryflwLWXqfs//N6YCLWVMeIm70jXqzsQlzcyfde+L48MYoIIvvz/DcwNjAG8IBDc N8zKMw9VLinGJsfN8J9LhaokqICot27UOzI2/chZA//rlZ2/fOlLd8yfvyP0RVo3iRSQAkkU AOl2XtfJ9W31BF9R7wzzxBDn1NVLsC8xUw8PDw98cI/kUFj5lH29Heuvi6DenWbgvf60kcQE 34D/Q5L7ttg0WMRG6l1299eKbUltaxf11op612ycnO7q3tHRsdsxMFDb+a+OS4F2FIBTLzwc DHzh+dBOaaXLK+qdYcg+cMdVYSdO/NPtPX525Vk2eQcbBS/b6fI7rydGYth023FjQF6MRTsl tHDHYmkjpwR+BGghu7K0r4Cot1bUO9nbF0ReEvDatTvnEqK+jI3tPGAAHhzcdfT17ejtbXgs XfpiSmYZGdlVCMrxOMB++/eOSpACUMAFX4R3wFq3+sgi6o0ba+49i8M19CIDVlnN3lO23heN uzD0wtwbpuThT3UMfPKC7G4n2/mir69vLf8FZv967oXnOSuwSVv2tamGCAVEvfWh3tvvmIhG 3oDpN/W32CAd6AwgxoMFKKyXFKiWAtixAlHMaPGtFfiKehtOZPgzAHbJN/BzCKSDCTO8c0Ry 42jFUiKiBRa0heNawCIOQMnuWRGI/suIv1wbl+nLvgtlWosKb6SAqLc+1Pv9m0aLod4wRnd1 7TQew048PLyTg6emdIdKgVIrEADfkfGRUncnYeNFvQ2Fwgp9wg2cHMKJ5NobAPewa2+8U2/C CRqfDOveFi5cGA4ADBswfCey2wp8wZplnBup9EKFNKuAqLc+1LvpuvUNqfeP/uhFHwa4+dJX gUjKIxD6EN+H7SOerFwZdHVYvHhnmbNnJ0LtWbN2Lq1DjRMTzc5hpZcCPigA8O29tdc2b6sD +Ip6oyceIpTZthT3P/FoOBGICtEJKmaybac74b0qdl758HtzuLHhcIKFceGIv1gqN2fOnJUr V6Ye99e8vRnJTq+cFRD11od6b3lg+3+9ZFY0g2a6oG379p1YDH9fkDQ4GKFm4p0oYAkGMcO3 GBn1kgLlUWD777bP/8f59QFfUW/03LT9h7E/RaPZq6i9LiWHo/ZGRurN9FEQjvhrO1/Q8Rc7 jKTSAAtmh5VtqRSoQppSQNRbH+pFiN/7lq2MIE6YY/P3McDKudHRnRzc378ThWHrjURhGYCb up+VuGgFAuA7ODZYdIsyrF/UGyEuDHj8/RoHtqhoJP/g5ZcNfuyP27GPViwvdmgzX+ednr7Y wS4lymz2DoDnAxx8Ozs7A/u9wRcCHhHtRwK+4p5bOT0QxazZtil9+wqIemtFvQDfBz41/MKf OV4HPT2+RFqA1wQ8fdGeSPyVAbj9u10l5KVA/3f6zeJbYfAV9UZMqCSGXmRDwKyufffU1sTG 7m4kh+ElfzzwifPzulsb1gPA7e/vDyx6AwrjCq637PmAjakbLXMsvMt1aICot27UC/DFRhVf uWT440f1eOpEC8MzvIQR9qGRAXjhwp12Yr2kgMcKuOA7cFc1Q2KLeoMTEKEbekcGZjT0Mtvi RR9euUxbE7+oQHdXx8QdO9927v3SnMPoxjxJYHKGe0N43Rvswa09f2ylI3Ynbq0E5WpHAVFv DakX4FuaHYlBt/A5jnQFxkXAcUE/grVz0ylvTRRYevdSs/gCgqvXa1FvcEwtRu/F379xxvHG L+k9r92rYo4K7XRnZ4Des3bu09a34OQZ1cs/Ade9wceXng8tbwt3x8/u4fci4G/+vVCNol5R bznuAsR2QIQHuPkG/B/glAy/CG2HUY5RrF0r4d5g4AsIrlj/Rb3BAcXWA039eA28i9yMtx12 LG9e+Ht0vbrj8EP2xPcBn28V4G87gYQ3/eInnCRwhvG5m1Vtm6hX1FuyuY0YakNDO+DmG8Bf uD1kH1+8ZFqpuR4o4ILv8OZhD1qUWhNEvbtJid0omt12C3jXuffLsB1DkcecvYusffe+H/Ca Wd2HdqU2Q70s6JFnHhf1Fjgyol5Rb4HTr62qsdMbdn0LsC8WwyFEmtwe2lJWmVNWwHV1WD+x PuXSiytO1Lub9vBqIM3AzyH5oAB88W+4qNeqb459fqSoyqPr/eUvf5lcPZ9TwiQMdwi84BcR WPoGKy+i2k1Oa3+mAgZQ1CvqLWDapVgl7LuIfRZg387OnTHR8g/HlmK/VFS1FFh4x0Lbsnjz k5lvepqPeKLeF3VGkDLbaRZr2vIZgPZrueDGh95/9f0v/O6/2y9KJQQUwA4XbuyzdIP+Su2W FRD1inpbnjweZQTgwrsXsOviL0JA4KLsvh6NU32b4sbxnX3t7IlfV2EPQlHvixPagrCWyFnz /kd/feqlYzjW3fdkfW/NzHq+cwe+rq7IoL8ICpFZtSp4BgVEvaLe6twkAFy4NwQCPgCFFeas OmNc4p5gy+Kem3to8e36YtfUttL/vCnq3TUdbQtibERcom1mYegl9crcm91zhUF/scNFAH8Z 9Lf9PS+ya3lVSxb1inorOLexATLC/bp2XwR/UJyHCo50ybo0OT0J3iX4goBhAC5ZB3Zvrqh3 lx4WgXXZ3V8ry4iaoVfm3hyGjEF/LeqZS8DC3xz0d6sQ9Yp6c55y+VUHE69r94XDA5x95fCQ 3wCopggFxqfG4eFA8J3/j/NLDb6i3p0DDC/eU1cvSbgzhT/3hBl6Ze7Nc1CwrA3+vr29vQHT r235Jutv1sMh6hX1Zj3HiiwfjIswZ+4eb+BgOTwUOSSqe8foz0dnXT2L4Fvq3StEvTtnM3bY IvIuuvP6sszugKFX5t78Bw6bz8XjbzshgfPvTolqFPWKeks0XVtsKta6BRwe8FYRHlpUU9lS UGDtv6613SsQ0DeFEosoQtS7U/UP3HFVUztTFDFSwToDhl6ZewsclBj8FfhmMS6iXlFvFvPK xzLDDg8wA+slBQpSYOi+IQPfkfGRglrRVrWi3h1bntpK5F2wZllbWuaYOdLQK3NvjiMQXVUY f+XtkMWg1Ip6zxkcOW3RII8TTjuHfjX7HdpjF3GyfOPkqi07Kn9csmrshHm9Wcwor8uMdHjQ jm5ej1mVG7f4u4sNfOH2ULquinp3YK+BFnamKHakIw29MvcWOyhu7cRf7G3hT5Oq1JJaUS+I 9pWvDobPc33KQb2V5112sKbUy1s37PAwPFylm1p9KZECfd/ss90rsNCtRC1HU+tOvc+98DxC lYF6e0cGyrIzRYyhV+bect1+am1rCtSKekF7MeBbH+StO/XyVgk4PCxcuGN6urWbSLmkQMsK IIbDnFvmEHw7r+tEaLOWi8o/Y92p19axYYuK/NVvrcYYQ6/Mva1JWmAubIQxf/78hQsXIiwa gqMV2JISVV036m0EvrVCXlHvrjsUT4nFi18M64vwDhNV2DGrRM8fNRUKYPcKC+KLE7wtiyx1 p96Lv38j3Rvuf+LRUowZdh7+6ePTdvz96OMk3S98a8K9vu3//K4U3Sl1Izf94ifL77sNPxe0 0wvscxHY9BiuEXCQaKfMyuetIfWGwbduyCvq3e2+hveUhTabPXvH+vWVv+vVQd8UgIkXhl5a fGH6LUsQ31pTbxndGwLzftOWKVLvN35Ypp8YfLt7W2iPbebX5v7Vo6OjtusbzL3gOb7+5V/+ 5cknn3z++baQuoV+lSJLPanXBd8aIq+oN3hvjo/v6Op60eiLzSz0kgL5KgCnXgviC2fffCtv sbZaU28Z3RtEvS3O9LSzPfXcs2nFeIZlF+ve4OTwy1/+slEzV6xYcc3vXwC+LVu2WDJecXOF rzQqc9u2bYHEGzZswJV4qVCdpWF6/s0zRltr1PuFTVNHzX3rXx8/r9THIUcf17n/gaXuAhv/ /iXXN7sIr9ar2SJvSzj19va+CL7YwVhuvmk/6lVevAII42AhHYY3D/svV62p19wb8FO1/0MV 2ULZeosaOKPe/u9cm0Mb5s6dC0eIQ37/wgneslK8DXBq+EpM85DYimJp7tvIjKgOyfDR1q1b 2RJemRGXU1SpNeoFMx181GtXja3SUbgCnxr+FMBX1JvOTTEw8CL4wvoLG7BeUiBHBQC7FtJh 4te+e5nXl3rNvQExHMoSvSE8jUW9Od7awaryDPMMuCRr4rV69WrgJinTcBMMShsw/j799NM8 IZvyBBftI+vJeeedhxKYnhSLwvkpEuMKz2EVZl77a81gerdkq9HKYXb8TWuwWqbennnHb0Fj dRStALBb1JvW7bCzHPj1wru3o2PnAX/ftWvTLFxlSYGZFJj/j/MJvt0ruj138K0v9cK+S2pZ dvfXZhpQfz8X9RY4NkVRL7oMCKZRltRLDiaAGgfTcEsj8RlnnEFuNsalbiRduE/gfMmSJWbE ZUq8gMX4CFWYpZmWXVAsrc52TgonRrMuQrMVxVpSeYl6yw7uot5UboTdCkEkB8RzIPjigAFY LymQlwJT26ZsZdvAXV7PvfpSL2CX1FJe9wbMZ1FvXjd1RD3YzI9TKIc2uLZeUi8JFX9BtKBP 4mmAenmRiWlwRUrXLZjpDaBRFK4QkXECuER6wCupF2/pCsyq3dKI2mRouPmyEJbGFqYrkahX 1JvujKpIaXDq7evbzc1XwRArMrQl6Ibr4Ovznm01pV64NHBzilK7N4h6i30SFEu9hqoMfGZu ta6tlxcNkSOplyZeoCq5lpxKVMULJ1xIR9LFK4Z6kZKevmZadik8xcEqhHpXb1l919N3lR03 PWm/bL0p3g7BohDMwSy+WN8m8M1QaxW9mwKw8trWFbD++qlOTam3Gu4Not5ibyqsY6OtFyvb sm6Ja+uldwHtuDwhidI9t1nqRS5zQmAvzH0C5zQMJ6Re2oaJzubpa+1JUaI8qXfd1nUnn3Hy /ofsj67hL44Lr7nQ2JEf4cCJXbxy9ZW8iAOsjMPehk+QCwUGrvfM7XFriczOGq1wnODt6eed jryfXvHpMN3GtIF5GyVgS8KNRHrUdcOGG1ogaVFvirdDRFFw87VovgLfbLVW6S8qAI/enpt7 CL7w9PVTmppSbzXcG0S9xd5Ui+68Pk/qpRmV+Iu/XBxmTIkrxsGBhW7xtl5irusjQZMtbMC0 9QKLE1KvETPtx/jrtjDFwcqNemHcNd4F4fEcL0NSXOQVfGTwB/TkRbwC1GuJDTEJlIHrfHv2 krNZpsvcltGo1ypCSrbHJWZrlQu1geqMeo3s3cRGveHG80oL4CvqTfF2iC4KexcLfDNXWRUE FUAMB4vg62cgszpSr+ve0ObGWoVPefn1FjgE9t3pkWcez7oZFq+Xa9esOguUyzC6bghe+4h5 kYWfhmMpMK9FbEBKVIEreNF+7MbotXO3NKuLiOw20j5KUaLcqBdGU1AdUDJAtMa4pExSKdnR INWFUcseSaWk3phaAuW7tlVUmpB6LVe4OrfZ1ouABTecC18J2B3Xzp3Q7ivqTfF2aFiUwDcP lVVHUIGVD630OZBZHanX3BsQr7fsE1bUW+AIXnHPrbT1bnlqV4SvAhtTq6pzo16iHqDTPHpx AhQ2NCT20bhLmyg8IoiwkaiakHoDLOsn9aKzsEYHeF3U69edGABfvxqn1lRWAezT5m0gszpS r8EK9mYr+6QT9RY4gtiLuAJhQAoUsOWqc6PegIcDIA9GShfsSLFw5DX4o3kYKduhXqNt1wqL WugvwYMfpW7rRctRu3uwooCtF8rAsYF9BPQnhF1LJltvy5O/6YwjIy8ubuvvbzq7MkiB5hXw OZBZHan3PbdfTlgpu3sDpqKot/n7MbUcq7Zs5ESqwNen1ETJpaDcqBeUBrYz5136EuBtwNZr S8qQHj/309W1Werl4jDXe9g8B8yfmA2g+Tkj6rUqAhU1cj52HTOSs6+oN5cb5Q+VxIMvlp/u vqt5rm1TZRVVYGxyzHYq9iqQWe2oF6Sb5+YCWc9nUW/WCseUf9sjd3Mu4aTAZtSw6jyplyQH SoMRNLx2jVdAvS7sAkl/tO1HzVKvi5vI6xpQWRSZmIcBcc62XqK5ra6D+Tk56bopRb1537aN wHd4WFta5D0WtanPz0BmtaPe+594lKRyyaavVGDuiXoLHESYeDmXYPRNtxkInmC7TsSUzBhh 8S+GzmWEhywWls1U/87tKlLclY3V5Ua9YEqAHVx13Z/myXx0dTDqpWMD2Zfmz2aplyZkHG51 M64zS516E65ms2V84dYm4WBR74w3TvoJAuCLOL6LF+9yfujpSb86lVh7BRDIbM4tc3wLZFY7 6h0ZHyWp4KQCc1LUW+Ag2rJIOPim2AxuL4yXG1QhXL4bVTemdsbitZBnKDYJK6fYnVLH67XF ai7JEWdp5jTq5SI2vhhxrAXqbcSLHq5mM49neTikeLNkXpQLvnvv/aK/L3a10GYWmatfxwo8 DGRWO+qFiZfUC6NvBeagqLfAQUToBs4lrI9MsRm2sZmZe93AYbCb4oUrxFmaUS1eWJhoibxs HvdmYxQzy8LYZHhZtDIWwkr5142VxmRmvmX8Mu5abJHOkJ3h0tjOyBpZMvaE46dNvXKz9XKZ GkEWRlBYKBmuwaI6GPUa5poZuEDqhck5sCINHheG1PGRy8Kr2bjnRTgXzdt4RYYHjrf4ytbb 1IRPM7ELvraFG04S/HCUZjNUVm0UGBkf8SqQWe2o13aRrcBSNtw1ot4CHx0I00vqReDetJrB ndKAjEDe8CbAqIVWW24kwY3ZQJxm0N3pY+pE80V6Ui94Fy8kpq2XtdCPgvtQ0MCMfSV4BYkB o7hC1wh+hNL4qe2UYSTNZEbYSIwsuML9L0jDgRpZPi82q15u1At0c7ecIOQBZ82f1aVeujfY OrMCqdesznbi+i3EU284L625kbmsy83u1SzqbXbOp5Ye27b9yZ/sZuUl+2IfY72kQDYKWCAz 7NyWTQ1NlFov6n32+d9WaSmbqLeJmZ5BUmxEzOmETdrSKp67mtHUaggLQDQCNscGQ0zuoMYG uKzMK/iIcMm/ZGK3QNpiyaConUxsaXjOYoHX1iSjc9qPWaw1njiOK0zG8q2R7hWzNDclYJ7U 6y5lA/8B/lzCg70TV2hJBcnh3HYDprXVNbIiDdMHwp8FMoatpJFFMRnKdz9l+eHDbUaj6iIz Wo8ic0EK5mp2ezZRb1MTPrXEQ0MRvEvq7etLrRYVJAV2V2B6+3TndZ20+K7917XFylMv6h2b HK/SUjZRb7E3j1Fv/3euTaslZrWllZTOCfHU6zr4uimNelkIyRUeBTgHKKNw/KU3BQmVCQjH dD8IGJsJuPhrJSONe9GykGvdZOEaw01NrmHO1JtkeZbSNKWAqDf5bE8nJdx2Fy5siLyg3tmz 06lIpUiBKAWwOzGpF/iLVW4FilQv6rUAq9VYyibqLfDOYdXp/nRA+y4spjSO0rWALrPgSHjQ 4mUmXjshrXKfYVKsK4slw0V6JtAT17LgHFXAWEtXXVCsa/2lj685QhjOmim6EfXSb4HJzNbL RrJGUW9TmFixxKLevJ9d09M7EKSsqysOfMfH826V6quTAnBvIPiCgAvsd72ot2JL2US9Bd45 rPoDd1yV4mo211cBhdM9AMRJdiS/GsXSGIwsSMbrfNGaay+XelkOCiQ92wsMilxMyaJo67VK XR8GWqCRhlwbSb30EmYyUm+4Rpd6L7vsslFsnZr41aytd3hs+n2fGt7v0J6X77XnifNPDDgY VAwoS9EdUW/iyZ52wrVrd8yZE82+K1emXZnKkwIvKrB+Yr2Ze+HzUJQ09aLeU1cvqcyubJwx Ws1W1J3Del/4r/9EJIe02gCCDEQrsyu4jnMALk6YBudueq5XC7vJBspkOWwws1jjWaAVYvbg yBLcjHYOtLVzqwhXaOIN1Ogm7urqAhyPJzY1NUW9yzdOdnZ1BxZpXTR0USnosKqNFPWm9dBo sRz8hgNHXjeGA861X3GLaipbUgXM3IsNLJLmSTtdjajXvDARxiFtGQsrT9RbmPRVr7gdD4Rm tQH1zpo1a2pqasaMk5OTQN7h4eEDu3uwS0SS48Aj54TjEuCKLL4FIrWod8apnkeCycmdG1XM mrULf+H/oJcUyFKB8alxi2I2tW3mB34WbakR9VZvKRsmhKg3i7tCZUIBN0hw1oJs3rwZODtj LcBiwHEAYV/6Z7MPPaYXx4kL+k9bNBg43ti30zc68rWgf0GB2FfzqkW9M872/BLA5RexHTo7 d7IvzvWSAlkqYFHMFn93cZb1NCy7RtRbiL5ZVyrqzVphle+PAiDjRgjbwvVXd7265uhZYPdF vZG31Tnn9J/0pjcVdQwddthHjjmmqNrD9c6dN+9Nb+r15/mjlqSigJl7YfTFeSplNlVIiamX MfDdV/wOrk3pAh9Hc0ZsKmPOiUW9OQuu6opVABbowcHBN7/5zS/bc6eJF4beFniXWY6cc2QM 9mFbB2wz4R4I1osdK9wsiFOLBNipwb2IZMyFPYqtEG4SwfQ8LAu39uUR3uTMPrV9MZgRhTML Sg431QoM12sfoZ0WZDemna4CSIbOBtrPQMW8GGhkjLyi3vB9tH79+lPecuq6jZt0UIGPfHTx X/zF3snd/Yt9NKn25ArAqZd+DrD7Js+VVsoSU68FNDXwTYt6uZ7dXa+TltyplyPqTV1SFei/ AuHVbJesGsPxiZtGzcOBVy4avvOP/+QlkWR81sBZ8dTLXIZ9fMuNyniEtyvjVm2EUSTAX+Yy +rSW2GZptukxPorc2pf7nwXYGvsGsyK3lgCmWzPYTrcv3DcOL4Jvo3YGCkQyUjgyogGmA3sd aGG8IVnUG77L3va2t6359oZnfrNdBxT41dT0fvsf8MUVXz399NP9fyKphU0pAI/eWVfPIviO TY41lbf9xOWmXrBpQAIswWHYUQYExV+6J/Kvu1krzi0x0jMBeBd/GVEfYVP9N/eKetu/B1RC 6RRoKoYDYpaFqRfuDWPTYzNSr2uUBSAS+MziG6DeAPI2okkWYoBLqOUrknqJxcjl7gnnoieZ 1W1qoF9hOkdRLqpGUq/L9wELt9ueyObN6Dsh6g3cdLBoHnnU0eJdU+Bz1990zrnn4+2hhx42 MTFRumeUGhyvgJl789+juPTUywD4xq9A3p2WldWrbcMqhh3lBlRkWQwGo+670U8tOinj/DNL Wsbj7G4AUW922qpkbxVoinoR5+GMi4ZcX4hDew7dOLkxnswiUZL4aHzp0iRQmB+ZEbcR9TKl MSXtqWTQSOpFOWRc2+sY7g2kZJxYLU1RL3LRWsxmNEW9SO8ScwDiZ+RdJhD1Bm4uWDRHVn9L 1GsKHHHkUXff+yDeXrX8C5/8ZGFRrrx9Bpa9YdiezfYoRhzfPLtTbuolm/LFXVWNaM1FgQGY GMeUsAuWJRnjCjcCACu7yUjA8nDIcyKqLimQXIFmqRfg+4VNU++7ZPgvu/ZbM74mCZlFUm8j OiTI4hVwbI1MD9w011jyKyAynnoDoOwCq0u9gGb3MEoO2Hph6A3YrRv1i07DPH607UemG5iV /aWhupFVWH69Cac0gpPsf8AB+E1f1EsF8AXg7e9cwHPIAnGShDVMqLaSeaKA7VHcvaI7zz2K y029YQ8HDCe8FPAgto/csKM8d3eTQnpushpIJur15MZQM6RAWIEWqBfgCzffnnnHJ0HeRgbU GD9dUmCA/yLTg0EJi2BHgClOQLHx1EvKNCeHgOnXamEb7GWNCfv1Blo7Y7+QPmCHJnnz1ULk Y9l63Vm9fPnQJwb+RshrCvS9+8ybb/mGvT3nI+ev1L5xlftP4Jp789yjuILU6+6DinlCwy3+ TZqtl/ZdXMcV7tFKH18XlEW9lbvF1KHqKOAh9TI+Q4AOG1Gvwa7hr0u9+JTWXzdqhJEuzcOu m6+ZpeNtvfSjYDmBeAuR7WR6O8xybF8bAl7OCb9OyMMhfB8e/4Y3fO8H94p6zbi7zz6v2jr5 jAmCRX5Y6led55d68gcF3D2KczP3lpt6adO1F4y49GEA18J/l7BrDrv01qVjAz8lH8ORl3Bs 1EtjcCnCOMivVw+QGipQLPUacZoNlY4NFleB7raN/GWRyxwbzNXBpV4r1jUem5MDa3EDJjS7 ms1W3cW3c0a/hXj7tGI4JLwx8dv9q17VKeR1GffNp5zqCgInB0g0rR00Ek6pUiWzPYpzM/eW mHrhngs8dV8Ya7y1JWg8J84iGoP7EVJads4QJrDZwmL9nzyi3sLHaNGd159wy8fvf+LRwltS nwYURb0B/9pwbASaP40XG9l6bYGaJXYJEr/+m9U2sIKNlIxcrgNxs9Rr0cfi2ynqzeeGwm/3 +AVf1PuiP8O55yOAQ0CQM97zvrVr1+YzIqolTwVGfz7KEGZdX8xpQ+wSU2/CgXGNuAmzlCiZ qLfYwZqcnjpm1SIcF3//xmJbUqva86ReA1ALMWabO4Sp14Lv0gs2hnqtNAa+TWI3tSC7gXAN jTwc0AZ63IbbSRcL88doNoYD7bhJ2tzI4iu/XrthFaY3ALhwb3jksV8GLsLN9/3vX1irp1x9 OovVbATfzU9uzqHX1adeOjnkIGUhVYh6C5HdKn3quWdJvbD4FtuSWtWeG/Xagi2eADfdRV1h mjQWREruzcaM7i4VLMG4k2CahCBtAVlgP4hGq9kMaiPbSeymt4aot8DbZ9asWYreYIz74wcf PviQw8KWb3AwnBwKHCZVnZ0CQ/cNkXoXf3dxdrVYydWn3hxELLAKUW+B4qNqUW8h+udAvQjU FVgcBjuuu08Eg84iTWCZF2CXGWEStkIY9ovpibn2Ea2hKMQ+amQfRe0s2fxxmTLcVGs564ps p5XWqJ3h5WuBhiVps2y98TcI9l/ALgxybzAFYNNFAIdIQUC9il9WyPM260qxVRupd/a1s3NY 0ybqzXpAsy1f1JutvjOV/sJ//Sdtve+5/fKZ0urz1BTIgXqbikigxM0qIA8H3gzwVYXHqqjX FLh4YMlll18VKcgpbzl1dHQ0tYeICvJJgd5bewm+OexYUQXqdcM48LzZ0TTf39I5AYt6mx3r 1NOTehesWZZ6ySqwkQKi3mYp07f0ol7O7aVLlzaCvHqiMKI3IE5ZZN8/MbBkaGhIT8VKKjAy PkLq7ftmX9YdrA712tbELXjxmu+vqDfrCVe98kW9+Y+pqNc3im22PaJe3jVaypZkKRvTaEFb /k/a3Gqc3j496+pZoF78hcNDpvVWhHoReTcgE6LwIjQv/uIjxCBDgF6c4C+TIawv9zEmImNH 4nDU3kx1T6tw2XrTUrLlck5dvYTg23IJytisAqLeZinTt/SiXs75Aw7oeujhx5o1667buOn+ hx5hrmWf+SyPH/zzAzh4cejzw7yIE1z86cRkILF9yusokFcspZWAj6xYNzESWGJeR5NYiLWN zUveOyxZQwCHRunvvvfBo48+utlnhdKXRYGFdyykuXflQyszbXNFqBdeDaRYvICwkIxXsDsx fR5At9yZAgRMgy4+si0t5OGQ6SSrduHwbRD15jzEol7fKLbZ9oh6ecvstddsdxOyhIAIrLzw ogEmPvCgg3FO3HzDnBPP+lA/LuLkHae9ixfxKdIAXgOJycS4iASWGCn/4bZvB0rApyiQ1eHc Tbzi5q/zOgpBmkAzWGPCTiEZvgDst/8BjdLjU3xJyPlRo+pyU8AC9865ZU6mlVaHes3DgZsP 257D3IANV7jjGveewF/AMajX5WBcl4dDprOtkoWLevMfVlFvs5TpW3pRL+8a/ANKDoVuSsNQ YKXZYh9/8tekTAKopcc5adhNbJ+6YArkBdSGS0CBqMXKYV7YepEXf4HU1h5+hLcE4qaoF9bc I448qpEg+HqALwn5P21UYz4KIHpD53WdNPdO/Hoiu0orQr1hD4cY6oXRF5/iL8BX1Jvd3KpJ yYjUS1svopjVpMuFd1PU6xvFNtseUS9uImyxC4xrjXpBsXQwSEK9SEwIjqReYC4SBNwYAtxM 6g1nR0YYjK186wuQl/TcFPWCnk+ce1KMIPh/XfjDRw3ITgHE6yX1Lr17aXa1VGEO0ZkhsDVx DPXSEYKWXVFvdnOrJiWLevMfaFFvs5TpW3pRL+6aycnJ/Q9o+IN+PA0DK82YCiS1g54PeAvc tIOGXjKoe5g9mN4R+AioSq9cvnVLjkRYc2mgX4QdQGRaf5uiXkRvQAyHmI5jR4/t27fn/8BR jfko8LP/+BlCmOGAj292NVaEegPBy6CXUS+WqZmHA07Mrxfn9OtlAAemkYdDdlOtqiUb9WJ3 4qr20bd+iXp9o9hm2yPqbZN6Yeg1Yyrwl0vZbHmZWWppoDUkjbT1upRJ/CX1AqBZrK1Oi7T1 0u0hsGoNTWqBem9c8dX3n3V2DPXiSwK+Kvj2OFJ7yqVAFai3XIqn21rFcEhXzxZKu+KeW+nh sOWprS1kV5YWFBD1NkuZvqUX9bZJvUBDo96Ac0LAKxduA6BVuPxGejiAaAMuuZGewSRR0K2t osNbuhEDtY1xDVjRthb8emM2ZmPJ2p6thaelsgQUEPWWe0qIegsfP1Fv/kMg6vWNYpttj6i3 NeoFwjIaAw7aYiPNtwGvXNCqrWazgA90TiA942DJxrWBEgxnGSYC9XIFm0EwLrIQfIRzd7Gd xVabMYqZ/Hrzf5ZmVyN/OXdf8CzdujUT2xDWaCUvWdSb3aDnUbKoNw+VY+tYft9ttPXe/8Sj hTemJg1ojXovHdn8sr327Jl3vI7CFTj4qNceNfetq7bsaOq4ZNXYCfN6qzTJm43h4FIvzLSw pwIlacd1D6wwMzjmdSZzAdSoF5+iHPAraNUikYVLsPK5fA3pA1WEC2G9ot4qzdjkfQH1BsIM wKeUGyOk/qLzasJia0S9Tz/37Kotd+K455cPJ1TH/2Si3sLHaNWWjaTejY/dX3hjatKA1qgX gAXwBTnp8EGBL2yaagp5kVjUG+PzWoGPFK+3Sg/wMPUCTLmAii/uDoZk27Ztsyt4tvM6dhmz NDznCwkQgAsAbReRnlG5WM7TTz+NMlECt24Iv2pEvQgsRTr5wB1XVWZuiXoLH0pRb/5D0DL1 NotZSu+VAtWj3tb2ZqsA4EZ2QdSb/7M0uxrjbb0wA4NcLboAgZW7KyAjiBYnZGKecx8GnuMv 3tpuuy71AnlZAkpuZFquEfVCMttQ4Nnnf5vdYOdZsqg3T7Uj6xoZH+W3qdseubvwxtSkAaJe r2A0t8ZUj3qxxS62ZqgqxTbbr19NIYDxXvgbmRFxzd72trfV5BFXgW4yMqzr12vuDXiAu0Zf 4CkSk3pxzr4HzpmAyMsEBFyem4cDzcCmXqTnQ72o1xYeVebHaFFv4U8HzCVSL4y+hTemJg0Q 9eYGml5VVD3qPeecfoTrapYOK5wee7M1+hpw5TVfGBgYqMkjrgLdpK2XGylwZZu53vItd06g fZcewPhLum10jpSA3TDUWuFWmpVsBVquelHv2OQ4AQX4W4FZhS6IegsfR1Fv/kMg6vUKRnNr TPWod3h4+GMXXFxhim22a4jX2+hrwMKzzh4ZGcn/aaMaW1Mg4OEAK6wtbnOBmFjMCAxJqNeN 1WCw61IvKnL3LDOn4ZpS73MvPE/qPXX1ktYG0rdcot7CRwShGzip4OpQeGNq0gBRb26g6VVF 1aPene6J8+L24G2WGsueHgbdRRdcFNmLI486enx8vCaPuAp0M+zXa5649HAwHrW1azNSr5vA dZMw6uU6NqqH8iNjpdXL1gshsJSNjLL12ScqMLFEvT4MIoKXXbLpK1gu6UNj6tAGUa9XMJpb Y6pHvdPT8GSdXXZUTbH9jUL2/t7ld7a2Iy7R4z1MvRs2bICnL9elwfuWCAtINRvwjNTLKBDI C4Ou6+NLxwYGbcA5l8G5nsGubrWj3i89uK5Ka49EvSV6CqipaSkg6s0NNL2qqHrUiztCYRxc aN46+QwWtIUxGs6+WPmX1gNE5eSgAEyt4Z0jzJkBDcCn4FRCMF+4YgbgRudIhgVteLkOvriI ki0vPYkbRfCtHfVi21hS76I7r29t4CcmJnrnvb53Xo8Px5vPOPfUS8dwnHLWUh/awzasXfON 1rRVLimQRAFRr1cwmltjKkm9WKGFn/VTNJeWvagT554U2P8CPVpy6WWDg4NJHg5KIwXiFagd 9b7wX/95wi0fB/XiL85bmB9wqJ8/90/HVnX4cPzw5pecednadyzd9M2bDvahPWjD0v6O/g+/ twVhlUUKJFRA1JsbaHpVUSWpV669AUyPdO2VU2/CZ6OSzahA7agXisDK284WsqDe/tNfvmNL hz/Htgc8as/IoKh3xvtOCdpSQNTrFYzm1phKUi/uBHis4pf9stto02p/eK8KXIEfSFuPDGWW An9QoI7Ui90ESL3XP3B7CzPBQ+r1h7/RElFvC5NKWZpSYPPmzS/fc/aRx/fqqJUCB76255S3 zm9qqpQisaL2Bog5ELVXkXpLMY3L0sg6Ui+iN5B633P75S2Mk6g3HrJFvS1MKmVpVgGALyy+ etVNgampqWaniv/pR0dHT3nLqWnZSitQDrx4cVhHENzNXfPk/4CqhT4rUEfqxXggXi/BF/tW NDs8ol5Rb7NzRumlgBSQAjEKFBvJ4d+nprddftULc0/6731e9X/fueA3395QLDo/8tgv99v/ AG5NrOgNunHSVaCm1GtODgjf26ygol5Rb7NzRumlgBSQAjEK3HBDYZu0/cdjv/zdIYft6Ohw j+cbbBWRGw2fc+75n7v+JlR3xnvet3btWk2ecimAiLkIoGsvhM7NyFrPCL5NiVNT6kX0BjP3 IpZZU5KJekW9TU0YJZYCUkAKxCuA/RcOOOAA2Dhzw0qr6P+cdXYAefn2f9/yjfwbYzXCxAvv XggCWbQ5ReluH3e/CQTWRfRcsGk4fG8q/WoUl7dR4TWlXsiB/WPp5IBdtZqSXtQr6m1qwiix FJACUmBGBZYuXXrZ4FU5gyYMvZHIi4u/O/KonBsTqO7t71zwtvnvhBV8RumUwDcFXOpl22D9 xZ5q1k7sT8Ed1GyzCe5YwevYhAIp3XNmxHXsyoYE3IYNL+xMgULsBASMBHiZaZnM7WapL/U+ +/xvGbi32d2JRb2iXt8eMWqPFJACZVcAC/Ve9apOrNzK81j214c3ot4X/uiP8mxJuK7Xvf71 s2bNkqG3jBM7TL3gVHNF4F7B3EENFwm+3FUYV4C2OCET85wIy02GuX7Xdhs2DwecYLtjErNb LMvEp6gRn6Kc+lIvOo/IZS2Ye0W9ot7AY+i5F56Hp3izrjJlfJapzVJACmSnADb+zDkox798 +csNqfcVr8i5MeHqfvrTn2antkrOToEw9RqeEmStasAoTLOkXjMGB85pzQU3m4/Ehg0bkAYX Xeo1gGZp3P0YF+kCAaswT2pNva65d3I6aUAcUa+oN/Cw4Ncn/HSAGZXdc0QlSwEpIAVSVmD7 9h2zZ0eD75lnplyXiquNAmHqNdgFwrquDrTgklNJtzHnAF/kpVU4knpNYFIv3gKpuagOJzQq 15p60X8z9ybfsULUK+oNPLuuuOdW/mggc29tnurqqBSoigIjI9HUe/LJO8DEekmB5hUIU685 GNDL1opMTr30DMYPArDgNrL1hqkXVwC7YG7kpTG47tRrO1YkN9SJekW9ot7mH4PKIQWkgK8K rFy5m8X3j/5oFwf39/vaYrXLawUC1AvohNMt3XPxF/QJfwN2wNaZzWjrNV8F5KLFFycBD4cA 9YKPmYwvllB36oUQiOHQ1AbFol5Rr6jX6yeuGicFpECzCmDTO0AJ8Hfz5h2u9Xfp0mZLUnop YE4IPMGLYRn4IrPS6GtUOiP1MrHlonNwPPUiAbJwYZzVJerd4Zp7k3j3inpFvYGHmvnJbPrF T/S8kwJSQAqUXoGhoRfdHoaHS98ddSBfBWBkBY/aK1w5EjC0gn2EK2YAbnTO0GZc02Z5wyf4 1I0NzGARlkzUu1PzZXd/jeZebNWGDSzip4eoV9QbmCGrtmzk/Nn42P35PltUmxSQAlIgGwUG Bl4E3/Xrs6lDpUqBvBUQ9e5UHEvvbau2Lz24TtQbz7WiXlFv3g8q1ScFpED+CixcuAt8Z83a 6f+glxQovwKi3l1jeP8Tj9JcN+NKfNl6Rb2i3vI/+tQDKSAFZlIAMRzmz98Fvp2dO+D7q5cU KLkCot4XB3D5fbeRehesWYZ9BxqNrKhX1BuYG9iigjMHJyV/IKj5UkAKSAFHgenpHT09u8AX pl+9pEBeCkz8emJscgzH9PbpFOsU9b4oJjx633P75cQXRGB1VX7quWdtAwJRr6g3cAfCnZfT Bg6+Kd6cKkoKSAEpULwCExM74OHQ0bHzQHgHvaRALgr0f6e/44oOHADfFCsU9e4m5iPPPI7A vSQYW4+PIA+w/tpCJVGvqFfUm+IzSEVJASnguwKIaEbqxUZuk5O+t1btq4QCot6chtHW4/eO DMDEC+TFCSAYYX3ZgnSpd8MNHXN7Orau6wBK4i/Ozzt95zkOnJxx8q7zay7c+RGOFZ/edQUf uW+R2M0byG6Fo4ptP+pAaWOrdpXTzsK1yLwjgx39H35vTqPlRzWy9foxDmqFFJACmSnQ27sL fHGilxTIXgFRb/Ya/6GG/u9cS3PvB//paiIvDtiAGdQsXeoFhuJFlgWM4nXI/rt4FCckYOAs z0G6eC05e+dFXMHLsJhvkZIk+vRduxIYJW/ZuTdKB/7yBHWlzrsssIbUi58FOElmDACS3yRW TVJACkiBFBXAUjYYemnxVQTfFIVVUQ0UWHjHQnk45DQ7YOI1PwcL7IATxHlInXrJry7dkk1J w6uv3AnEO7fy+4Np1gzAyEUaRgn4lG+NegG1gSui3uxmz5antka6g2dXo0qWAlJACuStgO3Z BjdfOPvqJQWyVKB7RTepV6vZspT5D2V//sdrXd7lOYI8ZEG9hFc4HuAvMBd/wayAXZzAZAtr rll/XessWRl/gbOw/hJ5jXpxHRlRmhGzqDe7eSPqzU5blSwFpIBHClgEXwR2QFwzvaRANgqA dIm8XV/sSrcGrWaL0NPcNAPgi50ssqBe2mXh4EvMJbySaM29IeyNQDjmX6Q38KXp12DXDMmi 3nTvHLc0UW922qpkKSAFPFIAgcwQuJd+DoODHjVMTamWAojbQOrt+2Zfuj0T9Qb1bIS8JGAE eUjXrxeQSh41my6tvEarhr8EX5hvcdAvArzLRWw4B+marZfuv3zLoqwW+fWme/+wNKNebG2d RfkqUwpIASngiwKjoy/uVDw+7kur1I5qKTC8eZjUO3TfULo9E/XupqcFcAi7N1hA1tSp15am 0buXHr106jXDLT8yS7BRL30YzCpMDwe6N4CJccAGjBdIWrbedO8ctzQ4gnN6LLrz+uxqUclS QApIAS8UWLx4F/j2pWyH86J3aoQHCsDES+od/flous0R9e6m5+T01PUP3A5PhkbU+4E7rsqC ekGr7pI1GmjBuLTvglx5hQf41aiXsRoIuxbaDEUxFBoPJghQr1tguvEcahjDQdSb7lNJpUkB KeC1AojnYPtWyNzr9VCVtXFw581iKRvkEPVGzwmEa8Cv1ZGRHG78+s39p7883bBfgFeyLA8w q/uWVl6Ydd0gu0iABXB0XbBwvzgJ57UrVib9HOxgOWkdot6yPmbUbikgBaRAQgUGBmTuTSiV kjWrQHZL2US9M4zFcy88Dzdf/Gztmn4vuWUodepNizh9KEfU2+wdrvRSQApIgZIpIHNvyQas TM2FV0NGS9lEvUnnAX7CHhkffc/tlwN/3/W1vxH1xuD13w11veMzZ0OxpOJWIh1cXzA3rrjn 1kr0Rp2QAlJACsykgMy9Mymkz1tTACvYSL1Y09ZaCTG55OHQnKSI4XDeLYPnvHsvH6yqHrZh 8sezzS6O8MbPPv/b5vQtbWr0FDu0cfc+vaSAFJAC1VdA5t7qj3ExPbSlbIhflnoLRL1NS5rF ajYP+bW1Jj27+aUnf+UDBr5wjMbqQDiKNK2yMkgBKSAFpIDnCsjc6/kAlbN52S1lgx6i3qYn RSrUa0F5LS6vUSYD9DJsGQ5uReEejEoWuMi9KvARc1kQX8Y+Y0BfroqzmA9uhIdAwIfWkJe5 vvzZl771s+e4ntC9IwMICSc7aNNTTRmkgBSQAj4rMDmp2L0+j08Z22ZL2bAjcRbtF/U2rWr7 1AtCxQt0i/3YGE/XaJWBxlwwBa1a2F3yLoiZJSAvg/LiQDJ3PwuUwATGzURS5OXLwkHwCv4y pftRa+zL1Wzw671k01dc9kU8uNseuVvs2/SEUwYpIAWkgLcKIGQvt2pT7F5vx6hUDbOlbAvv WJhFw0W9TavaPvVyFwljSrAvoRMHd50gCrsxdxlt1wLrEk8D0c2YF7lo3LWt2uyENmBuAuc2 gFdQGv4SlNs53BgOW5994uLv3+iy74I1yxAWo2nRlUEKSAEpIAU8VADxekm9OODpq5cUaE+B TJeyoWmi3qbHp03qDfCrBc0laAJAAaYIoBvwfIikXuKsOTZwUzcANLcpphMFiyLLgobxAhxz 2wvbBYNuDzza4V3mDUcuw4a9/d+51mVfRDwYmxxvWnplkAJSQApIAd8UMHPvypW+NU3tKZ0C 8/9xPgM4ZLGUTdTbynxIkXppXqU3As5JnzTo0v5qDBpJva6Hgznp0s8BHxkEm9OCuUAESkNe WpfNmbgd9m0UrxeYy9BvdiAQMoC4lTFQHikgBaSAFPBEgdHRXbbe+fM9aZGaUVIFprZNzbp6 FpAXf7f/bnsWvZCtt2lV26Reeu66DgbmrkD0NLOri6FJPByMlW3tWsCCS7w2znapOtJlojX2 jd+lAu4NgQ2f4QIBR4imh0EZpIAUkAJSwAcFtm/ftUExtimenvahRWpDSRUw94aMnHpl621l YrRPvaRbgCZYFuZVeCPQ1ksaNp8Hd01bJPUib2BXYS5NM5yFcRcvlG8ew5aFKW1NW27UC8Wx oA3L2hDYwbX7Yn8HBThrZToqjxSQAlKgcAUWLtxl7l27tvC2qAHlVcBilmXk3iDqbWVutE+9 FleBhAoqBYxyCZrrY0DvW65pIxO7q9nMjssTfoTEriEZpZlTr7umzdwhzOTMUGiB5XFZ2HpN cTAuwpkhoK+xL2zA2ASklSFRHikgBaSAFChQgZGRXdQL/NVLCrSkgEVvyChmGRslD4emBycV 6iVQulEaWkNMD3PFezgE5MaWZtjGwjX6funBdU0PiTJIASkgBaRAgQrAsQHuDQjjMHv2Djg8 6CUFmlfAtmTLYiNia46ot+mRSZF6PWTW9pvUFPVSfZh43YVuCPgwOa0IOE3PTGWQAlJAChSm QG/vLnMvFrfpJQWaVMBdx4bzJnM3kVzU24RYTCrqjSfjFqgXqsLZd/l9t7lbGZcrrC8W5MFD Ayvzmp5PyiAFpIAUqIACCFvGqL2LF1egN+pCzgrksI6NPRL1Nj2yot4sqJfDcP8Tj7oRHgCR ZVniZsgu1+Sm7yhlkAJSoAIK2O7EnZ0V6I26kLMCOaxjE/W2OKai3uyoF0MCT193OzdAMFC4 xaHKMRtiUNBQrQjEOaquqqSAFPBJgZ6eXebezZt9apba4rsC+axjE/W2OA9EvZlSL0fljp/d 44Z3wIo3uEC0OGC5ZDNbr/acy0VvVSIFpIB/Cixduot6h4f9a5xa5K8C+axjE/W2OANEvTlQ L8YGC9rcfYyx3M3nzSwQhY223nK5I7d4DyibFJACUiCsAIL10rV3YEDySIGECuS2jk3Um3BE gslEvflQL3SHfReBzNwlbiPjnq4OFvW2eDspmxSQApVRAI4NpF5tTVyZMc2+I7mtYxP1tjiY ot7cqJcjhPVh7hK3RXdeD9/fFgcvs2yi3sykVcFSQAqURAFE7SX1dneXpMVqZvEK5LaOTdTb 4mCLenOmXowTIjnYcjGYfhesWeZbQF9Rb4u3k7JJASlQJQWwSwXBVy8pkECBPNexiXoTDEhU ElFv/tTLcYDLbO/IAB0ecOKVmy+W37FhwN8WJ5aySQEpIAXKrsCcObuod2Ki7F1R+3NQIM91 bKLeFgdU1FsU9WLAnnruWRh6DXz9CWoGIhf1tnhHKZsUkAKVUWDhQu3QVpnBzLojm5/c3HFF B45ZV8/KdD82tyP6GaLpYRX1Fki9GC14O3zgjquImIhu5kmkMFFv0zeSMkgBKVA9BQYHFbys eqOaRY+2/257z809pN7BscEsqogsU9TbtNSi3mKpl+CLNW0W28GHYGGi3qZvJGWQAlKgegoo eFn1xjSbHg1vHibyYjUbCDibSiJKFfU2LbWot3DqxZghqJm7hVvhEc1EvU3fSMogBaRANRQY GtrR27vreP3rd9l6X/GKFy/i05GRavRVvUhFAYvRC+pdP7E+lTITFiLqTSjUi8lEvT5QL8HX DeyAyL5Nj2V6GUS96WmpkqSAFCiVAuPju0iX0RvCx6xZO6amStUlNTZbBRbesZCGXqxmy7am UOmi3qYFF/V6Qr0cOdsKGA4PgOCmhzOlDFhXR4+LAtuQUldUjBSQAlKgSQX6+uLAV1u1NSln tZNbtLI8F7GZpKLepmeXqNcr6sX4WaxcQOclm74CG3DTg9p2hi1PbRX1tq2iCpACUqCcCsSY e2XoLeeQZtRquPB2r+imoRe7smVUS0yxot6mNRf1+ka9GEILlwv0hL8vlrs1Pa7tZRD1tqef cksBKVByBRqZe2XoLfnAptt8238Y7JvnIjbZelsfR1Gvh9SL4TTPWoAvQpvlDL6i3tbvKOWU AlKgAgpEmntl6K3AyKbXhcnpSXg10NA7NjmWXsFNlCRbbxNiMamo10/qxdDAuRYRfOlp8J7b L8eWFk2PbqsZRL2tKqd8UkAKVEWBsLlXht6qjG0q/bCd2LCaLZUCWyhE1Nu0aKJeb6kXYwn6 tF2LAb65WXxFvU3fSMogBaRAxRQImHtl6K3Y+LbXHUQoy38ntnCTRb1ND6Oo12fqxXBuffYJ A1/4+DY9wC1lEPW2JJsySQEpUC0FXHOvDL3VGtt2egMX3s7rOkm92J+inaLazCvqbVpAUG/n 3rN6j5+tI1KB7gNfunjRh5uWNdUMAF9zdbj+gdtTLTu6sMnpKXpWIJJaDtWpCikgBaSAjwqY uVeGXh+Hp7A2Lb17KZEXuxAX1ojfVyzqbVr/7du3j/n0+u5dY0tu8qlBY2PT09NNy5p2hrHJ cduyGBEe0i4+ojxE6j119RIYfXOoS1VIASkgBTxVYM6cnbF7Zej1dHgKaNbErydsEdvmJzcX 0AKnSlFvsfqnUPudm5869dKx+x/9dQplVasIbFNM8IXdVzBarbFVb6SAFPBVgfXrd8jQ6+vg 5N8u+Db03tpLQ2//d/rzb0CgRlFv4UPQbgP+ZtU4qPf9V9//m+deaLesyuVfdvfXCL7w9M0z pEPlhFSHpECVFcDPU+9Y0HfCvF4dqShw9aHdqZSjQqDAlVcXsJVDinf74u8uJvLCr3dqW/Eb U4t6UxzcAooC6QJ5efzt139aQAv8rhL7tPV/51qLZVbItm1+K6TWSQEpsAMuYge+tueSVWM6 pIBXCnx0+drX7N9V3lsUC9eIvDgQw8GHjoh6fRiF1ttA9wY78Lb1siqa89nnf7tgzTKCL/Yr rmgv1S0pIAVaVwDUe+Txvau2YHtzHVLAIwWWb5wsL/ViHwpz5x0cG2z9/kw1p6g3VTlzL4zu DXacdtm9T/xH3pvx5t7ppit0Qzp86cF1TedXBikgBSqtgKhXuO+nAuWlXmzDNvva2bTyYnMK f54fol5/xqLplrjuDQa+n/zyv7zwu/9uuqyqZ3BDOmz6xU+q3l31TwpIgSYUEPX6yXxqVUmp FyvYuld0W6gyvG3ibsw4qag3Y4GzLD7g3mDg+40fTmZZbVnLhpXXQjo88szjZe2G2i0FpEDa CvhGvX+7egsOY77A2yvXbXU/RbKPXLm678Jr8DeAiZ+/62n7COf2KUtwC3Gv3PSjbfw0cCB7 4CPkagpMrRYrOZwdbrXoywc+vSJQeLjXKATtQQmRrW30kRUbyOXq01SnMk1cUuq1nYdh7oXR N+37ta3yRL1tyVds5oB7g+vq8G+/+m2xbfOzdvj1EnwRWFchHfwcI7VKCuSvgG/Ue3DP3H32 P4Qchr847+joAAsSsPgpzwG1/JQvnBvLXnjDBn5kf3HFSmB6Q0ArBNlRkRXoloy84Y9ed/IZ ybEPLQ+UjHpdDHX7gpRvPP08K9ztNUnXNAnkYhWUK/wRyrHsbmOQ0q0ueacyTVlG6rUNKeDU C9fe/G/n+BpFvb6NSNL2RLo3GPiefe1m+TmEpUQMhw/ccRXBFycK6ZB0timdFKi0Ar5RL+GS tlv8JZwR10hyPAcv4hwHcNZo1ZIRE0m6MJ26JRh94rqBNQGRBlTaQZkMDTDDsDUMV2CUZQIW kuRgk8zICspEduNmg3sm4KdGojHUy/QUCsn4lrZeauWadQnZhOZTz17Cj+wbQrPW6yS9bidN 6ah37b+utaANKx9a6eFjQ9Tr4aAkalIj9wYD3+u+NZGooJolgokXhl6FdKjZsKu7UiBOAd+o 15gMwAQoJLrRvut+RC50HRuAccagBGKwKakL1+0jlmb0TF5kaa7bA6HWvULqtSvMaEboGfEu klyJ6eTygLWVjQxbuAO2XiagMgb9gW8Igba5pmIrP9DZGbuTQ4JyUe/41LgFbRi4a8DPh46o 189xmblVke4Nb192D64vX/MzuPZqt7ZGIsKpF7u1EXy1sm3mqaYUUqDqCvhGva5Bl2xKKDSD Llk2AJEBCDNvBP52b/hrGXGRTEmwBjE3Rb0wiyJjC7ZeNIwHOZvQzHO3kWyYNSnG1htPvRTQ DqI/qRflW2Ncws4BZxNWUSLqxQ4UXV/soqEXm7F5tYLNfYCJekv5OKd7AwD3im/8KwD3yxt+ ThMv3payP7k3euNj95uD73MvpBPrDeWgWIQHzr03qlAKSIG2FPCQes0ZgFwIxOQJCdUMmXYe SVGwxbIc+kgEvAVoqQVoIgH5LyH1EhBZZsC2agBqThFuw2g8trw4cZ2Vw6ZWt0ktUy9rtIM1 knrdjkAB39wb0M6yUC8Yd84tc4i8YN/p7dNt3ZBZZhb1ZqluXmVv+z+/I/W++4r78qqz9PVc /P0bCb7L77stlc5wqdyiO69PpTQVIgWkQG4KeEi9tLy6Xgfm5xD40T8QnMGlTPq24gj4rdpq OfIu7bXJqRdto4k0HDXCgJJM7HpHuMZptoc+vmwh+xso0HWxaJl6G3E5v0VAvYADcUIrbD7J ykK9tu0wPBwmfu21d6WoN7fnarYVXXDjQwTfXzy1LduaqlL65PSU+TmkEsjMdoCrikLqhxSo iwIeUi9MsGaMJGART12TLUnRdaslSgJ2udDNDbDgArQRpJldkT459QZYNsB/qN3cBgy7zXfW kB3gyw4yja1Fs9JQS8Cvl5ZpJgi7FLfj10u8Tu6gnA/ylsXW6+G2wzFPLlFvRR7rK+/c5eSw 7r4nK9Kl7LuxasvGFOM5iHqzHzHVIAUyUcBD6gXxEEmNXC2YgxlEwYtMA6IFsRHdXDcG+4h8 HF4ZRhTm9bSoN4YIA/bacJQGukygJWgwu2adpWcznSJw8FPXD7gR9VoWY3EzSBvmWjQM36L2 +m/rHf35qAVtGLpvKJP7M9VCRb2pyllcYVi7JtfeZuVH5LL33H45wXdkfLTZ7IH0ot42BVR2 KVCUAn5SLxnRAi8wcC+OgEsDPX1JhG4MBCRzP2IALzMbk3QZ7pdgTZR07bjMHojhELjSlNXT dUpGRlK7WyAX2JmRO+DwYChs+OvWTttwIH4wyw8cpF7SsJXA7jcVfripvreW2HPqBfJa0Aav th2WrbeoZ2l+9cq1tzWttzy11TZsa3PfClFva0OgXFKgcAX8pN6mOCnG6wAf+WbCjO8aLK8x DcanHi47a2qwkif2mXpd5O25ucfboA2Bx4tsvYU/b1NrgFx7W5Ny2d1fI/hifVtrJTCXqLcd 9ZRXChSoQAWoNzlIKWWJFPCWegPI63PQBlFvgY/WbKuWa29r+iLWWO/IQPvhe0W9remvXFKg cAVEvSUCwVo11U/qxQZs5tgAK2+JkBePGtl6C3/eptYAufa2LOUdP7un/fC9ttdxWgGAW+6O MkoBKdCUAqLeWqFkiTrrIfWOjI/Y8rXSIa+ot6kHo++JzbX37Gs3+95W/9rX/51r2wzfi0i9 LKFN/2D/tFGLpEDFFRD1lggEa9VU36jXRd75/zi/XFZePsVk663U09xce5/5zfZKdSz7zmx9 9ok2w/eKerMfJdUgBTJRQNRbK5QsUWe9ot4A8pZl+VrgkSHqzeQZWlSh5tq7actUUW0ob73X P3B7O+F7Rb3eDv3WrVvn7v4677zzcDGLBm/btg0IlUXJaPAZZ5yResmQYsWKFakXW64CRb0l AsFaNdUf6h0cGzTHBlh5S4q8svWW68k8c2vNtfe6b3m9JeDMPSkiBcL3nrp6Scvhe0W9RQxa ojq3bNlyyCGH4K+9gHrA4ESZm0wEML3mmmuazJQoOXuRKGkziaBDRg1uphUFpxX11golS9RZ T6jXRd6FdywsL/KKegt+1KZevVx725R0bHK85fC9ot42xc8ueyQvkoNZ6dNPP7169WrXRguT LWyruA47KK3C7rk1FSVYAlxELkDkkiVLcMI0yIsEVlG4j+EEuEKDccAaHUO9jWpBIegXWm71 IiWuuBdFvRBH1FsiEKxVU32gXhd5+7/Tn92DOp+S5eGQj8751WKuvf/2q9/mV2uFarpk01cI vojj21S3RL1NyZVn4jAvgnJAvcRBICDOgao0APMizJ+4SITlp3aO9Gw8rtCyixPkxRUALhLj RZ8BFogESBbpnOAmMNszTlh1IEsj6o0sBHSLQvAR20+AZi/QHlzHRVK+qFfUWyuOLFdnC6fe pXcvNceGCiAvbnZRb57/fPOo6xs/nOTWxDetz8RtMY8+FFoHwvdyWRv+4jx5W66451biMvZ7 S55LKXNQALyILUxdz14wn8Gr8R9hl6xJ6qXJNnBOPAVBGpUimZGlQSS504y+SBxwnyV5hxOE eZcSRVJvo0JcRwu0H61FCbhodl+ALx0bRL2i3nKBYK1aWyz1AnMNeRd/d3EOz+ocqhD15iBy rlUgegOp991X3PfC7/4717qrUpkta8NJ8j6JepNrlXNK8iIgL2DmNJTkR6RD+s7Sgst2Rp7j U5dijR3thKxsJYfNvUbYgVoaYWgk9TYqxPXfcNWmSwa7Keo1ZeThUCuULFFnC6ReF3nh5JDz Qzu76kS92WlbWMl/+/WfEnzHHv73whpR5ooRxcy8e7HELWFXRL0Jhco/WYAXXdutC8RGqAmp 16zFrsW0EfWi8ICtlwhuahhbN0u9kYVEUi+t3agILQf4inpFvSXiv3o2tSjqrSry4pYX9eb/ LzjzGgG7pN6/WTWeeWUVrcC8e2975O6EXRT1JhQq/2RhK6l54uIXf3PwRcM2bNhANp3R1gvW dHEz7CZLd2EXagMRzQIJ6IPrAnRAqEhbb0whBuU4gaU5kD1snM5/XPypUbbeejKl/73On3qx 8UTfN/vMsaFKVl4+cES9/jx4U2sJHBvg3kDw1XYVrcn6yDOP2x7FCc29ot7WpM4hV+RqNnj6 gnFRO9d4MdyB+fvOSL1020UyFO7GQeM50ZlsjQS0LocjBAcS0Ok23tZrBmmc2HI0txYWgq6x LzzBX/I9A0pwNRupXX69EEHU6z//1bOFOVPvxK8nuld0G/JiW4ocns85VyHqzVnwnKrDUjZS Lxa35VRl5ar5wB1XEXw3PnZ/ks6JepOoVEgarBjjr/nuC/xnLgegQ9puycHEIPu00Tk4kmva XNcFXHSdGfAREiBZo00xmABZbJ0ZrkTuc8FehKkXrQ0Xwi6wU1aaXUF/GeyMeXF99Oejvbf2 4oCZB9YdO9b+69rNT1Z/h3NRbz2Z0v9e50m96yfWz752NpF31tWzKom8eOKJegv5L5x5pQhb Ruo9+9rq/8fKSE2L3Qv8TVKFqDeJSkrjpwLuXqNm6XFPYAHChkyg4UpysKjXf/6rZwtzo143 KG/ndZ0V/q4r6vXzf1AKrbLAvT99fDqF4mpZxII1y2juBQHPKAA8gJl4clrbQc+olhL4pcCM 1BtG4SpxsKi3nkzpf69zoN6AI++cW+ZMbavyvzBRr1//e1Jszbr7nqS5d/man6VYbK2KMpC9 +Ps3zthxuP/CF+L+Jx6dMaUSSAHfFMD/ubHJMTuGNw/TyQFBOuH2gJ87Iw3AgYs9N/fQQQI/ lY5PzfxF0R8RcqDe4bHpY05Z8NfHz9NRJQXe+8mrM0XnrKk34MiL+73Uuw0neaSIepOoVMo0 v3nuhdMuuxfUi7/YqbiUfSi60QDZU1cvoQUX4cyKbo7qlwKFKUAsBg0P3DUADjb/v3gaBgdj byf/fy3NgXovWTV28FGvXTW2SkdlFFi+dvk+++5fXuoNOPKufGhlYc+XHCsW9eYodu5VXfGN f6W5987NT+VeeUUq/NKD60i9iGVWkS6pG1IgDQXwwyg5GFwLDoYvYAwBg5IX3rEQfhR+/nia D/X2zDt+C7bY01EVBTZObiwv9bqOvF1f7CrXjzPtPMBEve2o53ve+x/9Nan3k1/+F9/b6mv7 Wt6g2NcOqV1SICsF8NsoOBgWo3gOhgEYBmNEjciqHc2XK+oVi7egQEmpN+DIi6+suNL8TVPW HKLeso5cknYjcO/7r76f4PvEfzyfJIvShBVobYNiKVlJBRiO114ISYaAYln0FAHF3F0wsqgi hzInpycBwXD2jfQMxkV8hARIlkNjYqoQ9bbAfMpSRuoNOPLi+2ext17+tYt689c81xr/fvRx Ui9Ocq24QpW5GxTD9FuhnqkrTSsA3gXpYqMHvLjnGa40XUqCDG6Q4ATJfU8CMzCcCLFWBr+l NoqMVqABuNTUu3rL6vYBFIXc9fRd7ZdTqxJKR70BR15EIfT9wZFB+0S9GYjqU5Ew8ZJ6saYN 69t8alqZ2tLCBsVl6p7amliB8E5m5GArADQMM627JwWu4FPu/cZk7jmvID0+xcv2qoAJmYXw BNfxKYuyF8uxLIk7UXBCWJvgDYzov5H4W4gBuFjqxequ/Q/ZH4ch45Wrr+SV08873S72zO3B lQuvuZBXkOvkM07GFewyiL/49IYNN1hifhQ4cHHd1nUumKIQFstC3PKZjOVYpbzIlABlHOFa 7ApSxiQgrEe2k1JYXqb89IpPo6muIPGddbvTqJHsV2QjUVeg12GgLxf14lul3XG1cuQNPO9E vQX/A8ihelvTtvLOn+dQXSWraGGD4krqoE6FqdfduxifcqM1bjVMubD3L9/SMMz90lwjMbdE Ri5uFMyt1KxY7mZMtmb5+JTbCyM9LnLD4TIOTRIDMPwfcnA6LJZ6yZHgTrPagu3wliRqsOWm ARZbAsNWXMF1psdFA1kyn6U3m26jQpDXRW1kDFMvW+vyopUfoN7wdYPmyHbaFwAUzryUBW3A udu2SOoNVMeWu1jvErBRb7iRvHL2krNjrNdloV7cQXDeNeTFF84c7ilvn0iiXm+HJrWG/eKp bTL3tq+mbVC86Rc/ab80lVBSBcLUC/sruBPd4e7E7BcMtLhIYy1ObD/kwDltt8hl9lqALBMH qJfew4RdnMCcbJ4VNBKXVE9rdowBGNbf/u/0Zxr+zBPqNbgMQyoR0CCYCczw+aNtPzLMdanX pVValJELRlOkAfvyLTIiO3PBWsyLRnssthH1ukQYmTLQ7DBBRuZisuTUa8U2qi7wpSLQjMhc /OLhfusoqa0XwRlctyKEbij7s6LN9ot62xSwHNll7m1/nLADBUOYYefh9ktTCSVVIEy9ACaS KD4CjFq/LCU+Nc+ERuf0i6DhNky9rusw6yL+0gDselOUVFW32bBCwd0QmBsOhYbd4DIy/RZO vWQs/NwPtIITAnmLREjzrWvpBLaGgQwUi0ICtt4ArbqIaYUY8pLqWJHRXm2pF18AKkC9iBVo C0kRPRB+vRV4RLTZBVFvmwKWI7uZe2H0xXk5Gu1ZK5974fkTbvk4qLd3ZAC7V3jWOjUnJwXC 1EvHA1Kva3NNTr2MCAHYRXaUloR62VuAMuzEdHXIqf/5VoPoZojyG3D/bcr0m3CjqcKpl84G ZE3yKAiYAEqDrkufROTI3/obeSaApFmsYTQLDBdC5saLfgVpUS/64h60N1v5MC3TX4JHRrZe 1BJohluRa9ZFGxrp41p8ffZwQGBs13Ue3xjxc0q+t6+ntYl6PR2Y1JsFp176OcDum3rhNSkQ +xLT3Ktth2sy4uFuBqiX7g2EXTrsWhbz0I239ZqDBDNa+a6HQ9jWC0ozrwk49dIAXNUX/n8j AHDY9DvnljkwZcVwLT7CP/sk4fcLp176G+DACXiXbOr+8u7+Rp8EyAJ+vQRZY+hGOEukC9fV poeD1W4nRttsZ+BF8E3dwyFQi2GuVWQuv0yJt/HxMbylXtwX7u6JiA9YZ0fewINR1FvV/xTB ftkGxTL3tjzkd/zsHlLv8vtuCxeCoGaL7rwe0R5kCW5ZYf8z2no1QGfAzgpPA/onAGQZ1pfd iade+irAastcZridkXpJ28xl/sT+C9hOC+H5EI78gP/uCIgWacdCpAjYiZFgRvAtnHqNNelZ S/zlRRyBX9ubol5b64YTl+FYSDgkgvn75mnrpTuHHQw0kTr1xtt6afk2Cp8xgANa6CH1Bky8 mPwg4HZuuurlFfVWb0wb9kjm3jYHG1xL6j119YuRqqxMY2Itd2tTZ5+zA0/Bo/YK+NQCYbmm zXXwRWLbySLyHMhFOzEoFgUyr8XrDQTuNRMvrofr8lm6tNqGLS2SmH5h6DXz8Izg6wP10sTL v2aGdC+afRT0FumcgOsWmMz1TGCkhUCWRm4SWPTGBhC70/JwCC8Fcz0cIhEzdeptZLgNrGaz ABrmJN2o8b5Rb8DEi6+Ifm4AntajoLVyRL2t6VbKXK65F5sVl7IPRTca1lyC75andi7Pd1+r tmzkR1j3VnQzVb8UqL4CMaZfkDENvXbEg68P1Gt+t64J1r1ocRUIpnjhxIAsfhUarcV4WSEW tizAdgFDctgkbI6/gdC/VYrhYP4h8Tt3+EO9cGBwPeBl4o15/Il6q/+/we3huvuepHfvBTc+ VK+ep9Tb2x65m2j7pQfXiXpTElXFSIHWFWhk+t3jqj0Cy+BiwNcH6jWadHE28iJI10zCwGKY Kom8Li6HGdRMmMbK9ms+F5MBf+2KbXhh2I3sbppwSK946g0sI8NbNiMyV8xqNtQbKMpF//jI ZWEPBy6qC+eC7LSOM6qG57ZeLPp0vd5l4o1/moh6W3/aljHnC7/77/dffT/BV+beFkbwqeee JfUuWLNM1NuCgMoiBbJQAP4M+HkX69si93ub0eLrA/Waa28AKIlfjSjTXaHlBmQI0yQilIX9 HMKLyZAm0vrrVkRX4wALxlBvYBkZ39KroVnqDRflekfEU284LxWLzGVfJMI9tY4XbuuFiRcx /mx6I7yJvHhnfLyIemeUqGoJfv2//+9PH5/GsfXJ56rWt1z60/+dawm+W599Qh4OuUjeeiXY 2uDSuy8dmxxzj/ufuP/x3zz+wn9pg+7WhfU2J5a1nb/x/D/67B81wt9Ii68n1AvTI2DLonqR riIv8iPgKUywQDc3Uq+by7WD4jre0lDqOifgIoygKAR2TdQV+Zu+VYRkyB6Zhu0M1AjUDlt5 eYUpI3OxC5aXEYWt8TG2XssSIPJGbaDU8bkCw+GWXCz1Bky8+Mqn2GRJnkui3iQqlTUNVsZg IXlGQewt8H5Z1Wm13ea/ixNRb6sqZp4Py/bD6/1njHWVebNUQfYKBDx6w/gbBl9PqDfmx3R9 5KECRVFv2MQ7dN9Q9jdWRWoQ9VZkICO7ATDFbzpZ4Ck3kaqydo37Njk9RVvve26/XNTr4RyA o6f7qx+hJ+stbT3UoZ5NckM3xHg7BMBX1OshU/rfpEKoVybeNp9sot42BfQ6u1Evgx8xsj1i 2qPRDL3E1vMiQzIh9BIv4oRpkItXkMBeQF7bOtVrCbJpHHiX4As3X6tBMRyyEbuJUmECGbhr wHbgZKxW7Duv8D1NiFjypDMaeg2Fu77YhS9I7K6o13/E9LCFmVLvip9s/+jGtX/9xVP3WDwL 20wAdmXiTeXhJOpNRUZPCzHqBbwCUhFGFDFBYf2F2wPj4TO4PRGWcfVxAt5lvH28cAXpufUU zy0vzmsSGz88ugjgQOodGR8V9fow+2Hhw2987nZEgBsQsHjXh9HJrQ3AgvAWbjEWXwNfUa+H TOl/k7KjXiDv4V+ZH5i6L73mpXZFXrwtP1VEvS1LV4KMAepFi3mFVl7wK7ePsu2guE2UbTrF HpKPmd68GtzzEgiRdhMfeeZxUi/C94p601a36fJWPrQywDoIXWlmvKaLU4aSK4Chx+JFfAvC 157eW3uBtjOCr6jXf8T0sIXZUe9JI4sbTVr8liUv3nYeUaLedtTzPW9y6jVvB1KvATF6SDux S8kBAvZdhWzah8hlBF9s2MYaYPflFcT0zaZOlRpUYP3E+u4V3e6/B1DOjNvPSscaKoBoHpgt cHfBNyJMEtcNBli8dnTtkcf3IqZAdsclq8Z65h3vIbqpSS0rkBH1Dm+e/pMrZ0VS78uXv1yB Gtp8fIl62xTQ6+zJqZe+CkgPwIXzLu273EYVH9Ek7KJwzW29UOP6B24n42IjYk4CbMnGK4HY Dl5PkdI2DsY8sIv7j6Hn5h5cLG2H1PC8FYA7BCYMfigACr/rq+86Ys5J2SEvShb1tgyX3mbM iHqX/2jyxSfbZzo65nR0fPTFXQbzvk8qV5+ot3JD6nQoOfXSi5eOvCgArg7kWr64AC5gAIan hDk8VFnEBn3DjsRk3Iu/f6OoN88JAFMH1na4vLvTVveva/Nsg+qqmAKl83BgmF47EGo3EEYX EXkZgtdFRqRhFsagxad2zvQ83HC8VhFOGtEn0jMZdq9g8GArwYp1IwTjU0YIRnocaEZgJwg2 zL0Y6A7a73bf1YGNDOhj0YjTBeg8qBchaN7b0bFvR0dnR0dfx6wrZlXs1su/O6Le/DXPtUaG LYPV1uKX4YRGXCxZYyhfejXgPBDjDG/xsqgOlp4d4Ke5dsazyk5dvQTUe8ItH3/uhefRNNl6 sx4fLE1b/N3d3N3gzos1+1nXq/Irr0DpqDe8pxr3b8M2YwS78H5j2GkisGsxt2rj3mZMz5e7 LwPT4OVu/Oayo23eS4RlYpwQfK1Yt2FuMqvUperwHnKB7tjGaYHt1mwHu0h9YnrRGg1nRL34 ZaDzut0ct3Z+yV+MMeiYNXvWwMDA5ORk5W/J7Doo6s1O29KUTOotTXO9aegV99xKcy/svqLe TIcFP0YvvXtpOCQZrmdarwqviQIlpV5YTIGDOEC05DzDvgAmhpEXnNeIes1CbLlieBG0ik+R hZiLHdRYLCk2QL1IY0TLvdkAzSwBL9vXzbDYdhuOpF50md13D/Ir1TB9kMBAObDfcmu8y1zZ US9iloX9evEA/OHPfjg8PNzV1TV//vz169fX5PZMt5ui3nT1LGVpblDeUnagoEbDo9ddviZb bxbjgJBksOYqJFkW2qpMU6Ck1GtQCAIzoCTVuZgImgxYeQltYeo1rwPzEyDvxlCv8aXhI1oF kKXBOEC9wFCiOTcZtgPQjCNMvUhJ14hG1NuIWdkqVx9D4cBFP6kXXwjO+OaQu6YNz0CE7LUZ Ozo62tfXB/wdGhqamprSvZxcAVFvcq2UUgrspsDWZ58g9V6y6Suy9WYxOeCtGwg7pZBkWeis MitAvUZ1tNQaJuKEdBvw8W1EveRFsiadFmiLbeThYDZUJMC5eTK4jhbIzuthRI6ETtbLxIHu MD0rDdt6DabD1Gs6uP4b7SBvprZeLqxEMIfT//7qPzt9NsKPRN6kcHVYunQp2Le/v3/z5s26 kZMoIOpNopLSSIEIBV74r/+EUy+oF1HMRL3pThG48M7/x92CtCskWboKqzRXgSpRL/HUjKyu E23Awhpp6yVQcm0c6dMQsxEjAkxd/1pmiaRet0YkQHuQ0g7jUdZrnArrdUK/XqvX/D240M18 jhuxe2v4m52Hg4UTWb5x8jX7d8Xfrdu3bx8ZGZkzZ05PTw9O8FZ3d4wCol6vpwd3CU6liQhG hpdbFDdjw2vJkiXuXsRtVodFbyiT6+Qq//rAHVfR3IsFbfJwSGu4R8ZHXJcGhSRLS1iV00iB ClMvbaKur60RXiT1ki+RhU69MPS61BvgVCsKzglI6S5ogzND2MMhQL3uEjrXnMxyzKaLczpp mNcym0R7sHsYNxv1utCfopWXHfeEem1Wj4+Pw+jb2dmpFW+i3rI+7VMMi+vGHaMctsOwBSmz cA3t6FUr6l1+322k3vufeFTU2860Yd6AiVe7ELUvqUpIokCVqNd1CTCUND8E851t5OFgjg20 4IJ9Xep1OdUYNBCVjB4R/DTg1xvwcDCGZl1miDXqNaeIwFq9Gc3ProdD5Eq+1oy7gVy+US+n +vT0tK14W7tWIR2DDwDZepM8EgtL04h6aQNevXq1tQznuOKabJnGrkRSrwXc5f4UZgwOlI+3 +K/AKhi/DCe4yNrxEStiexAWDef4yxMmtmYArPnWshcmbhoV24I2bMy26Rc/IQHjPI2ya1dG wMSrjeZrNwOK63A1qJd2TXcZmbtuLLwoLdLWa6BJcoWfg4uYblhf4jULcWHaSBeJE65mC1Cs S72I2mvuEwFbb4y7QsCv16A/XXOvn9RrtxFWvC1cuFAr3gLPFVFvcQ/aBDVHUi8v8i85FRCJ 54J5LOAKNlTDp3BdsI0n4qkXWSxBuHyryz5CXagR5MqNMOg+gRP887CtMXiCLNzpzd3gDQ3G FW4IV+qXu6ANTg5w8O0dGcDFUncq/8YHTLxwb9BG8/mPQp1rLCn1WmQuQCfNpcaF4Xi9FsmB vgcxtl5jRNfNoBFimpmWFl/uWNHI1huOXEaqJjpH2npRpoU2C1NvfOQyN1yDWYvdPTjatPh6 Tr28o7niDW4PWvFGQUS9Xj/qw9QL0AQv0hUBtlU8KWBMNfzFdRpccYIXuJP460KtdThQON9G lm9ATLzm5hQW5Zc7WWD/Nl4JUC/bQ/5mLpRG47HX0idrnC1ow44VyXIoVVABAK7rxYtFbIBg ySQF8lSgpNTrriEjaNp+ZmHqBeHZsjOaZhvZes1Ay5i78e4EtksFG2B+tG4ANXxksR0soG8g PTJaJF3X1kuSZrEB6g10n2/dYBEu9Vo7YzaZaxaCS0G9dh9xxVt3d3fNV7yJevN8tDZdV5h6 aSVlQcaX4W0mzMrbFPWiusjyY6iXXrxm0A1TLxHZigUcs1N4PFXA1ouu2YK2Z5//bdMDXO8M 2FsYbgwWjB3sCyeHekui3hejQOmoN7zjLqMuGLdF7kiMBFz7RfIL70hsROjuCcztf2NgkTtN EFVxuJF3k+xIjMIDjgcM3+syKLfhsIuNdiRGGpqcqU+gWEjE7gfCqzULu5a+XNTLW2tiYoIr 3hYvXlzPPd5EvcU8ZBPWGqZe2ndpKCVKws5q3gJkSlp/Ab5IQ+8CnMR7OMD4imLpmxsuP4Z6 DWfZjHjqNU9ft2EJpfA2mS1oG5sc97aRHjYMJl53rzWZeD0co/o0qXTU2zKoKWOKCpSRenlT Y8XbypUrucdb3Va8iXq9frAzzAJo0l5oLs23/IhoC1S1BOY+yzTGzZHU6xZuS9nC5cdQLynZ KprR1us6DVfD1msL2lZt2ej1ZPKmcTLxejMUasguBUS9KbJgfYoqL/XanV/DFW+iXq+f+7Da wkPAfbG5vOLGxKUXL90JLA0T8CJjL7i9dQsPxCwLlG95Yay1KnCCtyw5UIWbhjUGMgaa6vUY zNQ4W9B28fdvnCmtPt8hE68mgYcKiHrrg6op9rQC1MubsVYr3kS9Hj6B1aQyKWAL2hC9oUzt zr2t41Pjrhdv53WdjbbZzL1pqrDuCoh6U2TB+hRVGeq1+78OK95EvXV/3Kv/7StgC9qeeu7Z 9kurXgnbf7d96d1LbdUaTvq/0z+9fbp6PVWPSqqAqLc+qJpiT6tHvbx/q73iTdRb0qd03s1+ 7vn//Onj0zye+Y22+d5Nfy1oi5mOm5/c3L2i25AXJt7Rn2sXj7zvX9UXr4CoN0UWrE9RVaVe 3ixVXfEm6tW/g6QK3Ln5qVMvHeOB86TZapDOFrR96cF1Nehu0i7KxJtUKaUrWgFRb31QNcWe Vpt67aas2Io3UW/Rj9tS1f/3o48b+D702P8qVdszbKwtaFt05/VWzeT0VJ03acNOEwEvXpl4 M5yCKro9BUS9KbJgfYqqCfXy3qrMijdRb3sPy/rlvu5bEwTf0y67999+Vet9GbCObdndX/vw +qGFd1x57Fc/dsyqjx371cW9tw7MueVCnON4523LwME1ZN+xyTF3u7XF310sL976PSrK1GNR b31QNcWe1op67X4u+4o3UW+ZHs0+tPWF3/333379pwTfd19xH9x8fWhV/m24/4lHsQvxMasW xR9Y6JZ/24qtcXBs0N1uTYEaih0O1Z5EAVFviixYn6LqSb28odwVbzhPcpd5kkbU68lAlKkZ 2/7P7y648SGz+NbW1aH/O9fOSL212rANBl1ssWbI23NzDzakKNPMVlvrqoCotz6ommJP60y9 fFRwxVt3d3eJ9ngT9db1Md9ev13wBf5u2jLVXnmlzA3P3RNu+XgM+NbK0ItYDV1f7DLkRWwy rGYr5biq0fVTIAfqvXRk88v22rNn3vE6KqPAXx/X8+oDD121ZUd2x/KNk6/Zv8v/O5Ir3jo7 O4eGhqamvOYBUa//08nTFgJ8/2bVuC1u++bYrzxtaJbNsugNkexbH0PvyodWzrp6FpEXJ3ib peoqWwqkrEAO1AswAvhesmpMR5UUAJVmh7wouSzUyxsSvLt06VKwLwh48+bNKd+lO3Zs374d t2qbxYp62xSw1tnh43vFN/7VwHflnT+voRxYrxaJvDUx9MKgu/COhWbihbkXe7DVcBqoy6VW IB/qzRSPVHglFSgX9dpDYO3atXPmzIHnA/wfgKrtPBwQOwL24yN7ejo6OvaYNev43l6c4DWv t3d4eLgFu7Kot53hUN6dClhUB+AvzoHCtdIF+7FF+jnUwdALt1047xry9n2zT7EaajX5K9NZ UW8lkbECnSop9fLJgFVuixcvhukXf1tY8Qan4U8vXXpQd/e5S5euGR/fsmOHe6waG/vgwMDB 3d3XDA01Bdai3so8t4vsyDd+OGkWX0R4qBv4hv0czvzWFUWORy51IziDG54MoRtyqVaVSIH0 FRD1VgAQK9mFUlMvb9TWVryNj48f0dPziaGhB7ZvD/Cu+3ZsevojS5ceO2cOTMIJnwui3oRC KdkMCqy770kD309++V/g9VsryS763rDr51B5Q+/AXQNueDIE6K3VcKuzFVNA1FtJZKxApypA vfasSL7i7fujo6+bM2fj5GQM77ofwRJ8eE8PQDnJc0nUm0QlpUmkACI5YOsKsi9Cmz3zm7a8 eRJV6U2iZ5//7Ym3XETwPe22Zd60K/2GBDZdwwZsuJJ+NSpRCuSogKi3AoBYyS5UiXp5Q8+4 4g2+EEBeGHETIi+TAZGPmTMniZuvqDfHJ2sNqkLsXgPfs6/d/MR/PF+DTu/q4rp/+xGp94eP 4x6s5gs23c7rOs3KC4uvwpNVc6Rr1itRbyWRsQKdqh712qMlcsUbPHTh2HDHxERTyMvE8PTF ErcZH12i3hklUoLmFPjFU9uwZ5tt3oa3zeUvc+r33H5578hAmXsQ1/ah+4Zcr4a1/7q2qj1V v+qmgKi3AoBYyS5UmHr5kAmsePu7wcHFg4MtIC+zvGPhwjVrZ/jHJOqt2+M9j/6CdGHoLWTz tq9//esnvelNRR3z3vGWExadUVTt4XqPf8MbLrroovaHHJEZEJ/BkLd7Rbc2XWtfVZXgjwKi 3koiYwU6VXnq5UOAK94OPvjgV+yzT/zytXgg3jQ1tV9XV3xIB1GvPw/eSrUETr3nXfegrW9D kIccuoe5vtdes9dt3KSDCrz5lFP/9E9f2lRUl/AwIf6uu+kaovMqPFkOk1lV5KmAqLcCgFjJ LtSEenmzj4yMnHb22Y24dv9DDrFj9ZYtjZIhoG/8Thai3jwfrfWqK7BrMTZy+81zL2QqwQ03 DH/sgosB3DqgwCOP/XK//Q/46KILIUvLsgc2XRve3HpRLbdBGaVA1gqIeiuJjBXoVK2o963z 5980OhpDvWcvWXLhNdfg+NG2bY2SfWp4+JMDcX6Got6sH6e1Lh+Be909LN5/9f0/fXw6I0Vg 0TzggAOAekJeKrDogouuvOYLEASytGbuXfzdxebVgEVsm59Mf4fJjCaDipUCTSkg6q0AIFay C7Wi3v27uhpFK4NxF/uxkXrvevrpGD+HGde0iXqbejYqcSsKuBHN4POQkbcDFoSe8Z73CXmp wK+mpvfZ51VbJ5/BOWSBOE2NHCIzuI68vbf2yquhKQGVuFwKiHoriYwV6FStqBdc2whnAbv4 tGfuXDo5xIAvuBn0HPP8EfWW6+Fc1tYihJnr5puFt8PRRx99970PinqpAKy8sPXyHLJAnORT B4CLKLxm5V1699LkeZVSCpRRAVFvBQCxkl0Q9RoHr9u6FefgXVAvILgRH4t6y/gErmab4e1w 0/qttr4tXW+HzZs3H3vcG4S8psDBhxz24wcftrcQBxIlmViT05Pu2jX49SbJpTRSoNQKiHor iYwV6FStqHev2bMbbU4B5L1hwwaSbjz1Yp+2I3t6ZOst9QO5Uo0fe/jfLZpvit4OS5cuvWzw KlEvFQDvgnpdNSAOJJpxJiFcw+xrZ9PKO+vqWesn1s+YRQmkQAUUEPVWABAr2YVaUe8h3d2N 9qegh8OnV6w4/bzz4j0csB4Oq+JEvRV4LFenC/B2wH7FZvRNxdvhsMO6XdNmzfH3ssuvunhg iSvCQw8/dsABca5OmF6jPx8F6RJ5wb5au1adW049mUkBUW8lkbECnaoV9S5avHjZypWNXBew lA28C9deM/pGpjx36dLlQ0Oi3pmeefo8XwXS9XbA5i6HHrqbabPm1HvMscd/7wf3BkSId3IY GR8xR154OGgTinxvCNVWsAKi3goAYiW7UCvqHR0dnTd/fssbszHjQd3dQAJRb8GPVFUfqUBa 3g7Llw99YuBvak661n2EKkP0hrAaSy69bHBwMHIgBscGDXl7bu6Z2jalGSsFaqWAqLeSyFiB TtWKevHMgUsuHHNbBt/r1q9f0NcX/+xSDIdaPdu96yy8HT755X9p09sB++6GTZspQvDjT/76 /ocecQsMvP3BPz8QuILEuILrP52YZEacB44UW+gW9bnrbzrn3PPDhcMDBH4g4RnQ/51+Q975 /zhfEcq8u0nUoOwVEPVWABAr2YW6Ue/69etP6etrmXpf29MzPj4u6s3+kaka2lAA3g4r7/y5 gS/Wuq2778nk5XEXYoSnzQgiUeyyz3z2DXNOtPIBr/YWHx140MF4ywMfMZldwcmFFw3gyjtO exfOkdjSh0E5lS68/6yzb1zx1ciiIBS2OzdtEZQXmGvIC/zFleTKK6UUqIwCot5KImMFOlU3 6sUj5fzFiy9r7N0bA8TnLV16daxHL59XsvVW5rld7o7c/+iv3dgOMAD/4qltSbqEL3ZHHnV0 KrzYqJBG1Lvi5q8DZGEJZsZ/uO3bIFqcDH1++KwP9VtpuGiAGygqi2YfceRRjeIWu669sOnC mUFBeZPMMaWpvAKi3goAYiW7UEPqhSVrbm9vzNbEkeB7xcjIjL4Not7KP8lL1sHfPPfC3379 p2b0xcnfjz6+7f/8Lr4bIyMjC886Owt8tDIbUS+Qd93GTW7VMOgChUnD5tvg2nSzpl7YvPfa a69Glu9zPnL+ypU74+8qKG/J7g01N2MFRL2VRMYKdKqG1It7Hb9Jzuvt/cTQUBJXhwe2bz97 YODMhQuBy0meE7L1JlFJafJTAEZfbGDhbmaBKzHVDwwMYB+yrKkXkQLpnGAuCqgR54a2bACg FgdPmBJGX5eMs6ZeWHlh622kBoSCXArKm99sVk0lUUDUWwFArGQX6km9fGx8eulS+OmuGhuL YV8sX0PQhuuHh5M/aUS9ybVSypwUgH0XVl7X6AsbMEgusvq3ve1ta769IWvqjfTrdV0X2AC4 8JJ6ecDKS/w18M2aem++5Rt97z6zkRpoxuHvOVxBeXOax6qmPAqIeiuJjBXoVJ2pF88PeDDC 6Lt3Z+eZvw/lCwLm8anh4dP7+/ecPRteDZOTk009aUS9TcmlxPkp8G+/+q0b3uG0y+795tiv wtVjhdbWyWcKoV74M8CF162agBu27xoKZ029iy64KMbyfcVdn3OD8sLPIb/hVE1SwGMFRL0V AMRKdqHm1MtnxtTUFHzzsIcFCJjHJwcG4NzoLs5O/nQR9SbXSikLUADxHNxVbudd9yBomO1A 8IefPj79iv17Hn/6/y2EemHKBebCi5e1A3bBwTihXy/tu0jjuv9mTb2BAA7rHtmE41e/3hng 4uLvLnGD8ipCWQGzWVX6qoCot5LIWIFOiXpTf2aIelOXVAWmrABWuS1f8zPX4eG6b02s/edf ue6/V/3jo0/++vmM2DcQkwEgayEacM6QZDhc3waCL4OUIbaDNSxQVOoNfvs7F4ys/haKvfHH X91raC/D3L/64kF2fsrIKYpQlvIcVXElV0DUWwFArGQXRL2pP1pEvalLqgIzUeChx/4XDL0u +wbOz7/hwezAN3U8zajAE+eeBBszkNcYN3Dysg+9vFkvqEyGU4VKAZ8UEPWmgoxf+cl/L7tj 6uwv/vSD140vWjmxfNNvUym2zoWIelN/Toh6U5dUBWalAFwasMrttL+9txH7/sOmXRuhZcSU /heLAA7f+X/u3uOqWZHUO+/vT0Zs4xm3rslq/FSuFPBVAVFv+2QJ5AXvBh7On/zGZPsl17kE UW/qzwxRb+qSqsBsFfjGDycbUS9Wv/kPppm2cL/9D/jC6IpGht43j5w6d95J+Aef7QipdClQ NgVEve2TJYy7kU/mwQ2/br/w2pYg6k39WSLqTV1SFZitAljfJupthM777POqT2+4vBH1Hnzj YaDeVd8U9WY7RVV66RQQ9baJlTf9+IW3L4v+FQ7eDm0WXufsot7UHyai3tQlVYHZKjD28L83 ol6saUvXkgofWW48YbtR8C2OH/zzAzjc6pgY69UCW1cwai8O26QNmxgHQp6l1WzYem/a9LVG 1Nu35kxQ7+CqMSwEhK9IoxDI2Y6fSpcC/ikA6n35nrOPPL5XR2sKHHtqvz2W33LJpqPe9Xf2 9pRPrm+tTOWCAof1zNl3/y7/7pgSt0jUW+LBq2fT4d3rRm9wCfieh/89LXzklhOIz0BgRTQG hmLACbeiYAwyC+aAlG5iC2eGxAzv4KYHLrvbXqTY5mOOPX79XT+ETTcSfNeMbzj00MMeefTf TMArvvGvWCZYz4mkXksBVwGAr14tK/AP/zTmPooPeuM5OHjlzCtaLlUZdyowMTGhWzVFBUS9 KYqponJSAGF63SC+fLbetH5rivhIwLUCgbyMxYuLZuKFyZZpQLSGv3gLWy83K4b1N0C3eAsg zo56GcPhe/92rxu2jAR8zj+dj7btf8ABiOGATZ7df1FnX7sZO4AgQlxO46dqpIAUqJACT/zH 859Y8S+Bn+AMfBF3skJ9VVdKr4Cot/RDWM8O/OKpbYjae8bgj/CoRcyy7/3Pp9NFXpQGzAXL BtwYIqnXvchmICND87pBfHEdyItis6NebEeMTYlR0SP/v1++ffWC/W44ALx74i0nIZYZGzZr 1qzt23fu7YxNngP/pbD7HSS1TUDqOa/UaykgBZIrwLg6fJK89dO7mXtxBeB76Lx+PKuTF6iU UiBrBUS9WSus8rNVoKOjI3XetQLplgCoBarSK5cbT9gBB4aAVZh5zaXB3aIC18m72VFvYG+2 /3975/dix3necf8FkW+i+MayimOsYCtdE+L4QnICptROmyqmSIgmStwKqzI4sgiyLUckCq4t Uyp7SVC8qBAvVCCVErQ4oihqA1uTNsJYYa2LRFGMESbEm1402+BSQXPhfJKXvozm/Nhz5syP d2Y+h8MyOzvz/vg8c/Z855nnfZ5BMuAK9uCrCJk7NEKavMjnLv7ivf/9TbWWs3UJSKDNBHjm ls2hzvM3VlZk/6sQSfXo408dPXq0zbN07F0joOrtmkX7Np/bbtv8xps/rU74RhUbYhVCCeKw lC2uWhvq6w1hD4O+3kpV76Gnj/AeRePfX3/zzju3xCtk4dxbY6p+8B1G0AjPLvt2RTlfCUhg PAFuiXkulKuXGe6T+ck9M/klWXYcGkH1Kny9otIhoOpNxxaOpAiBHTt2hBq85b7x7OZCckMI 76DADfEMwekb3iHeF00c6hJnB4bPuNK4XlBQlHgUCv4Krkh5zLrA7PcZWZAvXFotYhvPkYAE OkeA/wbZ9cSsClh3RazCt3NXQYsnpOptsfEcenAkjPFuziKFQ1oGFofxjrp2qOqll5DPAQdw WMEWRTA7QyP8ie0ggtmmnZgErcQsZri9SV42atZHvvY3hw8fzl42Y9LAZYUvoXtebBKQQM8J sOA1tx6A/wzcPE+CReE7CSWPqYGAqrcGyHZRIYGlpaWQXaGKN35Z9CtqNWYiQ6riyh3aV1i+ xvFo3OwBg43QQpS8IcVviYPfsGHD1Wu/HNrgw3++68yZMzlj4ModE+fAn1yCXeHla9MSaAkB 0rxkY3b5vzHtMjWFb0tM3fFhqno7buDOT488XGTjKlE1tr2pkLxs6Cy2fvQPV1ZWcpcEX11j VO+TJ1cm9OV0/kpzghLoJwH+RWTvjdG+KOBiKBS+xbh5VokEVL0lwrSpZghs2HDzKO9m2yVs gfHve+zxZ5//u8ET31ldA1RIW5Z7jVrW9uln/u1HP/tVM0a1VwlIoGkC2cRk4d6YCIcZE3sr fJu2at/7V/X2/QrowPwrWtBWQHGmcMqoBW04gO//5CeHmnYnGSAAABMWSURBVJtl16PK3eHX OfuDn3fgInEKEpDAVARYo5ZNTMa/iLJWtSp8pzKEB5dLQNVbLk9ba4DA4uLi7r/Yk4LiTGEM v/fpbuBnbjBf/KtHFxYWRpmHZEPZOIc/+cpru5/7j7iHwsWm723gyrZLCTRBYExisrKGo/At i6TtTEtA1TstMY9PjsDa2u+e3aegOBMZA8nLBrO5fehDt6yujktA9tg33ogyl5LFfPMhduMe 8hNNu3gluQvFAUlAAusRwKGbrfeOu3fdxGTrNTn87wrfYtw8a0YCqt4ZAXp6EgR4dj9qCVci SrTOYXzjxN9TpC3b45jwhmi/uKwtG9LAdly4zQYu4STs7SAkIIGyCfAfo3BismJjUfgW4+ZZ sxBQ9c5Cz3NTITA/P//Xj32pTmWZcl+s7SPIITvCAwefPHbshXWtRTE23rnDfvLOr3H0Rqcv icyMdliXpAdIoF0EBhOT1VOXUeHbruukA6NV9XbAiE7hffOX5VR4Ln8Zyd1AtO6FMkrOsj/r BOKhp9EO68L0AAm0ggC3tdnEZIQ3FE5MVmy+Ct9i3DyrGAFVbzFunpUcATM5ZIVvNpNDrhBx YcvxXRg9vkY7FMboiRJIhEAVicmKTU3hW4ybZxUgoOotAM1TUiRA/QWqMKQceFDz2O7e+tHv v/Y6nQ4tTlHMhLiFsjnOjv/TFWtYFCPpWRJolgDVyLOfZbbZ0+CQFL4Nwu9V16reXpm745O9 9xOf+Od/ea1mcZlsd3/74je/+JePAgQsJRp+MNqhnvi/EqdgUxLoM4HLb69lE7bwAIfb1xSC 9RW+fb4sa5u7qrc21HZUOYGlpaVP/+mfJStDax4YKXtv3XTbA3/0x2ApHf0//Ou1bLRDWenr Sx+nDUpAApEA4fi5LA3IX0RwOogUvunYoqsjUfV21bI9ndedd27Ztv1+34HA5s1/sHHjxoou Bb4sjXaoiK3NSqBcApQRJj1LthINH940ExEqfMs1va3lCKh6vSQ6RYBMBcu+/p/AhQsXLl++ XJ2B+Sp98uRK/CrFb2S0Q3W0bVkCBQgQusCTmZh1m08rWRrYk3JEvsK3gKE9ZUICqt4JQXmY BCQwnEA22oEv1GbXxGgkCUggEqDKTPaBDJJ34dxb3Kymj0jhm76NWjpCVW9LDeewJZAQAaId slVMeZaasicpIXAORQLVEKCoeLa4DHqXAuPtehSj8K3m0uh7q6revl8Bzl8CpRDAgZTNdW+0 QylUbUQC0xIgvWA27gi9ywczqSVrk89I4Ts5K4+ckICqd0JQHiYBCaxP4Nvn345hvnh/ze2w PjKPkEBJBMgSg0M3u2QNdy9O35Kab6YZhW8z3Lvbq6q3u7Z1ZhJogsAbP/2vbLQDbqd2PVdt gpl9SmAmAjxpIWA3q3f5DBLU241AI4XvTBeHJ99IQNXrFSEBCZRMIBftwPrxxNeMlzx/m5NA XQTQtZQKz95n8nHjkUsKVSdKZKDwLRFmz5tS9fb8AnD6EqiKQO7LeO/x13EDV9WZ7UqgfwSI IMqlaDh2+setSNFQwFYK3wLQPGWQgKrXq0ICEqiKAF/AuUBDap929Vu5Koi2K4EBAtxA5qoK E0pE6bVuo1L4dtu+9cxO1VsPZ3uRQH8J8A2dTaLE09g0i0L110LOvD0EhlYV7s9TFIVvey7V REeq6k3UMA5LAl0iQPRhNr1DyKbkKrcumdi5VE2AhyQ8KmlFVeFKUSh8K8Xb+cZVvZ03sROU QCoEkLnZnL58fyOFu7HMPBXEjqOLBFiaxielXVWFK7WDwrdSvN1uXNXbbfs6OwkkR4AlONkl 5yzH6c/z2eSM4YDSJhBSkmU/Ly2qKlwpWoVvpXg73Liqt8PGdWoSSJQAvqvcs1oWvbnKLVFr OawmCPBgJPcZaWNV4UrJKXwrxdvVxlW9XbWs85JA6gSokko6s2wtN5KdpT5oxyeBignwuchl PuEz8pVXLre0qnCltBS+leLtZOOq3k6a1UlJoB0EQo79bMAigb8/eefX7Ri9o5RAqQSoHpwL fEfv4vHtfEqyWSgqfGeh18NzVb09NLpTlkBaBH75q+u4srKL04ll7FhxqbSIO5rECBDsnn3u wWeBW0E+BXw0EhtpisNR+KZolVTHpOpN1TKOSwI9I4CjK1toim329IyB0+0XAW7tzv7g57n6 avxKBW/v+qa6FBS+U+Hq88Gq3j5b37lLIC0CfNPj38o6ffEB6+5Ky0iOpgwCrN0kGVkuOQPF XCjgYi6/YoAVvsW49e0sVW/fLO58JZA6AeJ6c9GNhDaqfVM3m+ObjABXMtdzNpad2zzKCy+/ +Z+TNeBRIwmMEr7nz5/ft3/fxls23pR5bZ3b+vThp69cuSLQXhFQ9fbK3E5WAq0hwJPfnCcM rWA5t9bYz4EOEOB2bjA5w5MnV8xXXeLFkhO+y8vLqNvtD25/ZuGZC6sXLr1/Kb5Pr5x+/IXH b99y+87dO69du1biGGwqZQKq3pSt49gk0GsCIUV/ziuGbnBJe68vixZOHl2Lus2G7rB97PSP vZKrMGYUvl89+tV7P3Uv6jYrdge3j505dtfcXWeXzlYxGNtMjYCqNzWLOB4JSOAGAmpfL4j2 EiA5A9ELWb3LXdw3l64asVOpTY8cObL1nq37j+4fr3fjX5fXlh/47APPvfBcpaOy8RQIqHpT sIJjkIAE1iGg9vUSaREBVqQRosPqtKzeJWKH5AzWIKzBjnse2XP4W4cnlLzxsId2P/TK4is1 DM8uGiSg6m0Qvl1LQALTEQjaNxfvS8yDZaum4+jRlRHgEkXaDiZnQASbnKEy6jc0/PLCy7v2 75pW8nL8D6//8J777llZWalnnPbSCAFVbyPY7VQCEihOgARng8KCuEm1b3GmnjkzAZIwDC5W I7yBIIeZ27aBSQmsrq5+eMuHiVgooHo5ZfHi4sfv+/iknXlcCwmoeltoNIcsAQm8/77a16sg BQJkZiBON+fcJbDB5AyNWOfAwQOH5g+Nkbxnr54dL4gJ8F1aWmpk8HZaAwFVbw2Q7UICEqiK gNq3KrK2O5YAy9H+cfmdXORuqCRMij2TMzR1+Wy4ecMoR++eQ3s23bEpvE9dOjVK+x5fOv6Z z36mqfHbb9UEVL1VE7Z9CUigcgJh8VCusivONmsaV46+Zx1wpRGxMJiGDL1LHUH+ZPBug1cE 2XlJVTZUzuLipULFUyee+t6730P1zm2bG6V6ie79wM0fuH79eoMTsevqCKh6q2NryxKQQK0E hmpfAivVvrWaoaOdkXN3sKYaYhd3L05fM5GlYPb5+fnPHfzcKDkb/btI3jGql9M/MvcR17Sl YNAqxqDqrYKqbUpAAo0RGKV9z138BeEQjQ3LjttJgHKA3z7/9mAkA4G8hPMS1NvOaXVz1FQY ptza+LDdZ089i9OXn2MOo5YbRYy7yaj3s1L19v4SEIAEukggPIkeFCsUxNL120WDlzwnbpC4 TcoVmAjJd0nUQLoGIxlKJl5Gc1945AtHF4+OkbNB8u7Yu2O8Mt7xyI7FxcUyRmQbyRFQ9SZn EgckAQmUSGCo9iUCGEcdbrwSO7KpbhBA0XJrlKsezK97j79O7Lg1JlK2MrWI9x3dN0rRTih5 OZ3gYEKEU56pYytMQNVbGJ0nSkACrSEwKihTKdMaE1Y8ULIucCOUWxCJ2A03SOZkqBh/Oc0v LCzs3L9zqOoNi9hw9Iag3vHu3tu33H7lypVyxmQriRFQ9SZmEIcjAQlURoDH1qMW4PvYujLq STeM7xYPLjc/g85dPL74fZMevYO7kQBSFcE6VPW+9OpLQe+uq3ovrF7YeMtG0XaVgKq3q5Z1 XhKQwEgCo5KtskSJdfouUer8pYOJWaM2NGyXnUT0GsnQ0mtg0+ZN37323WKF2cJZRAYTH9zS 6TvsdQmoetdF5AESkEBnCYwqrMUyOIoem46qS4bHmshZPLiDddRCJMPCubcM9W67xV+af+nz Bz8/i+o1bVnbr4Hx41f1dtu+zk4CEpiIAM+yCXIYfMxNPQKCIlqR8uzq1asPP/zwRLOd5qAT J07s3bt3mjPSOpaQbuTs0BgGzI0CRgdzTFqDdjRFCVBd4u65u79z5TvFhO/XF7++55E9RTv3 vBYQUPW2wEgOUQISqIcAz7WH5qsKZWYT10aXLl264447Sgf1/PPPb9u2rfRmK20Qly3RuhRL w3CDdzLsIYyBCAdDWSq1QlONk37h/gfvp8TatMKX0IiP3fex1dXVpkZuvzUQUPXWANkuJCCB lhFANuEgHLqiH/mL9zfB4Icxqvfdd989derUYDIm9rCfv0bz4DBmT3ZnW1Qv/ngyMZNvYTBJ cxC+WBPb4dRvhee+ZR+YxIb74vyL5NydSvUury3P3Td38eLFxKbicEomoOotGajNSUACXSIw KuVZKEWblAIepXqRsPiADx06RKACG+haDMRPttnD/riTbdy6yNxwZFDJiatecopREPiJb/1o qE+XnXh88fuaeqxLn8pJ5oLw/V3a3bXlSbTv6ZXTd83dZY7eScC2/RhVb9st6PglIIHKCYxJ eRbEFgqY8FCiIxpcDjVK9Ub9GiRsiP3lJ9sBHBvo3bAz+n0RvuGABFUvgSi42wE+6IwP5iCK F1c9rl8rqFX+2Ui4A1TsrZtvPTR/aEy0A3nKdu3ftXVu67Vr1xKeikMrjYCqtzSUNiQBCXSe QHiMjqIamvQqPklvRAEPVb25nfFXpDDbg/ZiJ8vXggM4KdVLSAl+91HpxuK6NG48Egw+6fzn ItkJrq2tHTh44IO3fPCh3Q8dO3Ps5PLJ+P7y/Je3P7id1LwvL7yc7PgdWOkEVL2lI7VBCUig FwRSU8Czq17CG0KEA0ERCN8GVS8+2stvrxGZQJwuaTRGRS+wn9gG16X14vM2wyTRvmfOnNm5 e+f2T22P7ycOPnH+/PkZWvXUVhJQ9bbSbA5aAhJIikAKCnio6iViAa9tjFtAzoaEDPxkOzBk g9iG3OlB/vLXeiIciLtlnRk5kgnDHbUcLWpf16UldfE7GAm0iICqt0XGcqgSkEALCEyogHFh 4qRkJRZOzVLWWgXZikiNr7A6hwhdJGxI18ABr776Kjv5yTZ7wgY/gz4mvIF2wmq2kKa3CtUL ImbN3FkOOGYhWpS5JCADF4ElzUZOt+Dic4gSkMBYAqpeLxAJSEACVRGYRAFHbYePE23HM31c nsSwogunGtZ7772XlbxsxzXpwZtL0EJ2lTrb6FpecWfcw/EkeUABMwB2ho1ZXmTGZf0ZKp8J Di2NlothIGya2OjAwTjdWch7rgQkkCWg6vV6kIAEJFAHgakUcM7NiQQsxR9c3Tz/+3/+D5nO m9V+qFXeQeOOWfYX54gODp5vlLGVI6qzkS1LQAKqXq8BCUhAAnUTCI/4QyQrT/nRfKOScEVp iCKse5TT9LduMG7Wm0tUA7MO0R2kIZumH4+VgAQkUJyAqrc4O8+UgAQkUC4BPJ0IwaGO0vaq XgQ9sp5JofIT91iXa01bk4AEUiOg6k3NIo5HAhKQwA0ECGxFCjdY/2ISexCDEaRteIe4ZN7W iZiEnsdIQAL1EFD11sPZXiQgAQlIQAISkIAEmiSg6m2Svn1LQAISkIAEJCABCdRDQNVbD2d7 kYAEJDArgZB5N77IREa2slkbHXY+acvIdFZFy7YpAQlIoEECqt4G4du1BCQggSkIoHdRulSR 4BVS8IZCa6W/Qurf0pu1QQlIQALNElD1Nsvf3iUgAQlMSiBWCY4nBB0cfw2lJdDE2T1I2LA/ 1CXObofD2B9KUfCneGJsJGxwQLbCBXvYnztl0ml4nAQkIIGGCKh6GwJvtxKQgASmJDCoerPl gkP8A3uyPuAQDsGeUGQ4/DVsBxEcKhIjnXmFA4KiZTtu0AKncGLYySu0GXrPyu4pJ+ThEpCA BGoloOqtFbedSUACEihMYFD1RnmKIxZJGsN8kaShjHCQp1mpGreDwEXOInzDTqImQshEVvXe dNNN0ctLF/wJl3Dsi21jIQob1BMlIIGaCah6awZudxKQgAQKEhhUvUHs0lxw4sZ2ow84e8qo bZQrejecMqh6o383aOgQ8MAG+1HMubCHghPzNAlIQAK1EFD11oLZTiQgAQnMTGBQ9RJdEHQq mhUNWkD1hsAGfuIbxuk7oeoNjuEQKVHRirqZadmABCQggTwBVa/XhAQkIIF2EMip3hCHgPoM GjTrlEWPhnDbdX29IWghzD9q6Fxcb6QTfL3EUcRYXrazLbSDo6OUgAT6SkDV21fLO28JSKBt BOIashDPEGIMspKUX1Gl/DUuVltX9YaVavGs7CI2Wo7yN/QSIxzCurd4VttAOl4JSKCnBFS9 PTW805aABFpHgCAEtGZ8ZRONhblwQEitEPIzhD0x9HboNkfiuA2r32Ka3sGN2FpYMMdZQXln +2odTwcsAQn0jYCqt28Wd74SkIAEJCABCUigjwRUvX20unOWgAQkIAEJSEACfSOg6u2bxZ2v BCQgAQlIQAIS6COB3wLt6c0W3DcOmQAAAABJRU5ErkJggg== --------------050607020303030608040006-- From nobody Wed Apr 29 10:16:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6197B1A90D4 for ; Wed, 29 Apr 2015 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 DDKkSPqvkzwD for ; Wed, 29 Apr 2015 10:16:51 -0700 (PDT) Received: from ntbbs.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 801AD1A89FC for ; Wed, 29 Apr 2015 10:16:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1126; t=1430327804; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Y0ogeWzIPMCEuwy8BUYHpjHVko0=; b=VjdGQ4TznKHnOONzVjdA IdjSKtGnQNObSFMII7vFpXpshkOqH4LS8COfI6wwjzBuYAKKrcHauw2pOawQgxNJ 6HV04+dU49VGsu65KpCahAnWwDkgnXgxVncNJkDHP3C3p4r0Ja4ampz0sCZ9udSC l8hTMuwQMYRP8vsJ0md/Bfw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 13:16:44 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4037804541.2434.4976; Wed, 29 Apr 2015 13:16:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1126; t=1430327545; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yLTO6tH ZcBg6J8kBiOxBm8oPPtQ72gb8HFoy4vzsFf0=; b=tXS0qZ9n0+cDd6ZOcIv9erz ApdheiTy/RKE7m58vhdK2rmLGJk+e5AQ63k9FPSYM7ntJcviSL0zIpcVqSoCROeO zhsw3tsleuzFShmXirKxOdy+zo/rDyHSBxbc+MizmzQQF16+K4RcoFLijZLP48Fd o6gVjpoLeNzFnAzll9i8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 13:12:25 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2630081316.9.3268; Wed, 29 Apr 2015 13:12:24 -0400 Message-ID: <554111FB.5040801@isdg.net> Date: Wed, 29 Apr 2015 13:16:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:16:54 -0000 I downloaded OpenDKIM source code to see whats it offers. I believe I saw: o ADSP was no longer supported, pulled. Grep showed one instance of an inline comment referring to ADSP. o ATPS was offered, but I failed to see how it was hooked into ADSP because it ADSP was pulled. o DMARC was offered. ATPS was suppose to be based off the ADSP record with the optional tag "atps=y" I believe that is how it worked. If the "atps=y" was present in the ADSP record, then ATPS was supported and an ATPS_Hash(ADID, SDID) lookup was done. If OpenDKIM is popular among many big systems, it would make sense to slightly update OpenDKIM so that the "atps=y" option is based off a DMARC lookup. The change is small. Maybe Murray can explain how its setup and triggered in OpenDKIM. Once it is in place, systems can finally experiment with ATPS records authorized 3rd party signers. Larger Systems or any system can explore registration systems, proprietary, free or otherwise. There would be no more excuses with an 3rd party policy solution made available to help the legitimate MLM resigners. -- HLS From nobody Wed Apr 29 11:26:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B9C1A890D for ; Wed, 29 Apr 2015 11:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 Ey6NSIaM0dB3 for ; Wed, 29 Apr 2015 11:26:17 -0700 (PDT) Received: from secure.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BDF491A897A for ; Wed, 29 Apr 2015 11:26:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3265; t=1430331969; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=h5cJgJAfhNs4SJthdZlezDli1xw=; b=akwISOYjx+kQ3pSQR2Mw /YzKIzqnqKUNAgc8k8dqW036/1qDw0vicCuvOmP4rcznFTcCqmXpqQfne2vL2xn2 o1+Jr9dTQLJC51pN/ZDo/M4E4TBMbJUpv71e99s0IRUfByDOWYXYtV1uMhuDgbN/ vK91wjnqtYBRAVwh0XdHuEg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 14:26:09 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4041969862.2434.1644; Wed, 29 Apr 2015 14:26:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3265; t=1430331708; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Z6PrRYk wiaJxxlaYvjovNDp5T5GqRQxyO7kQxP7VOD4=; b=vBVZpcJ34/esqTdQ6oj71Do rn4qIrB936R53A3+nRgFD1to/Z3BpiYvCoQYaZqswDl8hFdcF+0+M3p+GY6ahGHm kaO9TFBgCNkfxLHOZ5Q9GA5jHpMzIsLLOx/IX8weY9a8cBaikjJvIdrqddrqNt44 MXwYU+CdsSN5EoRr0+Ac= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 14:21:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2634243645.9.11420; Wed, 29 Apr 2015 14:21:47 -0400 Message-ID: <5541223E.6020703@isdg.net> Date: Wed, 29 Apr 2015 14:26:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin , dmarc@ietf.org References: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> In-Reply-To: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 18:26:19 -0000 I think overall, there are two concerns I have: 1) The over estimated use of the idea for "rewriting" and 2) the word or term "common" is used for mitigation methods. Common means most and its not the case. Rewriting is a major industry taboo, in all mail or communications concept. Just because one or two renegade MLM wrote a kludge for their site, puts it on a wiki, does not make it legit at all, not one iota. The doc infers that RFC6377 provides guidance, and it immediate jumps to a Rewriting "common mitigation policy." Thats not right. In fact, RFC6377 preaches ADSP or in general the DKIM Policy framework. I don't support Rewriting, its not common, its not a BCP. It reeks with IETF appeal problems. I don't think the doc should legitimize any idea of rewriting. Other comments... The doc should make a note that DMARC is an informational status domain. It is not a proposed standard nor a BCP. It is very incomplete and it is missing lots of considerations. The 3rd party issues was intentionally in an attempt to avoid a complex design issue, but that it could not avoid. The doc fails to mention technical history with SSP ADSP, ATPS, or any of the RFC documents products such as: rfc4686 Analysis of Threats Motivating DKIM rfc5016 Requirements for a DKIM Signing Practices Protocol rfc5518 Vouch By Reference rfc5863 DKIM Development, Deployment, and Operations and possibly others. The docs should explain why ADSP was abandoned and why its "Super ADSP" [sic] version called DMARC replaced it. -- HLS On 4/28/2015 7:49 PM, Franck Martin wrote: > FYI > > Please post more reviews... > > ----------------- > > A new version of I-D, draft-ietf-dmarc-interoperability-02.txt > has been successfully submitted by Franck Martin and posted to the > IETF repository. > > Name: draft-ietf-dmarc-interoperability > Revision: 02 > Title: Interoperability Issues Between DMARC and Indirect Email Flows > Document date: 2015-04-28 > Group: dmarc > Pages: 20 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperability-02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-02 > > Abstract: > DMARC introduces a mechanism for expressing domain-level policies and > preferences for email message validation, disposition, and reporting. > The DMARC mechanism can encounter interoperability issues when > messages do not flow directly from the author's administrative domain > to the final recipients. Collectively these email flows are referred > to as indirect email flows. This document describes interoperability > issues between DMARC and indirect email flows. Possible methods for > addressing interoperability issues are presented. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Wed Apr 29 12:09:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602A81ACE08 for ; Wed, 29 Apr 2015 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4mlN3LR-fhcK for ; Wed, 29 Apr 2015 12:09:44 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 0F9301ACE45 for ; Wed, 29 Apr 2015 12:09:39 -0700 (PDT) Received: by wgin8 with SMTP id n8so38892009wgi.0 for ; Wed, 29 Apr 2015 12:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GLEhUcJ9LL//8MWzeG7SATEcO61pwfuXngrnGITPRmY=; b=Dxi3slIeEIfHf1Jy1hQKND/w2QoZB5cUvL1D8cSBmOaneM8ugFXFvZDCtbeTc2gahn YT+BY/mLaiZ2KDnCr2NHnimOHycdevaIDf7aifB8S7cPgU9p1GZ70sg902FChz4jj87N 1rSFSgfoUvehipPHdHFREZFhkrB542qdBYjd3nIJYdp+fNkzO51ph0gUDvcroSCzpYMT J0JoKE4OIhIzs/X8BtY5WKD0i4nWqlhZwQ5RSHC55WDzS3VWgriLHsgu+RBYUntyUpSa 9R9CDFg/cph555krHiv6fdKe4BhxuZLxnaPEFcZN7gllGpbDm3bjQ6cAM257MrV1dIwF 33Sw== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr1012649wjr.135.1430334577773; Wed, 29 Apr 2015 12:09:37 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Wed, 29 Apr 2015 12:09:37 -0700 (PDT) In-Reply-To: <554111FB.5040801@isdg.net> References: <554111FB.5040801@isdg.net> Date: Wed, 29 Apr 2015 12:09:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7b86d3e66b12650514e1b825 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 19:09:46 -0000 --047d7b86d3e66b12650514e1b825 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos wrote: > I downloaded OpenDKIM source code to see whats it offers. I believe I saw: > > o ADSP was no longer supported, pulled. Grep showed one instance of an > inline comment referring to ADSP. > Correct. > o ATPS was offered, but I failed to see how it was hooked into ADSP > because it ADSP was pulled. > It has nothing to do with ADSP. o DMARC was offered. > OpenDKIM doesn't know anything about DMARC other than the fact that "dmarc=" is an Authentication-Results field is not a syntax error. OpenDKIM runs in the milter stream before OpenDMARC does, and OpenDMARC consumes the results OpenDKIM provides. > ATPS was suppose to be based off the ADSP record with the optional tag > "atps=y" I believe that is how it worked. If the "atps=y" was present in > the ADSP record, then ATPS was supported and an ATPS_Hash(ADID, SDID) > lookup was done. > Nope. See RFC6541. > If OpenDKIM is popular among many big systems, it would make sense to > slightly update OpenDKIM so that the "atps=y" option is based off a DMARC > lookup. The change is small. > Sure, if that's consensus. That would also involve promoting ATPS to the Standards Track, but to do that we'd need to see some hope that widespread deployment is likely. But we still have that pesky registration problem to deal with. > Maybe Murray can explain how its setup and triggered in OpenDKIM. > If you enable it, you just have to name which domains you authorize to sign for you. -MSK --047d7b86d3e66b12650514e1b825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos <hsantos@= isdg.net> wrote:
I downloaded OpenDKIM source co= de to see whats it offers. I believe I saw:

o ADSP was no longer supported, pulled. Grep showed one instance of an inli= ne comment referring to ADSP.

Correct.<= br>=C2=A0
o ATPS was offered, but I failed to see how it was hooked into ADSP because= it ADSP was pulled.

It has nothing to = do with ADSP.

o DMARC was offered.

OpenDKIM doesn'= ;t know anything about DMARC other than the fact that "dmarc=3D" = is an Authentication-Results field is not a syntax error.=C2=A0 OpenDKIM ru= ns in the milter stream before OpenDMARC does, and OpenDMARC consumes the r= esults OpenDKIM provides.
=C2=A0
ATPS was suppose to be based off the ADSP record with the optional tag &quo= t;atps=3Dy" I believe that is how it worked.=C2=A0 If the "atps= =3Dy" was present in the ADSP record, then ATPS was supported and an A= TPS_Hash(ADID, SDID) lookup was done.

N= ope.=C2=A0 See RFC6541.
=C2=A0
If OpenDKIM is popular among many big systems, it would make sense to sligh= tly update OpenDKIM so that the "atps=3Dy" option is based off a = DMARC lookup.=C2=A0 =C2=A0The change is small.

Sure, if that's consensus.=C2=A0 That would also involve promot= ing ATPS to the Standards Track, but to do that we'd need to see some h= ope that widespread deployment is likely.=C2=A0 But we still have that pesk= y registration problem to deal with.
=C2=A0
Maybe Murray can explain how its setup and triggered in OpenDKIM.

If you enable it, you just have to name which do= mains you authorize to sign for you.

-MSK
=
--047d7b86d3e66b12650514e1b825-- From nobody Wed Apr 29 12:35:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD21ACE9A for ; Wed, 29 Apr 2015 12:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 wWSKEraItwsf for ; Wed, 29 Apr 2015 12:35:44 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id F01431ACE8B for ; Wed, 29 Apr 2015 12:35:43 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id CF4708A3C for ; Wed, 29 Apr 2015 21:35:41 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 29 Apr 2015 21:35:41 +0200 Message-ID: <0D7E7B5FFB8F4981A4DDDD5E7AEB5598@fgsr.local> From: "J. Gomez" To: References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 29 Apr 2015 21:35:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 19:35:46 -0000 On Wednesday, April 29, 2015 2:04 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez suggests: >=20 > > > > That would force DMARC-compliant Mediators to reject (or = accept > > > > but not resend) incoming email from p=3Dreject domains,=20 > > > > irrespective of whether such mail passes or not the initial > > > > incoming DMARC checks. >=20 > Something about having mediators (ie, non-MTAs) implement this check > was bothering me. I realized that the nagging thought was the > *Mediator* doesn't have to do it. How is a Mediator not an MTA (among other things)? Didn't we agree that = a Mediator is an actor that does both the role of Receiver (MTA-based) = and the role of Originator (MTA-based)? Original Originator =3D=3D> [ Mediator's Receiver role -> Mediator's = internal process -> Mediator's Originator role ] =3D=3D> Final Receiver. The important point is that "Mediator's Originator role" SHOULD NOT = inject DMARC-rejectable messages into the public email infrastructure = (but I don't care if the Mediator rejects[*] those messages at the point = "Mediator's Receiver role", or at the point "Mediator's internal = process", or at the point "Mediator's Originator role"; that is an = implementation detail specific to each Mediator. [*] I don't care also if the Mediator *rejects* those messages, or = *forwards* them to /dev/null, or *transforms* them into non = DMARC-rejectable messages. The point is: Mediator SHOULD NOT inject = DMARC-rejectable messages into the public email infrastructure[**], how = they achieve that is 100% up to them to decide/solve. [**] And if they do inject them, then such Mediator SHOULD be labeled = and non DMARC-compliant and the DMARC specification SHOULD spell out = clearly that doing such a thing is a VIOLATION of the DMARC = specification. (Keep in mind DMARC is not mandatory for SMTP, so email = actors can always choose to be or not to be DMARC-compliant.) Regards, J.Gomez From nobody Wed Apr 29 12:47:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CE51A0107 for ; Wed, 29 Apr 2015 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 xt0opHw5pLxb for ; Wed, 29 Apr 2015 12:47:23 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0F51A0158 for ; Wed, 29 Apr 2015 12:47:22 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Wed, 29 Apr 2015 15:47:21 -0400 From: "MH Michael Hammer (5304)" To: Franck Martin , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: AdCCtU2TR9WZGmMYSjqY/KOulDXP5g== Date: Wed, 29 Apr 2015 19:47:20 +0000 Message-ID: References: <246357292.45499.1430264919058.JavaMail.zimbra@peachymango.org> <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> In-Reply-To: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.230] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 19:47:25 -0000 2. Causes of Interoperability Issues This section focuses on intended recipient perspective but fails to mention= /discuss the originator perspective where some subset of originators, parti= cularly for high value transactional messages, want the message discarded i= f it passes through an intermediary and is modified in any way resulting in= a failure to validate. Examples of such messages include those related to = financial organizations and medical establishments. 2.1 (This is just a nit) Last paragraph SPF can provides two Authenticated Identifiers... This should be "SPF can provide two Authenticated Identifiers..." > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Franck Martin > Sent: Tuesday, April 28, 2015 7:50 PM > To: dmarc@ietf.org > Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc- > interoperability-02.txt >=20 > FYI >=20 > Please post more reviews... >=20 > ----------------- >=20 > A new version of I-D, draft-ietf-dmarc-interoperability-02.txt > has been successfully submitted by Franck Martin and posted to the IETF > repository. >=20 > Name: draft-ietf-dmarc-interoperability > Revision: 02 > Title: Interoperability Issues Between DMARC and Indirect Email Flows > Document date: 2015-04-28 > Group: dmarc > Pages: 20 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperabili= ty- > 02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperabilit= y/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-0= 2 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-interoperabili= ty-02 >=20 > Abstract: > DMARC introduces a mechanism for expressing domain-level policies and > preferences for email message validation, disposition, and reporting. > The DMARC mechanism can encounter interoperability issues when > messages do not flow directly from the author's administrative domain to = the > final recipients. Collectively these email flows are referred to as indir= ect email > flows. This document describes interoperability issues between DMARC and > indirect email flows. Possible methods for addressing interoperability is= sues > are presented. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Apr 29 13:18:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D191A0E10 for ; Wed, 29 Apr 2015 13:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.88 X-Spam-Level: X-Spam-Status: No, score=-99.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 ALbHhxyuNXx8 for ; Wed, 29 Apr 2015 13:18:32 -0700 (PDT) Received: from catinthebox.net (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 949581A19FE for ; Wed, 29 Apr 2015 13:18:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2067; t=1430338690; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=DvZEHoCchvRjH2ghCiD+6Prve/4=; b=fSAz1CZyRQ2tKet5wAMu DVrdqrsu/7rkL9Ko3fIwK4ZC4O4SAb6a0ndBOVWNyX8UMyhY2Qe1gbU/Wi2uM2/b t1iXLb8dU4LG+GuuO/antgU8rzC8w0QkygFXVZWgz0oT0lC76FUR2oLdHlOI8J/K ij3CAeTYcjiPCRg4One4O5M= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 16:18:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4048690057.2434.3344; Wed, 29 Apr 2015 16:18:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2067; t=1430338433; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FZbz7N4 JOOvJmu7E2ER6PyWY4TBTqEoEA21pZR7l6RE=; b=Y6BVdnLQklju5QwKL7gqG1W enXBnZXwGRyQZZLSPNkLDoctjxT+fQ1qEEHVkt5tkQVQ1AhjVynuiLix2dJbd0LK zjXACIaSnu3vivcrGiPjznNJzAJpvo1WzJU1tznwd1c3LYHGRLCHIp0BBSFkjxYu RmDPjV0Te9DwbwwuDd+8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Apr 2015 16:13:53 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2640968863.9.7420; Wed, 29 Apr 2015 16:13:52 -0400 Message-ID: <55413C83.9050408@isdg.net> Date: Wed, 29 Apr 2015 16:18:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 20:18:34 -0000 On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote: > On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos > wrote: > > I downloaded OpenDKIM source code to see whats it offers. I > believe I saw: > > o ADSP was no longer supported, pulled. Grep showed one instance > of an inline comment referring to ADSP. > > > Correct. > > o ATPS was offered, but I failed to see how it was hooked into > ADSP because it ADSP was pulled. > > > It has nothing to do with ADSP. > > o DMARC was offered. > > > OpenDKIM doesn't know anything about DMARC other than the fact that > "dmarc=" is an Authentication-Results field is not a syntax error. > OpenDKIM runs in the milter stream before OpenDMARC does, and > OpenDMARC consumes the results OpenDKIM provides. > > ATPS was suppose to be based off the ADSP record with the optional > tag "atps=y" I believe that is how it worked. If the "atps=y" was > present in the ADSP record, then ATPS was supported and an > ATPS_Hash(ADID, SDID) lookup was done. > > > Nope. See RFC6541. huh? Ok, I see what happen, I was working off early drafts when ATPS was an extension to ADSP. I can see it changed in rev 05 and in the final RFC6541 production it was made an in-band extension to DKIM. I don't have time to read it all now at the moment, but it is only meaningful when a DKIM signature is present? What happens when it is missing? I wanted to keep a extension to the policy lookup that was already being done. No change to DKIM was necessary. Could this be a reason why they was no traction? I can see why now. It required a change to the DKIM engine. As an extension to ADSP as the original proof of concept was (often the best idea), what I did was two new tags: asl=[list of resigners] atps=y use ATPS This allows for a small and large scale. I only need 10 domains and I can fit domain in my "asl=" tag. Large scale can use atps=y instead. So does DKIM require the atps|atpsh tag before an ATPS lookup can be done? -- HLS From nobody Wed Apr 29 13:40:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2661A039D for ; Wed, 29 Apr 2015 13:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 lnLCU3_tAVEy for ; Wed, 29 Apr 2015 13:40:43 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id F23A31A1A27 for ; Wed, 29 Apr 2015 13:40:42 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 84BA55643BB; Wed, 29 Apr 2015 15:40:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 74E5EA03DA; Wed, 29 Apr 2015 15:40:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zST0mKeTzibX; Wed, 29 Apr 2015 15:40:42 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9D691A03F3; Wed, 29 Apr 2015 15:40:41 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 9D691A03F3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430340042; bh=EZTJDq73pC65Q8ZNJjiEJysU65BPCmy6n7tU78RpucE=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=NF7r8gK0zsFHekODFurfrTSKf1/NAtC4c3paiFDaPOTBb5bdyWpu1qmLoRlJXVvWO suLZjBonpz80ANfZHiaLOD+ZTxHWnDtR3YB16Ov9LRpymacyLQFPKd7mxyGJ17SCJW 0ZJPVoczh73j86FHhd4W4XqQcTiAIE9hkLaoyLYk= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7D7FAA03DA; Wed, 29 Apr 2015 15:40:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wpYU9kzru5vp; Wed, 29 Apr 2015 15:40:41 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 58BCFA0311; Wed, 29 Apr 2015 15:40:41 -0500 (CDT) Date: Wed, 29 Apr 2015 15:40:40 -0500 (CDT) From: Franck Martin To: Hector Santos Message-ID: <1947454892.64382.1430340040592.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> <5541223E.6020703@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: ICT/6y1mOT3xehtzKJ/4w+EQyl7XwQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 20:40:45 -0000 ----- Original Message ----- > From: "Hector Santos" > To: "Franck Martin" , dmarc@ietf.org > Sent: Wednesday, April 29, 2015 11:26:06 AM > Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt > > I think overall, there are two concerns I have: > > 1) The over estimated use of the idea for "rewriting" and > 2) the word or term "common" is used for mitigation methods. > > Common means most and its not the case. Rewriting is a major industry > taboo, in all mail or communications concept. Just because one or two > renegade MLM wrote a kludge for their site, puts it on a wiki, does > not make it legit at all, not one iota. I would avoid the words "renegade" and "kludge". I think you could better phrase the above paragraph. I'll tone down the use of common, however I'd like to point: 1)Google Groups and Yahoo Groups are doing rewriting, if not mistaken, to cite only one data point, these are large deployments. 2)Common, as in the sense, many MLM software have the option today. Will make it more clear in the doc > > The doc infers that RFC6377 provides guidance, and it immediate jumps > to a Rewriting "common mitigation policy." Thats not right. In fact, > RFC6377 preaches ADSP or in general the DKIM Policy framework. I > don't support Rewriting, its not common, its not a BCP. It reeks with > IETF appeal problems. I don't think the doc should legitimize any > idea of rewriting. In the realm of things to do to fix the issue, I think rewriting is an operationally used technique on several lists, but I have no data how popular it is compared to other methods. However, and I think this is your point, many more did not change anything and have to manually deal with the issues. I know a few ticketing systems that have done rewriting before DMARC existed. Anyone wants to comment or has data on what people did? I think this may be helpful. Looking for more guidance. > > Other comments... > > The doc should make a note that DMARC is an informational status > domain. It is not a proposed standard nor a BCP. It is very > incomplete and it is missing lots of considerations. The 3rd party > issues was intentionally in an attempt to avoid a complex design > issue, but that it could not avoid. yes it should be noted that [DMARC] is informational > > The doc fails to mention technical history with SSP ADSP, ATPS, or any > of the RFC documents products such as: > > rfc4686 Analysis of Threats Motivating DKIM > rfc5016 Requirements for a DKIM Signing Practices Protocol > rfc5518 Vouch By Reference > rfc5863 DKIM Development, Deployment, and Operations > > and possibly others. > > The docs should explain why ADSP was abandoned and why its "Super > ADSP" [sic] version called DMARC replaced it. I don't think the purpose of this doc is to describe history, but to explain what may break, how to avoid it, and what are the drawbacks of each solution, if any. https://datatracker.ietf.org/wg/dmarc/charter/ "Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them." "The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. " I think an history of email authentication would be interesting and could be an awesome informational RFC. Are you volunteering? From nobody Wed Apr 29 13:50:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CF51A1A90 for ; Wed, 29 Apr 2015 13:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 jIXV9GQXztXj for ; Wed, 29 Apr 2015 13:50:42 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id DE99D1A1A81 for ; Wed, 29 Apr 2015 13:50:41 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 7999F5643E0; Wed, 29 Apr 2015 15:50:41 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6FF2A60263; Wed, 29 Apr 2015 15:50:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBm8vFork5Pj; Wed, 29 Apr 2015 15:50:41 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3FA0C60268; Wed, 29 Apr 2015 15:50:41 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 3FA0C60268 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430340641; bh=+WTO+7+CsiViWJILoZbCw9n/LLMmRT202RqAKNPkp28=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=dRmiJ86QIdKTqc/jH8sVpt3AvhHSApTDP68rxkDxszfm29LTUyrpt0gI3h3pu56CZ rx8OWgVx6SSD+BeUq9Us0wl3WrVyoNi2BYK4evyzPc2OmiMMP8qmnteNpnknx3j9HP H572Bm0/meAP1ccDIAxHNsL95tzKXBw4t6iOVn6g= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2803A60265; Wed, 29 Apr 2015 15:50:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U8ip62g10O9q; Wed, 29 Apr 2015 15:50:41 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id F2BA660263; Wed, 29 Apr 2015 15:50:40 -0500 (CDT) Date: Wed, 29 Apr 2015 15:50:40 -0500 (CDT) From: Franck Martin To: "MH Michael Hammer (5304)" Message-ID: <417339468.64664.1430340640749.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <246357292.45499.1430264919058.JavaMail.zimbra@peachymango.org> <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: AdCCtU2TR9WZGmMYSjqY/KOulDXP5sXdfutF Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 20:50:43 -0000 ----- Original Message ----- > From: "MH Michael Hammer (5304)" > To: "Franck Martin" , dmarc@ietf.org > Sent: Wednesday, April 29, 2015 12:47:20 PM > Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt > > 2. Causes of Interoperability Issues > > This section focuses on intended recipient perspective but fails to > mention/discuss the originator perspective where some subset of originators, > particularly for high value transactional messages, want the message > discarded if it passes through an intermediary and is modified in any way > resulting in a failure to validate. Examples of such messages include those > related to financial organizations and medical establishments. Good point. added this section, may be you have better language: 2.1. Originator vs Receiver Perspective Some Receivers are concerned that wanted email messages are received, regardless if such email messages are not strictly in conformance to any standard or protocol. Some Originators, particularly for high value transactional messages, want the message discarded if it passes through an intermediary and is modified in any way resulting in a failure to validate. Examples of such messages include those related to financial organizations and medical establishments. > > 2.1 (This is just a nit) Last paragraph > > SPF can provides two Authenticated Identifiers... > > This should be "SPF can provide two Authenticated Identifiers..." > fixed From nobody Wed Apr 29 14:37:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8E1A1AD3 for ; Wed, 29 Apr 2015 14:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 EYGliIklry5P for ; Wed, 29 Apr 2015 14:37:09 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536DB1A6FEA for ; Wed, 29 Apr 2015 14:37:09 -0700 (PDT) Received: (qmail 22342 invoked from network); 29 Apr 2015 21:37:09 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Apr 2015 21:37:09 -0000 Date: 29 Apr 2015 21:36:46 -0000 Message-ID: <20150429213646.15673.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 21:37:11 -0000 >Please post more reviews... Hmmn. Section 3.1.2.3 on EAI is, to a first approximation, completely wrong. Please delete it, since the problems it describes do not actually exist. EAI does not, repeat NOT, downgrade messages in transit. If I send you an EAI message, either it'll be delivered as that EAI message, or it'll be bounced back. There's no reason that DMARC wouldn't work just the same as it does on normal mail, give or take some minor and easily resolved ambiguities about whether the domains in DKIM signatures are U-labels or A-labels. All of the downgrade stuff to which this section refers only happens in one rather arcane situation -- the MTA that received the mail does EAI but the user's MUA doesn't, and the user is trying to pick up the mail with POP or IMAP. Our choices boiled down to invent a new error code that says "you have new mail but you can't see it neener neener" or downgrade messages during POP or IMAP retrieval. Since the normal place to check DMARC is at delivery time, DMARC will have done its thing long before any possible downgrade, so the downgrade doesn't matter. People might try to forward downgraded messsages, but the issues there are the same as for any message that's smashed when it's forwarded, as described in 3.2.2. We invented the RFC6854 empty From: group syntax hack to enable simple EAI downgrades, but it applies to any mail, normal or EAI. My strong suggestion would be that if there's no address on the From: line, there is nothing for DMARC to do and no problem to solve. It's just like any other message with a return address for which the MTA has no reputation info. In 3.2.3, I've never seen list software do PGP encryption, but I have seen it do S/MIME decryption and re-encryption. You might want to change the example. In section 4.1.1.1, add: * Senders can use different domains for mail sent directly and mail sent in ways likely to have DMARC problems, the former with a DMARC policy and the latter without. Please also delete Section 4.1.2.3, since again the EAI problem it describes does not exist. In the first long paragraph in 4.1.3.3, at this point I don't know anyone adding .INVALID, but I know people rewriting the From: address to a different valid address that forwards to the real author. Some people do it the way I do, e.g. marissa@yahoo.com.dmarc.fail, or LISTSERV invents a pseudo-random address in the list's domain. Section 4.2.1 is hard to follow. Is it describing Doug's thing? In Sec 7, it's often considered tacky to acknowledge people listed as document authors. R's, John PS: I could swear we went around the EAI stuff in the last version of this draft. From nobody Wed Apr 29 16:12:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5083A1A8A9E for ; Wed, 29 Apr 2015 16:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=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 WRRGp2RLH7RH for ; Wed, 29 Apr 2015 16:12:01 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id CB9AF1A8A95 for ; Wed, 29 Apr 2015 16:12:00 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 52ABF5643BF; Wed, 29 Apr 2015 18:12:00 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3B3D7A04D0; Wed, 29 Apr 2015 18:12:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzD7rJhUpnJa; Wed, 29 Apr 2015 18:12:00 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E3C41A04D5; Wed, 29 Apr 2015 18:11:59 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com E3C41A04D5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430349120; bh=EEsN+UjSgyxotsdmZ31YblhxB9Wc729sAaZPg7VCk1M=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=bpG6pxYwn4iGy/I/SDsPz5LUcFU6bpwwcEavF5CJSwf6aVxSz88WgB6GQgcPPtlE0 EcHqTInLXzQqRA3yn0O5aR2ABXYVGukOR3aaIQcnprTFGduc7BkdXP21BOeEMBXNZq iVvFaV4VoFqUTLB371KXjeVe/vG1RQ07LRiUcDF0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B8413A04D4; Wed, 29 Apr 2015 18:11:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f4gMQeFau8ok; Wed, 29 Apr 2015 18:11:59 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 8AFFBA04D0; Wed, 29 Apr 2015 18:11:59 -0500 (CDT) Date: Wed, 29 Apr 2015 18:11:59 -0500 (CDT) From: Franck Martin To: John Levine Message-ID: <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150429213646.15673.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: jCLOxpUQBQoPYKtE53q9aszZ+JZrUw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 23:12:02 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: franck@peachymango.org > Sent: Wednesday, April 29, 2015 2:36:46 PM > Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt > > >Please post more reviews... > > Hmmn. Section 3.1.2.3 on EAI is, to a first approximation, completely > wrong. Please delete it, since the problems it describes do not > actually exist. > > EAI does not, repeat NOT, downgrade messages in transit. If I send > you an EAI message, either it'll be delivered as that EAI message, or > it'll be bounced back. There's no reason that DMARC wouldn't work > just the same as it does on normal mail, give or take some minor and > easily resolved ambiguities about whether the domains in DKIM > signatures are U-labels or A-labels. Yes, they are not downgraded in transit. I improved the solution section in "receivers", but I realize the description of the problem is not accurate. Fixing (and see below). > > All of the downgrade stuff to which this section refers only happens > in one rather arcane situation -- the MTA that received the mail does > EAI but the user's MUA doesn't, and the user is trying to pick up the > mail with POP or IMAP. Our choices boiled down to invent a new error > code that says "you have new mail but you can't see it neener neener" > or downgrade messages during POP or IMAP retrieval. Since the normal > place to check DMARC is at delivery time, DMARC will have done its > thing long before any possible downgrade, so the downgrade doesn't > matter. > I don't see anywhere in RFC6854 that the group syntax is for MDA/MS sole use as you describe it above. I wish it would say so. An MTA that has an EAI message that tries to pass it to an MTA that do not support SMTPUTF8 will bounce the message. The MUA or MSA or user may then decide to change the message and use the group syntax to transmit it to an non-EAI environment if it has a normal email address to send to. One can envision such process to be automatic without the user input, especially when the MUA/MSA/MTA is on the same server. See how Coremail handles it transparently (tho they don't use group-syntax). RFC6854 lacks a lot of guidance. Even in your case when the MDA/MS gets such message with group-syntax and forwards it, then an MTA will have to deal with it. > People might try to forward downgraded messsages, but the issues there > are the same as for any message that's smashed when it's forwarded, > as described in 3.2.2. > > We invented the RFC6854 empty From: group syntax hack to enable simple > EAI downgrades, but it applies to any mail, normal or EAI. My strong > suggestion would be that if there's no address on the From: line, > there is nothing for DMARC to do and no problem to solve. It's just > like any other message with a return address for which the MTA has no > reputation info. Yes there is nothing for DMARC to do, but a DMARC aware MTA, may not like to have a message with an RFC5322.From header field with no valid domain in it. Also moving to email over IPv6 requires you to move to domain blocking. So the point here, there is little incentive to do DMARC if you are not stricter in what you tolerate in the RFC5322.From. Therefore, if you don't want to reject emails from EAI based mail system, your system must support EAI. > > In 3.2.3, I've never seen list software do PGP encryption, but I have > seen it do S/MIME decryption and re-encryption. You might want to > change the example. I have seen lists do PGP encryption. Adding S/MIME nevertheless > > In section 4.1.1.1, add: > > * Senders can use different domains for mail sent directly and mail > sent in ways likely to have DMARC problems, the former with a DMARC policy > and the latter without. Added and rephrased > > Please also delete Section 4.1.2.3, since again the EAI problem it > describes does not exist. See above > > In the first long paragraph in 4.1.3.3, at this point I don't know > anyone adding .INVALID, but I know people rewriting the From: address > to a different valid address that forwards to the real author. Some > people do it the way I do, e.g. marissa@yahoo.com.dmarc.fail, or > LISTSERV invents a pseudo-random address in the list's domain. You used to do it no? Anyhow this is just an example of suffix to use. The LISTSERV solution is a derivative of rewriting the RFC5322.From header field to use your own domain. Not sure if we should describe it too? > > Section 4.2.1 is hard to follow. Is it describing Doug's thing? not specifically, people have searched to do some form of transitive trust. > > In Sec 7, it's often considered tacky to acknowledge people listed > as document authors. roger. will confer with other authors. It was to acknowledge my lack of contribution to the core of the document :P > > R's, > John > > PS: I could swear we went around the EAI stuff in the last version of this > draft. > Yes but both of our reality fields need to be adjusted... :P The solution part has been fixed but not the problem part correctly, I overlooked that part. While I'm doing some EAI+DMARC and have some practical operational experience, the large implementation that I know of is Google. It would be nice to have some guidance from them here. We may need a few iterations here. From nobody Wed Apr 29 17:00:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA541A8BB3 for ; Wed, 29 Apr 2015 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 MwELCyBi_0uR for ; Wed, 29 Apr 2015 17:00:14 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF881A8ADF for ; Wed, 29 Apr 2015 17:00:13 -0700 (PDT) Received: (qmail 37162 invoked from network); 30 Apr 2015 00:00:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9129.5541708e.k1504; bh=OwdDUUHqr834cYcOtyHVSjzt9S1cF02KnoIouZ501y4=; b=JXeHN401Ro9T3yXOhGJEXl4ooFWOsebKj7R5JOv1Vbm21pZLEATyeNngBblkMM3zCWW7UdNvkxFq2SfnA/lDbvKbybioWjmTCOF4YfBc8MULKJAyw+bVLKL75sWACYMpcHqbJVQyhhp7YRfjWMoWejXRmNo0yQKO3Iu7u4SHNxOQKFHSiyIlJi20/i8/Avwr1BMmLJKmAzMV2s2iNbfozNIMKzXggLMMcPt/UsFefU1tx/s2M9yHNJdeSgUhJQLQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9129.5541708e.k1504; bh=OwdDUUHqr834cYcOtyHVSjzt9S1cF02KnoIouZ501y4=; b=W5EwaEw4X1R8hPbQvidU20Yvq13l9tdE4qac7ocipuZwiTgHYFkJ+vCD/rCD3BrfbJk8UV7GOosv0i0eKhN3F5JxJ7BnnCl36gAeGWZ3nSJtkYmtWQupLkYn+NTSTmymndufWSB0id3y2Kw8Y+HOR+X/coKuNaoU9tyoXvwQ8AYWsbE+lPcD0GQjiFHk68STfbdhEckX4dPu2hUQ+0sDM4xvZGur7AHfOPI/OaPzFkO0OztNKYFLLIlNVw+wjAOt Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Apr 2015 00:00:14 -0000 Date: 29 Apr 2015 20:00:12 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> References: <20150429213646.15673.qmail@ary.lan> <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 00:00:18 -0000 > Yes, they are not downgraded in transit. I improved the solution section > in "receivers", but I realize the description of the problem is not > accurate. Fixing (and see below). Really, there is no problem. DMARC works fine on EAI mail. Just delete the section. > I don't see anywhere in RFC6854 that the group syntax is for MDA/MS sole > use as you describe it above. I wish it would say so. An MTA that has an > EAI message that tries to pass it to an MTA that do not support SMTPUTF8 > will bounce the message. Correct. > The MUA or MSA or user may then decide to change the message and use the > group syntax to transmit it to an non-EAI environment if it has a normal > email address to send to. No. That is completely wrong. Nowhere in the EAI documents does it contemplate that, and no mail system I know does that. If someone is going to send ASCII mail, the only sane way to do so is to use an ASCII From: address to which the recipient can reply. We do expect MUAs to be configured with an EAI address for recipients that can handle it and an ASCII address for recipients that can't. There may be Chinese systems that try different addresses, but since it's at the sending end, it's up to them to know what addresses they can use and to send valid mail. > Even in your case when the MDA/MS gets such message with group-syntax > and forwards it, then an MTA will have to deal with it. No. No, no no. The dowmgrade is only for POP/IMAP retrieval to non-EAI clients, not anything else. If it's forwarded by sieve or the like, it'll forward the original EAI message. > Yes there is nothing for DMARC to do, but a DMARC aware MTA, may not > like to have a message with an RFC5322.From header field with no valid > domain in it. Please don't invent stuff. In any event, the unlikely possibility that someone might send mail with an empty From: group has nothing to do with EAI or forwarding or anything else. >> In the first long paragraph in 4.1.3.3, at this point I don't know >> anyone adding .INVALID, but I know people rewriting the From: address >> to a different valid address that forwards to the real author. Some >> people do it the way I do, e.g. marissa@yahoo.com.dmarc.fail, or >> LISTSERV invents a pseudo-random address in the list's domain. > > You used to do it no? Anyhow this is just an example of suffix to use. I think there is an important difference between invalid addresses and valid ones. > The LISTSERV solution is a derivative of rewriting the RFC5322.From > header field to use your own domain. Not sure if we should describe it > too? It's different because the address in the From: line is (indirectly) still the real author, not the list. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 29 17:09:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7811A8AF8 for ; Wed, 29 Apr 2015 17:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 9a_Sp_s-9Yc0 for ; Wed, 29 Apr 2015 17:09:28 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6981A8AF7 for ; Wed, 29 Apr 2015 17:09:28 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id B159F5643B3; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AB4B2602E3; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pi9R0-JNuyK; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7D476602EE; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 7D476602EE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430352567; bh=gUaB3ueNLLR5AHX9C5srEuLowoY/Ii6lc0TQIcwIIy4=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=n9lS38FXpHQp91wOsWBG7bk34DsTBtHHgJMHgzpAyHDpWpEtAPs6Po/eSNMLl3rIb iBOi5/foImzNiB1H8eNimHabWOUTd7Q1RMmvjtGw7ku2+JAiM0Wsf2ZFIfKvnE9TbM kh4fNtbo756fIRqHMBg68a7kD2GDA1rr2lpSdNfE= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5F1F3602EA; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hqDhUq1vF0pX; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 3B630602E3; Wed, 29 Apr 2015 19:09:27 -0500 (CDT) Date: Wed, 29 Apr 2015 19:09:27 -0500 (CDT) From: Franck Martin To: John R Levine Message-ID: <163717603.66986.1430352567075.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150429213646.15673.qmail@ary.lan> <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: yRR39FqihdqEtoJyIEEGavjMbLiZnQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 00:09:29 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Wednesday, April 29, 2015 5:00:12 PM > Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt > > > Even in your case when the MDA/MS gets such message with group-syntax > > and forwards it, then an MTA will have to deal with it. > > No. No, no no. The dowmgrade is only for POP/IMAP retrieval to non-EAI > clients, not anything else. If it's forwarded by sieve or the like, it'll > forward the original EAI message. When I click the "forward" button there is no MTA involved... It will not forward the original EAI message. From nobody Wed Apr 29 17:12:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F1C1A8A41 for ; Wed, 29 Apr 2015 17:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 X9uc47pWz74e for ; Wed, 29 Apr 2015 17:12:23 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9731A8A16 for ; Wed, 29 Apr 2015 17:12:23 -0700 (PDT) Received: (qmail 38559 invoked from network); 30 Apr 2015 00:12:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=969e.55417368.k1504; bh=QPkKXOrq/Ws3TFKrlWEcV59qrrm13AoDaYGIiu/V5no=; b=NDk5h50mFreBnC5b7p7dnubr1sH/yf8REjNRh+cuzjRJBtULCK+F6slCL48QxIipx8LPgBzwdn2hY5XUQH5XI+VJLm0SVs7aH2SDMW2CtYD0Vn1rWYF6Bpj5ivUoEs5TK7FI7rOqoLIfi6DT1kVtgQn/qHEd8U295X7RvSIh28eO2yuL86R4iSWvhzW7fv7D7eyrCMYin9pldJrzJ0eLnvdy2qCEo7LdKwZgtWPxyQsuKN/XjzexCQaaYu3gxfE2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=969e.55417368.k1504; bh=QPkKXOrq/Ws3TFKrlWEcV59qrrm13AoDaYGIiu/V5no=; b=uMZiu0OqKXvFdKCK+IJVTyZt/mT1ZDU+QRtEkBGQKY2r6kqQhyS/0T8aMHUBqkwHA3x5QCosU47RphWjJcEIrTtUloUdNg/XWTgTguCVkLDbYPVB/uy+bKxQGaqGLMXWtj/OfgzBI/Xo3bYnkcT6elvBCkk5V2PHWK3j05BZO+3TGEmUSM4gRvwxkiwXEEoxxpk88Zyw1Jeja5KncAQs5ROKm3zdzYJvavdtbZ+d7I2nOuCYWyr7tFN+Pc9MGgQB Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Apr 2015 00:12:24 -0000 Date: 29 Apr 2015 20:12:21 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <163717603.66986.1430352567075.JavaMail.zimbra@peachymango.org> References: <20150429213646.15673.qmail@ary.lan> <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> <163717603.66986.1430352567075.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 00:12:24 -0000 >> No. No, no no. The dowmgrade is only for POP/IMAP retrieval to non-EAI >> clients, not anything else. If it's forwarded by sieve or the like, it'll >> forward the original EAI message. > > When I click the "forward" button there is no MTA involved... It will not forward the original EAI message. Right, this is the MUA smashed forward problem, which is nothing new. Outlook is famous for being unable to forward anything without smashing it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 29 17:47:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DEB1A8A7F for ; Wed, 29 Apr 2015 17:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 G67-s9US4YAY for ; Wed, 29 Apr 2015 17:47:16 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id B7AA51A8A65 for ; Wed, 29 Apr 2015 17:47:15 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4EEAB5642DF; Wed, 29 Apr 2015 19:47:15 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 36A71A04CD; Wed, 29 Apr 2015 19:47:15 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuApNXVsGfvn; Wed, 29 Apr 2015 19:47:15 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DD597A04D3; Wed, 29 Apr 2015 19:47:14 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com DD597A04D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430354834; bh=KfI/sk+ujQWqiQsAZ/KfwiAvYQqrqblbcF0BEmo2ACE=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=eFQLLzGk6UZpxp8I2nvcV/tTiH3rHPCzlQbQttOt5LaWy74jGisnRBd7Z0SAOiCOl CWEnnDgengPL+9AgMiLvFKcRw9JsWnAaWwbu4T4Z2q83+vj1mFUyEdrNmLpad7MKcH ZmM1MDzpwes4adsUJpTlxg4xH/Jd30nBhXh3K8nc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AC293A04D0; Wed, 29 Apr 2015 19:47:14 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QjVclqny07KO; Wed, 29 Apr 2015 19:47:14 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 8065CA04CD; Wed, 29 Apr 2015 19:47:14 -0500 (CDT) Date: Wed, 29 Apr 2015 19:47:14 -0500 (CDT) From: Franck Martin To: John R Levine Message-ID: <539715198.67333.1430354834325.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150429213646.15673.qmail@ary.lan> <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> <163717603.66986.1430352567075.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-02.txt Thread-Index: +Qqidt1UgW3OwUl5QjuVnQi1Dda43g== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 00:47:17 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Wednesday, April 29, 2015 5:12:21 PM > Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt > > >> No. No, no no. The dowmgrade is only for POP/IMAP retrieval to non-EAI > >> clients, not anything else. If it's forwarded by sieve or the like, it'll > >> forward the original EAI message. > > > > When I click the "forward" button there is no MTA involved... It will not > > forward the original EAI message. > > Right, this is the MUA smashed forward problem, which is nothing new. > Outlook is famous for being unable to forward anything without smashing > it. No. No, no, no. No, no, it is not. No, no, it is not, any email client can forward the message they downloaded via POP/IMAP. They have no idea about the "original EAI message" "smashing" the message, because MS-Exchange/MS-Outlook prefers MS-TNEF to MIME, is a different problem. Please, don't mix problems. From nobody Wed Apr 29 18:01:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754F21A8F4A for ; Wed, 29 Apr 2015 18:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 tkU-AdLcljV5 for ; Wed, 29 Apr 2015 18:01:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4277D1A8F49 for ; Wed, 29 Apr 2015 18:01:28 -0700 (PDT) Received: (qmail 44499 invoked from network); 30 Apr 2015 01:01:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=add1.55417ee8.k1504; bh=P6X5tNRAULkaIsoNNoKV0fvqyDg1OloSYcwKiUAqqpQ=; b=I3Lt87KuZ4WR8IchBW3Q/2Bwuvvbl9YwPOAaDkBxGSbe7/Tw11tQzk7S2x9gUylspmV5cXLPnNppMTgppSgYvTCa4LG9fVUSEctcbXWy2pyJIqm9N6PWURzuieGKBtGE/d5GTa4YgWthWd5tuVy3EwduOJ+lnNF+RksN+gJ5xPlPm5uNhr5lZsV4Fa5SGIN6CHDEbp03IOcJOFf8WKwQnHFfdQYbgQ8k4Xv2K+3rVUy5hdhCyZT1AB00K1BVuXA4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=add1.55417ee8.k1504; bh=P6X5tNRAULkaIsoNNoKV0fvqyDg1OloSYcwKiUAqqpQ=; b=uW0GsuJJb8q4ZdqUtkLeI3xKwwtAAp4a3RR+AjDrjkMdTTzlzt2E+Q5QuqkB0lSzKOjBrSEFFEiiESBmSEU7H/Z/YkMZlbWM2PP6+3I8kYffkmdIGZaJOOcKAsAIl2J/b/irRSvY1kIUx4zRkP0Zje3NMZh2i7xNbCsPiEFt9mR4XlQAsQieulhw1swOYsZEMnESGjD1YZjjoCCAtfDK/Zi+U6xhin3BsF7vmXWSkIat5HIYuyKFFce3/nP+KcXd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Apr 2015 01:01:28 -0000 Date: 29 Apr 2015 21:01:26 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <539715198.67333.1430354834325.JavaMail.zimbra@peachymango.org> References: <20150429213646.15673.qmail@ary.lan> <2033458425.66336.1430349119396.JavaMail.zimbra@peachymango.org> <163717603.66986.1430352567075.JavaMail.zimbra@peachymango.org> <539715198.67333.1430354834325.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 01:01:29 -0000 > No. No, no, no. No, no, it is not. No, no, it is not, any email client can forward the message they downloaded via POP/IMAP. They have no idea about the "original EAI message" > > "smashing" the message, because MS-Exchange/MS-Outlook prefers MS-TNEF to MIME, is a different problem. > > Please, don't mix problems. It's exactly the same problem -- the MUA changes the message so the DMARC info is invalid. In any event, I would be surprised if 0.001% of EAI mail gets downgraded after delivery. The people who use EAI are largely in China, and the whole point is so they can type Chinese into their MUAs. The whole null From: thing is a distraction. Please just delete it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 29 18:17:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06551A8FD6 for ; Wed, 29 Apr 2015 18:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eWVpmA0De1xV for ; Wed, 29 Apr 2015 18:17:50 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 28B561A8FD3 for ; Wed, 29 Apr 2015 18:17:49 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id F0C401C387B; Thu, 30 Apr 2015 10:17:47 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D54791A2CC0; Thu, 30 Apr 2015 10:17:47 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <5541223E.6020703@isdg.net> References: <985159909.45526.1430264983586.JavaMail.zimbra@peachymango.org> <5541223E.6020703@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 30 Apr 2015 10:17:47 +0900 Message-ID: <87d22mpg78.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, Franck Martin Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 01:17:51 -0000 Hector Santos writes: > Common means most and its not the case. You're wrong. "Common" in this context means "frequently observed". "Most common" means "most frequently observed." That said, with no statistics about actual usage, I would omit this word. > Rewriting is a major industry taboo, in all mail or communications > concept. Just because one or two renegade MLM wrote a kludge It is indeed a kludge, and IMO it is not legitimate. Nevertheless, rewriting From is now common in my experience, and even my own product was forced to implement it "by popular demand" (and by precedence, since Franck's patch that does rewriting was the first offered). > I don't think the doc should legitimize any idea of rewriting. It doesn't. It mentions them because they exist, and they are unpatentable because any practioner skilled in the art of email would immediately think of them and know how to implement. From nobody Wed Apr 29 19:37:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4471A90D1 for ; Wed, 29 Apr 2015 19:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=ham 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 X4pLzVn7edhh for ; Wed, 29 Apr 2015 19:37:47 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (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 4584E1A90D0 for ; Wed, 29 Apr 2015 19:37:47 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so46136855pdb.0 for ; Wed, 29 Apr 2015 19:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=COT8NkY4/VdJ2XbQceWG+pgTK9y6Zdssj9fyqA68t24=; b=onlkEhR79G7dHR71NZX4oEOPKb/9ybwdDluvBS2SvOdtOH4p/VnqMuL+VqFYhXKp2x rjpbvALF6cZIO2ZBhm2Yw9rRMo/OQjSq+Cr1KjOumNVFjqH0F3Sy6RUdRwOhoDx0zDV+ dYbQ5XnqWpwu/8bmAJF2MFfieAKOd+LzMckLeZVRlcEYBG0t+8HA0kHFBlc1TVJskcRU GtksF0PXTdpA1D28qPA6xX1UQngrTMHZ/wH2KzQFUbDZ1kUW3OnH49ZDOGT7wKhJ43Np AotZ+TnnHzRPT0MqZR/KOs9iog3+FnA2q8WLAXOJ3Mad+MTdjGUY0MQRMZsuKGLGNnez L4xg== X-Received: by 10.68.68.240 with SMTP id z16mr3821750pbt.31.1430361466904; Wed, 29 Apr 2015 19:37:46 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id jp10sm520259pbb.9.2015.04.29.19.37.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 19:37:45 -0700 (PDT) Message-ID: <55419574.2040909@gmail.com> Date: Wed, 29 Apr 2015 19:37:40 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5719430.pnL5xihlrb@kitterma-e6430> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <1406056764.43385.1430256868864.JavaMail.zimbra@peachymango.org> <87lhhbpg0x.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87lhhbpg0x.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 02:37:49 -0000 On 4/29/15 12:09 AM, Stephen J. Turnbull wrote: > Franck Martin writes: > > > I think we should refrain to blame anything or anyone. > > I think that there is no solution attractive to email users possible > without naming names. > > AFAIK[1], it is a fact that the problems that have made "DMARC" a > four-letter word across the Internet are almost entirely due to the > unilateral decisions to publish "p=reject" by *two* domains. Call > that "blaming" if you like, but that fact matters because any *good* > mitigation[2] involves their participation. > > The only alternative I can see to participation by those specific > domains (and any domains producing similar mailflows that may publish > p=reject in the future) is a general agreement among DMARC receivers > to treat "p=reject" as purely advisory (say, -2 spam points if > alignment is verified in SpamAssassin). I know you don't like that > weakening of the protocol, and I don't think it's a good idea, either. > DMARC is a great protocol for direct mail streams, proven in practice. Dear Stephen, An update of Dmarc-Escape draft attempts to unbury what should be a workable solution. Once DMARC libraries are updated to support an addition that includes a requested policy of "public", the cooperation of problematic domains should quickly become a minor concern. Domains making misleading assertions regarding their email alignment practices, especially in regard to exchanges involving public email would only require a small override to be imposed where an inappropriate "reject" becomes "public". In that case, the Domain Owner wishes for Mail Receivers to reject email that fails a modified DMARC alignment mechanism check will now include the Sender header field or the first email address in a multiple From header field. Failure can only result in Quarantine thereby making DMARC far more compatible with SMTP while also better ensuring against misleading policy assertions and undetected phishing. Domain reputation remains an effective tool when narrowed to specific criteria. The current situation where Author identity of a message being munged is not sustainable nor safe. https://tools.ietf.org/html/draft-otis-dmarc-escape-02 Regards, Douglas Otis From nobody Thu Apr 30 01:13:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6172D1ACED0 for ; Thu, 30 Apr 2015 01:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.599 X-Spam-Level: ** X-Spam-Status: No, score=2.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 s8_WfHAOu9eZ for ; Thu, 30 Apr 2015 01:13:32 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 894D31ACEB7 for ; Thu, 30 Apr 2015 01:13:32 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 23B901C385B; Thu, 30 Apr 2015 17:13:31 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0748A1A2CC0; Thu, 30 Apr 2015 17:13:30 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <554111FB.5040801@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 30 Apr 2015 17:13:30 +0900 Message-ID: <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 08:13:34 -0000 Murray S. Kucherawy writes: > we'd need to see some hope that widespread deployment is likely. > But we still have that pesky registration problem to deal with. IMO there is no registration problem for mailing lists for this WG. True, if big p=reject domains won't buy in, it's probably not worth our effort to even think about it. But if they *are* willing to buy in, registering a *lot* of mailing lists, probably the great majority, requires only parsing the List-Post header out of incoming posts, then adding this to a global list or to the subscriber's profile. Indeed, registration itself is a cost, a small amount of storage space per user, a user database schema change I suppose, plus the changes to the MTA (or MUA or MDA/submission agent) to hook into the user data base to update the users' lists of lists and access them for third- party authorization. But these aren't huge changes, the costs can be estimated reasonably accurately I suppose, and I doubt they are prohibitive. This automated registration scheme may provide a vector for abuse (the spammer can get any address registered they like), but in the per-user case it's limited to one user, and only posts originating in the Author Domain can get the authorizing signature. Paranoid Author Domains might even overlay an "explicit opt-in" scheme to reduce the attack surface. Getting lists that don't provide List-Post would require some manual scheme, but I don't see that as a huge barrier either. The point is not that *we* should "standardize" such a scheme, just that it's feasible to automatically register enough of the lists actually in use by a domain's mailbox users to be worthwhile. For mailing lists, registration is not *our* problem. From nobody Thu Apr 30 06:37:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92181A9131 for ; Thu, 30 Apr 2015 06:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.945 X-Spam-Level: X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wp20w6cGAosM for ; Thu, 30 Apr 2015 06:37:48 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5406D1A90CE for ; Thu, 30 Apr 2015 06:37:48 -0700 (PDT) X-AuditID: a66201d1-f79226d000006a45-56-5542302a37ac Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 28.7F.27205.A2032455; Thu, 30 Apr 2015 13:37:47 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Ynoew-00056g-NV for dmarc@ietf.org; Thu, 30 Apr 2015 13:37:46 +0000 Received: from EDO1XCHEVSPIN43.SYMC.SYMANTEC.COM ([169.254.2.26]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Thu, 30 Apr 2015 06:37:47 -0700 From: John Mears To: "dmarc@ietf.org" Date: Thu, 30 Apr 2015 06:37:46 -0700 Thread-Topic: DMARC,SPF, null senders, and indirect mail flow Thread-Index: AdCDStetqHaLagkbSX+8NKXuBkobaw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsVyYMU1HV1tA6dQgyv/2SyWHFrL6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJlzF7EVrOGvuPn1OGsD43SeLkZODgkBE4mXC3ezQdhiEhfu rQeyuTiEBD4wSjzZcYkdwvnLKLF17zFWCGcFo8SmNf/BWtgEtCSWLv/IBGKLCKhKnJjWwghi swDZC55uYgGxhQUsJCZcfccOUWMrsX3+E6h6PYlvz8+BzeEViJLoWfoArJ4R6Izvp9aA1TAL iEvcejKfCeI8AYkle84zQ9iiEi8f/2OFqBeVuNO+nhGiXkdiwe5PbBC2tsSyha+ZIeYLSpyc +YRlAqPILCRjZyFpmYWkZRaSlgWMLKsYZVKTcwxzSxLzS0sKUisMDPWKK3MTgZGQrJecn7uJ ERgNy5IYL+5gvHBY9xCjAAejEg/vYQWnUCHWxDKgykOMEhzMSiK8YiAh3pTEyqrUovz4otKc 1OJDjNIcLErivI86RUOFBNITS1KzU1MLUotgskwcnFINjEl9gdZyQqxMf1bmiU/f3bGmnolX pS/vjMKRya8KnWuNcrwnzNIs9BA/brZh0vpkgWwNnntuL9ewOTJ3fZhz3aLxLdd9QxM1lweC zscqag97i33WjldRTsvvreyS0bwkb3yuma934cbpcT7LNteXvVmwYv1qTaOv5bfqK/3a2F9+ Nzd1rO1RYinOSDTUYi4qTgQAUEjipoICAAA= Archived-At: Subject: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:37:49 -0000 Hi. I wonder if people on this list can help me with a question about correct b= ehavior of DMARC and SPF in a situation involving an email with a null send= er. This reflects a real life situation where an email is being discarded b= y the recipient, even though it is a valid email and I believe the DMARC an= d SPF implementations are correct. The situation is this. There three parties involved : a sender organization= ; a third party organization that provides AV services and the like in the = form of an SMTP relay; and a recipient organization. The sender organizatio= n relays all its outbound email via the third party. The sender organization publishes a DMARC record p=3Dreject and an SPF reco= rd. The SPF record correctly includes the IP used by the third party to del= iver emails on their behalf. The sender does not do DKIM signing, as they don't have that capability at = present for practical reasons. Therefore, they are relying purely on SPF to= pass DMARC. 1 A null sender email is generated by a the sender organization. It could b= e an NDR, an Out Of Office, or similar. 2 The sender organization relays the email via the third party SMTP relay. 3 The third party relay delivers that email to its recipient. The problem is that SPF checking at the recipient is based on the ehlo doma= in presented by the third party relay, as the envelope sender is null. SPF = passes, but the authenticated identifier that results corresponds to the th= ird party, not the sender. That identifier fails to align with the from hea= der domain, so DMARC fails. As I said, the sender isn't doing DKIM signing = so DMARC is based purely on the SPF result. My feeling is that the SPF and DMARC processing I describe is actually corr= ect, and that this is an edge case that arises because the sender is replyi= ng only on SPF. I'd appreciate it if this mailing list can confirm that for= me. Thanks John From nobody Thu Apr 30 06:52:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22671B2A8F for ; Thu, 30 Apr 2015 06:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 egL_JaVDkBaf for ; Thu, 30 Apr 2015 06:52:48 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (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 2D9E41B2A90 for ; Thu, 30 Apr 2015 06:52:48 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so61414499pdb.1 for ; Thu, 30 Apr 2015 06:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0QY2Fx0MTC3cvUFfK128zSnNTtL8AJmMeKI+5DHxLYc=; b=xWsgQpQkxUN92ej6W5CCfASZ2uu43u1vmaO35dzgHxAbv/Qdga7jycUkFjeXqK8GOg ZzQLaVuUcEOAKxvdFVUoHHdpPYrJtcFNkcIlDEiRLuGW8ECg6Nw0kFRdlkTTeeeEEhat kjbHv25lnk6EZmX4nQ5ueCMhZxH0CQjKBcRw4GOeypXSEGSYIuiZH72IWyrjDhrofM4Z RAjq51eBGMebbg2zrLf8Fs2LvC9FEiPikHyEXM4wOi9uCChXCtR6XgPFpT95VjPs+sc5 HAL94ViaVkJzyJcpomiQ9kq2YsdxG8zkmcsSvHJjPN8MNH9Oia5lxYdPQaGW7bG5ZYND g56Q== X-Received: by 10.66.172.4 with SMTP id ay4mr8457640pac.157.1430401967861; Thu, 30 Apr 2015 06:52:47 -0700 (PDT) Received: from [50.95.215.116] ([50.95.215.116]) by mx.google.com with ESMTPSA id u8sm2293957pdi.90.2015.04.30.06.52.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 06:52:47 -0700 (PDT) Message-ID: <554233AE.8090901@gmail.com> Date: Thu, 30 Apr 2015 06:52:46 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Mears , "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:52:53 -0000 On 4/30/2015 6:37 AM, John Mears wrote: > Hi. > > I wonder if people on this list can help me with a question about > correct behavior of DMARC and SPF in a situation involving an email > with a null sender. I assume you mean an empty SMTP rfc5321.MailFrom command and probably and empty SMTP EHLO field? Rather than, say, an empty rfc5322.From field? d/ From nobody Thu Apr 30 06:58:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650831A907B for ; Thu, 30 Apr 2015 06:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 C2ucUBztYJRX for ; Thu, 30 Apr 2015 06:58:06 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69311A908D for ; Thu, 30 Apr 2015 06:58:02 -0700 (PDT) X-AuditID: a66201d1-f79226d000006a45-e1-554234e9b598 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 16.00.27205.9E432455; Thu, 30 Apr 2015 13:58:02 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1YnoyX-0001W1-NE; Thu, 30 Apr 2015 13:58:01 +0000 Received: from EDO1XCHEVSPIN43.SYMC.SYMANTEC.COM ([169.254.2.26]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 30 Apr 2015 06:58:02 -0700 From: John Mears To: Dave Crocker , "dmarc@ietf.org" Date: Thu, 30 Apr 2015 06:58:00 -0700 Thread-Topic: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow Thread-Index: AdCDTPQdz7DuZ8srQK+u2+BXIW7FywAAEHMg Message-ID: References: <554233AE.8090901@gmail.com> In-Reply-To: <554233AE.8090901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42I5sOKaju4rE6dQg69fWSw6f+9gtFhyaC2j A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx+WUXW8FXtoof/1sYGxhPsnYxcnBICJhI PFqU2cXICWSKSVy4t56ti5GLQ0jgA6PE1wlfWCCcF4wSzw+3sIFUCQmsYJQ4scIDxGYT0JJY uvwjE4gtIuAhsevsJWYQm0VAVWLb1z2MXYzsHMICnhJzpSEqvCROne9lhrCNJM787mUEsXkF oiR2n9rCCDG9UmLto79gNZwCmhITD0wDsxmBbvt+ag3YJmYBcYlbT+YzQdwsILFkz3lmCFtU 4uXjf6wQ9aISd9rXM0LU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSbhWTsLCQts5C0zELS soCRZRWjTGpyjmFuSWJ+aUlBaoWBoV5xZW4iMIqS9ZLzczcxAiNpWRLjxR2MFw7rHmIU4GBU 4uE9ZOwUKsSaWAZUeYhRgoNZSYT3sxFQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+jTtFQIYH0 xJLU7NTUgtQimCwTB6dUA+OSag2OvV2tvtMtfhRLKxfvmsiu1KQ6yaWXYcbTQ/83ZuXfzLu/ VbQ28/Y0ppOuE/5xLFgXZfToe7nNnTtX73Mczv1hFnH5Wqe9yIREm4//DPImP87Zs8Rs/oUP i700ul8+2J/OV8Aay3X0/p5ba3K/HknZuKJG48enwOADU+5/NZl551Aj504lJZbijERDLeai 4kQASj6AI6ACAAA= Archived-At: Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:58:08 -0000 The rfc5321.MailFrom is empty: MAIL FROM:<> The ehlo field presented to the recipient from the third party relay contai= ns the domain of the third party: EHLO thirdparty.org The from header contains the original sender's email address: From: John Doe -----Original Message----- From: Dave Crocker [mailto:dcrocker@gmail.com]=20 Sent: 30 April 2015 14:53 To: John Mears; dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow On 4/30/2015 6:37 AM, John Mears wrote: > Hi. >=20 > I wonder if people on this list can help me with a question about=20 > correct behavior of DMARC and SPF in a situation involving an email=20 > with a null sender. I assume you mean an empty SMTP rfc5321.MailFrom command and probably and e= mpty SMTP EHLO field? Rather than, say, an empty rfc5322.From field? d/ From nobody Thu Apr 30 07:04:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E931B2AA8 for ; Thu, 30 Apr 2015 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 wfulVpi7NrRt for ; Thu, 30 Apr 2015 07:04:12 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE771B2A9B for ; Thu, 30 Apr 2015 07:03:20 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C80E5C40243 for ; Thu, 30 Apr 2015 09:03:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430402599; bh=krQe8LY25q1LtTeR2Yl9M4IcHp5a7/O8mscLoyl4EP4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A7zPSPbAnxJEkXz1SUAstMb9yJp0+/RShACs8hKUrUtKFNjFdjdTAVfNmAKTxdnIo HJCKYV6io1qnjkWJhEq0++8TMXiZTxvPIj4Xy0D6hz9I2z/7kcISbtHlP+coDh+Sbo xY6RQaNwnI8I/yCOYNQpZt9ynUzFroeS1DfSdZIk= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 30 Apr 2015 10:03:19 -0400 Message-ID: <1855336.XpbIs9ZWtG@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 14:04:16 -0000 On Thursday, April 30, 2015 06:37:46 AM John Mears wrote: > Hi. > > I wonder if people on this list can help me with a question about correct > behavior of DMARC and SPF in a situation involving an email with a null > sender. This reflects a real life situation where an email is being > discarded by the recipient, even though it is a valid email and I believe > the DMARC and SPF implementations are correct. > > The situation is this. There three parties involved : a sender organization; > a third party organization that provides AV services and the like in the > form of an SMTP relay; and a recipient organization. The sender > organization relays all its outbound email via the third party. > > The sender organization publishes a DMARC record p=reject and an SPF record. > The SPF record correctly includes the IP used by the third party to deliver > emails on their behalf. > > The sender does not do DKIM signing, as they don't have that capability at > present for practical reasons. Therefore, they are relying purely on SPF to > pass DMARC. > > 1 A null sender email is generated by a the sender organization. It could be > an NDR, an Out Of Office, or similar. 2 The sender organization relays the > email via the third party SMTP relay. 3 The third party relay delivers that > email to its recipient. > > The problem is that SPF checking at the recipient is based on the ehlo > domain presented by the third party relay, as the envelope sender is null. > SPF passes, but the authenticated identifier that results corresponds to > the third party, not the sender. That identifier fails to align with the > from header domain, so DMARC fails. As I said, the sender isn't doing DKIM > signing so DMARC is based purely on the SPF result. > > My feeling is that the SPF and DMARC processing I describe is actually > correct, and that this is an edge case that arises because the sender is > replying only on SPF. I'd appreciate it if this mailing list can confirm > that for me. It sounds correct, but even if the Mail From wasn't null, it would still likely fail. If the third party's Mail From was used, it wouldn't align and if the sender's Mail From was used it wouldn't pass SPF since it came from the third party's infrastructure. The solution from an SPF perspective would be to include: the third party's SPF record. There's no reason that couldn't be done also for the EHLO domain. That would solve the SPF passing part of the problem, but would still fail to align. Relying on SPF for indirect mail flows like this is inherently problematic in terms of DMARC. The reason DMARC uses both SPF and DKIM is that they each have their strong and weak use cases so there's more coverage when used together. Scott K From nobody Thu Apr 30 09:06:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9EF1B2D56 for ; Thu, 30 Apr 2015 09:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_61=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 dCMYV9b5wzg8 for ; Thu, 30 Apr 2015 09:06:02 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5767C1B2D3A for ; Thu, 30 Apr 2015 09:06:02 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3982DC4001A for ; Thu, 30 Apr 2015 11:06:01 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430409961; bh=C2ivjJ4b1QiiVdmpphkYPO2aekFkLANVNtnRV+NKi+k=; h=From:To:Subject:Date:From; b=I/nbD/KVHS3DS395jXy8Ypw2Ht44z3f74NTZK8EoT93OR/pzmswUW2fJMWIm+CemZ e/GY2IasM4BPYScHei9RmNdK7e60XwOYiUh4GDhqCPdaxzLoUXhQBnPrIfdQ/hD5mE O9MCsgdgU18rAQ7pIhFujfY77pPEkBB4bKByd8QM= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 30 Apr 2015 12:06 -0400 Message-ID: <7120368.SRLs5cRkaz@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:06:04 -0000 This isn't fully fleshed out yet, so no I-D, but I've been running short of time, so I decided it would be better to at least get something written down. Historical SPF discussion: One of the use cases presented for macros in SPF records was to enable senders to dynamically assess information communicated via a DNS query from a receiver. This is described in RFC 7208 Appendix D Section 1 (D.1). I have seen SPF records in the wild that do variants of this, but they are rare. This was seen a one potential solution to the SPF "forwarding problem". Analogy to DMARC: That got me thinking about the possibility of something similar for DMARC. It can't be the same, since one of the indirect mail flow cases we have to address is mailing lists and they typically use their own mail from, so any needed mail from encoding would be lost. It might be useful though to have some opt-in mechanism for DMARC senders to get an additional query for verification purposes. I recall some earlier discussion about encoding information in From local part, but if for no other reason, automatic addition of new email addresses to contacts by some MUAs makes that highly problematic. Fortunately, we don't have to be tied to either mail from or from. We can add a new header field and since we aren't asking the user to interpret is, it need not and should not be displayed. For the purposes of this mail, I'm calling it yaimfs-id. If the concept has legs, we can bike shed the name later. Concept: Participating senders add a new optional tag to their DMARC record, something like yaimfs=y and a new field in the header that is something like: yaimfs-id: localpart@domain Domain must be aligned with the From domain For mail that passes DMARC, no changes are made. If a message fails DMARC checks and both the DMARC record (which is already in the local cache) has yaimfs=y and the message has yaimfs-id is possible, then the receiver sends a DNS query to message-id.yamfsidlocalpart._dmarc.domain. The sender then replies pass/fail/error. I suggest message ID be included since it's supposed to be globally unique to reduce the risk of collision. This idea effectively would create a new authentication protocol based on direct query/feedback and extend DMARC to use it. It would be totally opt-in. Functional assessment: This idea has similar security properties to the proposal for adding an additional signature with fs=. Since some of the indirect mail flow use cases are one to many transitions, a sender would have to give multple positive responses per message to enable mailing list (for example) use. The security advantage is has over the fs= proposal is that the number of such approvals is in control of the sender. For fs=, signature validity time is the only available replay constraint. For this proposal the sender can determine a policy on maximum number of uses or time limit and implement it unilaterally. This does not require mediators to do anything. This does not require senders or receivers to know who are 'good' mediators. It does require senders to maintain state on the yamfs-id tokens and pass or fail messages. It does create traffic for any DMARC fail message. It's opt-in and doesn't have a significant impact on non-implementers. Utility assessment: This does not require anything that's unique to a large provider. This should scale reasonably well up or down (I think there's enough space in message ID plus yamfs-id to cover large provider needs, but it would be nice to get an assessment from someone at a large provider). It requires changes from the originators and receivers, but not mediators. I think this is useful to consider since we don't have a large/small, no mediator change option on the table at the moment. Thoughts/questions (I'm sure I haven't described this well)? Scott K From nobody Thu Apr 30 09:09:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782C31B2D57 for ; Thu, 30 Apr 2015 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 ChJLiuLN0MWx for ; Thu, 30 Apr 2015 09:08:57 -0700 (PDT) Received: from groups.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC21B2D3A for ; Thu, 30 Apr 2015 09:08:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3056; t=1430410130; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=SdBsfEB 8ic7E0tox3Z9CJZV3VI0=; b=nHu+d8BPW1ONV8lgUfA+ozsPGVtjLvcjg0eKq9w bZ6IXxeZeeAe/mE6iEO1t075ryLa9j8YkW22rH3FzwQLBYHiSY83hgH6Tn0vUYBN va/pFaNvjEUDYZ3GgaTU3INXCyX76/OXy1PR2r1M3BauhKzsJ401NapYcsGlZgxT jhLE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 12:08:50 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4120129467.4153.3512; Thu, 30 Apr 2015 12:08:49 -0400 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (12B435) From: Hector Santos Date: Thu, 30 Apr 2015 12:08:48 -0400 To: John Mears Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:08:59 -0000 Off hand, based on what you stated, when dealing with bounces, its a genera= l rule of thumb that you always accept and maybe then do some AVS filtering p= erhaps. If you want to apply SPF, fine, but beyond that, well, its going t= o be indeterminate conditions. You can't assume that bounces will be signed= and/or it will be perfectly aligned and correct all the time. Too variable= . Our receiver will pretty much always accept a bounce out of "standard" pr= actice. It's an unfortunate loophole for support of legacy operations. Sin= ce you had using a host, you really can't put too much constraints. The hos= t isn't a resigner. If you can't setup a hard fail policy, its all going to= be wasteful and redundant processing anyway. -- Hector Santos http://www.santronics.com > On Apr 30, 2015, at 9:37 AM, John Mears wrote: >=20 > Hi. >=20 > I wonder if people on this list can help me with a question about correct b= ehavior of DMARC and SPF in a situation involving an email with a null sende= r. This reflects a real life situation where an email is being discarded by t= he recipient, even though it is a valid email and I believe the DMARC and SP= F implementations are correct. >=20 > The situation is this. There three parties involved : a sender organizatio= n; a third party organization that provides AV services and the like in the f= orm of an SMTP relay; and a recipient organization. The sender organization r= elays all its outbound email via the third party. >=20 > The sender organization publishes a DMARC record p=3Dreject and an SPF rec= ord. The SPF record correctly includes the IP used by the third party to del= iver emails on their behalf. >=20 > The sender does not do DKIM signing, as they don't have that capability at= present for practical reasons. Therefore, they are relying purely on SPF to= pass DMARC. >=20 > 1 A null sender email is generated by a the sender organization. It could b= e an NDR, an Out Of Office, or similar. > 2 The sender organization relays the email via the third party SMTP relay.= > 3 The third party relay delivers that email to its recipient. >=20 > The problem is that SPF checking at the recipient is based on the ehlo dom= ain presented by the third party relay, as the envelope sender is null. SPF p= asses, but the authenticated identifier that results corresponds to the thir= d party, not the sender. That identifier fails to align with the from header= domain, so DMARC fails. As I said, the sender isn't doing DKIM signing so D= MARC is based purely on the SPF result. >=20 > My feeling is that the SPF and DMARC processing I describe is actually cor= rect, and that this is an edge case that arises because the sender is replyi= ng only on SPF. I'd appreciate it if this mailing list can confirm that for m= e. >=20 > Thanks > John >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Thu Apr 30 09:28:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5CF1B2CD6 for ; Thu, 30 Apr 2015 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=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 GPlYteD5iJcv for ; Thu, 30 Apr 2015 09:28:09 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 586861A854B for ; Thu, 30 Apr 2015 09:28:09 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id CA53D56492F; Thu, 30 Apr 2015 11:28:08 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C24A6A0330; Thu, 30 Apr 2015 11:28:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj2qLG2xKSGs; Thu, 30 Apr 2015 11:28:08 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D7B28A033B; Thu, 30 Apr 2015 11:28:07 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com D7B28A033B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430411288; bh=EDbC58eUbJQFKtSfWI+sIise5ZiOsYXAxRpJpG+KBu4=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=KCaVsaijviLkK42SCC8OIGGv5Fp9UOehVTS0LwPhLi0DFeo+rHIs8ZnvQqrReGizw pxBd0mHSe4mm84s/aASW063CEADFbqUS3CqxX5XlSutOWF1PonI5AlxT8xR+zVWzyk U72UAwr4hM2VyctYhMn6aSQf4Iyeyv/mMm/+yJrA= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A99B1A0333; Thu, 30 Apr 2015 11:28:07 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m7ZqQXtwSo9P; Thu, 30 Apr 2015 11:28:07 -0500 (CDT) Received: from [10.0.0.6] (c-67-180-100-98.hsd1.ca.comcast.net [67.180.100.98]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 3299AA0330; Thu, 30 Apr 2015 11:28:07 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Franck Martin In-Reply-To: Date: Thu, 30 Apr 2015 09:27:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:28:10 -0000 > On Apr 30, 2015, at 1:13 AM, Stephen J. Turnbull = wrote: >=20 > Murray S. Kucherawy writes: >=20 >> we'd need to see some hope that widespread deployment is likely. >> But we still have that pesky registration problem to deal with. >=20 > IMO there is no registration problem for mailing lists for this WG. >=20 > True, if big p=3Dreject domains won't buy in, it's probably not worth > our effort to even think about it. But if they *are* willing to buy > in, registering a *lot* of mailing lists, probably the great majority, > requires only parsing the List-Post header out of incoming posts, then > adding this to a global list or to the subscriber's profile. >=20 I log any rejected email that has a List-Post or List-id (not all MLMs = use List-Id). I see a lot of marketing emails and spam with these = headers. So there is a need to make sure this is really a MLM. It is not = overly complicated, considering I=E2=80=99m mostly the only one to = subscribe to MLM with my corporate email address, but I wanted to = mention the presence of such headers is not foolproof. From nobody Thu Apr 30 09:34:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651EA1A8780 for ; Thu, 30 Apr 2015 09:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 OX9XI7foVsGM for ; Thu, 30 Apr 2015 09:34:36 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id D31931A874C for ; Thu, 30 Apr 2015 09:34:35 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 73BE4564AB0; Thu, 30 Apr 2015 11:34:35 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6917E601B5; Thu, 30 Apr 2015 11:34:35 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxnwb2UxQh7L; Thu, 30 Apr 2015 11:34:35 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2E51E601D3; Thu, 30 Apr 2015 11:34:35 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 2E51E601D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430411675; bh=thsVQpmmdpC/p91LoT2elJWL/al39nuBpYfTzTi7mnI=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=Lym76VdIkbP+csvJU4/6i+W4zsPBKCHvHHdu0uaRHATcHRNRR3fGeyb/Bipfje4tk iburh+Ax1u5CS488XZ395dwxILFrpW8orQhG+tWMp75w3/YZOw4WSHs7kTloMowC6B ZKJJsiSP+DvrXW3eQAMc3mcCJzwcVKLUfBoR1iHc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 150C4601D2; Thu, 30 Apr 2015 11:34:35 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1NMNMjSco7Px; Thu, 30 Apr 2015 11:34:34 -0500 (CDT) Received: from [10.0.0.6] (c-67-180-100-98.hsd1.ca.comcast.net [67.180.100.98]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 8C268601B5; Thu, 30 Apr 2015 11:34:34 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9109A243-2024-4F00-ADBD-694073AC8E8F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Franck Martin In-Reply-To: Date: Thu, 30 Apr 2015 09:34:30 -0700 Message-Id: References: <554233AE.8090901@gmail.com> To: John Mears X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:34:37 -0000 --Apple-Mail=_9109A243-2024-4F00-ADBD-694073AC8E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 30, 2015, at 6:58 AM, John Mears = wrote: >=20 > The rfc5321.Mail=46rom is empty: > MAIL FROM:<> >=20 > The ehlo field presented to the recipient from the third party relay = contains the domain of the third party: > EHLO thirdparty.org For SPF to pass you can put a record on the domain (thirdparty.org = ) of the HELO, but this will not align with = senderorg.com see the definition of RFC7208.MAILFROM and = https://tools.ietf.org/html/rfc7208#section-10.1.3 >=20 > The from header contains the original sender's email address: > From: John Doe >=20 What may work, is to get dedicated sending IPs at the third party relay = and ask them to put in the HELO a domain aligned with senderorg.com = , otherwise DKIM sign the bounces. Note that = postfix/sendmail can DKIM sign the bounces it creates.= --Apple-Mail=_9109A243-2024-4F00-ADBD-694073AC8E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 30, 2015, at 6:58 AM, John Mears <John_Mears@symantec.com> wrote:

The rfc5321.Mail=46rom= is empty:
MAIL FROM:<>

The ehlo field presented to the recipient from the third = party relay contains the domain of the third party:
EHLO = thirdparty.org

For SPF to = pass you can put a record on the domain (thirdparty.org) of the HELO, but this will not align = with senderorg.com

see the = definition of RFC7208.MAILFROM and https://tools.ietf.org/html/rfc7208#section-10.1.3

The from header contains the original sender's email = address:
From: John Doe <jdoe@senderorg.com>


What may work, = is to get dedicated sending IPs at the third party relay and ask them to = put in the HELO a domain aligned with senderorg.com, otherwise DKIM sign the bounces. Note that = postfix/sendmail can DKIM sign the bounces it = creates.
= --Apple-Mail=_9109A243-2024-4F00-ADBD-694073AC8E8F-- From nobody Thu Apr 30 09:47:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8B71B2DDC for ; Thu, 30 Apr 2015 09:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2Bd5NoeBompz for ; Thu, 30 Apr 2015 09:47:33 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4A41B2DCD for ; Thu, 30 Apr 2015 09:46:09 -0700 (PDT) X-AuditID: d80ac3f1-f79fd6d0000022fa-aa-55425c50f765 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id BB.5C.08954.05C52455; Thu, 30 Apr 2015 17:46:08 +0100 (BST) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1YnrbD-0004vP-7U; Thu, 30 Apr 2015 12:46:07 -0400 Received: from EDO1XCHEVSPIN43.SYMC.SYMANTEC.COM ([169.254.2.26]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Thu, 30 Apr 2015 09:45:55 -0700 From: John Mears To: Franck Martin Date: Thu, 30 Apr 2015 09:45:52 -0700 Thread-Topic: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow Thread-Index: AdCDY419RFf4ctMWR/ybXlGgofJrOQAAV1bg Message-ID: References: <554233AE.8090901@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F8699A71B5857448973275162939C218050E4DCC60EDO1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsXCZeB6SjcgxinU4M1XI4vO3zsYLZYcWsto 0XpnJqsDs8fOWXfZPZYs+cnk8aPVJ4A5issmJTUnsyy1SN8ugSvj4daVjAUHDSu+dLE3MDbo dDFycEgImEjsvi7excgJZIpJXLi3nq2LkYtDSOAdo8TB1dPZIZwXjBJHHnZCZVYwSixfup8F pIVNQEti6fKPTCC2CJD9fOlUNhCbWcBD4sGuv8wgNouAqsTsI/eB4uwcwgKeEnOlIaq9JE6d 72WGsI0kVi5aBWbzCkRJ/F23kBVi1S8miZnt05lBDuUUcJbYs8IUpIYR6NDvp9YwQWwSl7j1 ZD4TxAMCEkv2nGeGsEUlXj7+xwpRLypxp309I0R9vsSOaYtZIXYJSpyc+YRlAqPYLCSjZiEp m4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9ilCkpLTYszi3JLy0pSK0wMNQrrsxN BMZnsl5yfu4mRmCM3uA6/HEH49G9jocYBTgYlXh4NT2dQoVYE8uAKg8xSnAwK4nwmjkChXhT EiurUovy44tKc1KLDzFKc7AoifO+6xQNFRJITyxJzU5NLUgtgskycXBKNTA+aec3vzA/yXuD +bpjTo2Cr55JxN2c+FpqaWR2/Er7tCJZqTNcvdc/T1cy/LBuj5Hr8l3NmtFGoh0dehxndMsn 8U5x37+O4VDDs3+/1mxPeb7SfX7I7sS593dUb9NYt91JTXuZC5vwevObxa4xvI2/s34+zY6S TogK6WVcrbxqbsD+pavL1yxSYinOSDTUYi4qTgQA+uAk+M0CAAA= Archived-At: Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:47:35 -0000 --_000_F8699A71B5857448973275162939C218050E4DCC60EDO1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should have said, yes there is an SPF record for thirdparty.org so that S= PF passes based on the EHLO domain. From: Franck Martin [mailto:franck@peachymango.org] Sent: 30 April 2015 17:35 To: John Mears Cc: Dave Crocker; dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow On Apr 30, 2015, at 6:58 AM, John Mears > wrote: The rfc5321.MailFrom is empty: MAIL FROM:<> The ehlo field presented to the recipient from the third party relay contai= ns the domain of the third party: EHLO thirdparty.org For SPF to pass you can put a record on the domain (thirdparty.org) of the HELO, but this will not align with senderorg.com see the definition of RFC7208.MAILFROM and https://tools.ietf.org/html/rfc7= 208#section-10.1.3 The from header contains the original sender's email address: From: John Doe > What may work, is to get dedicated sending IPs at the third party relay and= ask them to put in the HELO a domain aligned with senderorg.com, otherwise DKIM sign the bounces. Note that postfix/sendmail ca= n DKIM sign the bounces it creates. --_000_F8699A71B5857448973275162939C218050E4DCC60EDO1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I should = have said, yes there is an SPF record for thirdparty.org so that SPF passes= based on the EHLO domain.

 

 <= /span>

From: Franck Martin [mailto:fran= ck@peachymango.org]
Sent: 30 April 2015 17:35
To: John= Mears
Cc: Dave Crocker; dmarc@ietf.org
Subject: Re: [d= marc-ietf] DMARC,SPF, null senders, and indirect mail flow

 

 

On Apr 30, 2015, at 6:58 AM, John = Mears <John_Mears@symantec.co= m> wrote:

 =

The rfc5321.MailFrom is empty:
MAIL FROM:&= lt;>

The ehlo field presented to the recipient from the third par= ty relay contains the domain of the third party:
EHLO thirdparty.org

 

For= SPF to pass you can put a record on the domain (thirdparty.org) of the HELO, but this will not align with senderorg.com

 

see t= he definition of RFC7208.MAILFROM and https://tools.ietf.org/html/rfc7208#section-= 10.1.3



=


The from heade= r contains the original sender's email address:
From: John Doe <jdoe@senderorg.com>

<= /div>

 

What may work, is to get dedicated sending IPs at the third party relay= and ask them to put in the HELO a domain aligned with senderorg.com, otherwise DKIM sign the bounces. Note that = postfix/sendmail can DKIM sign the bounces it creates.

=
= --_000_F8699A71B5857448973275162939C218050E4DCC60EDO1XCHEVSPIN_-- From nobody Thu Apr 30 10:19:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE61F1B2E5B for ; Thu, 30 Apr 2015 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_61=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 xEttvBfQSHbM for ; Thu, 30 Apr 2015 10:19:13 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCC31A88B9 for ; Thu, 30 Apr 2015 10:19:13 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9A669C4016C for ; Thu, 30 Apr 2015 12:19:12 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430414352; bh=aA7AaGfZaSWWZV7QWjkxRGrM/yligMwOITlNfDQS88M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NPj9ELZR7aTkKKVaOn/S0iL4dmlqfJ/g7vS+zaanSMw4pFPhY234r+r9aJfmhmr8o Kzwcl8fAgxNi3zQCxc26uHZH16lcrNkv3hKp13DSsHjkuqQkpeINghZRsUzF0l+BDW m4ClIqhSdbCMwXhVxmjJN8Q5PVNEFgMxxBGOXBqY= From: Scott Kitterman To: "dmarc@ietf.org" Date: Thu, 30 Apr 2015 13:19:12 -0400 Message-ID: <30438248.UfeGvtBVnr@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <7120368.SRLs5cRkaz@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:19:14 -0000 On Thursday, April 30, 2015 10:00:46 AM Kurt Andersen wrote: > On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman > > wrote: > > It might be useful though to have some opt-in mechanism for DMARC senders > > to > > get an additional query for verification purposes. > > > > Concept: > > > > Participating senders add a new optional tag to their DMARC record, > > something > > like yaimfs=y and a new field in the header that is something like: > > > > yaimfs-id: localpart@domain > > > > Domain must be aligned with the From domain > > > > For mail that passes DMARC, no changes are made. If a message fails DMARC > > checks and both the DMARC record (which is already in the local cache) has > > yaimfs=y and the message has yaimfs-id is possible, then the receiver > > sends a > > DNS query to message-id.yamfsidlocalpart._dmarc.domain. The sender then > > replies pass/fail/error. > > > > I suggest message ID be included since it's supposed to be globally unique > > to > > reduce the risk of collision. > > > > This idea effectively would create a new authentication protocol based on > > direct query/feedback and extend DMARC to use it. It would be totally > > opt-in. > > Interesting idea - essentially it would allow senders to provide an > independent authorization channel for messages. What worries me, is why a > sender would sanction a message that presumably has been sufficiently > altered as to fail DKIM validation without knowing something about the > content as received. > > It seems somewhat like saying that if you get a check (the old-fashioned > paper kind), that if you call me and tell me what color the paper is, then > you can cash the check (presuming that the color is correct). I would not, > personally, be granting any such approvals. I think it's a bit more than that. It's more like "Give me the serial number" "Oh, I just wrote a check with the number 30 seconds ago, OK" I agree it's not a 100% secure solution since there's a replay risk, but the risk is less than with the fs= proposal. Scott K From nobody Thu Apr 30 11:08:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E61B2E8C for ; Thu, 30 Apr 2015 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.537 X-Spam-Level: X-Spam-Status: No, score=-100.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 3DpOh0CUEUdz for ; Thu, 30 Apr 2015 11:08:28 -0700 (PDT) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C5E061B2E84 for ; Thu, 30 Apr 2015 11:08:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2896; t=1430417301; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=nJFAr0HoJCKJ3XmtNmhRnoHOBHg=; b=kEw0YKBlxaW0mNum2GKq QXhmDUPZm0BMsN3/CthaJk2UtjD6tLcTDKjaj4R8HgP8ilDxWoAkdwN0CIKFZ1Oq Lw50HTnM/76scTPqy9vtLuEZ7zVscgd5QBiXLQ1C+8MzMhyX8bvJonaEHqhzyU/y DRx6KlYaapvv4ezp1yB/ClY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 14:08:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4127300880.4153.4616; Thu, 30 Apr 2015 14:08:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2896; t=1430417041; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZzcSIST AH6HeUd2RZHY0JPLF7g8KY3kGUfTwH0zwEx0=; b=NeVTvwuEvkJRtM1+3pks6Pz F/GAk3h4lRpOKmKg8VpXtKczlGFksrXY7/IxT8lgNuPaup/nbUfTwqVMY3d6MveU 0/gmogA3KOSy807RWvtho4TGAh/7EfQZ3Y19lkWBe1iLBy9Nyd+70LXgWxbTwtDa xS8ykXP/bpOa4tMd2agg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 14:04:01 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2719576613.9.8528; Thu, 30 Apr 2015 14:04:00 -0400 Message-ID: <55426F96.8080500@isdg.net> Date: Thu, 30 Apr 2015 14:08:22 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <554111FB.5040801@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 18:08:30 -0000 On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote: > > If OpenDKIM is popular among many big systems, it would make sense > to slightly update OpenDKIM so that the "atps=y" option is based > off a DMARC lookup. The change is small. > > Sure, if that's consensus. That would also involve promoting ATPS to > the Standards Track, but to do that we'd need to see some hope that > widespread deployment is likely. But we still have that pesky > registration problem to deal with. Registration is a different situation that is tied to the market place. It should not be a barrier to the IETF technical protocol we wish to provide as a IETF recommended solution. > Maybe Murray can explain how its setup and triggered in OpenDKIM. > > If you enable it, you just have to name which domains you authorize to > sign for you. So if I understand RFC6541 (its unfortunate I wasn't around during work): Given two identities: ADID Author Domain Identity (5322.From.domain) SDID The signer domain identity to be placed in "d=" 1) The DKIM signer MUST add tag "atps=SDID" to DKIM-Signature 2) The DKIM signer CAN add tag "atpsh=hash" to DKIM-Signature At the DKIM ATPS compliant Verifier: 3) It takes atps=SDID and atps=hash to do the hash(ADID, SDID) lookup. 4) A positive results signifies authorization, allowance. Correct? In the original ATPS drafts, in step #3 would of been: 3) Do a ADSP lookup, if "atps=y" tag found, do hash(ADID, SDID) lookup. Correct? Well, I think you prematurely removed the ADSP dependency. Wish I was there to object. Making it based off DKIM increased the adoption barriers with a DKIM change requirement. This would be one big reason for no traction. Anyway, I think we can simplify this. Back when RFC5016 was being done, an implementation debate regarding when to do the policy lookup, under what condition. Concerns of too much DNS wasted calls, etc. The threat analysis RFC4686 pretty provided a consensus that the only time we really needed to do the lookup was under the mismatch condition: ADID != SDID Doing a lookup even under ADID == SDID condition did allow for addition policy offerings such as: o Domain has no mail operations o Domain does not sign mail But these events can be folded with other fail conditions so it wasn't necessary to do a lookup for a valid 1st party signature. After all, the Trust Lookup of SDID was the next step in this total DKIM+POLICY+TRUST process. So in short, all these extended ideas for a DSAP, TPA, ATPS, etc, can be done when the ADID != SDID condition exist. No "atps=y" dependency on any other protocol like ADSP, DMARC and DKIM. The mismatch condition is enough of a signal to run an optional 3rd party authorization check. I understand the reason for the "atpsh=" tag, but we can do it with a default hashing method. -- HLS From nobody Thu Apr 30 11:45:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262D71B2ED0 for ; Thu, 30 Apr 2015 11:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 QMmxH1Pi5y1u for ; Thu, 30 Apr 2015 11:45:49 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36141B2ECA for ; Thu, 30 Apr 2015 11:45:48 -0700 (PDT) Received: (qmail 79954 invoked from network); 30 Apr 2015 18:45:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 Apr 2015 18:45:49 -0000 Date: 30 Apr 2015 18:45:25 -0000 Message-ID: <20150430184525.21185.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <7120368.SRLs5cRkaz@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 18:45:50 -0000 >I recall some earlier discussion about encoding information in From local >part, but if for no other reason, automatic addition of new email addresses to >contacts by some MUAs makes that highly problematic. This trick also has patent problems. >DNS query to message-id.yamfsidlocalpart._dmarc.domain. The sender then >replies pass/fail/error. I think you will find that his has impossible scaling problems, particularly if you care enough about security to use DNSSEC to deter the usual poisoning attacks. There have been a variety of proposals over the years that publish per-message data out of band, so the recipient can check and see if the message is OK, and they all have the same scaling problem. Besides, you can get the same effect by taking whatever would be in that DNS record and putting it in the message, with a crypto signature to prove that it's real. The signature's validation key may come from the DNS, but that's OK since one validation key can be shared over many messages. We've just reinvented DKIM, perhaps with an extra field or two to include the yaimfs stuff. If you're worried about message mutations breaking the signature, don't sign the stuff that's likely to mutate. R's, John From nobody Thu Apr 30 12:03:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA561B2EEA for ; Thu, 30 Apr 2015 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=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 U2oQEehPmqED for ; Thu, 30 Apr 2015 12:03:09 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 3A9251ACDF3 for ; Thu, 30 Apr 2015 12:03:09 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so69314824pdb.2 for ; Thu, 30 Apr 2015 12:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lf366r1jan160Efr4PLAH93ZwkFFTmCwKj9nQHBZujQ=; b=AswdDHiu7GcfpimEjwYfn+2WIqGzGoBVZf8n3F/lYfKxXwZEF1koyVz+EIIoXU8j5/ 9Yx4J+0n0jPgxnQLh60F3TqQQj577O4tH81Q3/IORVPyKOz9i0SsiaPrimNW4gfNjxgV ttzkxPfLVBFqhW6jlq2nvpT4YoUyoiAmCqp8aP93nmOTTVCQaPIezdcqeoiSS/fJvk5c ErBEm7jsD9Gi0fYxunktLsl/FkLOcZ987blSQKbnWUVEnWJYzFC35Zr1BU2kls9bjdFS D0fVnDHm6ULIOQuHfz8BbUGPHkj7OcDom6k8DGhvD9mAgLUXV7v2W/YaEMyMLJ/stwnA yyBg== X-Received: by 10.70.25.37 with SMTP id z5mr11113558pdf.36.1430420588913; Thu, 30 Apr 2015 12:03:08 -0700 (PDT) Received: from US-DOUGO-MAC.local ([2601:9:7300:1510:a5bf:3aa1:6334:580d]) by mx.google.com with ESMTPSA id wh6sm2854082pbc.96.2015.04.30.12.03.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 12:03:07 -0700 (PDT) Message-ID: <55427C66.3020508@gmail.com> Date: Thu, 30 Apr 2015 12:03:02 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <55426F96.8080500@isdg.net> In-Reply-To: <55426F96.8080500@isdg.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 19:03:13 -0000 On 4/30/15 11:08 AM, Hector Santos wrote: > On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote: >> >> If OpenDKIM is popular among many big systems, it >> would make sense >> to slightly update OpenDKIM so that the "atps=y" >> option is based >> off a DMARC lookup. The change is small. >> >> Sure, if that's consensus. That would also involve >> promoting ATPS to >> the Standards Track, but to do that we'd need to see some >> hope that >> widespread deployment is likely. But we still have that >> pesky >> registration problem to deal with. > > Registration is a different situation that is tied to the > market place. It should not be a barrier to the IETF > technical protocol we wish to provide as a IETF > recommended solution. > >> Maybe Murray can explain how its setup and triggered >> in OpenDKIM. >> >> If you enable it, you just have to name which domains you >> authorize to >> sign for you. > > So if I understand RFC6541 (its unfortunate I wasn't > around during work): > > Given two identities: > > ADID Author Domain Identity (5322.From.domain) > SDID The signer domain identity to be placed in "d=" > > 1) The DKIM signer MUST add tag "atps=SDID" to DKIM-Signature > 2) The DKIM signer CAN add tag "atpsh=hash" to DKIM-Signature > > At the DKIM ATPS compliant Verifier: > > 3) It takes atps=SDID and atps=hash to do the hash(ADID, > SDID) lookup. > 4) A positive results signifies authorization, allowance. > > Correct? Dear Hector, My initial feedback on this was ignored. The matter became worse due to demands made by IESG out of DDoS concerns. The required use of a special DKIM signature is not practical for at least two reasons. 1) The label encoding used by a first party CAN NOT be directly ascertained! (There should only be one encoding scheme.) 2) It expects mediators to establish relationships with all first party domains. (Special DKIM signatures should be replaced by DMARC assertions to allow normal DKIM signatures AND other verification methods.) Imagine offering a free service. Because of a few irresponsible ESP making false assertions about their message alignment, this then requires all secondary services to establish a database against tens of thousands of domains. This effort is absolutely reasonable for the large ESPs attempting to assert restrictive policies, it is not reasonable for tens of thousands of third-party services now expected essentially replicate this effort. TPA-Label offers a much cleaner solution that does not require the use of DKIM or SPF. Use of a special DKIM signature actually increases DDoS concerns. > In the original ATPS drafts, in step #3 would of been: > > 3) Do a ADSP lookup, if "atps=y" tag found, do hash(ADID, > SDID) lookup. > > Correct? > > Well, I think you prematurely removed the ADSP dependency. > Wish I was there to object. Making it based off DKIM > increased the adoption barriers with a DKIM change > requirement. This would be one big reason for no traction. > > Anyway, I think we can simplify this. Back when RFC5016 > was being done, an implementation debate regarding when to > do the policy lookup, under what condition. Concerns of > too much DNS wasted calls, etc. The threat analysis > RFC4686 pretty provided a consensus that the only time we > really needed to do the lookup was under the mismatch > condition: > > ADID != SDID > > Doing a lookup even under ADID == SDID condition did allow > for addition policy offerings such as: > > o Domain has no mail operations > o Domain does not sign mail > > But these events can be folded with other fail conditions > so it wasn't necessary to do a lookup for a valid 1st > party signature. After all, the Trust Lookup of SDID was > the next step in this total DKIM+POLICY+TRUST process. > > So in short, all these extended ideas for a DSAP, TPA, > ATPS, etc, can be done when the ADID != SDID condition > exist. No "atps=y" dependency on any other protocol like > ADSP, DMARC and DKIM. > > The mismatch condition is enough of a signal to run an > optional 3rd party authorization check. I understand the > reason for the "atpsh=" tag, but we can do it with a > default hashing method. Absolutely. In fact, you should be able to use a simple assertion in the DMARC record and leverage existing DKIM signatures AND other authentication schemes. I would be happy to go over what it would take for the information contained in these schemes to be compatible, but why? It seems going to the trouble of establishing third-party profiles, this effort should anticipate what might be needed to help mitigate expected abuse. (Reducing the attack surface so to speak.) My latest draft on this matter offers a simple solution requiring minimal registration << 100. Regards, Douglas Oits From nobody Thu Apr 30 12:11:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813951A8A23 for ; Thu, 30 Apr 2015 12:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 saqdpAdl_ens for ; Thu, 30 Apr 2015 12:11:28 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA81A89C6 for ; Thu, 30 Apr 2015 12:11:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=564; t=1430421086; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5BnaL00gwslWWz2wC8d3Gv2CHqk=; b=ZVDlFh+p7aKjKCSuvwtw n5SITzA1c9LNTDwNyQ/Vy7sa9ADQKZAYZW14R35LBd93TSAj6hcvcr9QU7jzqu+K SQVjPBCrhR2YZ2cCZ5exTzwOEM/Xl5umWB8t2X10ZB2DxXMlEOsqLsMUzcxrOzYw guhdl4xXSnPJOUHC9z3eJSk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 15:11:26 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4131086057.4153.6020; Thu, 30 Apr 2015 15:11:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=564; t=1430420825; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7zH7Fh1 spIC5ORS21MVGZW7EDRcJH3K/SwvUgXahOoo=; b=UqSSjVP0t9w/o+cei53/sYE zObjnIe61H96gEFDtauHrKGuU5QCWd8X1dGpVUUImx//T8ROhPpxzexQuumXlck3 P3uDZ0Ra1FRzhmAIuTykOhtO3oc2fkkpWAJmeNCEIC8L8ye2jyl06hxt4u1SPI33 u3NCU9f7xKEE5kvY0xcY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 15:07:05 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2723360988.9.7528; Thu, 30 Apr 2015 15:07:04 -0400 Message-ID: <55427E5E.9030100@isdg.net> Date: Thu, 30 Apr 2015 15:11:26 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Need for DSAP Functional Requirements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 19:11:30 -0000 With all the DKIM Signature Authorization Protocol (DSAP) proposals and ideas being offered, I think we need to rewrite or re-establish what are the DSAP goals and functional requirements. What are we trying to accomplish? Under what conditions and requirements? I think it has been established there is a chasm on what is considered a registration problem. I think that happens to be a separate "Big Data" problem, possibly even an IETF protocol problem, however most likely a proprietary problem, but not the main one we can resolve here. -- HLS From nobody Thu Apr 30 12:27:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475971ACDF3 for ; Thu, 30 Apr 2015 12:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 e2soNSLzOsoc for ; Thu, 30 Apr 2015 12:27:24 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D531A886A for ; Thu, 30 Apr 2015 12:27:23 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5FDCAC4016C for ; Thu, 30 Apr 2015 14:27:22 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430422042; bh=2lzItobt5dX+QATsmJcQmcAOGZpFI2pV3A+TXF9yOtQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TPPEtPmzwDD6dOWnQtnKgWvRF9O+TjW94gCLNezTDSlXjtwDm+m68l9W+a7ktL6aD 1JajySQp/i2/RhZApguj9UW80jyzkWLszfs9bFva5WLU5+IHCgCKA76sX+Vb7fINR3 yXfpQ2DfVhZcALBfeeOgFY1pNN7IFSzkPmaLzE1M= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 30 Apr 2015 15:27:21 -0400 Message-ID: <3459026.YU4BBsPhrU@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150430184525.21185.qmail@ary.lan> References: <20150430184525.21185.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 19:27:26 -0000 On Thursday, April 30, 2015 06:45:25 PM John Levine wrote: > >I recall some earlier discussion about encoding information in From local > >part, but if for no other reason, automatic addition of new email addresses > >to contacts by some MUAs makes that highly problematic. > > This trick also has patent problems. > > >DNS query to message-id.yamfsidlocalpart._dmarc.domain. The sender then > >replies pass/fail/error. > > I think you will find that his has impossible scaling problems, > particularly if you care enough about security to use DNSSEC to deter > the usual poisoning attacks. > > There have been a variety of proposals over the years that publish > per-message data out of band, so the recipient can check and see if > the message is OK, and they all have the same scaling problem. > > Besides, you can get the same effect by taking whatever would be in > that DNS record and putting it in the message, with a crypto signature > to prove that it's real. The signature's validation key may come from > the DNS, but that's OK since one validation key can be shared over > many messages. We've just reinvented DKIM, perhaps with an extra > field or two to include the yaimfs stuff. If you're worried about > message mutations breaking the signature, don't sign the stuff that's > likely to mutate. Yeah. If you want something signed, then it becomes equivalent to the fs= proposal. To be effective, it would have to have something based on database queries, not a static zone, so I can imagine DNSSEC problems. Is having a non-DNSSEC subdomain that has no real hosts in it problematic? RBLs seem to scale reasonably well, although I realize per message is more of an issue than per sending IP. Scott K From nobody Thu Apr 30 15:25:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05C81B2E4D for ; Thu, 30 Apr 2015 10:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, SPF_PASS=-0.001] autolearn=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 zI2l_OQwuVFr for ; Thu, 30 Apr 2015 10:00:46 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 A48191B2E40 for ; Thu, 30 Apr 2015 10:00:46 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so19375758igb.0 for ; Thu, 30 Apr 2015 10:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nryep2wla6BuhIVMNcPgI1r9JQ1YMlMAqhI077hmXmA=; b=OlS9/HjFYks/qyINfygGgWEpWy9ynY3aePdhg3kRzp4bGWy2VoHKd6oCvX4V33UmuV UDkH0udeyE8FDTl1wBcQShCX7XCVmqinQRDDrNYWF9zojd+ZAhr6MvI1wvgVTkgnwFH0 muZzsM+T9LqfYlrXd2oT03CRlXJ5jefJG+aSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Nryep2wla6BuhIVMNcPgI1r9JQ1YMlMAqhI077hmXmA=; b=KqDgu9/HwJadveRDmly2gfPnHU33rHbsAEmLnh2Dweqmj/cH5H9bske2K8vpNGqWws Ym5iTPSRWWmROoLVqO8nQZszyUJgngdnmGPJH0FzhqcaTyQwK2t60xJMxgbIkyM/ehT+ TWiYtKydz5BAyvGcU83+1X4sIrITuaoiLFIN0Dmocn8fsamWpVxzC7Ie5xdgz68vKcsy FJKMOOZDKsmn/hMZcu7Qsm/BoWFG+vRo4YW1c/flq5hJP567t/1BQtU5ntKPqFyiHpBx YU1SIrRgQpCfareBjuOmegM27USS8yupDLzjnt4IVseU7ikFYH3obH828tGXCkimmrrn XkIw== X-Gm-Message-State: ALoCoQmO8iE5PJ8WEb9qyW5BLVgfql7pcvsZNkvNQkzbgymmGczIjpMPN+GqMZopiuBed5OIUZ4i MIME-Version: 1.0 X-Received: by 10.107.30.10 with SMTP id e10mr6915653ioe.72.1430413246112; Thu, 30 Apr 2015 10:00:46 -0700 (PDT) Received: by 10.36.3.148 with HTTP; Thu, 30 Apr 2015 10:00:46 -0700 (PDT) In-Reply-To: <7120368.SRLs5cRkaz@kitterma-e6430> References: <7120368.SRLs5cRkaz@kitterma-e6430> Date: Thu, 30 Apr 2015 10:00:46 -0700 Message-ID: From: Kurt Andersen To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a1140f33c6ab3050514f4090c Archived-At: X-Mailman-Approved-At: Thu, 30 Apr 2015 15:25:57 -0700 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:00:48 -0000 --001a1140f33c6ab3050514f4090c Content-Type: text/plain; charset=UTF-8 On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman wrote: > > It might be useful though to have some opt-in mechanism for DMARC senders > to > get an additional query for verification purposes. > > Concept: > > Participating senders add a new optional tag to their DMARC record, > something > like yaimfs=y and a new field in the header that is something like: > > yaimfs-id: localpart@domain > > Domain must be aligned with the From domain > > For mail that passes DMARC, no changes are made. If a message fails DMARC > checks and both the DMARC record (which is already in the local cache) has > yaimfs=y and the message has yaimfs-id is possible, then the receiver > sends a > DNS query to message-id.yamfsidlocalpart._dmarc.domain. The sender then > replies pass/fail/error. > > I suggest message ID be included since it's supposed to be globally unique > to > reduce the risk of collision. > > This idea effectively would create a new authentication protocol based on > direct query/feedback and extend DMARC to use it. It would be totally > opt-in. > Interesting idea - essentially it would allow senders to provide an independent authorization channel for messages. What worries me, is why a sender would sanction a message that presumably has been sufficiently altered as to fail DKIM validation without knowing something about the content as received. It seems somewhat like saying that if you get a check (the old-fashioned paper kind), that if you call me and tell me what color the paper is, then you can cash the check (presuming that the color is correct). I would not, personally, be granting any such approvals. --Kurt --001a1140f33c6ab3050514f4090c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman <skli= st@kitterman.com> wrote:

It might be useful though to have some opt-in mechanism for DMARC senders t= o
get an additional query for verification purposes.

Concept:

Participating senders add a new optional tag to their DMARC record, somethi= ng
like yaimfs=3Dy and a new field in the header that is something like:

yaimfs-id: localpart@domain

Domain must be aligned with the From domain

For mail that passes DMARC, no changes are made.=C2=A0 If a message fails D= MARC
checks and both the DMARC record (which is already in the local cache) has<= br> yaimfs=3Dy and the message has yaimfs-id is possible, then the receiver sen= ds a
DNS query to message-id.yamfsidlocalpart._dmarc.domain.=C2=A0 The sender th= en
replies pass/fail/error.

I suggest message ID be included since it's supposed to be globally uni= que to
reduce the risk of collision.

This idea effectively would create a new authentication protocol based on direct query/feedback and extend DMARC to use it.=C2=A0 It would be totally= opt-in.

Interesting idea - essentially= it would allow senders to provide an independent authorization channel for= messages. What worries me, is why a sender would sanction a message that p= resumably has been sufficiently altered as to fail DKIM validation without = knowing something about the content as received.

It seems= somewhat like saying that if you get a check (the old-fashioned paper kind= ), that if you call me and tell me what color the paper is, then you can ca= sh the check (presuming that the color is correct). I would not, personally= , be granting any such approvals.

--Kurt
<= br>
--001a1140f33c6ab3050514f4090c-- From nobody Thu Apr 30 15:26:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B46A1A873D for ; Thu, 30 Apr 2015 10:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6JgQ8iGL2KT1 for ; Thu, 30 Apr 2015 10:03:09 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 0F5371A6FCB for ; Thu, 30 Apr 2015 10:03:09 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so19446755igb.0 for ; Thu, 30 Apr 2015 10:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KVQdtdxiGlW8BG4dJSBzsQ4RLZdK4SDYWAN06kTi+p0=; b=UVSR4UZJWPpPJEXjN10VQU8zmMNEMyMXdbYXS9exXhOD7mg3W2XLEjtHqH7zwFk34r hh70cT4OvWWcLQscltPhAzNDr72fSiN4ycb0B8CZxoD1BTiAjYkA/9bkaSeugKqMXsT6 AcYd+8gHiVpUQAD60l0RvCKYQMvJfpgpuwf8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KVQdtdxiGlW8BG4dJSBzsQ4RLZdK4SDYWAN06kTi+p0=; b=h/F8tWxHBIisywMuKk/mNGHH76fHVFJQGuRBwvarKk/JYjF8WA9r3N2gy8NQr9FvgE l0wcAUiEtPmSJhrOMRqfIyH2Y0B75Qv+l++No1YJ8jMgrhvAlTb8aaxF0TNVId3JtCTa 1113T9zgEUl6cLVsHeobhfRUugZU+gkkI7VQe4Gk6L+sHJMJ9cEywOkr5Yl7+aUycMU+ +woZ+WboDC5m7tndq9KSCZVlv9r+0XYH/ijDyFdY34t2GOdAHdrsH261n64mzyyrBsfF 9L+VGFB5Ye76ZN1nQmL/f/Rjn4WObiVlixRmV2JgRBtK2kraFzAQNnRbGQmJmxvSPnIm 9EOw== X-Gm-Message-State: ALoCoQn3UpbP61iFlCovTF7SVJBbpQFZEQBUEdXI4DsA5vzATeH3jgaIPkcTTFAwo7g0lcvR8Fol MIME-Version: 1.0 X-Received: by 10.42.204.14 with SMTP id fk14mr10182024icb.96.1430413388582; Thu, 30 Apr 2015 10:03:08 -0700 (PDT) Received: by 10.36.3.148 with HTTP; Thu, 30 Apr 2015 10:03:08 -0700 (PDT) In-Reply-To: <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> Date: Thu, 30 Apr 2015 10:03:08 -0700 Message-ID: From: Kurt Andersen To: Franck Martin Content-Type: multipart/alternative; boundary=20cf30363b93e8c60c0514f411f3 Archived-At: X-Mailman-Approved-At: Thu, 30 Apr 2015 15:25:57 -0700 Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:03:10 -0000 --20cf30363b93e8c60c0514f411f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin wrote: > > I log any rejected email that has a List-Post or List-id (not all MLMs us= e > List-Id). I see a lot of marketing emails and spam with these headers. So > there is a need to make sure this is really a MLM. It is not overly > complicated, considering I=E2=80=99m mostly the only one to subscribe to = MLM with > my corporate email address, but I wanted to mention the presence of such > headers is not foolproof. > With List-Id becoming a more generic feedback channel, I suspect that its value for indicating the participation of a MLM will further degrade. --Kurt Andersen --20cf30363b93e8c60c0514f411f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin <fr= anck@peachymango.org> wrote:
I log any rejected email that has a List-Post or List-id (not all ML= Ms use List-Id). I see a lot of marketing emails and spam with these header= s. So there is a need to make sure this is really a MLM. It is not overly c= omplicated, considering I=E2=80=99m mostly the only one to subscribe to MLM= with my corporate email address, but I wanted to mention the presence of s= uch headers is not foolproof.

With List= -Id becoming a more generic feedback channel, I suspect that its value for = indicating the participation of a MLM will further degrade.

--Kurt Andersen
--20cf30363b93e8c60c0514f411f3-- From nobody Thu Apr 30 16:30:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960D91A8920 for ; Thu, 30 Apr 2015 16:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 R7aJP6FX4ycJ for ; Thu, 30 Apr 2015 16:30:16 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 44C551A8951 for ; Thu, 30 Apr 2015 16:30:16 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so74176158pab.3 for ; Thu, 30 Apr 2015 16:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7yICpswkLaMjPWESKiy2WSGiWbCuAM5nSK1HEyC3Ntg=; b=maNvfLlSDCVSIWgmVP6kNGinkeXgo4CxIpIKpqK1UkauQebRxBk7ovEKTxYyQoWEkB Y4rNZBaUjaKaOjtM/QnDNU0nb3fWxEdO8Lc0oVw3PyMqLPzYT6XITTHsvvxmrtcox1pU 7/QaKL0FjtQRyknCjTCA4sSu3gGZoV6Bqw/kavbzyHEIRK8VUEVLGiuzgoNsIQma3U8d RFLZef2LbKYPxecOWf9UjX8FF8qB5kimhZIPmHIniK14ZHwzsq/MSi/m/+aT28jAU5x3 kYfG8blzkREQ33CK/HLYR7qTRYrolK8GdBOixE2MkWgXuiKXbT26qkJkoZfbKQpfEd4m iORA== X-Received: by 10.66.156.198 with SMTP id wg6mr12635558pab.126.1430436615989; Thu, 30 Apr 2015 16:30:15 -0700 (PDT) Received: from US-DOUGO-MAC.local (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by mx.google.com with ESMTPSA id t8sm3180518pbs.59.2015.04.30.16.30.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 16:30:14 -0700 (PDT) Message-ID: <5542BB03.1090605@gmail.com> Date: Thu, 30 Apr 2015 16:30:11 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 23:30:17 -0000 On 4/30/15 10:03 AM, Kurt Andersen wrote: >> It is not overly >> > complicated, considering I’m mostly the only one to subscribe to MLM with >> > my corporate email address, but I wanted to mention the presence of such >> > headers is not foolproof. >> > > With List-Id becoming a more generic feedback channel, I suspect that its > value for indicating the participation of a MLM will further degrade. Dear Kurt, Rather than seeing List-ID as representing feedback, it can be used to restrict the scope of an authorization scheme as a way to acknowledge a known relationship closely monitored by the domain granting authorization. Limiting the attack surface so to speak. This would allow less disruptive methods in seeking cooperation in the removal of an errant participant as described by TPA-Label. TPA-Label does not require modifications made to current verification schemes. It simply leverages available identifiers using a highly scalable authorization method with little DDoS risk. Domains wishing to improve protections beyond what a "public" assertion would allow can adopt TPA-Label to offer actionable and lower disruptive policy handling request adjustments. Such "pointy stick" feedback better ensures cooperative message handling. When authorization is based on comprehensive message signatures, this feedback can not be leveraged by malefactors. Regards, Douglas Otis From nobody Thu Apr 30 20:52:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420211B3019 for ; Thu, 30 Apr 2015 20:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 SVnVoIcax2Vs for ; Thu, 30 Apr 2015 20:52:44 -0700 (PDT) Received: from pop3.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C19A11B3020 for ; Thu, 30 Apr 2015 20:50:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1068; t=1430452217; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8I8qTu5uLkCzY9M5meYhkskQiNE=; b=wUTPK7N47k6ZqREHfOyA xk8I4j4RaO18hontr3/bqwXkqtSOwUJgTaEBDczqH/YP+doMfeNVVPHRqSCGWngX kP5k2agVRpNEjgK3/1ImqzcqjnuOD2Huyw8wiuL5Iti8PrAkZ1/jBxnvCVrGiUSn 2IS0/7pkv7drK8gZ5BO5jB0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 23:50:17 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4162216399.4153.924; Thu, 30 Apr 2015 23:50:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1068; t=1430451958; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bY2/l0g g3Cz0ApH2xdHCMYkBWpFG81JDw7hBoX/k8Bo=; b=OWTWfjSL94hkMfDHvvxZkEh x6jnOaBE7bHT0wEcp1nh613f0rs6P/9c0ONhyd8MTy/+T1Dj7ckONvgnS1yQ7RMY Pzu9q00j3IDiI94gKBpjpBk6dvxZ3vttkLFc1IWaveYvbqyipnDWc1fbmNP/3RZS 175OrgL53S2zILmh4+Mg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 30 Apr 2015 23:45:58 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2754494176.9.10916; Thu, 30 Apr 2015 23:45:57 -0400 Message-ID: <5542F7FC.3030407@isdg.net> Date: Thu, 30 Apr 2015 23:50:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 03:52:48 -0000 On 4/30/2015 1:03 PM, Kurt Andersen wrote: > On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin > wrote: > > > I log any rejected email that has a List-Post or List-id (not all > MLMs use List-Id). I see a lot of marketing emails and spam with > these headers. So there is a need to make sure this is really a > MLM. It is not overly complicated, considering I’m mostly the only > one to subscribe to MLM with my corporate email address, but I > wanted to mention the presence of such headers is not foolproof. > > > With List-Id becoming a more generic feedback channel, I suspect that > its value for indicating the participation of a MLM will further degrade. > Our operators have signing rules that can use List-ID to determine when to sign and with various signing options. For example; [list-id:*] Enable=1 AddBodyLength=0 StripHeaders=DKIM-Signature Are you suggesting they might want to strip the List-ID for some signings? StripHeaders=DKIM-Signature:List-ID -- HLS