From nobody Fri Feb 3 10:40:56 2017 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 0E3501294E0 for ; Fri, 3 Feb 2017 10:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Yon8IS9qN1 for ; Fri, 3 Feb 2017 10:40:50 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BB11288B8 for ; Fri, 3 Feb 2017 10:40:50 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8825BC4020B for ; Fri, 3 Feb 2017 12:40:49 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1486147249; bh=WMfYDw8zlxFhKDCEB8uMIOl/DeM/VeVAKU6VIHcnzCs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QMQ+Y9txgyNYO8gdsDSmLBZyi1MPVyxeQU705tvk5Miu32/MH7oVXS/GO9hNp3Z97 4DEjMRJwJBaQ3vK6Po/tqtjBqhaAjJM202swuGyte4lTo89BEFjFKL7sz+WBJBMYcj h98h3yLtGD0Amld/QYrz99bd6cUpjMhOq8MpsOQI= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 03 Feb 2017 13:40:50 -0500 Message-ID: <2214481.LisCfLsDfL@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-106-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <6039311.QYNoohHPCE@kitterma-e6430> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3976608.7dGxshQr1y" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [dmarc-ietf] ARC Minimum Key Sizes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:40:54 -0000 This is a multi-part message in MIME format. --nextPart3976608.7dGxshQr1y Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Top posting since the quoting seems hopelessly confused. Here is a specific proposal (unified diff and rfcdiff attached). I liberally borrowed text from RFC 6376 to minimize the novelty of the proposal. The ARC draft already references RFC 6376, section 3.6, so I don't think we need another reference specifically to 3.6.2.2 to talk about how to concatenate TXT strings. I did not attempt to cover algorithm agility or define an additional algorithm beyond SHA 256. Whatever the next algorithm is, I think it needs to apply to both DKIM and ARC, so it's out of scope. I think the issues associated with ARC chains using different algorithms should be addressed, but I'm hoping the clearer proposal that John Levine mentioned[1] will address that. Scott K [1] On Saturday, January 21, 2017 08:09:59 PM Brandon Long wrote: > On Jan 20, 2017 4:08 PM, "Peter Goldstein" wrote: > > I think Scott's point about operational options is well taken. Google ran > into some operational issues with some DNS vendors when they attempted to > make all new G Suite DKIM keys 2048 - they rolled back to making 2048 bit > keys the default, but allowing 1024 bit keys as an option. > > > Yeah, it turns out virtually all DNS registrars with website editors fail > to handle long TXT records as of about 6 months ago. > > Brandon > > > The MUST/SHOULD language suggested makes sense. And we definitely don't > need to roll out new protocols using SHA-1. > > I would suggest some related language for verifiers. Something like what's > found in the DKIM spec, but with updated bit sizes: > > Verifiers MUST be able to validate signatures with > keys ranging from 1024 bits to 4096 bits, and they MAY be able to > validate signatures with larger keys. > > At a minimum I think we should require verifiers to be able to support 4096 > bit keys (and potentially 8192 bit). There's no reason verifiers shouldn't > be able to support longer key sizes, and this adds some future proofing to > the specification. > > Best, > > Peter > > On Fri, Jan 20, 2017 at 3:41 PM, Scott Kitterman > > wrote: > > On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote: > > > On Friday, January 20, 2017 you wrote: > > > > On 01/20/2017 11:23, Scott Kitterman wrote: > > > > > I'm not on the ARC list, so I'll pile on this thread here... > > > > > > > > This is the right place for anything constructive regarding the > > > > specification, so no problem regarding any other lists. > > > > > > > > > I understand the minimum key size in the draft is 512 bits. I'm not > > > > > planning > > > > > on releasing any software that supports key sizes less than 1024, so > > > > I > > > > > > > guarantee you interoperability problems for small keys. > > > > > > > > +1 -- no need for weak keys. > > > > > > > > 1) Do we have a normative reference within the RFC framework for key > > > > lengths for different crypto systems, and can we simply invoke that > > > > reference rather than including a hard figure in this spec? > > > > > > > > 2) Does such a reference still consider 1k keys as acceptable at this > > > > time? Is there a schedule for periodic review? > > > > > > > > --S. > > > > > > > > +++1 wrt Scott's comment about 512 bit keys. We inherit this > > > > requirement > > > > > > from the DKIM spec, but imho it is not reasonable. If this is worth > > > > discussing, perhaps we should move it to another thread? > > > > > > > > Regards, > > > > =Gene > > > > > > OK, Since I wasn't off topic after all, here's a new thread... > > > > > > I believe we've looked for such a reference before and not found a good > > > > one. > > > > > The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766 > > > > > > Operationally, 1024 is the minimum key size recommendation I generally > > > > see > > > > > for DKIM today. NIST recommends 2048 bits, SHA-256 only for US > > > goverment > > > use [1]. > > > > > > > > > Scott K > > > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. > > > > SP.800-177.pdf > > > > Moving John Levine's reply into this thread and then replying further: > > > > On Friday, January 20, 2017 10:17:02 PM John Levine wrote: > > > >1) Do we have a normative reference within the RFC framework for key > > > >lengths for different crypto systems, and can we simply invoke that > > > >reference rather than including a hard figure in this spec? > > > > > > There's RFC 3766, but it's over a decade old and has rules for how to > > > figure out how long a key you need, not the actual sizes. > > > > > > This NIST publication seems relevant: > > > > > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. > > > > SP.800-57pt1r4.pdf > > > > > The tables on pages 52 and 53 suggest that we use 2K keys and sha256 > > > > hashes. > > > > > >2) Does such a reference still consider 1k keys as acceptable at this > > > >time? Is there a schedule for periodic review? > > > > > > No. See the document. > > > > > > R's, > > > John > > > > Large keys like 2048 present other potential operational problems. Here's > > a > > 2048 bit, sha-256 key record: > > > > default._domainkey IN TXT ( "v=DKIM1; h=sha-256; k=rsa; " > > > > "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4Q > > > > DoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57 > > F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjR > > CJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y" > > > > "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102H > > > > P1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0 > > bz7cTwVX4QvP/8MUQIDAQAB" > > ) > > > > I'm sure that will get line wrapped into illegibility, so I'll make the > > actual > > point: It's longer than will fit in a single TXT string. While there is > > nothing wrong with that from a DNS standards or even a core DNS > > operational > > perspective, it is not rare that DNS provisioning systems don't support > > this. > > I don't want to make it so secure it's deployability is severely hampered. > > > > I would suggest MUST at least 1024 bit, SHOULD 2048 bits. I think MUST > > sha-256 is also a good idea. Approximately the last thing we should be > > doing > > now is rolling out new protocols using sha-1. > > > > Scott K > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc --nextPart3976608.7dGxshQr1y Content-Disposition: attachment; filename="arc.new-from-old.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="arc.new-from-old.diff.html" Diff: arc.old - arc.new
 arc.old   arc.new 
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Description of the New Header Fields . . . . . . . . . . 6 5.1. Description of the New Header Fields . . . . . . . . . . 6
5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9
5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10
5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 11 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 11
5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12 5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12
5.3. Key Management and Binding . . . . . . . . . . . . . . . 12 5.3. Key Management and Binding . . . . . . . . . . . . . . . 12
5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12
5.3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . 13
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Relationship between DKIM Signatures and ARC Headers . . 13 6.2. Relationship between DKIM Signatures and ARC Headers . . 13
6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13
6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13
6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13
6.4.2. Responding to ARC Validity Violations . . . . . . . . 14 6.4.2. Responding to ARC Validity Violations . . . . . . . . 14
6.4.3. Recording the Results of ARC Evaluation . . . . . . . 14 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 14
6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14
6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14 6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14
skipping to change at page 6, line 50 skipping to change at page 6, line 50
The ARC-Seal header field includes a digital signature of all The ARC-Seal header field includes a digital signature of all
preceding ARC message header fields on the message. preceding ARC message header fields on the message.
5.1.1.1. Tags in the ARC-Seal Header Field Value 5.1.1.1. Tags in the ARC-Seal Header Field Value
The following tags are the only supported tags for an ARC-Seal field. The following tags are the only supported tags for an ARC-Seal field.
All of them MUST be present. Unknown tags MUST be ignored and do not All of them MUST be present. Unknown tags MUST be ignored and do not
affect the validity of the header. affect the validity of the header.
o a = hash algorithm; syntax is the same as the "a=" tag defined in o a = hash algorithm; syntax is the same as the "a=" tag defined in
Section 3.5 of [RFC6376]; Section 3.5 of [RFC6376], but only the only valid algorithm is
currently defined for ARC is "rsa-sha256";
o b = digital signature; syntax is the same as the "b=" tag defined o b = digital signature; syntax is the same as the "b=" tag defined
in Section 3.5 of [RFC6376]; in Section 3.5 of [RFC6376];
o cv = chain validation status: valid values: o cv = chain validation status: valid values:
* 'none' = no pre-existing chain; * 'none' = no pre-existing chain;
* 'fail' = the chain as received does not validate; or * 'fail' = the chain as received does not validate; or
skipping to change at page 13, line 9 skipping to change at page 13, line 9
5.3.1. Namespace 5.3.1. Namespace
All ARC-related keys are stored in the same namespace as DKIM keys All ARC-related keys are stored in the same namespace as DKIM keys
[RFC6376]: "_domainkey" specifically by adding the "._domainkey" [RFC6376]: "_domainkey" specifically by adding the "._domainkey"
suffix to the name of the key (the "selector"). For example, given suffix to the name of the key (the "selector"). For example, given
an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of
"example.com" and an "s=" value of "foo.bar", the DNS query seeking "example.com" and an "s=" value of "foo.bar", the DNS query seeking
the public key will a query at the name the public key will a query at the name
"foo.bar._domainkey.example.com". "foo.bar._domainkey.example.com".
5.3.2. Key Sizes
Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits. Verifiers
MUST be able to validate signatures with keys ranging from 1024 bits to 4096
bits, and they MAY be able to validate signatures with larger keys. Verifier
policies may use the length of the signing key as one metric for determining
whether a signature is acceptable.
Factors that should influence the key size choice include the
following:
o The practical constraint that large (e.g., 4096-bit) keys might
not fit within a 512-byte DNS UDP response packet
o Larger keys impose higher CPU costs to verify and sign email
o Keys can be replaced on a regular basis; thus, their lifetime can
be relatively short
o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes.
6. Usage 6. Usage
For a more thorough treatment of the recommended usage of the ARC For a more thorough treatment of the recommended usage of the ARC
header fields for both intermediaries and end receivers, please header fields for both intermediaries and end receivers, please
consult [ARC-USAGE]. consult [ARC-USAGE].
6.1. Participation 6.1. Participation
The inclusion of additional ARC sets is to be done whenever a trust The inclusion of additional ARC sets is to be done whenever a trust
boundary is crossed, and especially when prior DKIM-Signatures might boundary is crossed, and especially when prior DKIM-Signatures might
skipping to change at page 23, line 5 skipping to change at page 23, line 5
Andersen, "Interoperability Issues Between DMARC and Andersen, "Interoperability Issues Between DMARC and
Indirect Email Flows", June 2016, Indirect Email Flows", June 2016,
<https://tools.ietf.org/html/draft-ietf-dmarc- <https://tools.ietf.org/html/draft-ietf-dmarc-
interoperability-17>. interoperability-17>.
[ENHANCED-STATUS] [ENHANCED-STATUS]
"IANA SMTP Enhanced Status Codes", n.d., "IANA SMTP Enhanced Status Codes", n.d.,
<http://www.iana.org/assignments/smtp-enhanced-status- <http://www.iana.org/assignments/smtp-enhanced-status-
codes/smtp-enhanced-status-codes.xhtml>. codes/smtp-enhanced-status-codes.xhtml>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
 End of changes. 4 change blocks. 
