From nobody Tue Jul 1 09:02:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0411B27FC for ; Tue, 1 Jul 2014 09:02: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 Em7uocvmZWel for ; Tue, 1 Jul 2014 09:02:10 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846A61A0391 for ; Tue, 1 Jul 2014 09:02:10 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 131so5796452ykp.35 for ; Tue, 01 Jul 2014 09:02: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SZhI+NJCavqmRdXMg323zigzEfd72WwAUWNJQ7cZuGg=; b=Vo/nDnwFHr8XIzAT+JI3J7dt2WCggbdzS7Xnrxba78ZF1pfUESdy+p7WGyQABiICAX lwzJSrnNDEO2mBawdQumTSjncnJiB8xIMEdRmvXKLyTsbdBj9s0JgwH6vn8weQYOFQai lxd1PobTRGee/D8iqC8EKVOj08FOjve3uzPr1T4uaR6mpaGtxFPnw0dAq+vvbhETnJlm kVCOeF8vdo+9YVGcH4VA2xwS1tT6H0TyiIxuLO2TX6xZzNMyizIQrPQqWskdwmEiJZ0B /3pzRHhw3IxABdyvoVpuNzORGMCufUBAMiAj75IaMrLqnjvH8K8TEQF49nBK6Jjof5do BoPg== X-Received: by 10.236.131.193 with SMTP id m41mr24708834yhi.96.1404230529839; Tue, 01 Jul 2014 09:02:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id j46sm28589276yhc.14.2014.07.01.09.02.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 09:02:08 -0700 (PDT) Message-ID: <53B2DB2B.2090301@gmail.com> Date: Tue, 01 Jul 2014 09:00:43 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> In-Reply-To: <53A48DB1.9080706@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NXGXgB6whQ6xbDOoSX0Gywpy_J4 Cc: Pete Resnick , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 16:02:13 -0000 On 6/20/2014 12:38 PM, Dave Crocker wrote: > Here is some draft text to consider for a DMARC working group charter: G'day, I've looked over the small amount of mail posted about the draft charter and do not see any changes mandated. Apologies if I've missed something, and I assure you it wasn't intentional. So please do re-state the suggestion. Otherwise, I think the major question now is whether there is general consensus on submitting this draft charter text to the IESG? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 1 09:53:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE79E1B2853 for ; Tue, 1 Jul 2014 09:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 xK0TD9fFqF04 for ; Tue, 1 Jul 2014 09:53:06 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 820551B283D for ; Tue, 1 Jul 2014 09:53:05 -0700 (PDT) Received: from [192.168.2.109] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 71C14CB46 for ; Tue, 1 Jul 2014 12:53:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: <53B2DB2B.2090301@gmail.com> Date: Tue, 1 Jul 2014 12:53:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3AD56B8A-CD9F-4398-9A6D-9E9123833A9F@eudaemon.net> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V81SiRD78qBuwREtz-ajC7K_noY Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 16:53:07 -0000 On Jul 1, 2014, at 12:00 PM, Dave Crocker wrote: > Otherwise, I think the major question now is whether there is general > consensus on submitting this draft charter text to the IESG? Dave, I'm not sure if you're asking, but I think the WG Charter is good = enough. Consensus++ From nobody Tue Jul 1 10:45:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A027F1A03B7 for ; Tue, 1 Jul 2014 10:45:15 -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 z75tyeFx7vUY for ; Tue, 1 Jul 2014 10:45:13 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681541A03A1 for ; Tue, 1 Jul 2014 10:45:13 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so8102220qab.29 for ; Tue, 01 Jul 2014 10:45:12 -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 :message-id:references:to; bh=V+8TOARa6MDjg+p7ikIuMA3BXJThvYufoDgXrsq64VY=; b=rT6Lst8mWMAubKAavZ+f/sW4G69IfL74NTDgCjl3kyIV4h3BU5M82y67Hke/dJ/oIG ovbJ0dykXUAKm6TyPZ/PCNpS91cx2hSlNqK3lBp74zY+XehMmka3DMJSN+pAWOVmnVUv 0po8wT+ENHg4ffijQSAn0zxdn9T8foQBmX49OU99ejldDiDU96949RrDxNgtXMsYIDI2 eBle0+bq8F8Fk1r9j3f8jMh0X4bCMhbXyaH33eOXFYtO+3t65UMPvvKxhJUgFvb5lsGN 8bCqjdORztHrmiznJf8tdoI+6ZsBAeiN4bpyPHpNrsgrgSb/Sr9kNPxBvP6UrU0X3sgQ oroQ== X-Received: by 10.224.11.6 with SMTP id r6mr77703162qar.74.1404236712665; Tue, 01 Jul 2014 10:45:12 -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 g17sm38331835qaq.44.2014.07.01.10.45.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 10:45:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_43339DDD-AA8B-4EB7-9978-9F86825266E5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <53B2DB2B.2090301@gmail.com> Date: Tue, 1 Jul 2014 10:45:10 -0700 Message-Id: <09DA5461-EFCA-45EC-B886-6E079DE20D15@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> To: Dave Crocker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ffJ03FQ7W7hW9QDV0m7IGaI8SbY Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 17:45:15 -0000 --Apple-Mail=_43339DDD-AA8B-4EB7-9978-9F86825266E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 1, 2014, at 9:00 AM, Dave Crocker wrote: > On 6/20/2014 12:38 PM, Dave Crocker wrote: >> Here is some draft text to consider for a DMARC working group = charter: >=20 >=20 > G'day, >=20 > I've looked over the small amount of mail posted about the draft = charter > and do not see any changes mandated. >=20 > Apologies if I've missed something, and I assure you it wasn't > intentional. So please do re-state the suggestion. >=20 > Otherwise, I think the major question now is whether there is general > consensus on submitting this draft charter text to the IESG? Dear Dave, I do not think the charter is adequate. It needs to address the topic = related to authorizing third-party use. Otherwise, it is not possible = to address the resulting disruption when reject is ever desired in = conjunction with a mixed use domain. At this point, it seems wrong to = expect this problem will somehow evaporate. Several have suggested things like DKIM-Delegate, CDKIM, and the like. = Frankly, your DKIM-Delegate distributes less data than would using the = TPA-Label. However, TPA-Label requires much smaller DNS resources = assuming public key retraction is to remain an important control aspect. = IMHO, reliance on expiry represents a poor option. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism +- Domain Federation or Authorization scheme. See DKIM-Delegate or = TPA-Label drafts as examples. Our company is willing to work with any large ISP to demonstrate = use of TPA-Label. http://tools.ietf.org/html/draft-otis-tpa-label Such a conclusion is easily supported since only the DMARC domain = receives feedback necessary to acknowledge and mitigate abuse of the = =46rom header field. As such, ONLY the DMARC domain is able to indicate = which other domains are permitted (authorized or federated). Phishing and spoofing is an extremely serious problem NOT addressed = using anti-SPAM techniques. If there is some time available in any = upcoming meeting, I would like to take a few minutes to review this = matter and relate our company's experience. Regards, Douglas Otis --Apple-Mail=_43339DDD-AA8B-4EB7-9978-9F86825266E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 1, 2014, at 9:00 AM, Dave = Crocker <dcrocker@gmail.com> = wrote:

On 6/20/2014 12:38 PM, Dave Crocker wrote:
Here is some draft text to consider for a DMARC working = group charter:

G'day,

I've looked over = the small amount of mail posted about the draft charter
and do not = see any changes mandated.

Apologies if I've missed something, and = I assure you it wasn't
intentional. So please do re-state the = suggestion.

Otherwise, I think the major question now is whether = there is general
consensus on submitting this draft charter text to = the IESG?

Dear Dave,

I do not = think the charter is adequate. It needs to address the topic = related to authorizing third-party use. Otherwise, it is not = possible to address the resulting disruption when reject is ever = desired in conjunction with a mixed use domain. At this point, it = seems wrong to expect this problem will somehow = evaporate.

Several have suggested things like DKIM-Delegate, = CDKIM, and the like. Frankly, your DKIM-Delegate distributes less = data than would using the TPA-Label. However, TPA-Label = requires much smaller DNS resources assuming public key retraction is to = remain an important control aspect. IMHO, reliance on expiry = represents a poor option.

Improvements in DMARC = features (identifier alignment, reporting, policy

preferences) = will be considered, such as:

- = Enumeration of data elements required in "Failure" = reports

(specifically to address = privacy issues)

- Handling potential reporting = abuse

- Aggregate reporting to support additional = reporting scenarios

- Alternate reporting = channels

- Utility of arbitrary identifier = alignment

- Utility of a formalized policy = exception mechanism

+- Domain Federation or = Authorization scheme. See DKIM-Delegate or TPA-Label drafts as = examples.
Our company is willing to work with any = large ISP to demonstrate use of TPA-Label.

http://tools.ietf= .org/html/draft-otis-tpa-label

Such a conclusion is = easily supported since only the DMARC domain receives feedback necessary = to acknowledge and mitigate abuse of the =46rom header field. As = such, ONLY the DMARC domain is able to indicate which other domains are = permitted (authorized or federated).
Phishing and spoofing is an = extremely serious problem NOT addressed using anti-SPAM techniques. If = there is some time available in any upcoming meeting, I would like to = take a few minutes to review this matter and relate our company's = experience.

Regards,
Douglas = Otis

