From jtrentadams@gmail.com Thu Aug 1 02:31:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F1B21F9A19 for ; Thu, 1 Aug 2013 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hvEvFYbcwzl for ; Thu, 1 Aug 2013 02:31:31 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A121721F844D for ; Thu, 1 Aug 2013 02:29:45 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so3288887obc.26 for ; Thu, 01 Aug 2013 02:29:42 -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=WwzSPR1cL7oKSu5B3idNOMXHx59xqe/u4w6IkMbgct4=; b=DFWaKxQhDVwF8bU1qopxtOV4TjRugqV4J5Pvf3gpdEXrfuUNfpzE24agZlVltk6dxE AQdmdyJhglhBkEA689nvHb6exaRIFlUNCSArh42m7T/CsKmqo0EdglULaafaCkZK+h7P D4QDW6YNH3nxuDrMsx3Km1+VmnN0bt0zsTGZRyyCnOJoFF7A/dBdOhAX2ShgJaTg9e5k 6rCDCRl0+/N7LBkG69lzCEMJ9CfS+u7HSnhmYLuUl1RtNOAxInIjNPSLf+Q5Sv0nHOLy 39R/HI6MOlrHylrIu465wtgaexXoYPkXCzoj78MTMb8+DY5HkfeqW4qB8js1ElDxa4MX FrGg== MIME-Version: 1.0 X-Received: by 10.182.158.36 with SMTP id wr4mr444401obb.60.1375349382832; Thu, 01 Aug 2013 02:29:42 -0700 (PDT) Received: by 10.76.160.41 with HTTP; Thu, 1 Aug 2013 02:29:42 -0700 (PDT) In-Reply-To: References: <51F8221A.9030503@cisco.com> <6.2.5.6.2.20130731064015.0d5371a0@resistor.net> <20130731155741.GA56454@mx1.yitter.info> Date: Thu, 1 Aug 2013 11:29:42 +0200 Message-ID: From: Trent Adams To: Barry Leiba Content-Type: multipart/alternative; boundary=089e013cbf0467e7d104e2df7bbf Cc: "dmarc@ietf.org" , Andrew Sullivan Subject: Re: [dmarc-ietf] Copying IAB remarks (was: [IAB] IETF 87 DMARC BOF evaluation) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:31:36 -0000 --089e013cbf0467e7d104e2df7bbf Content-Type: text/plain; charset=ISO-8859-1 As someone who was "anxious", I do believe that the transparency and openness of the report was very much appreciated. Thank you! I hope to see these types of reports continue to be made available. I also support Barry's suggestion for some sort of preamble to explain the context for the report. I believe my anxiety would have been reduced had I more clearly understood what the report was and it's function. Thanks again, this has been a fantastic experience and I'm excited and energized about the prospects for the work. - Trent On Wed, Jul 31, 2013 at 7:23 PM, Barry Leiba wrote: > > Just to be clear, we did this because the responsible AD asked us to > > Yes, and thank you for doing it. > > > Also, as we can see from the subsequent threads, the follow-on > > discussion suggests that people are made anxious by these reports, > > partly because they tend to be pretty terse, leaving out all sorts of > > subtleties. (If an AD thought something was being missed, I assure > > you s/he'd ask.) That's important because as I understand it the IESG > > is looking for a broad picture from the IAB, not a lot of in depth > > review. They don't have time to read an in depth thing. So I'm > > actually not sure that this is a good long-term plan. > > I think it is. > > Perhaps you could develop a preamble, much as some of the directorate > reviews have, that explains the situation. But I'd like to see most > of the IAB BoF reports sent publicly. > > Barry > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams --089e013cbf0467e7d104e2df7bbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

As someone who was "anxious", I do beli= eve that the transparency and openness of the report was very much apprecia= ted.

Thank you!

I hope to= see these types of reports continue to be made available. =A0I also suppor= t Barry's suggestion for some sort of preamble to explain the context f= or the report. =A0I believe my anxiety would have been reduced had I more c= learly understood what the report was and it's function.

Thanks again, this has been a fantastic experience and = I'm excited and energized about the prospects for the work.
<= br>
- Trent



On Wed, Jul 31, 2013 at 7:23 PM, Barry L= eiba <barryleiba@computer.org> wrote:
> Just to be clear, we did this because the responsibl= e AD asked us to

Yes, and thank you for doing it.