1 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart3976608.7dGxshQr1y Content-Disposition: attachment; filename="arc.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="arc.diff" --- arc.old 2017-02-03 13:13:41.096992188 -0500 +++ arc.new 2017-02-03 13:30:46.897018539 -0500 @@ -86,6 +86,7 @@ 5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12 5.3. Key Management and Binding . . . . . . . . . . . . . . . 12 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . 13 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Relationship between DKIM Signatures and ARC Headers . . 13 @@ -327,7 +328,8 @@ affect the validity of the header. o a = hash algorithm; syntax is the same as the "a=" tag defined in - Section 3.5 of [RFC6376]; + Section 3.5 of [RFC6376], but only the only valid algorithm is + currently defined for ARC is "rsa-sha256"; @@ -679,6 +681,33 @@ the public key will a query at the name "foo.bar._domainkey.example.com". +5.3.2. Key Sizes + + + Selecting appropriate key sizes is a trade-off between cost, + performance, and risk. Since short RSA keys more easily succumb to + off-line attacks, Signers MUST use RSA keys of at least 1024 bits. Verifiers + MUST be able to validate signatures with keys ranging from 1024 bits to 4096 + bits, and they MAY be able to validate signatures with larger keys. Verifier + policies may use the length of the signing key as one metric for determining + whether a signature is acceptable. + + Factors that should influence the key size choice include the + following: + + o The practical constraint that large (e.g., 4096-bit) keys might + not fit within a 512-byte DNS UDP response packet + + o Larger keys impose higher CPU costs to verify and sign email + + o Keys can be replaced on a regular basis; thus, their lifetime can + be relatively short + + o The security goals of this specification are modest compared to + typical goals of other systems that employ digital signatures + + See [RFC3766] for further discussion on selecting key sizes. + 6. Usage For a more thorough treatment of the recommended usage of the ARC @@ -1234,6 +1263,10 @@ Internet-Draft ARC-Protocol December 2016 + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, --nextPart3976608.7dGxshQr1y-- From nobody Sat Feb 4 18:07:56 2017 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 23AE312945C for ; Sat, 4 Feb 2017 18:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFpGgOQDNGWs for ; Sat, 4 Feb 2017 18:07:55 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93FF127A90 for ; Sat, 4 Feb 2017 18:07:54 -0800 (PST) Received: (qmail 64322 invoked from network); 5 Feb 2017 02:07:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 Feb 2017 02:07:53 -0000 Date: 5 Feb 2017 02:07:31 -0000 Message-ID: <20170205020731.19441.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dmarc-ietf] Changing algorithms X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list 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, 05 Feb 2017 02:07:56 -0000 As threatened, albeit kind of late, here's plan for how to rotate to a new algorithm. We note that every Arc-Seal and Arc-Message-Signature header has an a= tag that identifies the hash and signing algorithms used. (In sec 5.1.1.1 it just says hash, which is wrong.) Every DKIM key record has k= tag that says what signing algorithm the key is for. That should mean that we could publish several key records for several algorithms at the same domain and selector, except that RFC 6376 sec 3.6.2.2 says you can't. I think that's a bug in 6376, but we can fix that later. We relax the language saying that there can only be one Arc-Seal and one Arc-Message-Signature header for each i= value to say that there can be a group but they can only differ in the a=algorithm, s=selector, b=signature, and for A-M-S the bh=hash if the algorithms have different hashes. The group is valid if the recipient can verify at least one of them. The Arc-Seal signature covers all of the A-S and A-M-S headers, even ones it can't verify, and the header says cv=pass if it could verify at least one of the headers in each group. (Even if you can't verify a new algorithm, maybe the next system can.) To avoid infinite regress, we leave the instructions in 5.1.1.3 alone, so when adding new A-S headers, they're added as a group and the signatures are computed as through the b= in all of the headers in the newly added group were empty. I don't think this will add a lot of code, and it provides a straightforward upgrade path. When a system is upgraded to support a new algorithm, it starts adding headers for both the old and new algorithm. This potentially adds an extra A-S and A-M-S header at each level, but it's just linear, not exponential. When checking signatures, verifiers should try the new algorithm first in each group with multiple headers (it's a lot faster), and if so it need not check any others. Receivers can see from the ARC headers on their incoming mail how much of the mail has new signatures in addition to the old ones and who's adding them. Eventually there'll be enough new signatures that we can nudge the people still using only old ones and eventually only use the new ones. One minor weakness is that the A-S signature signs the headers in a group in whatever order they're in, and if a later system reorders them, the signature will break. We could address that by allowing sequence numbers like i=n.m where the m only affects the order in which they're signed, but I doubt it's worth it. It's hard to imagine a mail system that would only reorder the headers and not also break the signatures in other ways. R's, John From nobody Tue Feb 7 16:22:51 2017 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 F19FC1296E1 for ; Tue, 7 Feb 2017 16:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnoOKmw5Bf25 for ; Tue, 7 Feb 2017 16:22:47 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482B61296EA for ; Tue, 7 Feb 2017 16:22:46 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id w194so40769963ybe.0 for ; Tue, 07 Feb 2017 16:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EHCAmbZncxyqiHNCt7e5dWUq0un45/5fVA9Z6OZfCe4=; b=PMTMxBDYcPcVNmMxq2PMYSJD49LJM21hLUL0tvjXNe1sUCsy7LWdTqXM/1/PIq88s7 Ds2w+EYQ3HvzVkW3Z2nlxlHueYoIW6gWwQc1WjcFRXpnHH+fuYTMgAPMfJXtZ9I8f4dV F4vf3btyj8nxWOxyWa/ofChA8Jnzzpw1iQnayy+BAi7O+5NBaT/D9QL6HYxMloch5rOC iLv0+khzK/ZEEdBL9NpaYhZC8jLeSdit5R/zQTlx5BbYl9Ez1prStp2kYHUJK0F/ScYu /c4M3kkTcDNWCO6tCrhyS7tPn+Df6dfAP0KSH10vNHcbAFU6d/CznhqTQEzDPBv29rLy 3dxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EHCAmbZncxyqiHNCt7e5dWUq0un45/5fVA9Z6OZfCe4=; b=CVcf8+9G2HcUjvm8Mkof0DyRPgZ4wQi9gQqGtY+1dlfDf1xoewkQbkWya43/awY6Ar g9fpiUtYZNCQNS3F3VnsKypW4VE5XtCx+l5yF7MZU3syLyGxcx90rbuYIOUGa533qpcV ZwnSageizSjZmxS/lXRX0JXKQ9//NIVshmnLuhpcAf3oSHISOx5GVRTnIR/R9uxXjRhj nVsh27RoVU+ErgqKY4bAM0XpRb7FEP61LbR6Ofo+8IrrYorWKud0HB38MOI5Hx6xQJM/ mldBB9jVbWk6EJKUWJmEmSZzrghdD87usbSmnMVALjhTTcw2ar/hl6sD+9kv7bTDNgGS 7vpg== X-Gm-Message-State: AMke39n8ZCai3NC0nrrEPxBGSbgnGtGOh8DIa5r2R9tea32MwoOw8bC8wV3YDYNjMZe6VT3DeuYowM0h76FcLBy0 X-Received: by 10.37.178.39 with SMTP id i39mr12679358ybj.146.1486513365436; Tue, 07 Feb 2017 16:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.6.69 with HTTP; Tue, 7 Feb 2017 16:22:43 -0800 (PST) In-Reply-To: References: From: Brandon Long Date: Tue, 7 Feb 2017 16:22:43 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=f403045f42921a73040547f9ddcd Archived-At: Cc: "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] invalid ARC chains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 00:22:50 -0000 --f403045f42921a73040547f9ddcd Content-Type: text/plain; charset=UTF-8 On Mon, Jan 30, 2017 at 2:59 PM, Kurt Andersen wrote: > On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman wrote: > >> Extricating this discussion from the one about key sizes. We left off >> at discussing whether we should implement something like a cv=invalid >> for arc chains that are no longer well defined. >> >> Brandon, I think you had the last response, and suggested that >> receivers just refuse to continue to process invalid chains? This >> seems plausible, and might be simpler. I have no strong opinions one >> way or the other, although I think I slightly prefer the cv=invalid >> state, as it strictly defines what receivers are to do with invalid >> chains. >> >> Regardless, I still stand by the fact that section 5.2.1 needs to go & >> that we should probably explicitly codify what constitutes an invalid >> arc chain. >> > > I don't think that 5.2.1 needs to be deleted, just significantly > refactored (which I plan to do next weekend). > > I think that having a participating receiver mark an chain as "broken > beyond repair" (aka = invalid) is a beneficial terminal state beyond which > no other mediators should perform any further ARC machinations. It's > certainly possible that a malicious mediator could essentially break every > ARC chain that it sees, but that's no different than what can happen today > and also is a situation that we are not trying to solve. > One challenge is how to specify that a chain is cv=invalid. It implies being able to sign an invalid chain. Brandon --f403045f42921a73040547f9ddcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 30, 2017 at 2:59 PM, Kurt Andersen <kandersen@linkedi= n.com> wrote:
= On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman <gene@valimail.com> wrote:
Extricating this discussion = from the one about key sizes.=C2=A0 We left off
at discussing whether we should implement something like a cv=3Dinvalid
for arc chains that are no longer well defined.

Brandon, I think you had the last response, and suggested that
receivers just refuse to continue to process invalid chains?=C2=A0 This
seems plausible, and might be simpler.=C2=A0 I have no strong opinions one<= br> way or the other, although I think I slightly prefer the cv=3Dinvalid
state, as it strictly defines what receivers are to do with invalid
chains.

Regardless, I still stand by the fact that section 5.2.1 needs to go &<= br> that we should probably explicitly codify what constitutes an invalid
arc chain.

I don't think tha= t 5.2.1 needs to be deleted, just significantly refactored (which I plan to= do next weekend).=C2=A0

I think that having a par= ticipating receiver mark an chain as "broken beyond repair" (aka = =3D invalid) is a beneficial terminal state beyond which no other mediators= should perform any further ARC machinations. It's certainly possible t= hat a malicious mediator could essentially break every ARC chain that it se= es, but that's no different than what can happen today and also is a si= tuation that we are not trying to solve.