= --Apple-Mail=_43339DDD-AA8B-4EB7-9978-9F86825266E5-- From nobody Tue Jul 1 11:19:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFA71B2863 for ; Tue, 1 Jul 2014 11:19:40 -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 PEHh4SmzRwsH for ; Tue, 1 Jul 2014 11:19:39 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C841B2880 for ; Tue, 1 Jul 2014 11:19:38 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so10073659veb.13 for ; Tue, 01 Jul 2014 11:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VT1HJE9ZBgSJ/K6wa/9Ty/UBUlOAadN99J97vPIo41I=; b=M9i2J+OMk+0fVtzTCE1BPYsni1i2/mGq/TdsTKuUK9MdqAqgv/ZlgA5KZyyeBmlDRC lxKQPiJSPt2+7D0qNRhB5Lt04A2oqMwGrYB/+bKrnmV8X3Ipy02vojED7IqIu3KNTdg8 cSwlCN0YWY2iU1FAMb17g1TlZo0chi/UUgdB8= 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=VT1HJE9ZBgSJ/K6wa/9Ty/UBUlOAadN99J97vPIo41I=; b=TDzb8y0ngYuTKqWnQM3nDo6aMEEQ0UWhX2FetFTaq1m6KXgBJ0KhcJJjLNgzPZVh9S nB7PTCT12729FmN/rLJBlG2gjCA7/JzS+H7rOj4M7H983MCUezh5ZqEOC/5zLzY1rgVp TvGRWjqhdc0Hf7p1Yr/yaWzyppaWGkIy1LEMsW/v+UOxz37kBnfMwtAfY9p2j7jgKjo3 vsO4t4SVqS+1M6BDUYap3LuywuZO2AwMdtDVux7Vs2dtiC7c3s7Ei/wd/NQjwQiDQgiS bijhKfQnU/oozJHgnFOlgX8+Ka5F4a6kycHOofcR33V7TTTNWWD3pYWVZNuOC0HTUyXN i7WQ== X-Gm-Message-State: ALoCoQm60U1rdopJuTayIoSHOlO+FpBykF+WeGKIs0b3uvVrACffHYR3rvIhRV08t2mPRRy83a/l MIME-Version: 1.0 X-Received: by 10.221.21.69 with SMTP id qr5mr63839vcb.62.1404238777619; Tue, 01 Jul 2014 11:19:37 -0700 (PDT) Received: by 10.52.121.132 with HTTP; Tue, 1 Jul 2014 11:19:37 -0700 (PDT) In-Reply-To: <09DA5461-EFCA-45EC-B886-6E079DE20D15@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <09DA5461-EFCA-45EC-B886-6E079DE20D15@gmail.com> Date: Tue, 1 Jul 2014 11:19:37 -0700 Message-ID: From: Mike Jones To: Douglas Otis , Dave Crocker Content-Type: multipart/alternative; boundary=001a11339fb4852a9104fd25d18b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JdFYniBrHTrDEyErEFBqxkHcumc Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 18:19:40 -0000 --001a11339fb4852a9104fd25d18b Content-Type: text/plain; charset=UTF-8 I believe the WG charter is adequate as written. The activities described in section one of the working group activities addresses third-party email and DMARC. That section says that the working group will document the effects of DMARC on such mail flows and "consider mechanisms for reducing or eliminating DMARC's effects on indirect mail flows". I am in favor the of the WG charter as written. Thanks, Mike On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis wrote: > > On Jul 1, 2014, at 9:00 AM, Dave Crocker wrote: > > On 6/20/2014 12:38 PM, Dave Crocker wrote: > > Here is some draft text to consider for a DMARC working group charter: > > > > G'day, > > I've looked over the small amount of mail posted about the draft charter > and do not see any changes mandated. > > Apologies if I've missed something, and I assure you it wasn't > intentional. So please do re-state the suggestion. > > Otherwise, I think the major question now is whether there is general > consensus on submitting this draft charter text to the IESG? > > > Dear Dave, > > I do not think the charter is adequate. It needs to address the topic > related to authorizing third-party use. Otherwise, it is not possible to > address the resulting disruption when reject is ever desired in conjunction > with a mixed use domain. At this point, it seems wrong to expect this > problem will somehow evaporate. > > Several have suggested things like DKIM-Delegate, CDKIM, and the like. > Frankly, your DKIM-Delegate distributes less data than would using the > TPA-Label. However, TPA-Label requires much smaller DNS resources > assuming public key retraction is to remain an important control aspect. > IMHO, reliance on expiry represents a poor option. > > Improvements in DMARC features (identifier alignment, reporting, policy > preferences) will be considered, such as: > > - Enumeration of data elements required in "Failure" reports > (specifically to address privacy issues) > - Handling potential reporting abuse > - Aggregate reporting to support additional reporting scenarios > - Alternate reporting channels > - Utility of arbitrary identifier alignment > - Utility of a formalized policy exception mechanism > > +- Domain Federation or Authorization scheme. See DKIM-Delegate or > TPA-Label drafts as examples. > Our company is willing to work with any large ISP to demonstrate use > of TPA-Label. > > http://tools.ietf.org/html/draft-otis-tpa-label > > Such a conclusion is easily supported since only the DMARC domain receives > feedback necessary to acknowledge and mitigate abuse of the From header > field. As such, ONLY the DMARC domain is able to indicate which other > domains are permitted (authorized or federated). > Phishing and spoofing is an extremely serious problem NOT addressed using > anti-SPAM techniques. If there is some time available in any upcoming > meeting, I would like to take a few minutes to review this matter and > relate our company's experience. > > Regards, > Douglas Otis > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11339fb4852a9104fd25d18b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I believe the WG charter is adequate as written. =C2=A0The= activities described in section one of the working group activities addres= ses third-party email and DMARC. =C2=A0That section says that the working g= roup will document the effects of DMARC on such mail flows and "consid= er mechanisms for reducing or eliminating DMARC's effects on indirect m= ail flows".=C2=A0

I am in favor the of the WG charter as written.

Thanks,

Mike

On Tue, Jul 1= , 2014 at 10:45 AM, Douglas Otis <doug.mtview@gmail.com>= wrote:

On Jul 1, 2014, at 9:00 AM, Dave Crocker <dcrocker@gmail.com> wrote:
On 6/20/2014 12:38 PM, Dave Crocker wrote:
Here is some draft text to consider for a DMARC = working group charter:

G'day,

I've l= ooked over the small amount of mail posted about the draft charter
and do not see any changes mandated.

Apologies if I've missed so= mething, and I assure you it wasn't
intentional. =C2=A0So please do = re-state the suggestion.

Otherwise, I think the major question now i= s whether there is general
consensus on submitting this draft charter text to the IESG?

Dear Dave,

I do not think the charter is adeq= uate. =C2=A0It needs to address the topic related to authorizing third-part= y use. =C2=A0Otherwise, it is not possible to address the resulting disrupt= ion=C2=A0when reject is ever desired in conjunction with a mixed use domain= . =C2=A0 At this point, it seems wrong to expect this problem will somehow = evaporate.

Several have suggested things like DKIM-Delegate, CDKIM, and the like. = =C2=A0Frankly, your DKIM-Delegate distributes less data than would using th= e TPA-Label. =C2=A0However,=C2=A0=C2=A0TPA-Label requires much smaller DNS = resources assuming public key retraction is to remain an important control = aspect. =C2=A0IMHO, reliance on expiry represents a poor=C2=A0option.

Improvements in DMARC features (identifier alignment, reporting, p= olicy
preferences) will be considered, such as:

=C2=A0 =C2=A0- Enumeration of data elements required in "Failu= re" reports

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (specifically to address privacy issues)
=C2=A0 =C2=A0- Handling potential reporting abuse
=C2=A0= =C2=A0- Aggregate reporting to support additional reporting scenarios
=C2=A0 =C2=A0- Alternate reporting channels

=C2=A0 =C2=A0- Utility of arbitrary identifier alignment
=C2= =A0 =C2=A0- Utility of a formalized policy exception mechanism

=C2= =A0 +- Domain Federation or Authorization scheme. =C2=A0See DKIM-Delegate o= r TPA-Label drafts as examples.
=C2=A0 =C2=A0 =C2=A0Our company is willing to work with any large ISP to de= monstrate use of TPA-Label.

http://tools.ietf.org/html/dra= ft-otis-tpa-label

Such a conclusion is easily supported since only the DMARC domain = receives feedback necessary to acknowledge and mitigate abuse of the From h= eader field. =C2=A0As such, ONLY the DMARC domain is able to indicate which= other domains are permitted (authorized or federated).
Phishing and spoofing is an extremely serious problem NOT addressed using a= nti-SPAM techniques. If there is some time available in any upcoming meetin= g, I would like to take a few minutes to review this matter and relate our = company's experience.

Regards,
Douglas Otis

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

--001a11339fb4852a9104fd25d18b-- From nobody Tue Jul 1 11:34:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813E71B286A for ; Tue, 1 Jul 2014 11:34:40 -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 pPyYtnCPx8Za for ; Tue, 1 Jul 2014 11:34:39 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17831A02D9 for ; Tue, 1 Jul 2014 11:34:38 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so8335632wiv.8 for ; Tue, 01 Jul 2014 11:34: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=7HsaehBG0cxj8rrineIpx719q2iD1LJSs0a1jNHFeSI=; b=T26LvUQFHFS1hDh+P56vC7ArnYa5WPX+Ivm+Tyh7XpdvgZVzu+PLfnyb/55M4YpFjN yQ0NKVzMnekgaJhAaLvliiOe+w364lmMz+Y2F3/fTzwaJp2OPhgwmN/Q0KcWOSv9DbjV 4/KuUEIqGSCKv/Q8/yu8taa2IL5DwT2BLffUVzPiRUUr1bdfiw/jzeRcC0/t5Bth2REt IRwb4WedK7B6pKD7a2s8wL8e8nklg2Bq8alrhI7a8YQE0iWtgnFUXaZVwkxZmBkET6RX wdYTDIsM0pTZJQnIvUv3rotCYhI5PIUfpzcbezGqYpRGsu9uvKg98EN5xMZO3A6BkC7E deRA== MIME-Version: 1.0 X-Received: by 10.180.188.103 with SMTP id fz7mr38893646wic.73.1404239677328; Tue, 01 Jul 2014 11:34:37 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Tue, 1 Jul 2014 11:34:37 -0700 (PDT) In-Reply-To: <09DA5461-EFCA-45EC-B886-6E079DE20D15@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <09DA5461-EFCA-45EC-B886-6E079DE20D15@gmail.com> Date: Tue, 1 Jul 2014 11:34:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=001a11c37e5e27f18804fd260762 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hXL7JmCsPd4tEUYn-aVY85aGSfg Cc: Dave Crocker , Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 18:34:40 -0000 --001a11c37e5e27f18804fd260762 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis wrote: > I do not think the charter is adequate. It needs to address the topic > related to authorizing third-party use. Otherwise, it is not possible to > address the resulting disruption when reject is ever desired in conjunction > with a mixed use domain. At this point, it seems wrong to expect this > problem will somehow evaporate. > One of the bullet items in the charter is "Utility of a formalized policy exception mechanism". I consider that to cover the thing you're talking about, meaning there's no need to call it out separately and explicitly. -MSK --001a11c37e5e27f18804fd260762 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis <doug.m= tview@gmail.com> wrote:

I do not think the charter is adequate. =C2=A0It needs to addres= s the topic related to authorizing third-party use. =C2=A0Otherwise, it is = not possible to address the resulting disruption=C2=A0when reject is ever d= esired in conjunction with a mixed use domain. =C2=A0 At this point, it see= ms wrong to expect this problem will somehow evaporate.

One of the bullet items in the chart= er is "Utility of a formalized policy exception mechanism".=C2=A0= I consider that to cover the thing you're talking about, meaning there= 's no need to call it out separately and explicitly.

-MSK

--001a11c37e5e27f18804fd260762-- From nobody Tue Jul 1 11:38:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664771B286D for ; Tue, 1 Jul 2014 11:38:47 -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, HTML_MESSAGE=0.001, 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 VAK4PIaRbcS2 for ; Tue, 1 Jul 2014 11:38:44 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636331A03C9 for ; Tue, 1 Jul 2014 11:38:44 -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.0.985.2; Tue, 1 Jul 2014 18:38:41 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.62]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.62]) with mapi id 15.00.0985.004; Tue, 1 Jul 2014 18:38:41 +0000 From: Terry Zink To: Mike Jones , Douglas Otis , "Dave Crocker" Thread-Topic: [dmarc-ietf] Draft DMARC working group charter Thread-Index: AQHPlUXWEqozMyIKEkaKXmK8TYiNE5uLfdwAgAAJoICAAAVHEA== Date: Tue, 1 Jul 2014 18:38:41 +0000 Message-ID: <4f3c9067e3ca4adeb9d406e1618b4f7a@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <09DA5461-EFCA-45EC-B886-6E079DE20D15@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.159.245] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(24454002)(189002)(164054003)(479174003)(377454003)(46102001)(21056001)(19609705001)(99396002)(19625215002)(80022001)(20776003)(101416001)(77982001)(64706001)(66066001)(107046002)(76482001)(33646001)(15202345003)(16236675004)(105586002)(81342001)(83322001)(19580395003)(15975445006)(19580405001)(79102001)(19300405004)(50986999)(87936001)(2656002)(85852003)(106116001)(81542001)(83072002)(93886003)(74662001)(74502001)(31966008)(4396001)(76176999)(92566001)(106356001)(54356999)(108616002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4f3c9067e3ca4adeb9d406e1618b4f7aBL2SR01MB605namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dDQvjcUz7jTCAACj73VG-x56QzI Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 18:38:47 -0000 --_000_4f3c9067e3ca4adeb9d406e1618b4f7aBL2SR01MB605namsdf01sdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBpbiBmYXZvciBvZiBpdCwgYXMgd3JpdHRlbiwgYXMgd2VsbC4NCg0KLS0gVGVycnkNCg0K RnJvbTogZG1hcmMgW21haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TWlrZSBKb25lcw0KU2VudDogVHVlc2RheSwgSnVseSAxLCAyMDE0IDExOjIwIEFNDQpUbzogRG91 Z2xhcyBPdGlzOyBEYXZlIENyb2NrZXINCkNjOiBQZXRlIFJlc25pY2s7IGRtYXJjQGlldGYub3Jn OyBCYXJyeSBMZWliYQ0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBEcmFmdCBETUFSQyB3b3Jr aW5nIGdyb3VwIGNoYXJ0ZXINCg0KSSBiZWxpZXZlIHRoZSBXRyBjaGFydGVyIGlzIGFkZXF1YXRl IGFzIHdyaXR0ZW4uICBUaGUgYWN0aXZpdGllcyBkZXNjcmliZWQgaW4gc2VjdGlvbiBvbmUgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAgYWN0aXZpdGllcyBhZGRyZXNzZXMgdGhpcmQtcGFydHkgZW1haWwg YW5kIERNQVJDLiAgVGhhdCBzZWN0aW9uIHNheXMgdGhhdCB0aGUgd29ya2luZyBncm91cCB3aWxs IGRvY3VtZW50IHRoZSBlZmZlY3RzIG9mIERNQVJDIG9uIHN1Y2ggbWFpbCBmbG93cyBhbmQgImNv bnNpZGVyIG1lY2hhbmlzbXMgZm9yIHJlZHVjaW5nIG9yIGVsaW1pbmF0aW5nIERNQVJDJ3MgZWZm ZWN0cyBvbiBpbmRpcmVjdCBtYWlsIGZsb3dzIi4NCg0KSSBhbSBpbiBmYXZvciB0aGUgb2YgdGhl IFdHIGNoYXJ0ZXIgYXMgd3JpdHRlbi4NCg0KVGhhbmtzLA0KTWlrZQ0KDQoNCg0KT24gVHVlLCBK dWwgMSwgMjAxNCBhdCAxMDo0NSBBTSwgRG91Z2xhcyBPdGlzIDxkb3VnLm10dmlld0BnbWFpbC5j b208bWFpbHRvOmRvdWcubXR2aWV3QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpPbiBKdWwgMSwgMjAx NCwgYXQgOTowMCBBTSwgRGF2ZSBDcm9ja2VyIDxkY3JvY2tlckBnbWFpbC5jb208bWFpbHRvOmRj cm9ja2VyQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCk9uIDYvMjAvMjAxNCAxMjozOCBQTSwgRGF2 ZSBDcm9ja2VyIHdyb3RlOg0KDQpIZXJlIGlzIHNvbWUgZHJhZnQgdGV4dCB0byBjb25zaWRlciBm b3IgYSBETUFSQyB3b3JraW5nIGdyb3VwIGNoYXJ0ZXI6DQoNCg0KRydkYXksDQoNCkkndmUgbG9v a2VkIG92ZXIgdGhlIHNtYWxsIGFtb3VudCBvZiBtYWlsIHBvc3RlZCBhYm91dCB0aGUgZHJhZnQg Y2hhcnRlcg0KYW5kIGRvIG5vdCBzZWUgYW55IGNoYW5nZXMgbWFuZGF0ZWQuDQoNCkFwb2xvZ2ll cyBpZiBJJ3ZlIG1pc3NlZCBzb21ldGhpbmcsIGFuZCBJIGFzc3VyZSB5b3UgaXQgd2Fzbid0DQpp bnRlbnRpb25hbC4gIFNvIHBsZWFzZSBkbyByZS1zdGF0ZSB0aGUgc3VnZ2VzdGlvbi4NCg0KT3Ro ZXJ3aXNlLCBJIHRoaW5rIHRoZSBtYWpvciBxdWVzdGlvbiBub3cgaXMgd2hldGhlciB0aGVyZSBp cyBnZW5lcmFsDQpjb25zZW5zdXMgb24gc3VibWl0dGluZyB0aGlzIGRyYWZ0IGNoYXJ0ZXIgdGV4 dCB0byB0aGUgSUVTRz8NCg0KRGVhciBEYXZlLA0KDQpJIGRvIG5vdCB0aGluayB0aGUgY2hhcnRl ciBpcyBhZGVxdWF0ZS4gIEl0IG5lZWRzIHRvIGFkZHJlc3MgdGhlIHRvcGljIHJlbGF0ZWQgdG8g YXV0aG9yaXppbmcgdGhpcmQtcGFydHkgdXNlLiAgT3RoZXJ3aXNlLCBpdCBpcyBub3QgcG9zc2li bGUgdG8gYWRkcmVzcyB0aGUgcmVzdWx0aW5nIGRpc3J1cHRpb24gd2hlbiByZWplY3QgaXMgZXZl ciBkZXNpcmVkIGluIGNvbmp1bmN0aW9uIHdpdGggYSBtaXhlZCB1c2UgZG9tYWluLiAgIEF0IHRo aXMgcG9pbnQsIGl0IHNlZW1zIHdyb25nIHRvIGV4cGVjdCB0aGlzIHByb2JsZW0gd2lsbCBzb21l aG93IGV2YXBvcmF0ZS4NCg0KU2V2ZXJhbCBoYXZlIHN1Z2dlc3RlZCB0aGluZ3MgbGlrZSBES0lN LURlbGVnYXRlLCBDREtJTSwgYW5kIHRoZSBsaWtlLiAgRnJhbmtseSwgeW91ciBES0lNLURlbGVn YXRlIGRpc3RyaWJ1dGVzIGxlc3MgZGF0YSB0aGFuIHdvdWxkIHVzaW5nIHRoZSBUUEEtTGFiZWwu ICBIb3dldmVyLCAgVFBBLUxhYmVsIHJlcXVpcmVzIG11Y2ggc21hbGxlciBETlMgcmVzb3VyY2Vz IGFzc3VtaW5nIHB1YmxpYyBrZXkgcmV0cmFjdGlvbiBpcyB0byByZW1haW4gYW4gaW1wb3J0YW50 IGNvbnRyb2wgYXNwZWN0LiAgSU1ITywgcmVsaWFuY2Ugb24gZXhwaXJ5IHJlcHJlc2VudHMgYSBw b29yIG9wdGlvbi4NCkltcHJvdmVtZW50cyBpbiBETUFSQyBmZWF0dXJlcyAoaWRlbnRpZmllciBh bGlnbm1lbnQsIHJlcG9ydGluZywgcG9saWN5DQpwcmVmZXJlbmNlcykgd2lsbCBiZSBjb25zaWRl cmVkLCBzdWNoIGFzOg0KDQogICAtIEVudW1lcmF0aW9uIG9mIGRhdGEgZWxlbWVudHMgcmVxdWly ZWQgaW4gIkZhaWx1cmUiIHJlcG9ydHMNCiAgICAgICAgKHNwZWNpZmljYWxseSB0byBhZGRyZXNz IHByaXZhY3kgaXNzdWVzKQ0KICAgLSBIYW5kbGluZyBwb3RlbnRpYWwgcmVwb3J0aW5nIGFidXNl DQogICAtIEFnZ3JlZ2F0ZSByZXBvcnRpbmcgdG8gc3VwcG9ydCBhZGRpdGlvbmFsIHJlcG9ydGlu ZyBzY2VuYXJpb3MNCiAgIC0gQWx0ZXJuYXRlIHJlcG9ydGluZyBjaGFubmVscw0KICAgLSBVdGls aXR5IG9mIGFyYml0cmFyeSBpZGVudGlmaWVyIGFsaWdubWVudA0KICAgLSBVdGlsaXR5IG9mIGEg Zm9ybWFsaXplZCBwb2xpY3kgZXhjZXB0aW9uIG1lY2hhbmlzbQ0KDQogICstIERvbWFpbiBGZWRl cmF0aW9uIG9yIEF1dGhvcml6YXRpb24gc2NoZW1lLiAgU2VlIERLSU0tRGVsZWdhdGUgb3IgVFBB LUxhYmVsIGRyYWZ0cyBhcyBleGFtcGxlcy4NCiAgICAgT3VyIGNvbXBhbnkgaXMgd2lsbGluZyB0 byB3b3JrIHdpdGggYW55IGxhcmdlIElTUCB0byBkZW1vbnN0cmF0ZSB1c2Ugb2YgVFBBLUxhYmVs Lg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vdGlzLXRwYS1sYWJlbA0KDQpT dWNoIGEgY29uY2x1c2lvbiBpcyBlYXNpbHkgc3VwcG9ydGVkIHNpbmNlIG9ubHkgdGhlIERNQVJD IGRvbWFpbiByZWNlaXZlcyBmZWVkYmFjayBuZWNlc3NhcnkgdG8gYWNrbm93bGVkZ2UgYW5kIG1p dGlnYXRlIGFidXNlIG9mIHRoZSBGcm9tIGhlYWRlciBmaWVsZC4gIEFzIHN1Y2gsIE9OTFkgdGhl IERNQVJDIGRvbWFpbiBpcyBhYmxlIHRvIGluZGljYXRlIHdoaWNoIG90aGVyIGRvbWFpbnMgYXJl IHBlcm1pdHRlZCAoYXV0aG9yaXplZCBvciBmZWRlcmF0ZWQpLg0KUGhpc2hpbmcgYW5kIHNwb29m aW5nIGlzIGFuIGV4dHJlbWVseSBzZXJpb3VzIHByb2JsZW0gTk9UIGFkZHJlc3NlZCB1c2luZyBh bnRpLVNQQU0gdGVjaG5pcXVlcy4gSWYgdGhlcmUgaXMgc29tZSB0aW1lIGF2YWlsYWJsZSBpbiBh bnkgdXBjb21pbmcgbWVldGluZywgSSB3b3VsZCBsaWtlIHRvIHRha2UgYSBmZXcgbWludXRlcyB0 byByZXZpZXcgdGhpcyBtYXR0ZXIgYW5kIHJlbGF0ZSBvdXIgY29tcGFueSdzIGV4cGVyaWVuY2Uu DQoNClJlZ2FyZHMsDQpEb3VnbGFzIE90aXMNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbWFyYyBtYWlsaW5nIGxpc3QNCmRtYXJj QGlldGYub3JnPG1haWx0bzpkbWFyY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG1hcmMNCg0KDQoNCg0K --_000_4f3c9067e3ca4adeb9d406e1618b4f7aBL2SR01MB605namsdf01sdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGFt IGluIGZhdm9yIG9mIGl0LCBhcyB3cml0dGVuLCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRtYXJjIFttYWlsdG86 ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDEsIDIwMTQgMTE6MjAgQU08YnI+DQo8Yj5U bzo8L2I+IERvdWdsYXMgT3RpczsgRGF2ZSBDcm9ja2VyPGJyPg0KPGI+Q2M6PC9iPiBQZXRlIFJl c25pY2s7IGRtYXJjQGlldGYub3JnOyBCYXJyeSBMZWliYTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2RtYXJjLWlldGZdIERyYWZ0IERNQVJDIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGUgV0cgY2hhcnRlciBp cyBhZGVxdWF0ZSBhcyB3cml0dGVuLiAmbmJzcDtUaGUgYWN0aXZpdGllcyBkZXNjcmliZWQgaW4g c2VjdGlvbiBvbmUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgYWN0aXZpdGllcyBhZGRyZXNzZXMgdGhp cmQtcGFydHkgZW1haWwgYW5kIERNQVJDLiAmbmJzcDtUaGF0IHNlY3Rpb24gc2F5cyB0aGF0IHRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgZG9jdW1lbnQgdGhlIGVmZmVjdHMgb2YgRE1BUkMNCiBvbiBz dWNoIG1haWwgZmxvd3MgYW5kICZxdW90O2NvbnNpZGVyIG1lY2hhbmlzbXMgZm9yIHJlZHVjaW5n IG9yIGVsaW1pbmF0aW5nIERNQVJDJ3MgZWZmZWN0cyBvbiBpbmRpcmVjdCBtYWlsIGZsb3dzJnF1 b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBhbSBpbiBmYXZvciB0aGUgb2YgdGhlIFdHIGNoYXJ0ZXIgYXMgd3JpdHRlbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZTxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgMSwgMjAxNCBhdCAxMDo0NSBBTSwgRG91Z2xh cyBPdGlzICZsdDs8YSBocmVmPSJtYWlsdG86ZG91Zy5tdHZpZXdAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+ZG91Zy5tdHZpZXdAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g SnVsIDEsIDIwMTQsIGF0IDk6MDAgQU0sIERhdmUgQ3JvY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRjcm9ja2VyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRjcm9ja2VyQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g Ni8yMC8yMDE0IDEyOjM4IFBNLCBEYXZlIENyb2NrZXIgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgc29tZSBkcmFmdCB0ZXh0 IHRvIGNvbnNpZGVyIGZvciBhIERNQVJDIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcjo8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCkcn ZGF5LDxicj4NCjxicj4NCkkndmUgbG9va2VkIG92ZXIgdGhlIHNtYWxsIGFtb3VudCBvZiBtYWls IHBvc3RlZCBhYm91dCB0aGUgZHJhZnQgY2hhcnRlcjxicj4NCmFuZCBkbyBub3Qgc2VlIGFueSBj aGFuZ2VzIG1hbmRhdGVkLjxicj4NCjxicj4NCkFwb2xvZ2llcyBpZiBJJ3ZlIG1pc3NlZCBzb21l dGhpbmcsIGFuZCBJIGFzc3VyZSB5b3UgaXQgd2Fzbid0PGJyPg0KaW50ZW50aW9uYWwuICZuYnNw O1NvIHBsZWFzZSBkbyByZS1zdGF0ZSB0aGUgc3VnZ2VzdGlvbi48YnI+DQo8YnI+DQpPdGhlcndp c2UsIEkgdGhpbmsgdGhlIG1ham9yIHF1ZXN0aW9uIG5vdyBpcyB3aGV0aGVyIHRoZXJlIGlzIGdl bmVyYWw8YnI+DQpjb25zZW5zdXMgb24gc3VibWl0dGluZyB0aGlzIGRyYWZ0IGNoYXJ0ZXIgdGV4 dCB0byB0aGUgSUVTRz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkRlYXIgRGF2 ZSw8YnI+DQo8YnI+DQpJIGRvIG5vdCB0aGluayB0aGUgY2hhcnRlciBpcyBhZGVxdWF0ZS4gJm5i c3A7SXQgbmVlZHMgdG8gYWRkcmVzcyB0aGUgdG9waWMgcmVsYXRlZCB0byBhdXRob3JpemluZyB0 aGlyZC1wYXJ0eSB1c2UuICZuYnNwO090aGVyd2lzZSwgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFk ZHJlc3MgdGhlIHJlc3VsdGluZyBkaXNydXB0aW9uJm5ic3A7d2hlbiByZWplY3QgaXMgZXZlciBk ZXNpcmVkIGluIGNvbmp1bmN0aW9uIHdpdGggYSBtaXhlZCB1c2UgZG9tYWluLiAmbmJzcDsgQXQg dGhpcyBwb2ludCwNCiBpdCBzZWVtcyB3cm9uZyB0byBleHBlY3QgdGhpcyBwcm9ibGVtIHdpbGwg c29tZWhvdyBldmFwb3JhdGUuPGJyPg0KPGJyPg0KU2V2ZXJhbCBoYXZlIHN1Z2dlc3RlZCB0aGlu Z3MgbGlrZSBES0lNLURlbGVnYXRlLCBDREtJTSwgYW5kIHRoZSBsaWtlLiAmbmJzcDtGcmFua2x5 LCB5b3VyIERLSU0tRGVsZWdhdGUgZGlzdHJpYnV0ZXMgbGVzcyBkYXRhIHRoYW4gd291bGQgdXNp bmcgdGhlIFRQQS1MYWJlbC4gJm5ic3A7SG93ZXZlciwmbmJzcDsmbmJzcDtUUEEtTGFiZWwgcmVx dWlyZXMgbXVjaCBzbWFsbGVyIEROUyByZXNvdXJjZXMgYXNzdW1pbmcgcHVibGljIGtleSByZXRy YWN0aW9uIGlzIHRvIHJlbWFpbiBhbg0KIGltcG9ydGFudCBjb250cm9sIGFzcGVjdC4gJm5ic3A7 SU1ITywgcmVsaWFuY2Ugb24gZXhwaXJ5IHJlcHJlc2VudHMgYSBwb29yJm5ic3A7b3B0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkltcHJvdmVtZW50cyBp biBETUFSQyBmZWF0dXJlcyAoaWRlbnRpZmllciBhbGlnbm1lbnQsIHJlcG9ydGluZywgcG9saWN5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcmVm ZXJlbmNlcykgd2lsbCBiZSBjb25zaWRlcmVkLCBzdWNoIGFzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7LSBFbnVtZXJh dGlvbiBvZiBkYXRhIGVsZW1lbnRzIHJlcXVpcmVkIGluICZxdW90O0ZhaWx1cmUmcXVvdDsgcmVw b3J0czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IChzcGVjaWZpY2FsbHkgdG8gYWRkcmVzcyBwcml2 YWN5IGlzc3Vlcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDstIEhhbmRsaW5nIHBvdGVudGlhbCByZXBvcnRpbmcgYWJ1c2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDstIEFnZ3JlZ2F0ZSByZXBvcnRpbmcgdG8gc3VwcG9ydCBhZGRpdGlvbmFsIHJlcG9y dGluZyBzY2VuYXJpb3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDstIEFsdGVybmF0ZSByZXBvcnRpbmcgY2hhbm5lbHM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDstIFV0aWxpdHkgb2YgYXJiaXRyYXJ5IGlkZW50aWZpZXIgYWxpZ25tZW50PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 LSBVdGlsaXR5IG9mIGEgZm9ybWFsaXplZCBwb2xpY3kgZXhjZXB0aW9uIG1lY2hhbmlzbTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDsgJiM0 MzstIERvbWFpbiBGZWRlcmF0aW9uIG9yIEF1dGhvcml6YXRpb24gc2NoZW1lLiAmbmJzcDtTZWUg REtJTS1EZWxlZ2F0ZSBvciBUUEEtTGFiZWwgZHJhZnRzIGFzIGV4YW1wbGVzLjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7T3VyIGNvbXBhbnkgaXMgd2lsbGluZyB0byB3b3JrIHdpdGggYW55IGxh cmdlIElTUCB0byBkZW1vbnN0cmF0ZSB1c2Ugb2YgVFBBLUxhYmVsLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3Rpcy10cGEtbGFiZWwiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vdGlzLXRwYS1sYWJlbDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClN1 Y2ggYSBjb25jbHVzaW9uIGlzIGVhc2lseSBzdXBwb3J0ZWQgc2luY2Ugb25seSB0aGUgRE1BUkMg ZG9tYWluIHJlY2VpdmVzIGZlZWRiYWNrIG5lY2Vzc2FyeSB0byBhY2tub3dsZWRnZSBhbmQgbWl0 aWdhdGUgYWJ1c2Ugb2YgdGhlIEZyb20gaGVhZGVyIGZpZWxkLiAmbmJzcDtBcyBzdWNoLCBPTkxZ IHRoZSBETUFSQyBkb21haW4gaXMgYWJsZSB0byBpbmRpY2F0ZSB3aGljaCBvdGhlciBkb21haW5z IGFyZSBwZXJtaXR0ZWQgKGF1dGhvcml6ZWQgb3IgZmVkZXJhdGVkKS48YnI+DQpQaGlzaGluZyBh bmQgc3Bvb2ZpbmcgaXMgYW4gZXh0cmVtZWx5IHNlcmlvdXMgcHJvYmxlbSBOT1QgYWRkcmVzc2Vk IHVzaW5nIGFudGktU1BBTSB0ZWNobmlxdWVzLiBJZiB0aGVyZSBpcyBzb21lIHRpbWUgYXZhaWxh YmxlIGluIGFueSB1cGNvbWluZyBtZWV0aW5nLCBJIHdvdWxkIGxpa2UgdG8gdGFrZSBhIGZldyBt aW51dGVzIHRvIHJldmlldyB0aGlzIG1hdHRlciBhbmQgcmVsYXRlIG91ciBjb21wYW55J3MgZXhw ZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KUmVnYXJkcyw8YnI+DQpEb3Vn bGFzIE90aXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpk bWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5kbWFyY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4f3c9067e3ca4adeb9d406e1618b4f7aBL2SR01MB605namsdf01sdf_-- From nobody Tue Jul 1 12:53:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485EE1B27FB for ; Tue, 1 Jul 2014 12:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 iLocPVF-VELs for ; Tue, 1 Jul 2014 12:53:25 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F199C1A0418 for ; Tue, 1 Jul 2014 12:53:24 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so8614051iec.3 for ; Tue, 01 Jul 2014 12:53:24 -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=KYF6qiYaUYJfxzLt8Dw2bH0OhR9rKNR4M3AKc2g3Iz0=; b=VOjmpjaV71LucHdJB+RKsQr4c4rrOEhZzeetf312LLaXpI8saScLoLKWBihxHUV13S e30qt9daueL+nS/12/1hPhobS4Joo1sL6IJK+A5Tf9H9bZg9yH+4n0YNN9l3HbraPBqU Q6cHbYil85C9LuiVb+mF2lobsSyn1XnXEjaAGrK05Xx4jK87qQXByQKswkqwn1SbrxDy JEUUX21KZtjhFnLMpvKW1CpHmSUUMlFSFvMGQ21XskRXpI+ysAgQRYopma8Mh3OqdZkN n8aL6h01sQzMSEgXBLfot0QwmcEBrzLE+lLJk14zDq/G8qWqkdgoQFoxlNC/umtpqtQd EqAQ== 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=KYF6qiYaUYJfxzLt8Dw2bH0OhR9rKNR4M3AKc2g3Iz0=; b=J6Y/RC+uh98CFDh+4s0vReWwFGfnZOel+dqv3nAKMR8nyyuHACTlVIRkcoM77VheG8 wmXhp6nToY4wTkXsBzGNsUeoY+PlroxKB6yJ8tj/8GW2ObVECp0vvFph5gVn2L0oLVXH sGVosl9U8A0woUOMk6KCaAF7HhvVDMQgt41PSzo1dic0vW+RdsWO0XffP+IyY7+Gi6IV Xypj2hJDxKORD5o3gS8wbs0ZJ3bSQuc9EcfNNACtLAZabDzLok3B4zla0j40MJfXeo19 cqDnQfcx+bGORd9VVC3GDMM8xLV/m/iLTx26z1eEBBVRCKCNj2Otxao0qUae1d68YY1m YE0A== X-Gm-Message-State: ALoCoQk2uECKItUkCtld8tWiVPVll7c5WOr0ROUNMKTzVjff8RKmwtq1POKM3cwhfKjpBUdIVco0 MIME-Version: 1.0 X-Received: by 10.50.43.232 with SMTP id z8mr43310298igl.32.1404244404299; Tue, 01 Jul 2014 12:53:24 -0700 (PDT) Received: by 10.64.136.202 with HTTP; Tue, 1 Jul 2014 12:53:24 -0700 (PDT) In-Reply-To: <4f3c9067e3ca4adeb9d406e1618b4f7a@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <09DA5461-EFCA-45EC-B886-6E079DE20D15@gmail.com> <4f3c9067e3ca4adeb9d406e1618b4f7a@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Tue, 1 Jul 2014 12:53:24 -0700 Message-ID: From: Brandon Long To: Terry Zink Content-Type: multipart/alternative; boundary=089e01176c7de59a3204fd2720ca Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/v_gZCMxBdJo_DHjuTdKq4Pt53yk Cc: Dave Crocker , Mike Jones , Pete Resnick , Douglas Otis , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jul 2014 19:53:27 -0000 --089e01176c7de59a3204fd2720ca Content-Type: text/plain; charset=UTF-8 In favor as written. Brandon On Tue, Jul 1, 2014 at 11:38 AM, Terry Zink wrote: > I am in favor of it, as written, as well. > > > > -- Terry > > > > *From:* dmarc [mailto:dmarc-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Tuesday, July 1, 2014 11:20 AM > *To:* Douglas Otis; Dave Crocker > *Cc:* Pete Resnick; dmarc@ietf.org; Barry Leiba > *Subject:* Re: [dmarc-ietf] Draft DMARC working group charter > > > > I believe the WG charter is adequate as written. The activities described > in section one of the working group activities addresses third-party email > and DMARC. That section says that the working group will document the > effects of DMARC on such mail flows and "consider mechanisms for reducing > or eliminating DMARC's effects on indirect mail flows". > > > > I am in favor the of the WG charter as written. > > > > Thanks, > > Mike > > > > > > > > On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis > wrote: > > > > On Jul 1, 2014, at 9:00 AM, Dave Crocker wrote: > > > > On 6/20/2014 12:38 PM, Dave Crocker wrote: > > Here is some draft text to consider for a DMARC working group charter: > > > > G'day, > > I've looked over the small amount of mail posted about the draft charter > and do not see any changes mandated. > > Apologies if I've missed something, and I assure you it wasn't > intentional. So please do re-state the suggestion. > > Otherwise, I think the major question now is whether there is general > consensus on submitting this draft charter text to the IESG? > > > > Dear Dave, > > I do not think the charter is adequate. It needs to address the topic > related to authorizing third-party use. Otherwise, it is not possible to > address the resulting disruption when reject is ever desired in conjunction > with a mixed use domain. At this point, it seems wrong to expect this > problem will somehow evaporate. > > Several have suggested things like DKIM-Delegate, CDKIM, and the like. > Frankly, your DKIM-Delegate distributes less data than would using the > TPA-Label. However, TPA-Label requires much smaller DNS resources > assuming public key retraction is to remain an important control aspect. > IMHO, reliance on expiry represents a poor option. > > Improvements in DMARC features (identifier alignment, reporting, policy > > preferences) will be considered, such as: > > > > - Enumeration of data elements required in "Failure" reports > > (specifically to address privacy issues) > > - Handling potential reporting abuse > > - Aggregate reporting to support additional reporting scenarios > > - Alternate reporting channels > > - Utility of arbitrary identifier alignment > > - Utility of a formalized policy exception mechanism > > > +- Domain Federation or Authorization scheme. See DKIM-Delegate or > TPA-Label drafts as examples. > Our company is willing to work with any large ISP to demonstrate use > of TPA-Label. > > > http://tools.ietf.org/html/draft-otis-tpa-label > > > Such a conclusion is easily supported since only the DMARC domain receives > feedback necessary to acknowledge and mitigate abuse of the From header > field. As such, ONLY the DMARC domain is able to indicate which other > domains are permitted (authorized or federated). > Phishing and spoofing is an extremely serious problem NOT addressed using > anti-SPAM techniques. If there is some time available in any upcoming > meeting, I would like to take a few minutes to review this matter and > relate our company's experience. > > > 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 > > --089e01176c7de59a3204fd2720ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In favor as written.

Brandon

On Tue, Jul = 1, 2014 at 11:38 AM, Terry Zink <tzink@exchange.microsoft.com> wrote:

I am in favor of it, as written, as well.

=C2=A0=

-- Terry

=C2=A0=

From: dmarc = [mailto:dmarc-b= ounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, July 1, 2014 11:20 AM
To: Douglas Otis; Dave Crocker
Cc: Pete Resnick; dmarc@ietf.org; Barry Leiba
Subject: Re: [dmarc-ietf] Draft DMARC working group charter

=C2=A0
I believe the WG charter is adequate as written. =C2= =A0The activities described in section one of the working group activities = addresses third-party email and DMARC. =C2=A0That section says that the wor= king group will document the effects of DMARC on such mail flows and "consider mechanisms for reducing or eliminati= ng DMARC's effects on indirect mail flows".=C2=A0

=C2=A0

I am in favor the of the WG charter as written.

=C2=A0

Thanks,

Mike

=C2=A0

=C2=A0

=C2=A0<= /p>

On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis <doug.mtview@gmail.= com> wrote:

=C2=A0

On Jul 1, 2014, at 9:00 AM, Dave Crocker <dcrocker@gmail.com>= wrote:

On 6/20/2014 12:38 PM, Dave Crocker wrote:

Here is some draft text to consider for a DMARC work= ing group charter:

G'day,

I've looked over the small amount of mail posted about the draft charte= r
and do not see any changes mandated.

Apologies if I've missed something, and I assure you it wasn't
intentional. =C2=A0So please do re-state the suggestion.

Otherwise, I think the major question now is whether there is general
consensus on submitting this draft charter text to the IESG?<= /p>

=C2=A0

Dear Dave,

I do not think the charter is adequate. =C2=A0It needs to address the topic= related to authorizing third-party use. =C2=A0Otherwise, it is not possibl= e to address the resulting disruption=C2=A0when reject is ever desired in c= onjunction with a mixed use domain. =C2=A0 At this point, it seems wrong to expect this problem will somehow evaporate.

Several have suggested things like DKIM-Delegate, CDKIM, and the like. =C2= =A0Frankly, your DKIM-Delegate distributes less data than would using the T= PA-Label. =C2=A0However,=C2=A0=C2=A0TPA-Label requires much smaller DNS res= ources assuming public key retraction is to remain an important control aspect. =C2=A0IMHO, reliance on expiry represents a poor= =C2=A0option.

Improvements in DMARC features (identifier alignment= , reporting, policy

preferences) will be considered, such as:<= /u>

=C2=A0

=C2=A0 =C2=A0- Enumeration of data elements required= in "Failure" reports

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (specifically to address= privacy issues)

=C2=A0 =C2=A0- Handling potential reporting abuse=

=C2=A0 =C2=A0- Aggregate reporting to support additi= onal reporting scenarios

=C2=A0 =C2=A0- Alternate reporting channels

=C2=A0 =C2=A0- Utility of arbitrary identifier align= ment

=C2=A0 =C2=A0- Utility of a formalized policy except= ion mechanism

=C2=A0 +- Domain Federation or Authorization scheme. =C2=A0See DKIM-Delegat= e or TPA-Label drafts as examples.
=C2=A0 =C2=A0 =C2=A0Our company is willing to work with any large ISP to de= monstrate use of TPA-Label.

http://tools.ietf.org/html/draft-otis-tpa-label

Such a conclusion is easily supported since only the DMARC domain receives = feedback necessary to acknowledge and mitigate abuse of the From header fie= ld. =C2=A0As such, ONLY the DMARC domain is able to indicate which other do= mains are permitted (authorized or federated).
Phishing and spoofing is an extremely serious problem NOT addressed using a= nti-SPAM techniques. If there is some time available in any upcoming meetin= g, I would like to take a few minutes to review this matter and relate our = company's experience.

Regards,
Douglas Otis

=C2=A0

=C2=A0

=C2=A0

<= div class=3D""> _______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

=C2=A0

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

--089e01176c7de59a3204fd2720ca-- From nobody Tue Jul 1 17:14:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A2F1A0A9A for ; Tue, 1 Jul 2014 17:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 NXMvt88RnXuU for ; Tue, 1 Jul 2014 17:14:24 -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 5F5051A040C for ; Tue, 1 Jul 2014 17:14:24 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s620EGLs047714 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Jul 2014 17:14:21 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s620EGLs047714 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1404260061; bh=4hDDxXzt4F5XRSVQ13hw6eQ/A1z8NjZ+v7G453dj4Z8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bLFvI6jtyX58GrwafJKB6je5m8PXvTp2XB/dSRHrgr5e868YpR9oi0pV/B8KD95sr d9rz63Jl/vI7dGNfsnryCvYDKbPL5HXpZ4BRO6JYr1gtYSauebmxlyoTbajFieTMgB NHphD2E0xFfXtlFzL9v2dGUREoLWpwpIoZYvDelk= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <53B34EDA.1090604@crash.com> Date: Tue, 01 Jul 2014 17:14:18 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> In-Reply-To: <53A48DB1.9080706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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]); Tue, 01 Jul 2014 17:14:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FDUCjeCB7RwSwaWQD69RIte_HAs Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 00:14:26 -0000 As a couple people have observed it's a complicated charter, but then it's a complicated situation... I think this does the trick. +1. That said, one small point to consider: > The task of defining a > standard mechanism for identifying organizational domain is out of scope > for this working group. However the working group can consider extending > the base DMARC specification to accommodate such a standard, should it > be developed during the life of this working group. By limiting this consideration to "during the life of this working group," do we preclude the possibility of defining (in whole or in part) how such work completed outside and after this WG could be plugged in? Why not have the flexibility in the charter, if it doesn't make it a required deliverable? --S. From nobody Tue Jul 1 19:30:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E61B287F for ; Tue, 1 Jul 2014 19:30:51 -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 FQHcr9d73oSN for ; Tue, 1 Jul 2014 19:30:50 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEE81A0ADF for ; Tue, 1 Jul 2014 19:30:50 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 08FE33FA0B37; Wed, 2 Jul 2014 11:30:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F2270120B48; Wed, 2 Jul 2014 11:30:48 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53B2DB2B.2090301@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 02 Jul 2014 11:30:48 +0900 Message-ID: <87egy4v6ef.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ofXjky-mDvbbNCfjTrRdNR4yZv8 Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 02:30:52 -0000 Dave Crocker writes: > Otherwise, I think the major question now is whether there is general > consensus on submitting this draft charter text to the IESG? consensus += (1 if tpa_labels_and_similar__may_be_discussed else 0) I have no opinion on the value of tpa-labels as a device to extend DMARC alignment to certain 3rd party (re)senders, but I did read the draft charter as including discussion of that, among other remedies, and would be upset if the charter was interpreted otherwise. In particular, none of the in-band proposals can address the issues of 3rd party senders in non-forwarding scenarios. I don't know if they need mitigation as much as mailing lists do, but I don't know that they don't. python-3-cally y'rs From nobody Tue Jul 1 19:58:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6A21A01DD for ; Tue, 1 Jul 2014 19:58:48 -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 EEiNcSZZtQ_7 for ; Tue, 1 Jul 2014 19:58:47 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id DEDE31A01DC for ; Tue, 1 Jul 2014 19:58:46 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 00FAD3FA0B23; Wed, 2 Jul 2014 11:58:46 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E7473120B48; Wed, 2 Jul 2014 11:58:45 +0900 (JST) From: "Stephen J. Turnbull" To: Steven M Jones In-Reply-To: <53B34EDA.1090604@crash.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B34EDA.1090604@crash.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 02 Jul 2014 11:58:45 +0900 Message-ID: <87d2dov53u.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/d8BuMj1WDsopkY9VZU9KiDNYcg4 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 02:58:49 -0000 Steven M Jones writes: > That said, one small point to consider: > > > The task of defining a standard mechanism for identifying > > organizational domain is out of scope for this working > > group. However the working group can consider extending the base > > DMARC specification to accommodate such a standard, should it be > > developed during the life of this working group. > > By limiting this consideration to "during the life of this working > group," do we preclude the possibility of defining (in whole or in > part) how such work completed outside and after this WG could be > plugged in? I think "precluding" is advisable. Identifying organizational domains is a very big issue affecting security of essentially all applications on the Internet, and trying to specify an interface in advance seems useless -- either it will be obvious how to do so, or central elements of DMARC/DKIM/SPF will need to be revised/replaced anyway. By "obvious", I mean the following. For DMARC, we know that we're aiming at identity alignment of the mailbox in the From field with either the SMTP connection's remote host (SPF) or a specified domain in the DKIM-Signature field (DKIM). AFAIK in those cases the DNS record to retrieve keys to *authenticate* the sender's identity is well-defined and not affected by the issue of "organizational domain". DMARC policy (ie, author-domain-based *authorization* of senders) is specified by a DNS record. The core of DMARC is the algorithm to find the appropriate DNS record. If a later definition of "organizational domain" invalidates that algorithm, DMARC (v1) is dead, and needs to be resurrected with a new algorithm (v2) to find that record compatibly with "organizational domain". I don't see how we can really "define" a plug-in beyond "new algorithm", while that algorithm is a well-defined component of DMARC (ie, could be considered to be the "socket"). If changes beyond that are needed, I guess the Grinch stole Christmas. Steve From nobody Wed Jul 2 01:46:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931381A0101 for ; Wed, 2 Jul 2014 01:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 XEJGDbeFo4fv for ; Wed, 2 Jul 2014 01:45:59 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC0D1A00E6 for ; Wed, 2 Jul 2014 01:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1404290756; bh=6XGkuwS5Dure1dONc1Pt6p7Ox7gT6Pm2x/Cpx8aYobU=; l=1612; h=Date:From:To:CC:References:In-Reply-To; b=DXpNfu9kmMNmfnEwzVVOQTA9324W35cCYOxYa6P53te+XlXjcYQvRL/QAWVie/Dyf wEre+jHHOhskO6jJuOYYDXtrlisLuk0BxRVdSqX2DFRLB2f77Dp25c6v4Kw1WDI0YE aZ/ep3sQoowQLva0EUUdNUoW+AvvTbTMCd9Ul+YQ= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 02 Jul 2014 10:45:56 +0200 id 00000000005DC039.0000000053B3C6C4.0000210C Message-ID: <53B3C6C4.4000904@tana.it> Date: Wed, 02 Jul 2014 10:45:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Dave Crocker References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> In-Reply-To: <53B2DB2B.2090301@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jjv1xBaqfC2-LOhmSm3loOSgZ2M Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 08:46:00 -0000 On Tue 01/Jul/2014 18:00:43 +0200 Dave Crocker wrote: > On 6/20/2014 12:38 PM, Dave Crocker wrote: >> Here is some draft text to consider for a DMARC working group charter: > > > G'day, > > I've looked over the small amount of mail posted about the draft charter > and do not see any changes mandated. > > Apologies if I've missed something, and I assure you it wasn't > intentional. So please do re-state the suggestion. My question about the stance toward DKIM tweaks[1] was never answered. To re-state, while preclusion is apparent for the organizational domain issue, it is not clear for DKIM. The charter says: The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. Something similar to the example I-D in [1] was expressed in recent discussions, so I hope for additional developments of existing mail authentication technologies not being precluded. Please clarify. Clarity and comprehensibility are very important from my POV[2]. For that sake, I suggest the charter mention candidate solutions such as DKIM-Delegate and TPA-Labels explicitly. Some further wordsmithing may be advisable too. Thank you Ale [1] http://www.ietf.org/mail-archive/web/dmarc/current/msg01419.html [2] I'm a (very) small mailbox provider, and I think the IETF ought to provide some suitable-for-all specifications for running effective MTAs, the 'S' in SMTP. Otherwise we might as well limit ourselves to using Google or Apple and be happy. That's why I try and participate in some WGs. From nobody Wed Jul 2 09:10:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C2E1B2959 for ; Wed, 2 Jul 2014 09:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 BG8774fPo9E1 for ; Wed, 2 Jul 2014 09:10:38 -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 DAF591B2820 for ; Wed, 2 Jul 2014 09:10:38 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s62GARbt055825 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 Jul 2014 09:10:36 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s62GARbt055825 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1404317436; bh=89uKGefwMtXL395ZeCOmtjQk7NcsyKCTZhS/wzpxDBc=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TG8ZozCfcZHpkh7b/sev4Ss+vsGz4Oz0t6ij25JctkcYWGTbbqfepsofQ8DCD6xwx dD78Qi/+4mZiK4lK5GZpPFWgd9244N469RcKYGmJe83dn7VBTyZql6Vd4SAn9ek6ay paeWwyFINFX0+JvJ7pltLcmP8qiKXBA1txe9l9dg= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <53B42EF6.1090801@crash.com> Date: Wed, 02 Jul 2014 09:10:30 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B34EDA.1090604@crash.com> <87d2dov53u.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87d2dov53u.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 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]); Wed, 02 Jul 2014 09:10:36 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/A3lJBxym8pSjwY5mEtGduYPwUZ0 Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 16:10:40 -0000 On 07/01/2014 07:58 PM, Stephen J. Turnbull wrote: > Steven M Jones writes: > > [ ...] > > part) how such work completed outside and after this WG could be > > plugged in? > > I think "precluding" is advisable. [...] > > I don't see how we can > really "define" a plug-in beyond "new algorithm", while that algorithm > is a well-defined component of DMARC (ie, could be considered to be > the "socket"). > > If changes beyond that are needed, I guess the Grinch stole Christmas. I don't have such a definition in-hand, I just observed the potential synchronization issue / exclusion with respect to another working group and thought, "Do we have to create that dependency on completing/publishing?" - thinking back to Jim Fenton's comments. Maybe a year into this work such a definition would be clear, who knows? I'm not worried we'll run out of work so quickly that no other WG will have a chance to make progress. :) And from being around a previous WG I can appreciate the need to define a scope carefully to avoid potential time sinks. I didn't see that being the case with this particular small clause, but perhaps others have that concern. Again, not something I'd hold up adopting the charter over, just thought it would bear some public comment. Appreciate your feedback, --S. From nobody Wed Jul 2 09:24:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B26D1A034F for ; Wed, 2 Jul 2014 09:24: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 xfVkhTgK0pwp for ; Wed, 2 Jul 2014 09:24:10 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAC01A058E for ; Wed, 2 Jul 2014 09:24:10 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id q9so6641695ykb.37 for ; Wed, 02 Jul 2014 09:24: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=biPA8kheXtYySp4QuP05AxOLle8yltg2LGncUnR+6iM=; b=pmLoIoKCU4iCPuqbQazFb3Bw/JHJVVHrrrJzBO8vQYCmyNfvmelZIEvQKDnbCVRcxI w6/WU/Cp7E4ou0+Bpy1mLyXyLoOpW4OBJq7oYRvTk/Z4DjWMzruooiuFdkAZlinhKmwK ooe7rQoJX8f5w+kn1GflZZA10Wt1ABbp/tUY1hrnpOzyrX+S1XQPQRyTArLcIzMzkUlv B2m46jKO5+KlmQGdT+w/KntuN7Gj+ytgc2/W6loNcYFXHcqJn3H9iWi7efphRDF/ddyr MHhcETBp2vQGkVezTqk7vIopT3eKdJ2uKaSf0r8BrfNkyE5emowmWEQO2MnsRcynXfXu 2kOQ== X-Received: by 10.236.142.242 with SMTP id i78mr1513961yhj.17.1404318249513; Wed, 02 Jul 2014 09:24:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id p55sm31684680yhh.34.2014.07.02.09.24.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 09:24:07 -0700 (PDT) Message-ID: <53B431D0.1040509@gmail.com> Date: Wed, 02 Jul 2014 09:22:40 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven M Jones , dmarc@ietf.org References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B34EDA.1090604@crash.com> In-Reply-To: <53B34EDA.1090604@crash.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2IjMktl7MWgTaCcB5TIPCgVUPdA Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 16:24:14 -0000 On 7/1/2014 5:14 PM, Steven M Jones wrote: > By limiting this consideration to "during the life of this working > group," do we preclude the possibility of defining (in whole or in part) > how such work completed outside and after this WG could be plugged in? > Why not have the flexibility in the charter, if it doesn't make it a > required deliverable? 1. I'd like to do that. Good and important issue. 2. However, defining interfaces in the absence of knowledge about the details of what is being interfaced to pretty much never works. 3. It occurs to me that the charter /should/ make some comment about this wg's helping that other effort, beyond just 'using' its output. As a real and immediate consumer of that work, we can provide some guidance about what is needed. We aren't the sole 'experts' on the topic, but again, our need is real and immediate and concrete. So perhaps the most useful thing we can do is try to get the wg to formulate 'needs' -- I think the word 'requirements' is overblown, overused, distracting, and often inappropriately-constraining -- to communicate to that other effort? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 2 09:51:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9A01B29A3 for ; Wed, 2 Jul 2014 09:51:14 -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 ZUjltZ0wo6DN for ; Wed, 2 Jul 2014 09:51:13 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7201B29A4 for ; Wed, 2 Jul 2014 09:51:12 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so9943885wiv.3 for ; Wed, 02 Jul 2014 09:51: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=5v6HlfQM4kUUFwSGA3eHj0zK7qTS28mroYJsBStftzQ=; b=AI/4ZBLx7sdFsrA5DQcYCd2aESaxecKYm66WAtcFpNiqQ27QX3YzFAk89x8wqSJSOr q8jhgFEH8dUyCtKzwou1n/gUvzA6eFcLWXm0zYLAg6fga4z2GqParmBPnpr27ydmGEQc Qj28uigCLB5lUrGJnpZyf1O0dYTNTXWrTomkwtOwU43nj+MEDVgNeuhd8a9xvU53ELMo QlyYsg7gt8dZWFgFKb7qqSe3kIEDk2G4EgQL7GQZj1/KxJwoRKPpgiEbod+Lac8/HuLB HB8Mjph8oTVHjUVAwS88qJ9hybf+NvvfaKzRUJ86wODCS5hianhydLpQSeLM+deyCCCJ ZjKw== MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr5552703wib.24.1404319871344; Wed, 02 Jul 2014 09:51:11 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Wed, 2 Jul 2014 09:51:11 -0700 (PDT) In-Reply-To: <53B3C6C4.4000904@tana.it> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <53B3C6C4.4000904@tana.it> Date: Wed, 2 Jul 2014 09:51:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04426a60152a5d04fd38b3af Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jar4H4V1yDjayvcncIf1dyYzfYI Cc: Dave Crocker , Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 16:51:14 -0000 --f46d04426a60152a5d04fd38b3af Content-Type: text/plain; charset=UTF-8 On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely wrote: > My question about the stance toward DKIM tweaks[1] was never answered. > To re-state, while preclusion is apparent for the organizational > domain issue, it is not clear for DKIM. The charter says: > > The working group will not develop additional mail authentication > technologies, but may document authentication requirements that > are desirable. > It also says: The working group will consider mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows. Among the choices are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. So I think you're covered. Clarity and comprehensibility are very important from my POV[2]. For > that sake, I suggest the charter mention candidate solutions such as > DKIM-Delegate and TPA-Labels explicitly. Some further wordsmithing > may be advisable too. > It probably wouldn't be harmful to list them as possible inputs to the work, so that people reviewing the charter have some context, so long as doing so doesn't also constrain the WG's options. -MSK --f46d04426a60152a5d04fd38b3af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely <vesely@ta= na.it> wrote:

My question about the sta= nce toward DKIM tweaks[1] was never answered.
=C2=A0To re-state, while preclusion is apparent for the organizational
domain issue, it is not clear for DKIM. =C2=A0The charter says:

=C2=A0 =C2=A0The working group will not develop additional mail authenticat= ion
=C2=A0 =C2=A0technologies, but may document authentication requirements tha= t
=C2=A0 =C2=A0are desirable.

It also say= s:

The working group will consider mechanisms for re=
ducing or eliminating
the DMARC's effects on indirect mail flows.  Among the choices are:

   - A form of DKIM signature that is better able to survive transit
     through intermediaries.

   - Collaborative or passive transitive mechanisms that enable an
     intermediary to participate in the trust sequence, propagating
     authentication directly or reporting its results.

   - Message modification by an intermediary, to avoid authentication
     failures, such as by using specified conventions for changing the
     aligned identity.

Consideration also will be given to survivable authentication through
sequences of multiple intermediaries.

So I think you're covered.

Clarity and comprehensibility are very important from my POV[2]. =C2=A0For<= br> that sake, I suggest the charter mention candidate solutions such as
DKIM-Delegate and TPA-Labels explicitly. =C2=A0Some further wordsmithing may be advisable too.

It probably would= n't be harmful to list them as possible inputs to the work, so that peo= ple reviewing the charter have some context, so long as doing so doesn'= t also constrain the WG's options.