> Also, as we can see from the subsequent threads, the follow-on
> discussion suggests that people are made anxious by these reports,
> partly because they tend to be pretty terse, leaving out all sorts of<= br> > subtleties. =A0(If an AD thought something was being missed, I assure<= br> > you s/he'd ask.) =A0That's important because as I understand i= t the IESG
> is looking for a broad picture from the IAB, not a lot of in depth
> review. =A0They don't have time to read an in depth thing. =A0So I= 'm
> actually not sure that this is a good long-term plan.

I think it is.

Perhaps you could develop a preamble, much as some of the directorate
reviews have, that explains the situation. =A0But I'd like to see most<= br> of the IAB BoF reports sent publicly.

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



--
= J. Trent Adams
=3Djtrentadams

Profile: http://www.mediaslate.org/jtrentadams/
Link= edIN: http://www.linkedi= n.com/in/jtrentadams
Twitter: http://twitter.com/jtre= ntadams
--089e013cbf0467e7d104e2df7bbf-- From ietf@meetecho.com Thu Aug 1 02:07:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598621E804D for ; Thu, 1 Aug 2013 02:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq65d7dSkSdy for ; Thu, 1 Aug 2013 02:07:34 -0700 (PDT) Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id 0850921F859B for ; Thu, 1 Aug 2013 02:06:53 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6s1m00G0EaGCq01M6tVp; Thu, 01 Aug 2013 11:06:53 +0200 Date: Thu, 1 Aug 2013 11:06:50 +0200 (CEST) From: Meetecho Team To: dmarc@ietf.org Message-ID: <1059558514.35.1375348010492.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_34_1971347490.1375348010488" X-Mailman-Approved-At: Thu, 01 Aug 2013 03:02:51 -0700 Subject: [dmarc-ietf] DMARC session recording available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:07:43 -0000 ------=_Part_34_1971347490.1375348010488 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the DMARC WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#DMARC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_34_1971347490.1375348010488-- From MHammer@ag.com Fri Aug 9 11:27:17 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5721F9AD1 for ; Fri, 9 Aug 2013 11:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-1zjaFmL-lx for ; Fri, 9 Aug 2013 11:27:09 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 519E821F9D18 for ; Fri, 9 Aug 2013 11:19:20 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 14:19:19 -0400 From: "MH Michael Hammer (5304)" To: "dmarc@ietf.org" Thread-Topic: Section 12.2.2 Thread-Index: Ac6VLHKEGHO6Zz/eTYiSKoTaWKsYuA== Date: Fri, 9 Aug 2013 18:19:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.228] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:27:17 -0000 John Levine posted regarding using HTTP (see below) and this came up in the= BOF as well. Perhaps we could have the discussion on the list and perhaps = even have some conclusions for last call on the draft. >=20 > * Decide whether to remove section 12.2.2 since I don't think anyone has > ever implemented and it's rather badly specified. Every http POST I've e= ver > seen has had an application/x-www-form-urlencoded or multipart/form- > data body. While there's nothing in the http spec that forbids other ran= dom > multiparts, I wouldn't want to write it into a standards track document u= nless > I was confident that web servers would do something reasonable. Note tha= t > an http PUT means to replace whatever is at the URL with the body of the > message, which is not what you want. > POST makes more sense, but for a POST to work reliably you'd be much > better off with the gzip file inside a multipart/form-data. The Subject = field it > describes is also pretty dodgy since I don't know anyone who uses them wi= th > http, and would in any event be redundant with the filename in the form- > data. The section is also somwhat underspecified on the response side, s= ince > it gives no hint as to what http return codes might be returned and how a > receiver should interpret them, e.g., if it gets a 302 should it really g= o re-post > it somewhere else? If it gets a 4xx should it keep sending subsequent > reports? >=20 From sca@andreasschulze.de Fri Aug 9 13:02:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21821F9D1B for ; Fri, 9 Aug 2013 13:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVGpSo2Oq7b6 for ; Fri, 9 Aug 2013 13:02:35 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [IPv6:2001:1608:12:1:8ead:7d6c:3132:6a07]) by ietfa.amsl.com (Postfix) with ESMTP id 197BB11E8128 for ; Fri, 9 Aug 2013 12:56:04 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1376078160; atpsh=sha256; atps=andreasschulze.de; r=y; bh=C9BYEksji3aeHUUw6TuPw8BbFUDSXdsAogoVoSMPxoc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; z=Date:=20Fri,=2009=20Aug=202013=2021:55:57=20+0200|From:=20Andreas =20Schulze=20|To:=20dmarc@ietf.org|Cc:=20Jo hn=20Levine=20|Subject:=20Re:=20[dmarc-ietf]=20Se ction=2012.2.2|References:=20|In-Reply-To:=20; b=X1v+ep7SFOiOB9vLJGKKr+oiLMODSlDrU7T9TDqGtdCavYTctYlm3awWdGfn1wCQw YazPNhjj6wdD8NvenG3xj5bgHfjumn+N3tJeLGXk5zEhO2DUOgf+EDTaiTUOwog0zF KrhmFc+OwwCAly+h06q9UzTeTN9hlAPu9OGBM3+KdWqUIj5efbScMgzYrqxmPuGHVz 97Jmyn7ppdyIXNDGnP8HYM/DLpUGwRfaJMzuXR5OQdZNHvrSKuzQDKxO6KR99zRe9P waDkTSuWMdUPzgC+oUN3zsuSAXtupCjMnmgnQbKWC9jZJDrjz8nNklue5wPH7KM01Z EpP6ePM/rfdxx1H+m/Hecqqtig5s0E+We0lOr0E6QGd4o6LobgBRO9cdZKJ03N3yPu ZHu/z4QDDSRY6hgyyKdeYO9WeS0XKGJpXbZvr/eaxhe0k/MiJFnCMWRZT5BjI+ikNV sG3c259uKGtBf6jRKujvVI+77XpWKd8qvLpj9xw1MGI4Bsg4Q2oC1D9eR2pl1ikWQm Rd3I4gPDTDahky+YCEjue4gZUMagSjZBjspARTi3RBihMBgowolH6JJ+UGVHZS1GfI /A0tecQQFXJXzP38btZLMPOi12QpN70cyJU1T4afV7jq4MCn+zCzOgolIKNGE8zlrW mFxdT/WUtWljGGuR62q8bPZI= X-Received: line deleted by mout Date: Fri, 09 Aug 2013 21:55:57 +0200 Message-ID: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> From: Andreas Schulze To: dmarc@ietf.org References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: John Levine Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:02:35 -0000 Zitat von "MH Michael Hammer (5304)" : > John Levine posted regarding using HTTP (see below) and this came up > in the BOF as well. Perhaps we could have the discussion on the list > and perhaps even have some conclusions for last call on the draft. In my opinion the http transport has the disadvantage of total unauthenticated submission. for smtp one can force the submission message has to be valid dkim signed. On the other side there is no implementation. John, which domain request aggregated reports via http? Maybe an implementation using curl is really easy... Andreas From MHammer@ag.com Fri Aug 9 13:19:12 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84F21E80AB for ; Fri, 9 Aug 2013 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wybAJlp9rHk7 for ; Fri, 9 Aug 2013 13:19:08 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9D21F9930 for ; Fri, 9 Aug 2013 13:12:35 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 16:12:34 -0400 From: "MH Michael Hammer (5304)" To: Andreas Schulze , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Section 12.2.2 Thread-Index: Ac6VLHKEGHO6Zz/eTYiSKoTaWKsYuAAL4saAAAfeGQA= Date: Fri, 9 Aug 2013 20:12:34 +0000 Message-ID: References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> In-Reply-To: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.228] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Levine Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:19:12 -0000 Andreas, I'm not a fan of HTTP as a channel but recognize that it is in the spec and= that there are issues with it. I just figure that seeing as it came up it = is probably worth having the discussion and dealing with. Personally I woul= d have no problems if this was dropped as a channel for the reports but, th= ere it is. Mike > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Andreas Schulze > Sent: Friday, August 09, 2013 3:56 PM > To: dmarc@ietf.org > Cc: John Levine > Subject: Re: [dmarc-ietf] Section 12.2.2 >=20 >=20 > Zitat von "MH Michael Hammer (5304)" : >=20 > > John Levine posted regarding using HTTP (see below) and this came up > > in the BOF as well. Perhaps we could have the discussion on the list > > and perhaps even have some conclusions for last call on the draft. >=20 > In my opinion the http transport has the disadvantage of total > unauthenticated submission. > for smtp one can force the submission message has to be valid dkim signed= . >=20 > On the other side there is no implementation. >=20 > John, which domain request aggregated reports via http? > Maybe an implementation using curl is really easy... >=20 > Andreas >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From johnl@taugh.com Fri Aug 9 13:43:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93BD11E819A for ; Fri, 9 Aug 2013 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSzczqqY6sAb for ; Fri, 9 Aug 2013 13:43:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EF5971F0D9E for ; Fri, 9 Aug 2013 13:35:38 -0700 (PDT) Received: (qmail 77976 invoked from network); 9 Aug 2013 20:35:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=13095.52055297.k1308; bh=bABZjzGB1i6vPvSjVTbDSQ5uFHod5qOnnNhFv2IrbHs=; b=d09WKJ3gCoGErfzZVVkkJDa4uJ+DBhTbfmAOiDj09PP0x6h07aNFlHd7XG7v4MwtHlxmlWYes+6QeA9ePVJy8U7XRlaby/759tJChvU18sFGeH97+/H6IKesJ/i1SoQxarQWi/sKXURhPDAWz+h9chDR/qE9y80GRA9U4bCFodU0M0VcMM4B29EjptthAaNnehxWnAxlWTTv0mS9PjsI50UYUSwlm9rXm/dUR9FnwNdoOcj17hdZHogPiTDoP0lf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=13095.52055297.k1308; bh=bABZjzGB1i6vPvSjVTbDSQ5uFHod5qOnnNhFv2IrbHs=; b=YqsJ+MzgalB68O5Lj1lyBgUs7w46sN7c4In0rF+Jh1H08ECt6gDd0saN2150jv0Vk9c4cS1DDs5aScCuoJy3ogv49p6HVJKKPsUJYt+BJjG70983P6jh5sc2oYph2ktMY6IHBNR0vDjBha2kFt80zns9tHn38I13AWL3d8bcp0zzHf5TWtVjzK7bCfdO7SfB/qCs9qu6L0QEcl7gjxzy7Y85b+y4Cl+CpCN0yEQpVtiVC1fkEgvVSMZ81av7qDlG Received: (ofmipd 127.0.0.1); 9 Aug 2013 20:35:13 -0000 Date: 9 Aug 2013 16:35:35 -0400 Message-ID: From: "John R Levine" To: "Andreas Schulze" In-Reply-To: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:43:55 -0000 > In my opinion the http transport has the disadvantage of total > unauthenticated submission. > for smtp one can force the submission message has to be valid dkim signed. This objection makes no sense. The usual complaint about http security is that there are too many authentication schemes, not too few, ranging from plain text http auth to TLS client certs to oAuth. > John, which domain request aggregated reports via http? > Maybe an implementation using curl is really easy... A quick review of the DMARC spec reveals that HTTP submission has been there for over a year. Someone told me that someone somewhere sends http reports, although the current text is so underspecified that it's anyone's guess what they're actually doing. If you want authentication, you can use https and look for a client certificate. Since anyone sending reports is doing you a favor, it would be counterproductive to demand that they jump through authentication hoops to do so, and I've never understood the threat model. Are you worried that someone will send you fake reports? Why? If they do, what damage will it cause? How hard will it be to mitigate, and how does that cost compare to the cost of getting no reports at all from people who don't feel like following your authentication rules? Finally, it's not hard to tell curl to do an http PUT with or without http auth or TLS client certs, although I expect that most people sending reports have written their report generator in something like python, so they'd use one of the existing http client libraries. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From sca@andreasschulze.de Fri Aug 9 14:59:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029B321F8F67 for ; Fri, 9 Aug 2013 14:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHP-fbO+4yO1 for ; Fri, 9 Aug 2013 14:59:23 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [IPv6:2001:1608:12:1:8ead:7d6c:3132:6a07]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE2621F9DDC for ; Fri, 9 Aug 2013 14:53:15 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1376084775; atpsh=sha256; atps=andreasschulze.de; r=y; bh=V/YCqI1V9ST9dsAmABtpYLX//0fcZU1Zu9Wgk2MnMVk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; z=Date:=20Fri,=2009=20Aug=202013=2023:46:00=20+0200|From:=20Andreas =20Schulze=20|To:=20John=20R=20Levine=20|Cc:=20dmarc@ietf.org|Subject:=20Re:=20[dmarc-ietf]= 20Section=2012.2.2|References:=20=0D=0A=20<20130809215557.Hor de.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de>=0D=0A=20|In-Reply-To:=20; b=B4u9BhhzjUN/NVjLkK9zovBLnq2Z5mHQwp/U8xKbdfujp8p983KaCw/gsEZIo3eNv fHjvz2QmHgvgos5UxfW1uA6jSY+gjdxbXZ8m8ut3jgVbeLj7suARA+qUEYJgU+d0wS 6ZfDvHpNEZcokl/LovCe3sP/g7v2zYZ5D03WUJuQjTxvxSuEydDNbOaf6VArZj0XbE U4GhumE0A89yOyBpG9BHWEJspugR1ETTfZyRpNB7NdiUZeXmUNr+7DHJXoDbS07+TJ CHFKbcXAz6SkVPyAznvuePgt73bzRy/04H0wkJi6kZSOm/hwHKmWBJgOMoZswv9N8U dtndlVEoPy369kFYJEvE/CYMN+WSyFRDsyb6XZnbwik8JOt2ZbLGZC6qsgApwpfwm2 u6I95pADejdUYFqbQHrPR77tHS7icCdWysCBzkEpKJyKS0ocFfAeIoVQcKXvl4cuNu /W338tw8/8fp7A7nvu4xNXXaejsL5qO4QBNT46piXd58HWK0MGOr9SmAC5AhOg+ju4 LSvei5xeS7fSiVcHuUuNVGNEbt8sry+Qb7RU9qeuK2XOt4wnKlHnpFY7swz4bae9fI IjXfxD63SXBpoEvUKwAKSxpaVJI1wRDKDLwEA8UqrVGiYO/TWamTqpWIHdtDbtclAc OPgS09EdBrX3VZrFjWQJ2N/I= X-Received: line deleted by mout Date: Fri, 09 Aug 2013 23:46:00 +0200 Message-ID: <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> From: Andreas Schulze To: John R Levine References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:59:24 -0000 Zitat von John R Levine : > This objection makes no sense. The usual complaint about http > security is that there are too many authentication schemes, not too > few, ranging from plain text http auth to TLS client certs to oAuth. of course there are authentication schemes for http. > Are you worried that someone will send you fake reports? Why? If > they do, what damage will it cause? How hard will it be to > mitigate, and how does that cost compare to the cost of getting no > reports at all from people who don't feel like following your > authentication rules? If I think again about it, in both (http/smtp) cases the data must be received before any kind of validation can occur. From this perspective there is really no difference between http and smtp. So, sorry for my noise :-) If nobody implemented http reporting yet we should consider removing it from the spec... Andreas From smj@crash.com Wed Aug 14 20:33:18 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E49311E81CC for ; Wed, 14 Aug 2013 20:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbgx1A45bIc9 for ; Wed, 14 Aug 2013 20:33:13 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [72.52.75.15]) by ietfa.amsl.com (Postfix) with ESMTP id 849CC11E81C4 for ; Wed, 14 Aug 2013 20:33:10 -0700 (PDT) Received: from abort.crash.com (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 r7F3WrZs012600 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 20:32:58 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com r7F3WrZs012600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1376537579; bh=vOMz9GNs7ndLBPqumYcsTuNXX/pYCvR2/LUDx0YDQW4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=M0uqp985HBZyqJz+DPrfKLGgA6H/0o8gg2DATzyLtJyoxMAKxVHMjup4iQ3GcFE0k WZG06OLnGicWeOMcUN3ySLgz4qiB/feSUIJ/EZgcxpc9KiKJA8ZVMCD3lbdCYDavqx w/BGsI/5dTNuraTfgyKO24PRt6Ry3fkaHiPOPX74= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be abort.crash.com Message-ID: <520C4BE1.7070606@crash.com> Date: Wed, 14 Aug 2013 20:32:49 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmarc-discuss@dmarc.org, dmarc@ietf.org References: <5131C5CB-5B7A-43F8-A87B-9C505D8E9001@tnpi.net> <77426B543150464AA3F30DF1A91365DE53CCBA16@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE53CCBA16@ESV4-MBX01.linkedin.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 14 Aug 2013 20:32:59 -0700 (PDT) Subject: Re: [dmarc-ietf] [dmarc-discuss] DMARC URI size allowance X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 04:25:13 -0000 Adding the [dmarc-ietf] list for spec considerations. Direct follow-up spec discussion there; operational issues can remain with [dmarc-discuss]. PLEASE edit your To: and Cc: accordingly. Originating message on [dmarc-discuss] from Tomki Camp queried how many implementations obeyed the optional report size limitations described in section 5.1 ... On 08/14/2013 05:21 PM, Franck Martin wrote: > On Aug 14, 2013, at 5:07 PM, Matt Simerson wrote: >> I just iterate over the URI list and send the report to each one, skipping over any where the message size exceeds the published limit. > But this is not the intent, you are supposed to cut the report in smaller chunks and send them... (just saying ;) Can you cite the section(s) for that behavior, Franck? Matt, if no reports can be sent based on size limits, do you then send a "reports too big" notice to all the mailto: URIs per section 11.2.4? Section 11.2 indicates that any reporting URI with a size limit lower than the current report size should be skipped, with an exception that if no URIs qualify to receive a report, Mail Receivers should follow section 11.2.4 to send a "report too big" notice. Section 11.2.1 for the Email transport notes the possibility of a report larger than can be accepted by a mailto: URI and refers to section 11.2.4. Section 11.2.2 for the HTTP transport does not make a specific reference to the size limitation; neither does section 11.2.3 which notes the opportunity to add additional transports in future. I'd recommend that it just be made clear that the handling specified in section 11.2 applies across all transports. Pursuant to the original question though, has anybody received an error report as described in section 11.2.4 in the wild? I'm curious because there's a note in the spec that a more rigorous definition will be added based on operational experience... I'll go bodge something to generate some, but organic examples would probably be better if we've got any. Thanks, --Steve. From tcamp@agari.com Fri Aug 23 08:10:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464BA11E81D1 for ; Fri, 23 Aug 2013 08:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBqoJvwvjoIE for ; Fri, 23 Aug 2013 08:10:58 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4C27711E82F9 for ; Fri, 23 Aug 2013 08:10:58 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so779585pbb.19 for ; Fri, 23 Aug 2013 08:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=pUxbkvo5QJo3VkMoZOm8PER0CvzzbFvM6dzxugVrsqA=; b=ldOl4RJOz2l5Um4YXJ9kLclNB6pSmuq0NSi9/0EHJV4NoUqo0yilp6CXlnHxvBxad6 Wmp941R4EP29+PFRuI2ZKaCvWpmi5skrEU1BS9eDkdL5R70Mv/B9O4fIeP1uCANQOPln DEcOq0P1W+sXiOLfMaBG3qw/rEMYiEVhcmgrk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type; bh=pUxbkvo5QJo3VkMoZOm8PER0CvzzbFvM6dzxugVrsqA=; b=NQl56A+L5p0Ke4yhhEqygJ7tL+LLz/c0H1pFUw0V/R8j0iBjuOSYb4NRBjKTcwZ8X2 cpQV6bzxmm78cdM8Qg71FhR3l/yAMeOcjsqQY2/n+fv5G/KOqmk52UdtpkLprT8sQVYA r+mmnexm+IKV8RjjQ9wukneHLo1G63mYxZJu1rg60XZWqltTfg/QLK+CLwgkWN70Z6Hx r4UL0A146oSzbmzR3Uz4tjN6hnnkbFm+0NahAYH/2edrgCHvp3Ar9Fvni1ooN0qs8A67 jij3JDEpw86q6VACjgHs04nh0XuQ+GPHjystQmjDTi5O3u3yFNFZ7GbvRyV2kbZgEhZj VrEQ== X-Gm-Message-State: ALoCoQkdQ1IufqqSZVkAraxNsy7/kCRj2y3VZf6z/etcIIQGdniQXVaFyph+y6hokKb+4vAXeHR9 X-Received: by 10.68.254.138 with SMTP id ai10mr122635pbd.151.1377270657298; Fri, 23 Aug 2013 08:10:57 -0700 (PDT) Received: from [192.168.1.120] (c-24-6-247-35.hsd1.ca.comcast.net. [24.6.247.35]) by mx.google.com with ESMTPSA id fk4sm1607694pab.23.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 08:10:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 23 Aug 2013 08:10:50 -0700 From: Tomki Camp To: Message-ID: Thread-Topic: inconsistency - specified optional tags vs XML spec Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3460090255_147527949" Subject: [dmarc-ietf] inconsistency - specified optional tags vs XML spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:10:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3460090255_147527949 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit There are several options for the DMARC DNS entry which are called out as optional, with defaults, in the body of the spec. However some of these (aspf, adkim) which are spelled out as optional are not defined so in the XML itself. In 5.2 each are specified as optional, with default='r'. To match this properly, shouldn't the corresponding entry in XML show default="r" and minOccurs="0" elements? Also, the XML does not currently address the new 'fo' entry. ref: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 Thanks Tomki Camp, Agari Director of Support tcamp@agari.com l M: 415.779.2854 l www.agari.com Learn who is most vulnerable to cybercrime in the Agari Q2 TrustIndex here Sign up for our webinar 8 Steps to DMARC here --B_3460090255_147527949 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

There are several option= s for the DMARC DNS entry which are called out as optional, with defaults, i= n the body of the spec.  However some of these (aspf, adkim)
= which are spelled out as optional are not defined so in the XML itself.

In 5.2 each are specified as optional, with default=3D'r'= .  
To match this properly, shouldn't the corresponding entry= in XML show default=3D"r" and minOccurs=3D"0" elements?
Also, the XML does not currently address the new 'fo' entry.


Thank= s
Tomki Camp, Agari Director of Support
tcamp@agari.com l M: 415.779.2854 l&= nbsp;www.agari.com
Learn who is mos= t vulnerable to cybercrime in the Agari Q2 Trust= Index here
=
Sign up for our webinar 8 Ste= ps to DMARC here
--B_3460090255_147527949-- From tcamp@agari.com Fri Aug 30 12:08:18 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36A511E8113 for ; Fri, 30 Aug 2013 12:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpxpMCaZXQDM for ; Fri, 30 Aug 2013 12:08:18 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 086D511E8111 for ; Fri, 30 Aug 2013 12:08:06 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so2209518pdj.39 for ; Fri, 30 Aug 2013 12:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; bh=i7lVYkOLIU0uosWm9hyH8qreDEiAwCPgtSUKzrOqJEI=; b=eoOzsAGr2JA1SG4bpSLoiGICWoICQrS3jA1TuoVWQfpojzrP6srb6UU6KdT65vpQiM xT/BIZetJBn+q0MGg/CRc6+eZxQou4fS1KpzwUtDouk+6ljEn8+oUTu7pjTjEr7yuUqq zSJIBIBfzrRRC7BijNGkz9QJMaqkMsE4tPY0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=i7lVYkOLIU0uosWm9hyH8qreDEiAwCPgtSUKzrOqJEI=; b=IiHpZqcM4BZ0G+lNDQqmlo6ADN8nAnwxL2wdI+cCm9RJ8V7V26cSf3nKq+Ci2+kBvo 74PnTrPfy28j7vUfUUPsm5DjCcFd5+WP1orqI1KjtTPIJQKf2O2WXaKbCKbEuW8CsVdb 6Un3Z8vBJMavHzyrhxarU3JrFndDwM52RnCvyovrW7sYbWJUg+Xxri+GQzY0L1sPlTG5 kU0cL66W7FzEYawIxO3ogCVnbrocUXEXa/4iw6U9+2SVWNP61+i1fMxIlGCmsdo7kcMk i38lGyxHHalaCBMO0+WvwxgkyA7iQQl6MJllQggZk6jAECHZBCVT60oA8lCysncDjlyJ +E7A== X-Gm-Message-State: ALoCoQlAnm0newpqrGznUU6QMULqhPsuShqhC4PHx6ST7vuydVX6YvhLfu9ItHGgkzWbWQR4NazL X-Received: by 10.66.161.229 with SMTP id xv5mr12571237pab.87.1377889686364; Fri, 30 Aug 2013 12:08:06 -0700 (PDT) Received: from [10.0.1.42] (50-197-151-173-static.hfc.comcastbusiness.net. [50.197.151.173]) by mx.google.com with ESMTPSA id uw6sm46062929pbc.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 12:08:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 30 Aug 2013 12:07:56 -0700 From: Tomki Camp To: Message-ID: Thread-Topic: inconsistency - specified optional tags vs XML spec In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3460709284_182584915" Subject: Re: [dmarc-ietf] inconsistency - specified optional tags vs XML spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:08:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3460709284_182584915 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Mike J pointed out to me that I conflated some things; the 'fo' tag is probably not a reasonable candidate to include in the XML, because it's simply an advisory in the published DMARC DNS record, influencing the generation of forensic reports. So this is really just down to updating the XML to account for the disjunction of 'optional' items being set as 'required' via XML. (and updating the schema # and the XML hosted at dmarc.org) --Tomki From: Tomki Camp Date: Friday, August 23, 2013 8:10 AM To: Subject: inconsistency - specified optional tags vs XML spec > > There are several options for the DMARC DNS entry which are called out as > optional, with defaults, in the body of the spec. However some of these > (aspf, adkim) > which are spelled out as optional are not defined so in the XML itself. > > In 5.2 each are specified as optional, with default='r'. > To match this properly, shouldn't the corresponding entry in XML show > default="r" and minOccurs="0" elements? > > Also, the XML does not currently address the new 'fo' entry. > > ref: > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > > Thanks > Tomki Camp, Agari Director of Support > tcamp@agari.com l M: 415.779.2854 l www.agari.com > Learn who is most vulnerable to cybercrime in the Agari Q2 TrustIndex here > > Sign up for our webinar 8 Steps to DMARC here > --B_3460709284_182584915 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Mike J pointed out t= o me that I conflated some things; the 'fo' tag is probably not a rea= sonable candidate to include in the XML, because it's simply an advisory in = the published DMARC DNS record, influencing the generation of forensic repor= ts.

So this is really just down to upda= ting the XML to account for the disjunction of 'optional' items being set as= 'required' via XML.
  (and updating the schema # and the XML= hosted at dmarc.org)


--Tomki
<= div>

From: Tomki= Camp <tcamp@agari.com>
Date: Friday, August 23, 2013 8:10 AM
To: <dmarc@ietf.org>
Subject: i= nconsistency - specified optional tags vs XML spec

<= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">

There are several options for the DMARC DNS entry which are called out= as optional, with defaults, in the body of the spec.  However some of = these (aspf, adkim)
which are spelled out as optional are not defi= ned so in the XML itself.

In 5.2 each are specified= as optional, with default=3D'r'.  
To match this properly, sho= uldn't the corresponding entry in XML show default=3D"r" and minOccurs=3D"0= " elements?

Also, the XML does not currently a= ddress the new 'fo' entry.

ref: http= s://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=3D1<= /div>

Thanks
Tomki Camp, Agari Director of Sup= port
= tcamp@agari.com&nb= sp;l M: 415.779.2854 l www.agari.com
Sign up for our webinar = 8 Steps to DMARC here
--B_3460709284_182584915-- From tcamp@agari.com Fri Aug 30 12:11:25 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96C21F9D17 for ; Fri, 30 Aug 2013 12:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8g1pEkHE6dd for ; Fri, 30 Aug 2013 12:11:20 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E818621F9B8C for ; Fri, 30 Aug 2013 12:11:19 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so2709258pac.3 for ; Fri, 30 Aug 2013 12:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=Q+xE9uaZhRtWznsLCANkKAg3ZrGjgxZWOkw2kcSzKGw=; b=tO+1O2fxgbdeKtHU8qb6sKyLY91lJQc3WBJXg/zB73u2OQGvFr5Ep6b4qoZzPGrk6Q bAE8TyVrdpkSbwxfLOrGK287rMbLftqqaDm9g6Nt88A7xwOglNSGeVei6uJ//KwzDfpt gqTWU4MslZMNm9kDQfpo+RF7sEUlNqbJICpws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type; bh=Q+xE9uaZhRtWznsLCANkKAg3ZrGjgxZWOkw2kcSzKGw=; b=epVyPVXnAH5uzWFhAt5sGAB3ZyknQqazea2xKagU4sR9h+QkLeLQGu2Jekm4Nwzu+m a7QtdZns7+zQeXJR0NCkcbZEoH/cjpFHMyUEB/4sqfNUatWM9kCOxsYHry5hRk1xn6oQ Ab8zQbqrhfdJczPUQVxb+4j+MBlXz68sgyLl+HiTwoLIFK3Bv2OWVz0Vfpxya8lHM7B1 WaXlKXkxc9ZYcataAaeYUwPCoryxAHf3RaSfzslZoQZM96oKELkkBz/H2ylYCiOURGcb X5UONoNKVIga/rE2ZDG7HeGnYsuc9q8Cz5bHZvrSHhwO35AkUH8aXgmPCET0gv/Lqwg3 JxJw== X-Gm-Message-State: ALoCoQk1sIUD2llo7C7LJAp0/TJyzyv0m5x2pecXNsHn+h48H4+Q5GgQoYrWL8Bm8Lo9FtwNiLDP X-Received: by 10.67.23.164 with SMTP id ib4mr12637171pad.42.1377889879655; Fri, 30 Aug 2013 12:11:19 -0700 (PDT) Received: from [10.0.1.42] (50-197-151-173-static.hfc.comcastbusiness.net. [50.197.151.173]) by mx.google.com with ESMTPSA id iu10sm49487112pac.18.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 12:11:18 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 30 Aug 2013 12:11:11 -0700 From: Tomki Camp To: Message-ID: Thread-Topic: DMARC spec - brief feedback around GZIP Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3460709478_182606771" Subject: [dmarc-ietf] DMARC spec - brief feedback around GZIP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:11:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3460709478_182606771 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Based on our work importing gzipped aggregate data sent over to Agari, our experience and investigation indicated to us that the spec is a bit misleading here: ==== extension = "xml" / "gzip" For the GZIP file itself, the filename extension MUST be "gz"; for the XML report, the extension MUST be "xml". ==== because on one hand it says the extension can be gzip but then immediately says for a gzip file the extension must be '.gz'. (note that gunzip will not normally succeed with a .gzip extension) Also, it should probably be permitted that a double extension such as .xml.gz appear. Regards, -- Tomki Camp, Agari Director of Support tcamp@agari.com l M: 415.779.2854 l www.agari.com Learn who is most vulnerable to cybercrime in the Agari Q2 TrustIndex here Sign up for our webinar 8 Steps to DMARC here --B_3460709478_182606771 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Based on our work imp= orting gzipped aggregate data sent over to Agari, our experience and investi= gation indicated to us that the spec is a bit misleading here:

=3D=3D=3D=3D
     extension =3D "xml" / "gzip"

   For the GZIP file itself, the filename extension MUST be "gz"; for
   the XML report, the extension MUST be "xml".
=3D=3D=3D=3D
=
  
because on one hand it says the extension can be gzip =
but then immediately says for a gzip file the extension must be '.gz'.  (not=
e that gunzip will not normally succeed with a .gzip extension)
= 

Also, it should probably be per=
mitted that a double extension such as .xml.gz appear.


Regards,<=
/font>
--
Tomki Camp, Agari Director of Support
tcamp@agari.com l M: 415.779.2854 l www.agari.com
Learn who is most vulnerable to cyber= crime in the Agari Q2 TrustIndex here
Sign up for our= webinar 8 Steps to DMARC here

--B_3460709478_182606771-- From prvs=9495c86d5=fmartin@linkedin.com Sat Aug 31 17:39:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7A11E81AD for ; Sat, 31 Aug 2013 17:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwqwXrSDqB-G for ; Sat, 31 Aug 2013 17:39:47 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id F29FC11E80D1 for ; Sat, 31 Aug 2013 17:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1377995986; x=1409531986; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C0im22V/pGiZwZxwaaJ1fPM3FVDii4EbKrS23uNiH3M=; b=cOYHPVg4zEDhB6bPUBONUhcuZ/pCHBzkCESR7U2ovDZ6pkUoBpvbeamH rsLzCB9iWTa//E/R9jSDnGsZtr5KeO743A5R3gTV3vlm4Zuk71IrWm7KN Ts8DBjaccYLZch14xUKapsEdXcVR7IDJq8cR47R31cZN/pDTE/ur4yntA U=; X-IronPort-AV: E=Sophos;i="4.89,999,1367996400"; d="asc'?scan'208,217";a="59940122" Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Sat, 31 Aug 2013 17:40:12 -0700 From: Franck Martin To: Tomki Camp Thread-Topic: [dmarc-ietf] DMARC spec - brief feedback around GZIP Thread-Index: AQHOpbTTFuj4X301MEWvkWfYnTJqYpmwgVuA Date: Sun, 1 Sep 2013 00:40:12 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE6A89E0F7@ESV4-MBX02.linkedin.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/signed; boundary="Apple-Mail=_7B064232-1AA8-4C0C-B1C5-CEE19C648BCD"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "" Subject: Re: [dmarc-ietf] DMARC spec - brief feedback around GZIP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 00:39:51 -0000 --Apple-Mail=_7B064232-1AA8-4C0C-B1C5-CEE19C648BCD Content-Type: multipart/alternative; boundary="Apple-Mail=_1B5E6FD2-B966-4281-920B-DC1C1CBDF873" --Apple-Mail=_1B5E6FD2-B966-4281-920B-DC1C1CBDF873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On Aug 30, 2013, at 12:11 PM, Tomki Camp wrote: > Based on our work importing gzipped aggregate data sent over to Agari, = our experience and investigation indicated to us that the spec is a bit = misleading here: >=20 > =3D=3D=3D=3D > extension =3D "xml" / "gzip" >=20 > For the GZIP file itself, the filename extension MUST be "gz"; for > the XML report, the extension MUST be "xml". > =3D=3D=3D=3D > =20 > because on one hand it says the extension can be gzip but then = immediately says for a gzip file the extension must be '.gz'. (note = that gunzip will not normally succeed with a .gzip extension) >=20 > Also, it should probably be permitted that a double extension such as = .xml.gz appear. >=20 >=20 --Apple-Mail=_1B5E6FD2-B966-4281-920B-DC1C1CBDF873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii tcamp@agari.com> wrote:

Based on our work importing = gzipped aggregate data sent over to Agari, our experience and = investigation indicated to us that the spec is a bit misleading = here:

=3D=3D=3D=3D
     extension =3D "xml" / "gzip"

   For the GZIP file itself, the filename extension MUST be "gz"; for
   the XML report, the extension MUST be "xml".
=3D=3D=3D=3D
  
because on one hand it says the extension can be =
gzip but then immediately says for a gzip file the extension must be =
'.gz'.  (note that gunzip will not normally succeed with a .gzip =
extension)

Also, it should probably be permitted that a =
double extension such as .xml.gz appear.



<= /body>= --Apple-Mail=_1B5E6FD2-B966-4281-920B-DC1C1CBDF873-- --Apple-Mail=_7B064232-1AA8-4C0C-B1C5-CEE19C648BCD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJSIoy/AAoJEJHd9Bbysc+a95oH/35DtEiGciYolIddfCbfuMou eJ1ehbXvwWhkGknjFSSzatRaNlDjVd2idw4V2Qf3zJGweqK00N3qOQ5z+9Haxr9q UFvfoEYehK9WTNcMa38xe/KyMMLwaOhYRXH4BcEAzkYmXxlm/sySYIIiAuT63MlG TOnvzQfLwjLpA2vckS8T1reOvN3x7KcFVTaMAiROLlkzuR8sRw3UgIfjB26gImEH JqyO2e5ItKm6ZTqwP2u/ZzOOchRHAk4vKeMEYB10dfn0J7hGUifx5c+fPbfCwZOK kLMUoH0T3JLSF8y7L9HJjQXpUwYC9jIl4/L2AA0Y0BAKrXk+WNLVWf5Sl2tCMo0= =vGyu -----END PGP SIGNATURE----- --Apple-Mail=_7B064232-1AA8-4C0C-B1C5-CEE19C648BCD--