One challenge is how to specify that a chain is cv=3D= invalid.=C2=A0 It implies being able to sign an invalid chain.
Brandon=C2=A0
--f403045f42921a73040547f9ddcd-- From jrideout@agari.com Wed Feb 8 09:29:12 2017 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 72F75129CBD for ; Wed, 8 Feb 2017 09:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBTErXYfFPvR for ; Wed, 8 Feb 2017 09:29:10 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691E7129CC3 for ; Wed, 8 Feb 2017 09:29:10 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 35so114670442uak.1 for ; Wed, 08 Feb 2017 09:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kYk1wJu1+8IOyLWVoeZZNM/zCx1NQogunziyzAuCluk=; b=DcJ+UBD7zmQudyTGe8AoH2t9CuHiWgva0yDAZucZRnWfNbIPjJLe0D0VLsyTh3BOL7 C6GRjDn6eZfnY0/BqwChN7ZIcqQUXPFqkKFy/i6CgVLp3OuFVZvZXam5PlwMDaypvYOf xcTVzn7kQhgIiY2ebSIGDpheK/p/nv7LqLvBs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kYk1wJu1+8IOyLWVoeZZNM/zCx1NQogunziyzAuCluk=; b=Fnrv7nFUKi1HnohByDoEIIXn6nziXEtmO9ma3Wvc/LroCjZOKlzAyc3Wf1kvnxU0kl T/DOkytGVndHMTHc28qC6plj5iHeRJ0LDKHhb+wY+kEidKurfxgQRk7vDP2x6ksnn9mS 1/U5cwcQ6/nsjdgmlg4oCKFLW9/W9q3/qK9DZspdeBsD5C4qF2qE7Zg3PaRQ0vtYiP38 vKd6UVi7gDsynLlhNsTXwVtNjVbzQ6KCgaGPUJ5dZQnHEcDhRzz0rkE+rwCAQT+7jcmh i4w+H2KxAyg3Vis6wZ/o4Yndr3Osa1QWbqd4tY9dh7hioyCIEUQKhvJZsVOYG6Abcmbc KYOQ== X-Gm-Message-State: AIkVDXL1QXAX/tf3BFwF7w9QiAObsDUy6gYP5bvYNO3xwjIFLPnyvlYcnNMgj2HtavKtfOHIUpC9VWzyZC/3hoTd X-Received: by 10.176.82.130 with SMTP id v2mr11282689uav.62.1486574949418; Wed, 08 Feb 2017 09:29:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.56.140 with HTTP; Wed, 8 Feb 2017 09:28:49 -0800 (PST) In-Reply-To: References: From: Jacob Rideout Date: Wed, 8 Feb 2017 12:28:49 -0500 Message-ID: To: Brandon Long Content-Type: multipart/alternative; boundary=94eb2c18fe0ccb4db1054808331d Archived-At: X-Mailman-Approved-At: Wed, 08 Feb 2017 09:38:43 -0800 Cc: "dmarc@ietf.org" , Kurt Andersen , Gene Shuman Subject: Re: [dmarc-ietf] invalid ARC chains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 17:30:18 -0000 --94eb2c18fe0ccb4db1054808331d Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 7:22 PM, Brandon Long wrote: > > On Mon, Jan 30, 2017 at 2:59 PM, Kurt Andersen > wrote: > >> On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman wrote: >> >>> Extricating this discussion from the one about key sizes. We left off >>> at discussing whether we should implement something like a cv=invalid >>> for arc chains that are no longer well defined. >>> >>> Brandon, I think you had the last response, and suggested that >>> receivers just refuse to continue to process invalid chains? This >>> seems plausible, and might be simpler. I have no strong opinions one >>> way or the other, although I think I slightly prefer the cv=invalid >>> state, as it strictly defines what receivers are to do with invalid >>> chains. >>> >>> Regardless, I still stand by the fact that section 5.2.1 needs to go & >>> that we should probably explicitly codify what constitutes an invalid >>> arc chain. >>> >> >> I don't think that 5.2.1 needs to be deleted, just significantly >> refactored (which I plan to do next weekend). >> >> I think that having a participating receiver mark an chain as "broken >> beyond repair" (aka = invalid) is a beneficial terminal state beyond which >> no other mediators should perform any further ARC machinations. It's >> certainly possible that a malicious mediator could essentially break every >> ARC chain that it sees, but that's no different than what can happen today >> and also is a situation that we are not trying to solve. >> > > One challenge is how to specify that a chain is cv=invalid. It implies > being able to sign an invalid chain. > What is expected workflow in this case? Say I'm alumni-forwarder.edu, and I receive a message with an ARC set (and for the sake of this example, these are forgeries). After checking the signitures, I consider the ARC set to be invalid. Section 6.4.2 suggests I inform the sender of a message integrity failure. However, presume (given no other abuse or spam signals) I want to forward all the mail receive on and ARC failure alone is an insufficent reason to stop my forwarding. How do I proceed? Stip the existing ARC set and start over with i=1 ? Set cv=fail? A downstream receiver still might want to trust the [ARC-]Authentication-Results appended by alumni-forwarder.edu, but I think currently would be advised against it in the case of cv=fail. - Jacob --94eb2c18fe0ccb4db1054808331d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 7, 2017 at 7:22 PM, Brandon Long <blong@google.com> w= rote:
O= n Mon, Jan 30, 2017 at 2:59 PM, Kurt Andersen <kandersen@linkedin.com= > wrote:
On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman <gene@valimail.com>= ; wrote:
Extric= ating this discussion from the one about key sizes.=C2=A0 We left off
at discussing whether we should implement something like a cv=3Dinvalid
for arc chains that are no longer well defined.

Brandon, I think you had the last response, and suggested that
receivers just refuse to continue to process invalid chains?=C2=A0 This
seems plausible, and might be simpler.=C2=A0 I have no strong opinions one<= br> way or the other, although I think I slightly prefer the cv=3Dinvalid
state, as it strictly defines what receivers are to do with invalid
chains.

Regardless, I still stand by the fact that section 5.2.1 needs to go &<= br> that we should probably explicitly codify what constitutes an invalid
arc chain.

I don't think tha= t 5.2.1 needs to be deleted, just significantly refactored (which I plan to= do next weekend).=C2=A0

I think that having a par= ticipating receiver mark an chain as "broken beyond repair" (aka = =3D invalid) is a beneficial terminal state beyond which no other mediators= should perform any further ARC machinations. It's certainly possible t= hat a malicious mediator could essentially break every ARC chain that it se= es, but that's no different than what can happen today and also is a si= tuation that we are not trying to solve.

One challenge is how to specify that a chain i= s cv=3Dinvalid.=C2=A0 It implies being able to sign an invalid chain.
=

What is expected workflo= w in this case?

Say I'm alumni-forwarder.edu, and I receive a message with an= ARC set (and for the sake of this example, these are forgeries). After che= cking the signitures, I consider the ARC set to be invalid. Section 6.4.2 s= uggests I inform the sender of a=C2=A0message integrity failure. However, presume (given no other= abuse or spam signals) I want to forward all the mail receive on and ARC f= ailure alone is an insufficent reason to stop my forwarding.

How do I proceed? S= tip the existing ARC set and start over with i=3D1 ?=C2=A0 Set cv=3Dfail?

A downstream receiver still might want to trust the [ARC-]Authentication-Results appended by=C2= =A0alumni-forwarder.edu,= but I think currently would be advised against it in the case of cv=3Dfail= .

- Jacob
--94eb2c18fe0ccb4db1054808331d-- From nobody Wed Feb 8 10:59:35 2017 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 33965129BAE for ; Wed, 8 Feb 2017 10:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=aqBZJWYM; dkim=pass (1024-bit key) header.d=linkedin.com header.b=Y9aszP48 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld7DM2QLecUg for ; Wed, 8 Feb 2017 10:59:31 -0800 (PST) Received: from mail521.linkedin.com (mail521.linkedin.com [108.174.6.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D393B129D89 for ; Wed, 8 Feb 2017 10:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1486580369; bh=yvI35Hoz0GtVfqWBzGAA1f1WUSuQmD+vD/Lm1Z2OW5k=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=aqBZJWYMJ+4/UgtQQZp2H1c6JDXvwzTXu6pJ/EBhQCSmX0/wT9vIMJottg2QMLovT y/pYvUrvn+HN3Q5/fl9LILqB9BFak00Mq6aJdgUolDHD6G2dJJH4wJEOPe40Nv/bfy 6Y2BOE0n8SOe7Wbs/1UBrXWnJ7/Wki8QCl8kSAd4= Authentication-Results: mail521.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail521.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:400d:c09::247"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="mail-qk0-x247.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:400d:c09::247] ([2607:f8b0:400d:c09::247.38766] helo=mail-qk0-x247.google.com) by mail521.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 11/32-04459-19A6B985; Wed, 08 Feb 2017 18:59:29 +0000 Received: by mail-qk0-x247.google.com with SMTP id s186so104039291qkb.5 for ; Wed, 08 Feb 2017 10:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yvI35Hoz0GtVfqWBzGAA1f1WUSuQmD+vD/Lm1Z2OW5k=; b=Y9aszP48dAkOrk1BqyDIpbtVmGCgFJDY/iXQL/8pKFzdgysts++WHX7fEE9A3cmPM/ jsC6prS2T8YTggADJvz0dIFHgd0dBfOkQC1MpPdn4xll6IqFwxkQM+sX9ghU/jisnG69 zwKzqIp0gHvdPNYhnrUjwoJoZooGjmRCQThgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yvI35Hoz0GtVfqWBzGAA1f1WUSuQmD+vD/Lm1Z2OW5k=; b=FJVPr9jgn06uEd/Vzv/haUWomJ4CzKvvDbFIZtn37w/gm+9XTRdaBjV8+E5kqsL79q y52prd3b2MCRDlLDOGS6Eok8u96revwUOlwIZSQdllkh3wekK/PWKES3QIATyT3nup7f lCzwCWorUCHMjKXheb/yU7f0iuM2MT6o53JjB/VrAc9zZdYpZrkjBjjuxXaIVFrQy1sI X/11Z348tnlGP5CCxrdAnGMox81ZddggDvxy0RtW4C0LdmeI9aqsPF/UEqcTGv8yK9GY 1/3rLVuRMgIMAhn4Ha9GEOKVlaJPapXgCBwbP/RlZQt5aWX4EDDlKrVHNmcfYbZ7Hc+C 50+g== X-Gm-Message-State: AMke39k5keULx0weF8olAqRXxFSm7x29YUOiJKD2ByM9yozhL2Ou/b2345fdyqTAECSyRQqgEW1rqIjPa2V1aMOcYiNYjEQ4E0T1cZf1Ud1h/2TlwiRop5RO8P136vUdIJGOsVXOhPsvS5XUwtOd7BjCyvX9 X-Received: by 10.55.81.136 with SMTP id f130mr21568673qkb.75.1486580369104; Wed, 08 Feb 2017 10:59:29 -0800 (PST) X-Received: by 10.55.81.136 with SMTP id f130mr21568649qkb.75.1486580368810; Wed, 08 Feb 2017 10:59:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.75.136 with HTTP; Wed, 8 Feb 2017 10:59:28 -0800 (PST) In-Reply-To: References: From: Kurt Andersen Date: Wed, 8 Feb 2017 10:59:28 -0800 Message-ID: To: Jacob Rideout Content-Type: multipart/alternative; boundary=001a114a6fa0d066ad0548097668 Archived-At: Cc: Brandon Long , "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] invalid ARC chains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:59:33 -0000 --001a114a6fa0d066ad0548097668 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 8, 2017 at 9:28 AM, Jacob Rideout wrote: > > What is expected workflow in this case? > > Say I'm alumni-forwarder.edu, and I receive a message with an ARC set > (and for the sake of this example, these are forgeries). After checking the > signitures, I consider the ARC set to be invalid. Section 6.4.2 suggests I > inform the sender of a message integrity failure. However, presume (given > no other abuse or spam signals) I want to forward all the mail receive on > and ARC failure alone is an insufficent reason to stop my forwarding. > > How do I proceed? Stip the existing ARC set and start over with i=1 ? Set > cv=fail? > > A downstream receiver still might want to trust the [ARC-]Authentication-Results > appended by alumni-forwarder.edu, but I think currently would be advised > against it in the case of cv=fail. > > - Jacob > This question is exactly what we are discussing. There is no one else to define what "should" be done. What do *you* think should be done? --Kurt --001a114a6fa0d066ad0548097668 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 8, 2017 at 9:28 AM, Jacob Rideout <jrideout@agari.com> wrote:

What is = expected workflow in this case?

Say I&#= 39;m alumni-forwa= rder.edu, and I receive a message with an ARC set (and for the sake of = this example, these are forgeries). After checking the signitures, I consid= er the ARC set to be invalid. Section 6.4.2 suggests I inform the sender of= a=C2=A0message integr= ity failure. However, presume (given no other abuse or spam signals) I want= to forward all the mail receive on and ARC failure alone is an insufficent= reason to stop my forwarding.

How do I proceed? Stip the existing ARC set and s= tart over with i=3D1 ?=C2=A0 Set cv=3Dfail?

A downstream receiver still m= ight want to trust the [ARC-]Authentication-Results appended by=C2=A0alumni-forwarder.edu, but I think c= urrently would be advised against it in the case of cv=3Dfail.

- Jacob

This question is ex= actly what we are discussing. There is no one else to define what "sho= uld" be done. What do *you* think should be done?

--Kurt
--001a114a6fa0d066ad0548097668-- From nobody Thu Feb 9 15:37:18 2017 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 643BB129D30 for ; Thu, 9 Feb 2017 15:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp912JLe0UtT for ; Thu, 9 Feb 2017 15:37:11 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BEB129D23 for ; Thu, 9 Feb 2017 15:37:11 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u68so11949345ywg.0 for ; Thu, 09 Feb 2017 15:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=waiyEJfr4NqioWezElOPkyTPut+4S2VvulM/8a86JqI=; b=AHh1/pzIqDckUF2drXCaaSUgBqPFjSsxE0nR4TWqcZfOP693c2lVAkud1cNToU4lYa HfWw+Z+whoMO5t/xR8d9X/9ZO+U1GWovUsw1gTAB4U606DDmjcKiTCjsI8uWPKWDy7CX 5SsmIDtZzVUucL2AFqFNijaa17VYIqmAlznnUrzdG2EOI/VR2vr588aATRNPJhCCGy3V nxArJ0PXDOsanN8eEny05C4w/r/0o5nB4DNb9nmxZ0Ll5htZk7BymJlAmZa72a8qtSCx le0n3nFVCC29OBOp7SNF9BcaYkj/r8B1DKmz0R4zDSLpeKmtzg7t8HAqG4f+DQxiuv2V +GRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=waiyEJfr4NqioWezElOPkyTPut+4S2VvulM/8a86JqI=; b=L8u1sPy7Q8Qko8BXZJu48oyPkf1qWPnMz+7GKEZanNJ7lZ6eittkAdtUOOUuUIcArN q2hw54yLpu3S3e+tuvm/u+rxULPqfq1d4RBFNgm0Q2bWTzojIKadCvI+L9rEq1Tef5jU 0nUbpiINUZ4RRZIm3wGjN4vEIJwWK7kvYTxCnWILTN9y7yl/RQWiegTdzkogEiZRifoW lo6LvbtQC3xiAQDFqnX0NpQ/mDe0RIBoQf8twCeebDLlhgk4nqcYNhgD3wpNCgR9gK2u MpY32W1wXFRScY6h0jKmE4xBoj4nprGiB8RlwyKSTIYzkCNrMe9qmiO6MxCNhI7Nc93n r96A== X-Gm-Message-State: AMke39la7kOJW8ASWiMQVTvsG0pFS/1Pq3RU4dgeFjdmLbtZ8GstFm6uxdaLDAhwV0rp0Glydyb8MwA1TIVovh2E X-Received: by 10.129.141.68 with SMTP id w4mr4349476ywj.269.1486683430093; Thu, 09 Feb 2017 15:37:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.6.69 with HTTP; Thu, 9 Feb 2017 15:37:09 -0800 (PST) In-Reply-To: References: From: Brandon Long Date: Thu, 9 Feb 2017 15:37:09 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=f403045ef410bf329a05482175cc Archived-At: Cc: Jacob Rideout , "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] invalid ARC chains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:37:16 -0000 --f403045ef410bf329a05482175cc Content-Type: text/plain; charset=UTF-8 I see three options at first glance. 1) An invalid chain can not be signed, therefore it is left intact and the chain can not be continued. Anyone receiving the chain should be able to notice it's invalid as well. We could add another value in 6.4.3 for the local Authentication-Results header. 2) We define some mechanism to sign headers even if the chain is invalid, thus allowing a chain to continue with a cv=invalid statement. 3) We specify that a forwarder should remove all of the arc-* headers associated with invalid chains. I think fully specifying all the invalid cases for #2 is going to be challenging, and will be the source of errors in implementations, and I don't think the end result is likely to be worth it. I'm leary of removing the headers and therefore the information in #3. Based on the final copy of the mail, one wouldn't be able to know that the arc chain was removed or why. I guess one could rename all of the headers instead, ie arc-signature to invalid-arc-signature or something. So, I'm leaning to #1 myself. Brandon On Wed, Feb 8, 2017 at 10:59 AM, Kurt Andersen wrote: > On Wed, Feb 8, 2017 at 9:28 AM, Jacob Rideout wrote: > >> >> What is expected workflow in this case? >> >> Say I'm alumni-forwarder.edu, and I receive a message with an ARC set >> (and for the sake of this example, these are forgeries). After checking the >> signitures, I consider the ARC set to be invalid. Section 6.4.2 suggests I >> inform the sender of a message integrity failure. However, presume >> (given no other abuse or spam signals) I want to forward all the mail >> receive on and ARC failure alone is an insufficent reason to stop my >> forwarding. >> >> How do I proceed? Stip the existing ARC set and start over with i=1 ? >> Set cv=fail? >> >> A downstream receiver still might want to trust the [ARC-]Authentication-Results >> appended by alumni-forwarder.edu, but I think currently would be advised >> against it in the case of cv=fail. >> >> - Jacob >> > > This question is exactly what we are discussing. There is no one else to > define what "should" be done. What do *you* think should be done? > > --Kurt > --f403045ef410bf329a05482175cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see three options at first glance.

1)= An invalid chain can not be signed, therefore it is left intact and the ch= ain can not be continued.=C2=A0 Anyone receiving the chain should be able t= o notice it's invalid as well.=C2=A0 We could add another value in 6.4.= 3 for the local Authentication-Results header.