-MSK

--f46d04426a60152a5d04fd38b3af-- From nobody Wed Jul 2 09:59:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A781A007A for ; Wed, 2 Jul 2014 09:59: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 ejL7KxKzht2D for ; Wed, 2 Jul 2014 09:59:28 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081A31A0022 for ; Wed, 2 Jul 2014 09:59:27 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id r5so10033832qcx.39 for ; Wed, 02 Jul 2014 09:59:27 -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 :message-id:references:to; bh=otnqpKZV5EZmOuWQLQxHKnelpRowjc1Un7mcTA1Kx1g=; b=qSLV4P81Xn+TB921qu4yWh6+OIBtLNdgnNvENlL6T/Fb4ldhWfOdydX9ZOAKY9zoXQ Wx7UKGLv2QOCcz5d+5/FrT69oPqnVoiIiZMgPb86RXelUe7Ekz07wsVHhcDFJJsHhgvx rZ7WAWW6aMnFkjKce4IdwntC4Q4fQhvKy5v7JXshYKb/iikIy4h6IphiImgGNOxQlpEd dxSp36CPs41cQqYblE/KIuCbLTX8tPIoFxh2KmhkeYZZl7QI44EMW/bTlwdZxsGYhiUm NyYQhKlUtOf6ZHeGgIBsra9wvnkdRLBfG13yoyLFUI6yGYaRJBQ1Gu7qKHR7wF4RWani PLHg== X-Received: by 10.140.26.201 with SMTP id 67mr82692368qgv.51.1404320367273; Wed, 02 Jul 2014 09:59:27 -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 g18sm39252682qaa.33.2014.07.02.09.59.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 09:59:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A288ADF-EE25-43B4-857B-15F85A1FED9B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Wed, 2 Jul 2014 09:59:23 -0700 Message-Id: <7E18EF35-7181-4128-82AD-36B7B5A080A2@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <53B3C6C4.4000904@tana.it> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PMZEFet4Mi7i57t8Uy_A7YAl3LE Cc: Dave Crocker , Pete Resnick , "dmarc@ietf.org" , Barry Leiba , Alessandro Vesely Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 16:59:30 -0000 --Apple-Mail=_2A288ADF-EE25-43B4-857B-15F85A1FED9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2014, at 9:51 AM, Murray S. Kucherawy = wrote: > On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely = wrote: > My question about the stance toward DKIM tweaks[1] was never answered. > To re-state, while preclusion is apparent for the organizational > domain issue, it is not clear for DKIM. The charter says: >=20 > The working group will not develop additional mail authentication > technologies, but may document authentication requirements that > are desirable. >=20 > It also says: >=20 > The working group will consider mechanisms for reducing or eliminating > the DMARC's effects on indirect mail flows. Among the choices are: >=20 > - A form of DKIM signature that is better able to survive transit > through intermediaries. >=20 > - Collaborative or passive transitive mechanisms that enable an > intermediary to participate in the trust sequence, propagating > authentication directly or reporting its results. >=20 > - Message modification by an intermediary, to avoid authentication > failures, such as by using specified conventions for changing the > aligned identity. >=20 > Consideration also will be given to survivable authentication through > sequences of multiple intermediaries. >=20 > So I think you're covered. >=20 > Clarity and comprehensibility are very important from my POV[2]. For > that sake, I suggest the charter mention candidate solutions such as > DKIM-Delegate and TPA-Labels explicitly. Some further wordsmithing > may be advisable too. >=20 > It probably wouldn't be harmful to list them as possible inputs to the = work, so that people reviewing the charter have some context, so long as = doing so doesn't also constrain the WG's options.=20 Agreed, as it seems such efforts have been excluded by the charter = language. It would be a shame, since there needs to be a remedy = permitting back-office services such as those offered by Intuit and the = like. It seems such efforts are easily within the realm of being = practical without effecting DKIM. Regards, Douglas Otis --Apple-Mail=_2A288ADF-EE25-43B4-857B-15F85A1FED9B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On Jul 2, 2014, at 9:51 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely <vesely@tana.it> wrote:
My question about the stance toward DKIM tweaks[1] was never answered.
To re-state, while preclusion is apparent for the organizational
domain issue, it is not clear for DKIM. The charter says:

The working group will not develop additional mail authentication
technologies, but may document authentication requirements that
are desirable.
It also says:
The working group will consider mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows.  Among the choices are:

   - A form of DKIM signature that is better able to survive transit
     through intermediaries.

   - Collaborative or passive transitive mechanisms that enable an
     intermediary to participate in the trust sequence, propagating
     authentication directly or reporting its results.

   - Message modification by an intermediary, to avoid authentication
     failures, such as by using specified conventions for changing the
     aligned identity.

Consideration also will be given to survivable authentication through
sequences of multiple intermediaries.
So I think you're covered.

Clarity and comprehensibility are very important from my POV[2]. For
that sake, I suggest the charter mention candidate solutions such as
DKIM-Delegate and TPA-Labels explicitly. Some further wordsmithing
may be advisable too.

It probably wouldn't be harmful to list them as possible inputs to the work, so that people reviewing the charter have some context, so long as doing so doesn't also constrain the WG's options.

Agreed, as it seems such efforts have been excluded by the charter language. It would be a shame, since there needs to be a remedy permitting back-office services such as those offered by Intuit and the like. It seems such efforts are easily within the realm of being practical without effecting DKIM.

Regards,

Douglas Otis

--Apple-Mail=_2A288ADF-EE25-43B4-857B-15F85A1FED9B-- From nobody Wed Jul 2 10:01:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1071B2837 for ; Wed, 2 Jul 2014 10:00:57 -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 tAMpfpqBQ24m for ; Wed, 2 Jul 2014 10:00:55 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC6F1A0022 for ; Wed, 2 Jul 2014 10:00:55 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id t59so6961114yho.4 for ; Wed, 02 Jul 2014 10:00:54 -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=SY1EkkmA0wabcffRmag0brpBjQlGwY9BBwuXjQOQyWY=; b=H7rBXhJtH36jHDb8ozZPjKQ1njN/W+U/74a8pYhLaiaDeRXVJnlFVjNrniKZ5Ho3sd Z4sJiPwSEuMKCsvLOq7dJSJiIHuKU5IGBGha/xjZ89hYTSZok44SgMpTA8AencDT7dff /QrOnN+5xPMITGFWBpvPIE6ZYpyDjBoOU+GwPB7laGLR9udjswwY0akjf+IzTwZrEA72 2pIeeeyWe5kt3tY6dHRRd4fU92FToMQ8II8v9fqkxY1SRwhIS3ZDD/cfL8ctmaLrlOvB eMTu413gYH9WBKtMREhHNTOrzYRuctUZL1QyjRZWke9k/EAt3gmgYvOTcmJbywbphk6l Pewg== X-Received: by 10.236.8.103 with SMTP id 67mr81662535yhq.29.1404320454443; Wed, 02 Jul 2014 10:00:54 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id r48sm34968697yho.31.2014.07.02.10.00.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:00:53 -0700 (PDT) Message-ID: <53B43A6F.9030605@gmail.com> Date: Wed, 02 Jul 2014 09:59:27 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Alessandro Vesely References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <53B3C6C4.4000904@tana.it> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cceUjfMHguPVY2DxkSgjEJTmH9Y Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 17:00:57 -0000 On 7/2/2014 9:51 AM, Murray S. Kucherawy wrote: > Clarity and comprehensibility are very important from my POV[2]. For > that sake, I suggest the charter mention candidate solutions such as > DKIM-Delegate and TPA-Labels explicitly. Some further wordsmithing > may be advisable too. > > It probably wouldn't be harmful to list them as possible inputs to the > work, so that people reviewing the charter have some context, so long as > doing so doesn't also constrain the WG's options. The charter won't be directing the wg to 'start with' or 'work from' or 'build upon' or any equivalent constraint, for these drafts, I think the simplest approach is just to add these citations to the References section. (Actually meant to do that originally.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 2 10:08:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841001A0021 for ; Wed, 2 Jul 2014 10:08: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 t6Gol9b-Gtg6 for ; Wed, 2 Jul 2014 10:08:12 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091111B27D9 for ; Wed, 2 Jul 2014 10:08:11 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so869580wib.6 for ; Wed, 02 Jul 2014 10:08:09 -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=SlBIwDaBGzkxOPKUA9BFL0wgwhqfsIzy5A++U/FqmBY=; b=XLaqi/pRppk/RJwlN6grlr7vT7+ryXHf/9ityDxOLp13gD794rv/9XRrD+3lUC7xx1 /FqAUQId/x+Y1bAiCXdawFynsvjr/c75dgvTn14GPSvFgRJjv7DQyQcL2HZc4BwwRbFQ zkxnVO0OiKu4UP7fsJFx1unuHYVCIoxGBUhKtRuUiSX3zfCzqGH+pUBv8acLAWjyvPrp 5O3SSg9g1ggZiFj7WG5uZXWQAc9iLyCip5/BkgmYU86sn6zWyI93KlptAofGubUXIn+o PNyeVPrXoLhbB9lymzkxcAy36qFoaSyAvldJ0+Jg3BU0KsH5CzmNqql03kRvBwMhaU5W Rc0Q== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr25002932wjc.83.1404320888976; Wed, 02 Jul 2014 10:08:08 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Wed, 2 Jul 2014 10:08:08 -0700 (PDT) In-Reply-To: <7E18EF35-7181-4128-82AD-36B7B5A080A2@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net>

<6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53B2DB2B.2090301@gmail.com> <53B3C6C4.4000904@tana.it> <7E18EF35-7181-4128-82AD-36B7B5A080A2@gmail.com> Date: Wed, 2 Jul 2014 10:08:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=047d7bb04dd2bcfe3e04fd38ef59 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rTF1dqlaFz3aQSg2OKjEMv31w8M Cc: Dave Crocker , Pete Resnick , "dmarc@ietf.org" , Barry Leiba , Alessandro Vesely Subject: Re: [dmarc-ietf] Draft DMARC working group charter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Jul 2014 17:08:18 -0000 --047d7bb04dd2bcfe3e04fd38ef59 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 2, 2014 at 9:59 AM, Douglas Otis wrote: > Agreed, as it seems such efforts have been excluded by the charter > language. It would be a shame, since there needs to be a remedy permitting > back-office services such as those offered by Intuit and the like. It > seems such efforts are easily within the realm of being practical without > effecting DKIM. > To repeat: I disagree that they've been excluded. -MSK --047d7bb04dd2bcfe3e04fd38ef59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 2, 2014 at 9:59 AM, Douglas Otis <doug.mt= view@gmail.com> wrote:

Agreed, = as it seems such efforts have been excluded by the charter language. =C2=A0= It would be a shame, since there needs to be a remedy permitting back-offic= e services such as those offered by Intuit and the like. =C2=A0It seems suc= h efforts are easily within the realm of being practical without effecting = DKIM.

To repeat: I disagr= ee that they've been excluded.

-MSK

--047d7bb04dd2bcfe3e04fd38ef59-- From nobody Wed Jul 2 11:01:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E861B29E1 for ; Wed, 2 Jul 2014 11:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 FNyFabhE28pc for ; Wed, 2 Jul 2014 11:01:48 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF881B29E0 for ; Wed, 2 Jul 2014 11:01:48 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id hz20so7377515lab.28 for