2) = We define some mechanism to sign headers even if the chain is invalid, thus= allowing a chain to continue with a cv=3Dinvalid statement.

=
3) We specify that a forwarder should remove all of the arc-* he= aders associated with invalid chains.

I think full= y specifying all the invalid cases for #2 is going to be challenging, and w= ill be the source of errors in implementations, and I don't think the e= nd result is likely to be worth it.

I'm leary = of removing the headers and therefore the information in #3.=C2=A0 Based on= the final copy of the mail, one wouldn't be able to know that the arc = chain was removed or why.=C2=A0 I guess one could rename all of the headers= instead, ie arc-signature to invalid-arc-signature or something.

So, I'm leaning to #1 myself.

Brandon

On Wed, F= eb 8, 2017 at 10:59 AM, Kurt Andersen <kandersen@linkedin.com>= wrote:
On Wed, Feb 8= , 2017 at 9:28 AM, Jacob Rideout <jrideout@agari.com> wrote= :

What is expected workflow in= this case?

Say I'm alumni-forwarder.edu, and I = receive a message with an ARC set (and for the sake of this example, these = are forgeries). After checking the signitures, I consider the ARC set to be= invalid. Section 6.4.2 suggests I inform the sender of a=C2=A0message integrity failure. Howeve= r, presume (given no other abuse or spam signals) I want to forward all the= mail receive on and ARC failure alone is an insufficent reason to stop my = forwarding.

How do I proceed? Stip the existing ARC set and start over with i=3D= 1 ?=C2=A0 Set cv=3Dfail?

A downstream receiver still might want to trust = the [ARC= -]Authenticatio= n-Results appended by=C2=A0alumni-forwarder.edu, but I think currently would be a= dvised against it in the case of cv=3Dfail.

- Jacob
=

This questio= n is exactly what we are discussing. There is no one else to define what &q= uot;should" be done. What do *you* think should be done?

--Kurt

--f403045ef410bf329a05482175cc-- From nobody Mon Feb 20 21:44:11 2017 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 CB734129685 for ; Mon, 20 Feb 2017 21:44:09 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H94KFKZEqpAK for ; Mon, 20 Feb 2017 21:44:08 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F718129686 for ; Mon, 20 Feb 2017 21:44:08 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id a123so28464463pgc.0 for ; Mon, 20 Feb 2017 21:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=OmfqaTe7I53JNmfOY4PQOsOBTNtrUsWgDoQT99XLjnw=; b=i0R9j0OJsW/SQqe9WSPRovtHvoY3bZUdaPY+yvU1oUyZDH4l7WZE5w/iA4NtsUFNCt 3rbU7poD/3RDFYN9gnsgnw7Kma+jjaamIYTq4FbqFd/TFVvIe+K0AuN0jgo6JpxizrBf aEym1LQtfAlzNNragnqAIEKxcFdGO87WnEsvc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=OmfqaTe7I53JNmfOY4PQOsOBTNtrUsWgDoQT99XLjnw=; b=VSGUy1yla0WE1RM3HIcFPiFP5FHXC2Jfj6ay2bNS+BRYqJ18w0IffTh45pRUJ1OiHJ UjJ3hbkyrMVZeqG55Wr+Yar9qur5hrJnKO7uDfWy+kRRBSDhj88TmUV5WzN8vX4XmQxg 7gFarh3Oi09VPiNEM7VsNP/vpKb8mRK3uGFv4MgbvxxVRXI+pjmD0pSMmYGyrz+K7hoo H/myK82IO+OEXUlDnuojjrJDOmMq6dlvSAbEFZEcBC4zhbe0NXtqCUrWM0RZ3UXVERHv oa15LVoEfWBA6s7GMjb6xhslAfmfEUIQSMHx9yP4c9QoPrgdewaF5ncjJOQ5M9oUR5NL 5IBQ== X-Gm-Message-State: AMke39lMYM1v8x384oG+9GTdNqclllIKAjzER5KoUJYF0uQkB8tTMHiV4Gb/B9gFWAE1hw== X-Received: by 10.84.211.106 with SMTP id b97mr37488128pli.16.1487655847626; Mon, 20 Feb 2017 21:44:07 -0800 (PST) Received: from [192.168.1.207] (99-8-184-121.lightspeed.snfcca.sbcglobal.net. [99.8.184.121]) by smtp.gmail.com with ESMTPSA id t22sm38029392pfa.114.2017.02.20.21.44.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Feb 2017 21:44:07 -0800 (PST) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> Date: Mon, 20 Feb 2017 21:44:04 -0800 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dmarc-ietf] looking for collaborator for Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 05:44:09 -0000 Hi all, I'm looking to collaborate with someone on the creation of the = DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter as "3. = DMARC Usage": https://datatracker.ietf.org/wg/dmarc/charter/ If you or a colleague would be interested in this work, please contact = me off list. Thanks! =3D- Tim From nobody Tue Feb 21 09:41:41 2017 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 0E6FB1294C2 for ; Tue, 21 Feb 2017 09:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IMfV1vVIhMz for ; Tue, 21 Feb 2017 09:41:37 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA16129485 for ; Tue, 21 Feb 2017 09:41:37 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id n21so50004395qta.1 for ; Tue, 21 Feb 2017 09:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tkDOcAgHYD457+zQHSbjjv0gL7ZH9vryl8rhmCl8cHI=; b=CkRZsaVmaqEp6CfQWkmMDVUUTLjXRpgb3DgBZ0G4FeTfeHJG1SVlt2Is86sLDEoy39 1rC6DL029h1M3c9aA3mStx4gJtqowQ8mRJmMUxOZ9ceZnyuRJr8rhWsW+2VOCWGLXIs+ gjFOzSH2AYVLgS/NtxiTTyIX/b52yM45rEWyoIClsV0PLpKgcOQbd2vU8U4bxLJoeI/L u8A6Xr/dkYvCqJk9Wv26ESulG6L0+jhmyoGAU3fWA8cJHs4ul6/cMJkoG1/9R5ErAEka Br5m/0quSWDckPgnmXihEHamt4MP56jMqbz/cLk4GVA9tMo9Rpd09iunARnOGcyHqbKa 6YKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tkDOcAgHYD457+zQHSbjjv0gL7ZH9vryl8rhmCl8cHI=; b=Soz7VPr4mkI8EylX1R3fgoZfrIBLnvnxFrTYQMn8lT+Zumm573NrmWT6taFRGTjCJa n2g9KkKvd3HhIjB7sJHNaxKnuN1E4SSka69lES6tz0UxREUNPSj02YhktnBu/P+I2b9l PROK7lCYwYFFCt7Z+1o1Bg9t7ZTGuoISOicnILNHdzC/lsyqp8FsCduGRwt8Q7uHQkwF LFlzIX/nptZWaf26mGpnagvResnoZCBjHvXvdvkLR9amjDJABe3itfKF7jEcrvBxw0Oi LtLUCqc6guYm88Hil67X9VCzY5Pwq6DbyMKK7UGP7X2SIrWzVp4tbLaNgKpliKqySe78 cBPA== X-Gm-Message-State: AMke39kfhdtXQ+vd5CqEqU26OTUdi88+DlV3/MDUsEtK+bcqTUZsUGUeNTuHfppzm17TJeQQ6n3Bb0mnn4dJaw== X-Received: by 10.237.32.230 with SMTP id 93mr13669823qtb.144.1487698896355; Tue, 21 Feb 2017 09:41:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.16 with HTTP; Tue, 21 Feb 2017 09:41:36 -0800 (PST) In-Reply-To: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> References: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> From: Peter Goldstein Date: Tue, 21 Feb 2017 09:41:36 -0800 Message-ID: To: Tim Draegen , dmarc Content-Type: multipart/alternative; boundary=94eb2c0c9b9c40975905490de4c1 Archived-At: Subject: Re: [dmarc-ietf] looking for collaborator for Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:41:40 -0000 --94eb2c0c9b9c40975905490de4c1 Content-Type: text/plain; charset=UTF-8 Hi Tim, Mike Jones, Thede Loder, and I have already started work on the DMARC Usage Guide. We'd love to loop you in on the process. We can coordinate off list. Best, Peter On Mon, Feb 20, 2017 at 9:44 PM, Tim Draegen wrote: > Hi all, I'm looking to collaborate with someone on the creation of the > DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter as "3. > DMARC Usage": > > https://datatracker.ietf.org/wg/dmarc/charter/ > > If you or a colleague would be interested in this work, please contact me > off list. Thanks! > =- Tim > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 <(415)%20793-5783> --94eb2c0c9b9c40975905490de4c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

Mike Jones, Thede Loder, and I = have already started work on the DMARC Usage Guide.=C2=A0 We'd love to = loop you in on the process.=C2=A0 We can coordinate off list.
Best,

Peter

On Mon, Feb 20, 2017 at 9:44 PM, T= im Draegen <tim@eudaemon.net> wrote:
Hi all, I'm looking to collaborate with someone on the creati= on of the DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter= as "3. DMARC Usage":

=C2=A0 https://datatracker.ietf.org/wg/dmarc/char= ter/

If you or a colleague would be interested in this work, please contact me o= ff list. Thanks!
=3D- Tim


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



--


3D"logo

Bringin= g Trust to Email

Pete= r Goldstein | CTO & Co-Founder

peter= @valimail.com

+1.4= 15.793.5783
=
--94eb2c0c9b9c40975905490de4c1-- From nobody Tue Feb 21 19:35:24 2017 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 5C2FB129568 for ; Tue, 21 Feb 2017 19:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w154Zd47snA0 for ; Tue, 21 Feb 2017 19:35:20 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B51129560 for ; Tue, 21 Feb 2017 19:35:20 -0800 (PST) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id F38F4C403A2; Tue, 21 Feb 2017 21:35:18 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1487734519; bh=q4XRpnOzTqMYVOkCyV84QEFOSmIpWMtbRws8u0LOQdU=; h=Date:In-Reply-To:References:Subject:To:From:From; b=Lv2ovHR8lLxqr2vu7Hxg5S8pd+iYItigxlOlYceg9U6+PGBpGEKjFiqDUFeVXsQa3 mEYuopoN2uYEDHDjqZnCx3IgdCdwx6KmV1IOjYdCgpB860R57lsINPnj/3sBD7Qczr lyZ+1VO+ISryCypR+pc956drVk1TqSFkuV8/G0ZU= Date: Wed, 22 Feb 2017 03:35:17 +0000 In-Reply-To: References: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org,Peter Goldstein From: Scott Kitterman Message-ID: <35281094-4F9C-48D2-81F2-FE4FD7ACE997@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] looking for collaborator for Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 03:35:22 -0000 Would you mind sending a link to what you have done so far? I'd like to see= if I have anything to contribute=2E Scott K On February 21, 2017 12:41:36 PM EST, Peter Goldstein wrote: >Hi Tim, > >Mike Jones, Thede Loder, and I have already started work on the DMARC >Usage >Guide=2E We'd love to loop you in on the process=2E We can coordinate o= ff >list=2E > >Best, > >Peter > >On Mon, Feb 20, 2017 at 9:44 PM, Tim Draegen wrote: > >> Hi all, I'm looking to collaborate with someone on the creation of >the >> DMARC Usage Guide=2E The Usage Guide is mentioned in the WG Charter as >"3=2E >> DMARC Usage": >> >> https://datatracker=2Eietf=2Eorg/wg/dmarc/charter/ >> >> If you or a colleague would be interested in this work, please >contact me >> off list=2E Thanks! >> =3D- Tim >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc >> From nobody Tue Feb 21 23:45:55 2017 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 73EC21293FB for ; Tue, 21 Feb 2017 23:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=efuture.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NeN1qhR7pAA for ; Tue, 21 Feb 2017 23:45:51 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54B11293DB for ; Tue, 21 Feb 2017 23:45:50 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id k127so1810832vke.0 for ; Tue, 21 Feb 2017 23:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efuture.nl; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vBESZbZYKxHolCm27hxFj7xppyyAaQtCloBjqIT0DtY=; b=Lv78nIayzXpioJVqHz6ySEFm+xK6f0hA6AkWwxrozqUOUCJoX4fxnwB6fpgZr7gvLS Ys7p9tCNxWVPMG8q74/I5loxKgVEewdBKBKFO9oZ0yy7tM2WQvrCQx8357wphndIiZ1N H2WlQDPpbGQeSvUxIxZ2Km1att3WV6/R4P1To= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vBESZbZYKxHolCm27hxFj7xppyyAaQtCloBjqIT0DtY=; b=YdpQWC5kfosty6amEJ38aTzmZh2gToYarsrQBzwLOazqEZnx9MuwOmifiGDwKJw4NB APGTXs9yCn+ph3Jomm/VsGOgi4eme2PCBED7c3iCKgKk9tvrMLovzJd9pktZUyivxS6B 8ItqvLiucW4bjykZPEtQuvecNCXfzaJ5XafKp+VDrMA5YiTKP2MFLfgvtwZluvCPRPRc 5CvVhbzHlotGsABO4RgAIhqkEAf19Sq/bMAaGUrHynqBwdj/p+wSrA7+G+zwyu0MxNFg fu/xEGwSxchZAL1op+VNIJCNutFK86+T0v8dJ1Z8YO3IxiH8D0bcMfuet5x7kUvbiXPC 93YA== X-Gm-Message-State: AMke39l9zIsAlv5x8PnBuqYJd+q7P6q3QEBsyNeUh3uyD7pxIDMhCExX2CcjleYrxbETvM+MzBFStTmTU5U9Rw== X-Received: by 10.31.16.219 with SMTP id 88mr55024vkq.107.1487749549787; Tue, 21 Feb 2017 23:45:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.67.69 with HTTP; Tue, 21 Feb 2017 23:45:49 -0800 (PST) X-Originating-IP: [77.161.116.63] Received: by 10.176.67.69 with HTTP; Tue, 21 Feb 2017 23:45:49 -0800 (PST) In-Reply-To: <35281094-4F9C-48D2-81F2-FE4FD7ACE997@kitterman.com> References: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> <35281094-4F9C-48D2-81F2-FE4FD7ACE997@kitterman.com> From: Michiel van de Vis Date: Wed, 22 Feb 2017 08:45:49 +0100 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11432d466e1dcd054919af1e Archived-At: Cc: dmarc@ietf.org, Peter Goldstein Subject: Re: [dmarc-ietf] looking for collaborator for Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 07:45:54 -0000 --001a11432d466e1dcd054919af1e Content-Type: text/plain; charset=UTF-8 Hello, I'd also like to see your current document and how I could contribute. Regards Michiel DMARC Analyzer Op 22 feb. 2017 04:35 schreef "Scott Kitterman" : Would you mind sending a link to what you have done so far? I'd like to see if I have anything to contribute. Scott K On February 21, 2017 12:41:36 PM EST, Peter Goldstein wrote: >Hi Tim, > >Mike Jones, Thede Loder, and I have already started work on the DMARC >Usage >Guide. We'd love to loop you in on the process. We can coordinate off >list. > >Best, > >Peter > >On Mon, Feb 20, 2017 at 9:44 PM, Tim Draegen wrote: > >> Hi all, I'm looking to collaborate with someone on the creation of >the >> DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter as >"3. >> DMARC Usage": >> >> https://datatracker.ietf.org/wg/dmarc/charter/ >> >> If you or a colleague would be interested in this work, please >contact me >> off list. Thanks! >> =- Tim >> >> >> _______________________________________________ >> 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 --001a11432d466e1dcd054919af1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I'= ;d also like to see your current document and how I could contribute.=C2=A0=

Regards=C2=A0
Michiel
DMARC Analyzer



Op 22 feb. 2017 04:35 schreef "Scott Kitterman&quo= t; <sklist@kitterman.com>= :
Would you mind sending a= link to what you have done so far? I'd like to see if I have anything = to contribute.

Scott K

On February 21, 2017 12:41:36 PM EST, Peter Goldstein <peter@valimail.com> wrote:
>Hi Tim,
>
>Mike Jones, Thede Loder, and I have already started work on the DMARC >Usage
>Guide.=C2=A0 We'd love to loop you in on the process.=C2=A0 We can = coordinate off
>list.
>
>Best,
>
>Peter
>
>On Mon, Feb 20, 2017 at 9:44 PM, Tim Draegen <tim@eudaemon.net> wrote:
>
>> Hi all, I'm looking to collaborate with someone on the creatio= n of
>the
>> DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter = as
>"3.
>> DMARC Usage":
>>
>>=C2=A0 =C2=A0https://datatracker.ietf.org/wg/dmarc/charter/
>>
>> If you or a colleague would be interested in this work, please
>contact me
>> off list. Thanks!
>> =3D- Tim
>>
>>
>> _______________________________________________
>> 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

--001a11432d466e1dcd054919af1e-- From nobody Fri Feb 24 07:30:11 2017 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 CAFD7129881 for ; Fri, 24 Feb 2017 07:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-agari-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uPQyODVPO-T for ; Fri, 24 Feb 2017 07:30:09 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358E11297CF for ; Fri, 24 Feb 2017 07:30:09 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s186so21261519qkb.1 for ; Fri, 24 Feb 2017 07:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-agari-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iYapbve/vmV9InrWa8pE+fnTcRa2J2W4HvRhWl7LQns=; b=vWV4OLXxlAPU6vSH7n9GCQEBpvD5wAqiP2223ovoD8P7A/a+zsP+O389Hf7NGqI3wR fbh0CXPQx87mBkRD1cSb/3boRi95fHzrmM7FPEqpl1w2bK8iIUNV76PQOra4GE3P96yB f38E7YH5EJ5Lk7jW1I/o0BW1kGLwWEKxEy1SFUP6TF08CE86BuacgUSQe12HFSa3w3xk npVmVKKFLAdo6adRhIBoYKHXYgqPUMNd/1dQ7vErLFlnj1wNIeRavBAk0P1ZUVKRGsrB EmOqFDguNf0akU5ewCkZKKVh+ccVRO2TNf9bsSgww9ZESW4+EKKV/u2spCOAmGKHofWW S1yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iYapbve/vmV9InrWa8pE+fnTcRa2J2W4HvRhWl7LQns=; b=mHJfOiwsH3oSiSQazuDmARTWlaroBj+0xfaZ52xSLwLLYQcJMGgjqgWpjHLE14uoOh zbAv09e6o5hf/xz1gbLX0y7wauImgl0UljCBz/KtCPqMIRNCu2uX8btBPTWsfgZ+9Bo2 apzi2qpkojS9QsSuSbpn8mWGv+ZLXGA/paka2kmLME7NLBK22wKaKOOxDpJjsIDIgDCg Bpy2sx2IcekMyyc2Omcm76ac9tVGdZ44FSaym39SG+Ghhgo8vp1EFiHrn+0vJR+FGY9/ GNaLHQmcyfTNAFBwH5sk9oulIIAV5+DuFnhZ35E+WV6ahyfzO2egXEArb3tdH28dfRpU 14qg== X-Gm-Message-State: AMke39nctWVuwTe618a9+LCcKAtgUj0qtwlTOPcBj5AMkWXB+1JPMpx8EClb1eKxCAbqF3pJ4B+SB8zxUBjLDzFq X-Received: by 10.55.87.198 with SMTP id l189mr3071477qkb.106.1487950208290; Fri, 24 Feb 2017 07:30:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.8 with HTTP; Fri, 24 Feb 2017 07:30:07 -0800 (PST) In-Reply-To: <35281094-4F9C-48D2-81F2-FE4FD7ACE997@kitterman.com> References: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> <35281094-4F9C-48D2-81F2-FE4FD7ACE997@kitterman.com> From: Mike Jones Date: Fri, 24 Feb 2017 07:30:07 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a114dbb789c0f0c05494867ea Archived-At: Cc: "dmarc@ietf.org" , Peter Goldstein Subject: Re: [dmarc-ietf] looking for collaborator for Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:30:10 -0000 --001a114dbb789c0f0c05494867ea Content-Type: text/plain; charset=UTF-8 Hi Scott et al., When Peter, Thede, and I spoke recently about the DMARC usage guide, it was in the context of seeing if we could do some work on this and perhaps help pick up some activity in the working group in doing so. I'm happy to see Tim's outreach on it at about the same time. The only work I've done so far is to begin reviewing the already published guide, https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03, to see if that can be a starting point. I'm sure much of it needs updated or re-written, but I think it can be a start. I contributed a couple of sections to this document when it was written a couple of years ago. So my recommendation for anyone interested is to read this, https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03. We can collaborate on where it is incomplete or outdated, and revise as needed. Thanks, Mike On Tue, Feb 21, 2017 at 7:35 PM, Scott Kitterman wrote: > Would you mind sending a link to what you have done so far? I'd like to > see if I have anything to contribute. > > Scott K > > On February 21, 2017 12:41:36 PM EST, Peter Goldstein > wrote: > >Hi Tim, > > > >Mike Jones, Thede Loder, and I have already started work on the DMARC > >Usage > >Guide. We'd love to loop you in on the process. We can coordinate off > >list. > > > >Best, > > > >Peter > > > >On Mon, Feb 20, 2017 at 9:44 PM, Tim Draegen wrote: > > > >> Hi all, I'm looking to collaborate with someone on the creation of > >the > >> DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter as > >"3. > >> DMARC Usage": > >> > >> https://datatracker.ietf.org/wg/dmarc/charter/ > >> > >> If you or a colleague would be interested in this work, please > >contact me > >> off list. Thanks! > >> =- Tim > >> > >> > >> _______________________________________________ > >> 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 > --001a114dbb789c0f0c05494867ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Scott et al.,=C2=A0

When Peter, Thed= e, and I spoke recently about the DMARC usage guide, it was in the context = of seeing if we could do some work on this and perhaps help pick up some ac= tivity in the working group in doing so.=C2=A0 I'm happy to see Tim'= ;s outreach on it at about the same time.=C2=A0 The only work I've done= so far is to begin reviewing the already published guide,=C2=A0https://tools.ietf.= org/html/draft-crocker-dmarc-bcp-03, to see if that can be a starting p= oint. I'm sure much of it needs updated or re-written, but I think it c= an be a start.=C2=A0 I contributed a couple of sections to this document wh= en it was written a couple of years ago. =C2=A0

So= my recommendation for anyone interested is to read this,=C2=A0https://tools.ietf.o= rg/html/draft-crocker-dmarc-bcp-03. =C2=A0 We can collaborate on where = it is incomplete or outdated, and revise as needed.

Thanks,
Mike

On Tue, Feb 21, 2017 at 7:35 PM, Scott Kitterman <sklist@k= itterman.com> wrote:
Would = you mind sending a link to what you have done so far? I'd like to see i= f I have anything to contribute.

Scott K

On February 21, 2017 12:41:36 PM EST, Peter Goldstein <peter@valimail.com> wrote:
>Hi Tim,
>
>Mike Jones, Thede Loder, and I have already started work on the DMARC >Usage
>Guide.=C2=A0 We'd love to loop you in on the process.=C2=A0 We can = coordinate off
>list.
>
>Best,
>
>Peter
>
>On Mon, Feb 20, 2017 at 9:44 PM, Tim Draegen <tim@eudaemon.net> wrote:
>
>> Hi all, I'm loo= king to collaborate with someone on the creation of
>the
>> DMARC Usage Guide. The Usage Guide is mentioned in the WG Charter = as
>"3.
>> DMARC Usage":
>>
>>=C2=A0 =C2=A0https://datatracker.ietf.org/wg/dmarc/charter/
>>
>> If you or a colleague would be interested in this work, please
>contact me
>> off list. Thanks!
>> =3D- Tim
>>
>>
>> _______________________________________________
>> 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



--001a114dbb789c0f0c05494867ea-- From nobody Fri Feb 24 11:39:50 2017 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 373311294E0 for ; Fri, 24 Feb 2017 11:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iHFAkcSdgEN for ; Fri, 24 Feb 2017 11:39:47 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7C71294DB for ; Fri, 24 Feb 2017 11:39:47 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id g18so374237ioe.0 for ; Fri, 24 Feb 2017 11:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=Vq3K/VxN7My1SDtq/WrEdTHmosO/DYzAIaWgNelXMyA=; b=d7f/mhZIiKUnk8trBtDa8kciiCUV4fNJr6P3YsFITANRjVtm0cKovEoQauhZHUEKY3 ibgsgvFoSerLhVpJNMPa5BeociNbPtw19q93vhyjMVPsgzYPN5MqKjKqzwILwVTAGO2t jRSP5Ggr8if2MK/7ZQGg7/sFCI9OXev1ok61M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=Vq3K/VxN7My1SDtq/WrEdTHmosO/DYzAIaWgNelXMyA=; b=Pyh6cyJMmUcwGX4L+vMxkVKyyORNhtpBI9su8VugKEezILNCS6U0jiPqvcCBgJxahL iYLX2KpxsFsOrGQ59z7GpRA9FPYqP2oMkLknOjaUOYT9FEQB1Bh/Q7/zhjbCMxU62Mxz w9ptLack68CzK36LbIfvqxJx5i5JaCatwCeP0X3TXiWI7d8m6GkL71w48bpaBGFypHDH RF3rea5s7rO/c+cUqsCWyEkQryJQxawSH/StsKjF1w0e/9+x018fkhgTC7bibwjZAGjm wTgWK/GNAGh86zWvG4UGWcFCpMXTKMPYvZzJxpmaTZb1/Nds74+lnwR1fR/8VoVDbPC6 /oKQ== X-Gm-Message-State: AMke39mzwept77PX4/d5Xn3f5Mlo4AA6vlH6Pw4zNiTSn9Ca7EWDTWdzjg9HoLaMc8XUXg== X-Received: by 10.107.50.147 with SMTP id y141mr3641788ioy.130.1487965186196; Fri, 24 Feb 2017 11:39:46 -0800 (PST) Received: from ?IPv6:2607:fb90:44:f29b:ed23:f55c:60de:dfff? ([2607:fb90:44:f29b:ed23:f55c:60de:dfff]) by smtp.gmail.com with ESMTPSA id m127sm1081212itc.10.2017.02.24.11.39.45 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Feb 2017 11:39:45 -0800 (PST) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_95FF487B-06FC-4FCF-8CAF-63BE842370C4" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Fri, 24 Feb 2017 14:39:44 -0500 References: <71875641-80A5-4238-9326-2428819A7F67@eudaemon.net> <35281094-4F9C-48D2-81F2-FE4FD7ACE997@kitterman.com> To: "dmarc@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dmarc-ietf] looking for collaborator for Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:39:49 -0000 --Apple-Mail=_95FF487B-06FC-4FCF-8CAF-63BE842370C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 24, 2017, at 10:30 AM, Mike Jones = wrote: >=20 > So my recommendation for anyone interested is to read this, = https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03 = . We can = collaborate on where it is incomplete or outdated, and revise as needed. Thanks Mike, I'll review too. I'm starting off with an outline for people to review based on the = content of the linked draft and what is spelled out as being needed in = the charter. Once the outline is ~OK, people can bite off chunks to fill out. Enough = people from different areas have volunteered to make this approach = viable. =3D- Tim --Apple-Mail=_95FF487B-06FC-4FCF-8CAF-63BE842370C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Feb 24, 2017, at 10:30 AM, Mike Jones <mjones@mail.agari.com> wrote:

So my recommendation for = anyone interested is to read this, https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03. =   We can collaborate on where it is incomplete or outdated, and = revise as needed.

Thanks Mike, I'll review too.

I'm starting off with an outline for = people to review based on the content of the linked draft and what is = spelled out as being needed in the charter.

Once the outline is ~OK, people can = bite off chunks to fill out. Enough people from different areas have = volunteered to make this approach viable.

=3D- Tim

= --Apple-Mail=_95FF487B-06FC-4FCF-8CAF-63BE842370C4-- From nobody Sun Feb 26 18:10:16 2017 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 8E96D1295E1 for ; Sun, 26 Feb 2017 18:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=regumi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Cb9OqxZ8zb for ; Sun, 26 Feb 2017 18:10:13 -0800 (PST) Received: from mx01.regumi.net (153-149-28-102.compute.jp-e1.cloudn-service.com [153.149.28.102]) by ietfa.amsl.com (Postfix) with ESMTP id 58BEA1295DE for ; Sun, 26 Feb 2017 18:10:13 -0800 (PST) Received: from zcs03.regumi.org (v-182-163-50-23.ub-freebit.net [182.163.50.23]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx01.regumi.net (Postfix) with ESMTPS id 58445231E for ; Mon, 27 Feb 2017 11:10:07 +0900 (JST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx01.regumi.net 58445231E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=regumi.net; s=s161204a; t=1488161407; bh=aePVAtMt7VcIHX0lc4ogc/lEDwBXV4E12MAIyjnGMNk=; h=Date:From:To:In-Reply-To:References:Subject:From; b=nGQ3yGZe+7KimZntTeWwiXxNIZ2ga+KSIXk3P4mmbrBbDpQuRyhDQ1n8yxFq9xwqG VE8AeZ+n6iEotJHgdQFOMmLBtRJ6pvzkofb9mq0njE+W/eBYvF2fbQ+/ykd9bL/d38 CU4oaCVvGD/lZB7aHAsW2mWFNAiXfXEX8BvccxhA= Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs03.regumi.org (Postfix) with ESMTP id 3394D121B06F0 for ; Mon, 27 Feb 2017 11:10:07 +0900 (JST) X-Virus-Scanned: amavisd-new at regumi.net Received: from zcs03.regumi.org ([127.0.0.1]) by localhost (zcs03.regumi.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TPbQqdNBEsnh for ; Mon, 27 Feb 2017 11:10:07 +0900 (JST) Received: from zcs03.regumi.org (zcs03.regumi.org [182.163.50.23]) by zcs03.regumi.org (Postfix) with ESMTP id EB266121B06EF for ; Mon, 27 Feb 2017 11:10:06 +0900 (JST) Date: Mon, 27 Feb 2017 02:10:06 +0000 (GMT) From: Takehito Akagiri To: dmarc Message-ID: <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> In-Reply-To: References: <147444383872.26699.16623751845390083865.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [210.237.186.4] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - GC56 (Mac)/8.6.0_GA_1153) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt Thread-Index: SE6J5LOKldZ9ps3wgI35QXDYt96Nbg== Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 02:10:14 -0000 Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statistics= to show effect of "Virtual DAMRC" in corporation with some Japanese ISPs. I prepared very simple page for it. Please find it on the URL as bellow. https://www.vdmarc.dmarc.jp/?p=3D122 Any comments will be appreciated. Best regards, --Takehito Akagiri ----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 ----- =E5=B7=AE=E5=87=BA=E4=BA=BA: "Kouji Okada" =E5=AE=9B=E5=85=88: "dmarc" Cc: "Kouji Okada" =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5, = =E6=B0=B4=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 5:10:55 =E4=BB=B6=E5=90=8D: [dmarc-ietf] Fwd: I-D Action:=09draft-akagiri-dmarc-vir= tual-verification-01.txt We have submitted new version of draft-akagiri-dmarc-virtual-verification The diffs from 00 are listed below. * Removed Roadmap section * Added focus of document to Introduction and Problem Statement * Added Use cases section Any comments will be appreciated. Best regards, Kouji Okada > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8=EF=BC=9A >=20 > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > =E4=BB=B6=E5=90=8D: I-D Action: draft-akagiri-dmarc-virtual-verification-= 01.txt > =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST > =E5=AE=9B=E5=85=88: > =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : DMARC verification without record definitions > Authors : Genki Yasutaka > Takehito Akagiri > Masaki Kase > Kouji Okada > Kaoru Maeda > =09Filename : draft-akagiri-dmarc-virtual-verification-01.txt > =09Pages : 9 > =09Date : 2016-09-21 >=20 > Abstract: > While DMARC is a powerful architecture to protect email users from > malicious email activities, its deployment is still a work in > progress. To encourage further adoption of DMARC, in this draft we > propose an incremental deployment procedure. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification= / >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-akagiri-dmarc-virtual-verificat= ion-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Feb 27 20:12:06 2017 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 F3A111294B8 for ; Mon, 27 Feb 2017 20:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv9UuDifAWUr for ; Mon, 27 Feb 2017 20:12:02 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66ACB1293E3 for ; Mon, 27 Feb 2017 20:12:02 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n127so1184440qkf.0 for ; Mon, 27 Feb 2017 20:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wvvBvnXSkdCVIB5EepE5fupMY7ObQw90h39k5z6Dbms=; b=Z9A43ceSKSG4doI+03JGw9JoOz2Wtr+35sCJreqLLRBrhCJDTuBlZ8ihwhE49tD/bF Jo9hjoE5K3f4m1MMp6quWHNsPEzsP/w5NkYED832/XfTlNsX6u7BSQFDxeppsyTAvDkn IWr78xTOtUU15KaVktX+CER2JydoJmBuFisQwKFnArPaHtux6j4FhqNHXfky9E0q8cRf Fe8KQzzgvWkapS4G8Sag5xTm2aQN1I9KOTRwJZACNqvdOZ81VNIAScQ22iTxEI/xPwV/ J5aMbQFRCjmsyLjDeHTQjQzqm8cgoNHQOD4LiuS0pxSyum1+zX+dhF8JICzMJG3dJmwm d/2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wvvBvnXSkdCVIB5EepE5fupMY7ObQw90h39k5z6Dbms=; b=RGM5MCds/QRU1ZjVDhICXij4C8YZs+NXUgdYlju3rzps5LsQeqRPinkZpMe+FG2IGu lfXRsqO1XmAk9sxCyX3k5wOrMBVZXLwf0QQpOVAZWIo34BfQT3IUHTzM+4CUxWAccadU xcq/Ddk3NZBfVvfpRMPDbJxzSXHdlcrqn9VYYcDj8qb3n/sbi/M9w3rbBmD3M1xoobK6 3Dbmko3EbJnnh5+aHy8w1Mhn3tTC7iZk+usMPRwW9BMbk3z42UE3ZXxh6Ok70RQ7o7qZ sZ8PgptpYSn0tKGm57fHkB+vQ7EQjZlKm1C8WNVC+gTzXOaxOlF1xgPCMRb30QR3h4Gb F47w== X-Gm-Message-State: AMke39lZFAVOSyIiu/jMtyeabOmnTU1sAThe0LFt9xibrEtO/3mbLcC/5FWpDa0voCESLRODQ0h61L0hrIqCqg== X-Received: by 10.200.0.81 with SMTP id i17mr369564qtg.60.1488255121581; Mon, 27 Feb 2017 20:12:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.25.229 with HTTP; Mon, 27 Feb 2017 20:12:01 -0800 (PST) In-Reply-To: <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> References: <147444383872.26699.16623751845390083865.idtracker@ietfa.amsl.com> <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> From: Kaoru Maeda Date: Tue, 28 Feb 2017 13:12:01 +0900 Message-ID: To: Takehito Akagiri Content-Type: multipart/alternative; boundary=f403045e736adb6c7d05498f65b3 Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 04:12:05 -0000 --f403045e736adb6c7d05498f65b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Takehito, Thank you for the statistics. I'm glad to know virtual DMARC verifications has some traffic that could be applicable. Do you have numbers for non-aligned messages that Sender has a DMARC? I wonder if these are stats on Microsoft's "bestguesspass". Kaoru 2017-02-27 11:10 GMT+09:00 Takehito Akagiri : > Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got > statistics to show effect of "Virtual DAMRC" in corporation with some > Japanese ISPs. > > I prepared very simple page for it. Please find it on the URL as bellow. > https://www.vdmarc.dmarc.jp/?p=3D122 > > Any comments will be appreciated. > > Best regards, > --Takehito Akagiri > > > > ----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 ---= -- > =E5=B7=AE=E5=87=BA=E4=BA=BA: "Kouji Okada" > =E5=AE=9B=E5=85=88: "dmarc" > Cc: "Kouji Okada" > =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5,= =E6=B0=B4=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 5:10:55 > =E4=BB=B6=E5=90=8D: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dma= rc-virtual- > verification-01.txt > > We have submitted new version of draft-akagiri-dmarc-virtual-verification > > The diffs from 00 are listed below. > > * Removed Roadmap section > * Added focus of document to Introduction and Problem Statement > * Added Use cases section > > Any comments will be appreciated. > > Best regards, > Kouji Okada > > > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82= =BB=E3=83=BC=E3=82=B8=EF=BC=9A > > > > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > > =E4=BB=B6=E5=90=8D: I-D Action: draft-akagiri-dmarc-virtual-verificatio= n-01.txt > > =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST > > =E5=AE=9B=E5=85=88: > > =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : DMARC verification without record definitions > > Authors : Genki Yasutaka > > Takehito Akagiri > > Masaki Kase > > Kouji Okada > > Kaoru Maeda > > Filename : draft-akagiri-dmarc-virtual-verification-01.txt > > Pages : 9 > > Date : 2016-09-21 > > > > Abstract: > > While DMARC is a powerful architecture to protect email users from > > malicious email activities, its deployment is still a work in > > progress. To encourage further adoption of DMARC, in this draft we > > propose an incremental deployment procedure. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-akagiri-dmarc- > virtual-verification/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-akagiri-dmarc- > virtual-verification-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > 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 > --f403045e736adb6c7d05498f65b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Takehito,

Thank you for t= he statistics.

I'm glad to know virtual DMARC verifications has some tr= affic that could be applicable. Do you have numbers for non-aligned message= s that Sender has a DMARC?

I wonder if these are stats on Microsoft's &= quot;bestguesspass".

Kaoru

<= div class=3D"gmail_quote">2017-02-27 11:10 GMT+09:00 Takehito Akagiri <ak= agiri@regumi.net>:
Regardin= g draft-akagiri-dmarc-virtual-verification-01.txt, I got statistics to= show effect of "Virtual DAMRC" in corporation with some Japanese= ISPs.

I prepared very simple page for it. Please find it on the URL as bellow. https://www.vdmarc.dmarc.jp/?p=3D122

Any comments will be appreciated.

Best regards,
--Takehito Akagiri



----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 -----=
=E5=B7=AE=E5=87=BA=E4=BA=BA: "Kouji Okada" <okd@lepidum.co.jp>
=E5=AE=9B=E5=85=88: "dmarc" <dmarc@ietf.org>
Cc: "Kouji Okada" <okd@le= pidum.co.jp>
=E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5, = =E6=B0=B4=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 5:10:55
=E4=BB=B6=E5=90=8D: [dmarc-ietf] Fwd: I-D Action:=C2=A0 =C2=A0 =C2=A0 =C2= =A0draft-akagiri-dmarc-virtual-verification-01.txt

We have submitted new version of draft-akagiri-dmarc-virtual-verificat= ion

The diffs from 00 are listed below.

* Removed Roadmap section
* Added focus of document to Introduction and Problem Statement
* Added Use cases section

Any comments will be appreciated.

Best regards,
Kouji Okada

> =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82= =BB=E3=83=BC=E3=82=B8=EF=BC=9A
>
> =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org
> =E4=BB=B6=E5=90=8D: I-D Action: draft-akagiri-dmarc-virtual-verif= ication-01.txt
> =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST > =E5=AE=9B=E5=85=88: <i-d-a= nnounce@ietf.org>
> =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: DMARC verification without record definitions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Genki Yasutaka
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Takehito Akagiri
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Masaki Kase
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Kouji Okada
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Kaoru Maeda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= akagiri-dmarc-virtual-verification-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 9
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-09-21
>
> Abstract:
>=C2=A0 =C2=A0While DMARC is a powerful architecture to protect email us= ers from
>=C2=A0 =C2=A0malicious email activities, its deployment is still a work= in
>=C2=A0 =C2=A0progress.=C2=A0 To encourage further adoption of DMARC, in= this draft we
>=C2=A0 =C2=A0propose an incremental deployment procedure.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.i= etf.org/doc/draft-akagiri-dmarc-virtual-verification/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/h= tml/draft-akagiri-dmarc-virtual-verification-01
>
> A diff from the previous version is available at:
> https://www.ietf= .org/rfcdiff?url2=3Ddraft-akagiri-dmarc-virtual-verification-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-= d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html=
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= br>
_______________________________________________
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

--f403045e736adb6c7d05498f65b3-- From nobody Mon Feb 27 22:35:52 2017 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 00BB71293F4 for ; Mon, 27 Feb 2017 22:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=regumi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KcgsUj03LYN for ; Mon, 27 Feb 2017 22:35:48 -0800 (PST) Received: from mx01.regumi.net (153-149-28-102.compute.jp-e1.cloudn-service.com [153.149.28.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0054D1294CD for ; Mon, 27 Feb 2017 22:35:47 -0800 (PST) Received: from zcs03.regumi.org (v-182-163-50-23.ub-freebit.net [182.163.50.23]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx01.regumi.net (Postfix) with ESMTPS id 88F2D2322; Tue, 28 Feb 2017 15:35:43 +0900 (JST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx01.regumi.net 88F2D2322 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=regumi.net; s=s161204a; t=1488263743; bh=gBA1sXuz7YUZTI9fenCv++F/4/JhMFvAWwgwYsEOKEc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ezgJzbQr0OtBmDMEAX/w2P77fBzKMwUfZByejhk+v+/dLz8xI2R0QMZWvYOf3/UEf GEw8zhqswV7D9EiV5ypiCW3lXoiMrKg1CNiuAsyiS7SskYqvIWc4s/P3mCd/BC/6Td VRO0hFkob9jdDWJf5waJAjEJD/L/C98Ksa/yC5f4= Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs03.regumi.org (Postfix) with ESMTP id 636FC1065954D; Tue, 28 Feb 2017 15:35:43 +0900 (JST) X-Virus-Scanned: amavisd-new at regumi.net Received: from zcs03.regumi.org ([127.0.0.1]) by localhost (zcs03.regumi.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q-Xh-DgBh-d0; Tue, 28 Feb 2017 15:35:42 +0900 (JST) Received: from zcs03.regumi.org (zcs03.regumi.org [182.163.50.23]) by zcs03.regumi.org (Postfix) with ESMTP id EE50510659568; Tue, 28 Feb 2017 15:35:41 +0900 (JST) Date: Tue, 28 Feb 2017 06:35:41 +0000 (GMT) From: Takehito Akagiri To: Kaoru Maeda Message-ID: <2107401879.2135.1488263741453.JavaMail.zimbra@regumi.net> In-Reply-To: References: <147444383872.26699.16623751845390083865.idtracker@ietfa.amsl.com> <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2134_2095074698.1488263741452" X-Originating-IP: [110.233.245.237] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - GC56 (Mac)/8.6.0_GA_1153) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt Thread-Index: p1dHV3dZIW7F/L7lQ9lgrlsuVNtkjw== Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 06:35:50 -0000 ------=_Part_2134_2095074698.1488263741452 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kaoru=20 > Do you have numbers for non-aligned messages that Sender has a DMARC?=20 No, I don't have it.=20 But I think we don't need the stats like that to show effect of Virtual DMA= RC.=20 Because Virtual DAMRC focus on the case of PASS.=20 If Virtual DMARC is not PASS, result should be NONE.=20 That means non-PASS messages are not received any bad influences by Virtual= DMARC.=20 > I wonder if these are stats about Microsoft's "bestguesspass".=20 I am not sure MS's BestGuessPass is the same as Virtual DMDARC but almost s= ame idea so I am also interested in the stats.=20 Best,=20 --Takehito=20 =E5=B7=AE=E5=87=BA=E4=BA=BA: "Kaoru Maeda" =20 =E5=AE=9B=E5=85=88: "=E5=A3=AE=E4=BA=BA =E8=B5=A4=E6=A1=90" =20 Cc: "dmarc" =20 =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2017=E5=B9=B42=E6=9C=8828=E6=97=A5, = =E7=81=AB=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 1:12:01=20 =E4=BB=B6=E5=90=8D: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-v= irtual-verification-01.txt=20 Takehito,=20 Thank you for the statistics.=20 I'm glad to know virtual DMARC verifications has some traffic that could be= applicable. Do you have numbers for non-aligned messages that Sender has a= DMARC?=20 I wonder if these are stats on Microsoft's "bestguesspass".=20 Kaoru=20 2017-02-27 11:10 GMT+09:00 Takehito Akagiri < akagiri@regumi.net > :=20 Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statistics= to show effect of "Virtual DAMRC" in corporation with some Japanese ISPs.= =20 I prepared very simple page for it. Please find it on the URL as bellow.=20 https://www.vdmarc.dmarc.jp/?p=3D122=20 Any comments will be appreciated.=20 Best regards,=20 --Takehito Akagiri=20 ----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 -----= =20 =E5=B7=AE=E5=87=BA=E4=BA=BA: "Kouji Okada" < okd@lepidum.co.jp >=20 =E5=AE=9B=E5=85=88: "dmarc" < dmarc@ietf.org >=20 Cc: "Kouji Okada" < okd@lepidum.co.jp >=20 =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5, = =E6=B0=B4=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 5:10:55=20 =E4=BB=B6=E5=90=8D: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtu= al-verification-01.txt=20 We have submitted new version of draft-akagiri-dmarc-virtual-verification= =20 The diffs from 00 are listed below.=20 * Removed Roadmap section=20 * Added focus of document to Introduction and Problem Statement=20 * Added Use cases section=20 Any comments will be appreciated.=20 Best regards,=20 Kouji Okada=20 > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8=EF=BC=9A=20 >=20 > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org=20 > =E4=BB=B6=E5=90=8D: I-D Action: draft-akagiri-dmarc-virtual-verification-= 01.txt=20 > =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST=20 > =E5=AE=9B=E5=85=88: < i-d-announce@ietf.org >=20 > =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.=20 >=20 >=20 > Title : DMARC verification without record definitions=20 > Authors : Genki Yasutaka=20 > Takehito Akagiri=20 > Masaki Kase=20 > Kouji Okada=20 > Kaoru Maeda=20 > Filename : draft-akagiri-dmarc-virtual-verification-01.txt=20 > Pages : 9=20 > Date : 2016-09-21=20 >=20 > Abstract:=20 > While DMARC is a powerful architecture to protect email users from=20 > malicious email activities, its deployment is still a work in=20 > progress. To encourage further adoption of DMARC, in this draft we=20 > propose an incremental deployment procedure.=20 >=20 >=20 > The IETF datatracker status page for this draft is:=20 > https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification= /=20 >=20 > There's also a htmlized version available at:=20 > https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-01= =20 >=20 > A diff from the previous version is available at:=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-akagiri-dmarc-virtual-verificat= ion-01=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion=20 > until the htmlized version and diff are available at tools.ietf.org .=20 >=20 > Internet-Drafts are also available by anonymous FTP at:=20 > ftp://ftp.ietf.org/internet-drafts/=20 >=20 > _______________________________________________=20 > I-D-Announce mailing list=20 > I-D-Announce@ietf.org=20 > https://www.ietf.org/mailman/listinfo/i-d-announce=20 > Internet-Draft directories: http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 _______________________________________________=20 dmarc mailing list=20 dmarc@ietf.org=20 https://www.ietf.org/mailman/listinfo/dmarc=20 _______________________________________________=20 dmarc mailing list=20 dmarc@ietf.org=20 https://www.ietf.org/mailman/listinfo/dmarc=20 ------=_Part_2134_2095074698.1488263741452 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Kaoru

> Do you have numbers for non-aligned messages that Sender has = a DMARC?

No, I don't have it.
But I think we don't need the stats like that to sh= ow effect of Virtual DMARC.
Because Virtual DAMRC focus on the case of PASS.
If Virtual DMARC is n= ot PASS, result should be NONE.
That means non-PASS messages are not received any bad influences by= Virtual DMARC.


> I wonder = if these are stats about Microsoft's "bestguesspass".

I am not sure MS's BestGuessPass is the same as Virtual DMDARC but a= lmost same idea so I am also interested in the stats.


Best,
--Takehito

=E5=B7=AE=E5=87=BA=E4=BA=BA: "Kaoru Maeda" <kaoruma= eda.ml@gmail.com>
=E5=AE=9B=E5=85=88: "=E5=A3=AE=E4=BA=BA =E8= =B5=A4=E6=A1=90" <akagiri@regumi.net>
Cc: "dmarc" <dmarc= @ietf.org>
=E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2017=E5=B9=B4= 2=E6=9C=8828=E6=97=A5, =E7=81=AB=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 1:12:= 01
=E4=BB=B6=E5=90=8D: Re: [dmarc-ietf] Fwd: I-D Action: draft-ak= agiri-dmarc-virtual-verification-01.txt

Takehito,

Thank you for the statistics.

I'm gl= ad to know virtual DMARC verifications has some traffic that could be appli= cable. Do you have numbers for non-aligned messages that Sender has a DMARC= ?
=
I wonder if these are stats on Microsoft's "bestguesspass".

Kaoru
=

2017-02-27 = 11:10 GMT+09:00 Takehito Akagiri <akagiri@regumi.net>:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 .8ex; border-left: = 1px #ccc solid; padding-left: 1ex;" data-mce-style=3D"margin: 0 0 0 .8ex; b= order-left: 1px #ccc solid; padding-left: 1ex;">Regarding draft-akagiri-dma= rc-virtual-verification-01.txt, I got statistics to show effect of "Virtual= DAMRC" in corporation with some Japanese ISPs.

I prepared very simple page for it. Please find it on the URL as bellow. https://www.vdmarc.dmarc.jp/?p=3D122

Any comments will be appreciated.

Best regards,
--Takehito Akagiri



----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 -----=
=E5=B7=AE=E5=87=BA=E4=BA=BA: "Kouji Okada" <okd@lepidum.co.jp>
=E5=AE=9B=E5=85=88: "dmarc" <dmarc@ietf.org>
Cc: "Kouji Okada" <okd@lepidum.co.jp>
=E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5, = =E6=B0=B4=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 5:10:55
=E4=BB=B6=E5=90=8D: [dmarc-ietf] Fwd: I-D Action:       = ;draft-akagiri-dmarc-virtual-verification-01.txt

We have submitted new version of draft-akagiri-dmarc-virtual-verification
The diffs from 00 are listed below.

* Removed Roadmap section
* Added focus of document to Introduction and Problem Statement
* Added Use cases section

Any comments will be appreciated.

Best regards,
Kouji Okada

> =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82= =BB=E3=83=BC=E3=82=B8=EF=BC=9A
>
> =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org
> =E4=BB=B6=E5=90=8D: I-D Action: draft-akagiri-dmarc-virtual-verificati= on-01.txt
> =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST > =E5=AE=9B=E5=85=88: <i-d-announce@ietf.org>
> =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
>        Title          &nb= sp;: DMARC verification without record definitions
>        Authors         : = Genki Yasutaka
>                    &= nbsp;     Takehito Akagiri
>                    &= nbsp;     Masaki Kase
>                    &= nbsp;     Kouji Okada
>                    &= nbsp;     Kaoru Maeda
>       Filename        : draft-= akagiri-dmarc-virtual-verification-01.txt
>       Pages          &nbs= p;: 9
>       Date           = ; : 2016-09-21
>
> Abstract:
>   While DMARC is a powerful architecture to protect email us= ers from
>   malicious email activities, its deployment is still a work= in
>   progress.  To encourage further adoption of DMARC, in= this draft we
>   propose an incremental deployment procedure.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.i= etf.org/doc/draft-akagiri-dmarc-virtual-verification/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/h= tml/draft-akagiri-dmarc-virtual-verification-01
>
> A diff from the previous version is available at:
> https://www.ietf= .org/rfcdiff?url2=3Ddraft-akagiri-dmarc-virtual-verification-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
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

------=_Part_2134_2095074698.1488263741452-- From nobody Tue Feb 28 01:03:50 2017 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 6303A12947A for ; Tue, 28 Feb 2017 01:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o2DdJOE7nm0 for ; Tue, 28 Feb 2017 01:03:45 -0800 (PST) Received: from rcpt-expgw.biglobe.ne.jp (rcpt-expgw.biglobe.ne.jp [IPv6:2001:260:401:42e::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42777126FDC for ; Tue, 28 Feb 2017 01:03:44 -0800 (PST) Received: from vc-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (shby/5611300315) with ESMTP id v1S93gu0005351 for ; Tue, 28 Feb 2017 18:03:42 +0900 Received: from smtp-gw.biglobe.ne.jp ([172.30.160.83]) by vc-gw.biglobe.ne.jp (shby/0716090908) with ESMTP id v1S93gib000923 for ; Tue, 28 Feb 2017 18:03:42 +0900 X-Biglobe-Sender: X-Mailer: BIGLOBE Mail 1.0.0 Received: from bvea33554.zcs.mesh.ad.jp ([172.23.135.32]) by smtp-gw.biglobe.ne.jp id SmcSAC1EA053; Tue, 28 Feb 2017 18:03:42 +0900 (JST) Date: Tue, 28 Feb 2017 18:03:42 +0900 (JST) From: d_kodama@mub.biglobe.ne.jp To: dmarc@ietf.org Message-ID: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Biglobe-Spnum: 52339 Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 09:03:48 -0000 Hi Takehito, Thank you for your information. This is good! I would like to research my mail servers, too. Please tell me how to make data more easily. Daisuke. > Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statistics to show effect of "Virtual DAMRC" in corporation with some Japanese ISPs. > >I prepared very simple page for it. Please find it on the URL as bellow. >https://www.vdmarc.dmarc.jp/?p=122 > >Any comments will be appreciated. > >Best regards, >--Takehito Akagiri