From franck@peachymango.org Mon Jan 6 18:31:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B046E1AE3D2 for ; Mon, 6 Jan 2014 18:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.999 X-Spam-Level: * X-Spam-Status: No, score=1.999 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPvKE6gB9Bm6 for ; Mon, 6 Jan 2014 18:31:58 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0251AE3D3 for ; Mon, 6 Jan 2014 18:31:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9D22E4F5356 for ; Mon, 6 Jan 2014 20:31:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDOhJfzoKh_B for ; Mon, 6 Jan 2014 20:31:49 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7CCFE4F6E57 for ; Mon, 6 Jan 2014 20:31:49 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 679204F6E53 for ; Mon, 6 Jan 2014 20:31:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L_NxPe1c1nj6 for ; Mon, 6 Jan 2014 20:31:49 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 50C494F5356 for ; Mon, 6 Jan 2014 20:31:49 -0600 (CST) Date: Mon, 6 Jan 2014 20:31:48 -0600 (CST) From: Franck Martin To: dmarc@ietf.org Message-ID: <1299737918.42786.1389061908796.JavaMail.zimbra@peachymango.org> In-Reply-To: <1925987558.42665.1389061129115.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_42785_1245610182.1389061908795" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: The AR and the header.from and multiple address in from Thread-Index: TjY2seLqHJ1SVJ0E7ZZHtSEnYwQMSQ== Subject: [dmarc-ietf] The AR and the header.from and multiple address in from X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 02:31:59 -0000 ------=_Part_42785_1245610182.1389061908795 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I noticed the AR indicates in header.from the the domain portion of the RFC5322 .From field, but it is not necessary where the dmarc policy is. Shouldn't we add a field to indicate the domain where we found the policy where all alignments will be based upon. I suggest using header.d for it. We can query to find the orgdomain and the policy but this may be changing, and as finding the org domain is not an adopted standard, indicating what was used could be helpful. When there is an email with multiple addresses in the RFC5322 .From field? I think we need to clarify the language in the spec in 16.1 to: value: the domain portion of the RFC5322 .From field that was used to obtain the dmarc result. What happens if the RFC5322 .From does not have a domain like for some form of EAI? I suggest header.from=nil ------=_Part_42785_1245610182.1389061908795 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I noticed the AR indicates in header.from the= the domain portion of the RFC5322.From field,= but it is not necessary where the dmarc policy is. Shouldn't we add a fiel= d to indicate the domain where we found the policy where all alignments wil= l be based upon. I suggest using header.d for it. We can query to find the = orgdomain and the policy but this may be changing, and as finding the org d= omain is not an adopted standard, indicating what was used could be helpful= .

When there is an email with multiple addresses in the <= a href=3D"http://tools.ietf.org/html/rfc5322" data-mce-href=3D"http://tools= .ietf.org/html/rfc5322">RFC5322.From field? I think we need to clarify = the language in the spec in 16.1 to:
 =
value:  the domain portion of the RFC5322.From=
 field that was used to obtain the dmarc result.
What happe= ns if the RFC5322.From does not have a domain = like for some form of EAI? I suggest header.from=3Dnil
------=_Part_42785_1245610182.1389061908795-- From superuser@gmail.com Mon Jan 6 21:42:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2341AE390 for ; Mon, 6 Jan 2014 21:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adRaEOrGTlga for ; Mon, 6 Jan 2014 21:42:14 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 751BA1ADF9F for ; Mon, 6 Jan 2014 21:42:14 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id w62so145411wes.6 for ; Mon, 06 Jan 2014 21:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gug9Wn82iql96uRM+3ufqmM9wrociDSCiYTsNGe0gb4=; b=qthp7vqPHpliqwPCsFEagAqkitB3oUqIQlInQhLYqaUWEP5a+DkUfG133IZZgGdG0Y KKicOzividSlixgviJd/S/3xn2Lf18k5H83+SM+ghsxz0s5xk+NSp01MKg0eaLZ1FlSA SVmj/EDEV/uSXSjNSVXu/afjBy88A0/NWR5HBFcyx7InHfapom7wWSzj7e6eh4cEc4H5 VI1KiZzi2KkqDQ7YWjCqX7YzirU5ruus5ovDUmwv5QBvXyiv/4QEphXJTpfS7+X7TxP3 cXDXt7VpFYXB3XcoVnN93zL2fkkVJ6uFI2mpbZj9Yiqc93e776bfiPar3fIGctqgs7Bz h5lg== MIME-Version: 1.0 X-Received: by 10.194.186.140 with SMTP id fk12mr4403767wjc.77.1389073325385; Mon, 06 Jan 2014 21:42:05 -0800 (PST) Received: by 10.180.84.106 with HTTP; Mon, 6 Jan 2014 21:42:05 -0800 (PST) In-Reply-To: <1299737918.42786.1389061908796.JavaMail.zimbra@peachymango.org> References: <1925987558.42665.1389061129115.JavaMail.zimbra@peachymango.org> <1299737918.42786.1389061908796.JavaMail.zimbra@peachymango.org> Date: Mon, 6 Jan 2014 21:42:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=047d7bea4518206f1d04ef5ad637 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] The AR and the header.from and multiple address in from X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 05:42:16 -0000 --047d7bea4518206f1d04ef5ad637 Content-Type: text/plain; charset=ISO-8859-1 We can't use header.d if the Domain Owner only uses SPF, because there won't be a "d" anywhere. Off the top of my head, we could use header.from, and then just report the organizational domain as the "value extracted". On Mon, Jan 6, 2014 at 6:31 PM, Franck Martin wrote: > I noticed the AR indicates in header.from the the domain portion of the > RFC5322 .From field, but it is not > necessary where the dmarc policy is. Shouldn't we add a field to indicate > the domain where we found the policy where all alignments will be based > upon. I suggest using header.d for it. We can query to find the orgdomain > and the policy but this may be changing, and as finding the org domain is > not an adopted standard, indicating what was used could be helpful. > > When there is an email with multiple addresses in the RFC5322.From > field? I think we need to clarify the language in the spec in 16.1 to: > > value: the domain portion of the RFC5322 .From field that was used to obtain the dmarc result. > > What happens if the RFC5322 .From > does not have a domain like for some form of EAI? I suggest header.from=nil > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --047d7bea4518206f1d04ef5ad637 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We can't use header.d if the Domain Owner only uses SP= F, because there=20 won't be a "d" anywhere.=A0 Off the top of my head, we could = use=20 header.from, and then just report the organizational domain as the=20 "value extracted".


On Mon, Jan 6, 2014 at 6:31 PM, Franck Martin <f= ranck@peachymango.org> wrote:
I noticed the AR indicates in header.fro= m the the domain portion of the RFC5322.From field, but it is not necessary where= the dmarc policy is. Shouldn't we add a field to indicate the domain w= here we found the policy where all alignments will be based upon. I suggest= using header.d for it. We can query to find the orgdomain and the policy b= ut this may be changing, and as finding the org domain is not an adopted st= andard, indicating what was used could be helpful.

When there is an email with multiple addresses in the RFC5322.From= field? I think we need to clarify the language in the spec in 16.1 to:
 value:  the domain portion of the RFC5322.From field that was us=
ed to obtain the dmarc result.
What happens if the RFC5322.From = does not have a domain like for some form of EAI? I suggest header.from=3Dn= il

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


--047d7bea4518206f1d04ef5ad637-- From franck@peachymango.org Mon Jan 6 22:17:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A1A1AE443 for ; Mon, 6 Jan 2014 22:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O94Tqp9Q93kt for ; Mon, 6 Jan 2014 22:17:10 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF8F1AE441 for ; Mon, 6 Jan 2014 22:17:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B5B1239095C; Tue, 7 Jan 2014 00:17:01 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-jJEcSCxCe8; Tue, 7 Jan 2014 00:17:01 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9375C390975; Tue, 7 Jan 2014 00:17:01 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7E07D39095F; Tue, 7 Jan 2014 00:17:01 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GD-LuWNbmLSC; Tue, 7 Jan 2014 00:17:01 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 5D3C539095C; Tue, 7 Jan 2014 00:17:01 -0600 (CST) Date: Tue, 7 Jan 2014 00:17:00 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1576210910.44391.1389075420202.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1925987558.42665.1389061129115.JavaMail.zimbra@peachymango.org> <1299737918.42786.1389061908796.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_44390_1605343314.1389075420201" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: The AR and the header.from and multiple address in from Thread-Index: Ztn/AxzlAnJA84cJqxPo4ICSNVwZ8g== Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] The AR and the header.from and multiple address in from X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 06:17:12 -0000 ------=_Part_44390_1605343314.1389075420201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I think you think about the header.d for dkim, here I'm suggesting using header.d in for dmarc, may be they should be named differently to avoid confusion, may be header.dmarc= something like: Return-path: joe@d1.example.com Dkim-signature: d=d3.example.com From: Joe@d4.example.com Authentications results: spf=pass mail.from=d1.example.com; dkim=pass header.d=d3.example.com; dmarc=pass header.from=d4.example.com header.dmarc=example.com; ----- Original Message ----- From: "Murray S. Kucherawy" To: "Franck Martin" Cc: dmarc@ietf.org Sent: Monday, January 6, 2014 9:42:05 PM Subject: Re: [dmarc-ietf] The AR and the header.from and multiple address in from We can't use header.d if the Domain Owner only uses SPF, because there won't be a "d" anywhere. Off the top of my head, we could use header.from, and then just report the organizational domain as the "value extracted". On Mon, Jan 6, 2014 at 6:31 PM, Franck Martin < franck@peachymango.org > wrote: I noticed the AR indicates in header.from the the domain portion of the RFC5322 .From field, but it is not necessary where the dmarc policy is. Shouldn't we add a field to indicate the domain where we found the policy where all alignments will be based upon. I suggest using header.d for it. We can query to find the orgdomain and the policy but this may be changing, and as finding the org domain is not an adopted standard, indicating what was used could be helpful. When there is an email with multiple addresses in the RFC5322 .From field? I think we need to clarify the language in the spec in 16.1 to: value: the domain portion of the RFC5322 .From field that was used to obtain the dmarc result. What happens if the RFC5322 .From does not have a domain like for some form of EAI? I suggest header.from=nil ------=_Part_44390_1605343314.1389075420201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think you think about the header.d for dkim= , here I'm suggesting using header.d in for dmarc, may be they should be na= med differently to avoid confusion, may be header.dmarc=3D<domain where = the dmarc policy is>

something like:
Dkim-signature: d=3Dd3.example.com
Authentications results: spf=3Dpass mail.from=3Dd1.example.com; dkim=3Dpas= s header.d=3Dd3.example.com; dmarc=3Dpass header.from=3Dd4.example.com head= er.dmarc=3Dexample.com;

From: "Murray = S. Kucherawy" <superuser@gmail.com>
To: "Franck Martin" <= ;franck@peachymango.org>
Cc: dmarc@ietf.org
Sent: Mo= nday, January 6, 2014 9:42:05 PM
Subject: Re: [dmarc-ietf] The AR= and the header.from and multiple address in from

We can't use header.d if the Domain Owner only uses SPF, because = there=20 won't be a "d" anywhere.  Off the top of my head, we could use=20 header.from, and then just report the organizational domain as the=20 "value extracted".


On Mon, Jan 6, 2014 at 6:31 PM, Franck Martin <= franck@peachymango.org> wrote:
I noticed the AR indicates in header.fro= m the the domain portion of the RFC5322.From field, but it is not necessary where= the dmarc policy is. Shouldn't we add a field to indicate the domain where= we found the policy where all alignments will be based upon. I suggest usi= ng header.d for it. We can query to find the orgdomain and the policy but t= his may be changing, and as finding the org domain is not an adopted standa= rd, indicating what was used could be helpful.

When there is an email with multiple addresses in the RFC5322.From= field? I think we need to clarify the language in the spec in 16.1 to:
 value:  the domain portion of the RFC5322.From field that was us=
ed to obtain the dmarc result.
What happens if the RFC5322.From = does not have a domain like for some form of EAI? I suggest header.from=3Dn= il

------=_Part_44390_1605343314.1389075420201-- From superuser@gmail.com Tue Jan 21 12:55:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EEA1A0166 for ; Tue, 21 Jan 2014 12:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBC2nl3l7oAk for ; Tue, 21 Jan 2014 12:55:28 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C58D61A0221 for ; Tue, 21 Jan 2014 12:55:27 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id t60so8458207wes.37 for ; Tue, 21 Jan 2014 12:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b6F9CCA5ohnzOD5gOhJ0GJ8ah5q0x4qV2mparmF0jNU=; b=SQpiW0W3cfTwPcJNKpQddy5X9OLql81p3vKNcJd109JHH9HgjX9Nb8qYTXCRbxtCTQ llFJ0yGPYTw1Ua0nEaJRK9f+nmCzUN/CjNNINU9klvoTHUjd5Hr4RBHTl+Y8AeiQ1zEi p+d2l+d7CKiMpe5IKkm/6VNkop6qflKa47fcmtWcFtfawbVCRrAvDt/3HdbhmKv8+H9/ JQYPsH67BPQY0zlzxaK5P9q0NJT5JBbXt5EFmpiBWok9AzDyychB5AJDnmHqmcj9JkC3 1dOmKKEHu1YTS0unz1M2p1i0sWbM8DPq0eVPhb0kYvJqwhPulgbIf3GxDc9RxbrFva9L IAUQ== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr11717137wib.5.1390337726959; Tue, 21 Jan 2014 12:55:26 -0800 (PST) Received: by 10.180.98.41 with HTTP; Tue, 21 Jan 2014 12:55:26 -0800 (PST) Date: Tue, 21 Jan 2014 12:55:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=00248c0d7938555a5904f0813a15 Subject: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 20:55:29 -0000 --00248c0d7938555a5904f0813a15 Content-Type: text/plain; charset=ISO-8859-1 I've received a feature request for OpenDMARC to limit what goes into aggregate reports. Specifically, the suggestion is not to store any data regarding messages that pass the DMARC test and thus only report on things that fail. I don't believe the current specification says anything requiring that all messages be recorded, so I think this wouldn't violate the specification, but it might violate the spirit of what was intended or what's desirable to Domain Owners. Comments? -MSK --00248c0d7938555a5904f0813a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've received a feature request for Ope= nDMARC to limit what goes into aggregate reports.=A0 Specifically, the sugg= estion is not to store any data regarding messages that pass the DMARC test= and thus only report on things that fail.

I don't believe the current specification says anything requi= ring that all messages be recorded, so I think this wouldn't violate th= e specification, but it might violate the spirit of what was intended or wh= at's desirable to Domain Owners.

Comments?

-MSK
--00248c0d7938555a5904f0813a15-- From sklist@kitterman.com Tue Jan 21 13:10:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7C61A0224 for ; Tue, 21 Jan 2014 13:10:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCSOocpLs73i for ; Tue, 21 Jan 2014 13:10:07 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5C1A0166 for ; Tue, 21 Jan 2014 13:10:01 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 24971956252; Tue, 21 Jan 2014 16:10:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1390338601; bh=rVmr18yppKeqU8bQRAQAttz6feTd1zkKjaiiC2oQHsU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Eb+uRc3OJzbOMqiAtD8G08DagIryAHPtsT+97wLCaa/sU7sDa84boAZ4lvh0KAeJg Rv7OCNdJGh7qX/mKyZcjJUpAU1YOzlPF7xnQIA27dwfVI5/8gfcI48SwdDzFLdEVOI jC510bEh19+V2rLKd+FG7H0f83Bc33rrXr7o6w7U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EACB6956251; Tue, 21 Jan 2014 16:10:00 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 21 Jan 2014 16:09:59 -0500 Message-ID: <3921759.0AHoQxcqZV@scott-latitude-e6320> User-Agent: KMail/4.11.3 (Linux/3.11.0-15-generic; KDE/4.11.3; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 21:10:09 -0000 On Tuesday, January 21, 2014 12:55:26 Murray S. Kucherawy wrote: > I've received a feature request for OpenDMARC to limit what goes into > aggregate reports. Specifically, the suggestion is not to store any data > regarding messages that pass the DMARC test and thus only report on things > that fail. > > I don't believe the current specification says anything requiring that all > messages be recorded, so I think this wouldn't violate the specification, > but it might violate the spirit of what was intended or what's desirable to > Domain Owners. > > Comments? I've done statistical analysis on DMARC aggregate reports (and similar reporting) that can't be done without knowing the total population. If the results in the aggregate report are filtered, I think it'd be very useful to know that. I don't think there's currently any way to indicate it though. Scott K From franck@peachymango.org Tue Jan 21 13:20:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8E1A0340 for ; Tue, 21 Jan 2014 13:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf0hQ1vcDCae for ; Tue, 21 Jan 2014 13:20:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 89D7E1A0352 for ; Tue, 21 Jan 2014 13:20:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5C4DA390E10; Tue, 21 Jan 2014 15:20:39 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGnINygWYdxL; Tue, 21 Jan 2014 15:20:39 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3F891390E2A; Tue, 21 Jan 2014 15:20:39 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 28EDE390E29; Tue, 21 Jan 2014 15:20:39 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I57AFRq8sbtD; Tue, 21 Jan 2014 15:20:39 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 08D7B390E10; Tue, 21 Jan 2014 15:20:39 -0600 (CST) Date: Tue, 21 Jan 2014 15:20:38 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <989573323.66252.1390339238171.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_66251_710605470.1390339238171" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: Limiting what goes in aggregate reports Thread-Index: JgKfPm2BPcR2NzSssp3DQJCpWvWItQ== Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 21:20:41 -0000 ------=_Part_66251_710605470.1390339238171 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Tuesday, January 21, 2014 12:55:26 PM > Subject: [dmarc-ietf] Limiting what goes in aggregate reports > I've received a feature request for OpenDMARC to limit what goes into > aggregate reports. Specifically, the suggestion is not to store any data > regarding messages that pass the DMARC test and thus only report on things > that fail. > I don't believe the current specification says anything requiring that all > messages be recorded, so I think this wouldn't violate the specification, > but it might violate the spirit of what was intended or what's desirable to > Domain Owners. > Comments? I think it is starting to build too much complexity in what receivers must do to generate aggregate reports. We should keep it light for receivers, it is up to senders to process the data. It seems important to me to be able to look at the ratio pass/fail to know if you have a phishing problem, or if you have something in your infrastructure that would reject too many good emails, compared to your phishing problem, if you move to an active policy. I think the spec should indicate, if not done already, that the receiver SHOULD(MUST?) report all emails in the aggregate report, but if people decide to go for this proposed option then at least notify it dumped some certain categories. However if you don't have the report of emails that pass, how do you find sending IPs that may have your DKIM key? So I'm not for limiting what goes in aggregate reports. ------=_Part_66251_710605470.1390339238171 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: dmarc@ietf.org
Sent: Tuesday, January= 21, 2014 12:55:26 PM
Subject: [dmarc-ietf] Limiting what goes in= aggregate reports

I've r= eceived a feature request for OpenDMARC to limit what goes into aggregate r= eports.  Specifically, the suggestion is not to store any data regardi= ng messages that pass the DMARC test and thus only report on things that fa= il.

I don't believe the current specification says anything re= quiring that all messages be recorded, so I think this wouldn't violate the= specification, but it might violate the spirit of what was intended or wha= t's desirable to Domain Owners.

Comments?

I think it is starting to build too much comple= xity in what receivers must do to generate aggregate reports. We should kee= p it light for receivers, it is up to senders to process the data.

It seems important to me to be able to look at the rat= io pass/fail to know if you have a phishing problem, or if you have somethi= ng in your infrastructure that would reject too many good emails, compared = to your phishing problem, if you move to an active policy.
I think the spec should indicate, if not done already, that th= e receiver SHOULD(MUST?) report all emails in the aggregate report, but if = people decide to go for this proposed option then at least notify it dumped= some certain categories.

However if you don't= have the report of emails that pass, how do you find sending IPs that may = have your DKIM key?

So I'm not for limiting wh= at goes in aggregate reports.


<= br>
------=_Part_66251_710605470.1390339238171-- From mjones@agari.com Tue Jan 21 13:26:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25621A0376 for ; Tue, 21 Jan 2014 13:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_3F80kmXjvx for ; Tue, 21 Jan 2014 13:26:58 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E776C1A0250 for ; Tue, 21 Jan 2014 13:26:57 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tp5so4137648ieb.7 for ; Tue, 21 Jan 2014 13:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rAkqXFJNi6xS3TqwJkJ655fIeSDxudlzsnvpofTzU1E=; b=qgaIXtyjz23WyGkG0uLVZYrS8cdRw2UKpUrbUI4aqIqUpltEZeRVCdKF8n9h9azJcv 8YQJXswzvsu2HjpDHVo4Xi49fPKodOcjLrhs+BNKJpQ1YcyqQ/w53AnsawL8OFPpjHV0 +8ntZMEE/nj4tHNGydhBLJ7ruEB+sC/+wvo8I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rAkqXFJNi6xS3TqwJkJ655fIeSDxudlzsnvpofTzU1E=; b=VPEmcH6dmEjH1MYWllw1e5JNoFyQOmQ9p4xEzt3TYBXuHHl4c8iZi4UijCEUTuvR+W TRcjmGrPDTBGHxjH6SmnQoWr4bk3ABL0i+A5+LJtTyhuZGqRufhtViUK1U30QO5EFi51 rFNksezp16rCnK5ybwVAqpYB+Jl8y4TyflqqqDGzILu+bE83fLpm8DdX6KqvpPdB4uLr JLhpypcfGpRV87NJfq4CVehvPj5sVa1TiA7N/edlb3E9w5hCd172Zk017/j0VWNWSba6 kb1+ylKbEUmI52oZBaJXajKTGyq9iy7PRxoVVBeXnWYwHVgr5FV+hYM/aqIQAHqq387/ UY/w== X-Gm-Message-State: ALoCoQkAHwLCPzPC31PoYJl0+KQEmmmtaUuVXeheQCv5qusZAlNf4UVOvCY1a1CjsdV+XW/jSD2y MIME-Version: 1.0 X-Received: by 10.50.154.102 with SMTP id vn6mr19950992igb.15.1390339617591; Tue, 21 Jan 2014 13:26:57 -0800 (PST) Received: by 10.64.165.226 with HTTP; Tue, 21 Jan 2014 13:26:57 -0800 (PST) In-Reply-To: <3921759.0AHoQxcqZV@scott-latitude-e6320> References: <3921759.0AHoQxcqZV@scott-latitude-e6320> Date: Tue, 21 Jan 2014 13:26:57 -0800 Message-ID: From: Mike Jones To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bd7581e062b0104f081ab9e Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 21:26:59 -0000 --047d7bd7581e062b0104f081ab9e Content-Type: text/plain; charset=ISO-8859-1 I echo Scott's position. Understanding certain reasons for a daily increases (or decreases) in authentication failures is possible when you know the passing volume as well as the failing volume. Domains with sending volumes that vary widely day to day for example, will have failure volumes that vary widely. Is the increase due to a problem or is there is just more mail being sent and the failure rate is normal? Mike On Tue, Jan 21, 2014 at 1:09 PM, Scott Kitterman wrote: > On Tuesday, January 21, 2014 12:55:26 Murray S. Kucherawy wrote: > > I've received a feature request for OpenDMARC to limit what goes into > > aggregate reports. Specifically, the suggestion is not to store any data > > regarding messages that pass the DMARC test and thus only report on > things > > that fail. > > > > I don't believe the current specification says anything requiring that > all > > messages be recorded, so I think this wouldn't violate the specification, > > but it might violate the spirit of what was intended or what's desirable > to > > Domain Owners. > > > > Comments? > > I've done statistical analysis on DMARC aggregate reports (and similar > reporting) that can't be done without knowing the total population. If the > results in the aggregate report are filtered, I think it'd be very useful > to > know that. I don't think there's currently any way to indicate it though. > > Scott K > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7bd7581e062b0104f081ab9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I echo Scott's position.=A0 Understanding certain= reasons for a daily increases (or decreases) in authentication failures is= possible when you know the passing volume as well as the failing volume.= =A0 Domains with sending volumes that vary widely day to day for example, w= ill have failure volumes that vary widely.=A0 Is the increase due to a prob= lem or is there is just more mail being sent and the failure rate is normal= ?

Mike


On Tue,= Jan 21, 2014 at 1:09 PM, Scott Kitterman <sklist@kitterman.com>= wrote:
On T= uesday, January 21, 2014 12:55:26 Murray S. Kucherawy wrote:
> I've received a feature request for OpenDMARC to limit what goes i= nto
> aggregate reports. =A0Specifically, the suggestion is not to store any= data
> regarding messages that pass the DMARC test and thus only report on th= ings
> that fail.
>
> I don't believe the current specification says anything requiring = that all
> messages be recorded, so I think this wouldn't violate the specifi= cation,
> but it might violate the spirit of what was intended or what's des= irable to
> Domain Owners.
>
> Comments?

I've done statistical analysis on DMARC aggregate reports (= and similar
reporting) that can't be done without knowing the total population. =A0= If the
results in the aggregate report are filtered, I think it'd be very usef= ul to
know that. =A0I don't think there's currently any way to indicate i= t though.

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

--047d7bd7581e062b0104f081ab9e-- From steven.m.jones@gmail.com Tue Jan 21 13:32:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52F1A0381 for ; Tue, 21 Jan 2014 13:32:19 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPKYnxd1VpIs for ; Tue, 21 Jan 2014 13:32:17 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 29EA01A037F for ; Tue, 21 Jan 2014 13:32:17 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so6716028pab.32 for ; Tue, 21 Jan 2014 13:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tab2WodG+ATrJTbY5Vc8xCqxYLh+iUf1Av16wGWKJxA=; b=OeeZ0J2ox6NuyikFFBasIc5+TECLVaNF9rdRshYXT6vxbIy+3ZySMAwIfDvASXOxRW o9SiWWlwGnPxcFZVvRpB2G7lyDXAek0nu6tnxPMYkT9va8MmHQy8L6nw4meyryrKDc5y 9qBKoJ7uJCFdelhm3jbVB4NBXZ/IocjLQz5cBVxSe5mW+HGCV5HC8wSSbjkRC8xOAghD wYAa5Wx03PqFAfe/fiXL9Txwz8zC9K1nPPAsCzU2f1EtWax65LFqoF9Zlx7dAzmpbzs+ W9BF6zUexWuyi54OEM4VSBXfc0bHI4SlxZ9HMylNmmWzL2hYbsVDOxza2SQYMhvAMQLr qaDQ== X-Received: by 10.66.149.73 with SMTP id ty9mr27312281pab.36.1390339937037; Tue, 21 Jan 2014 13:32:17 -0800 (PST) Received: from [10.14.227.99] (mobile-166-137-214-182.mycingular.net. [166.137.214.182]) by mx.google.com with ESMTPSA id nw11sm33179954pab.13.2014.01.21.13.32.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jan 2014 13:32:16 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <206606ED-3FCE-464B-8DF3-5B3439767E21@gmail.com> X-Mailer: iPhone Mail (11B554a) From: Steven M Jones Date: Tue, 21 Jan 2014 13:32:04 -0800 To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 21:32:19 -0000 Bare minimum, you need a clear way to indicate tat the report is truncated i= n this manner. As a domain owner I'd prefer the whole picture. But as I'm mobile, a good re= ason for the receiver will have to wait... --S. Sent from my highly functional, highly vulnerable smartphone > On Jan 21, 2014, at 12:55, "Murray S. Kucherawy" wro= te: >=20 > I've received a feature request for OpenDMARC to limit what goes into aggr= egate reports. Specifically, the suggestion is not to store any data regard= ing messages that pass the DMARC test and thus only report on things that fa= il. >=20 > I don't believe the current specification says anything requiring that all= messages be recorded, so I think this wouldn't violate the specification, b= ut it might violate the spirit of what was intended or what's desirable to D= omain Owners. >=20 > Comments? >=20 > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From Alex.Popowycz@fmr.com Tue Jan 21 14:04:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92551A0225 for ; Tue, 21 Jan 2014 14:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 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, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYc3oVk_dyuC for ; Tue, 21 Jan 2014 14:04:13 -0800 (PST) Received: from msginmsm01vapp.fmr.com (ltm-fwus209m-210m.fidelity.com [155.199.204.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFEA1A01FF for ; Tue, 21 Jan 2014 14:04:12 -0800 (PST) Received: from msgrtphc04win.DMN1.FMR.COM (MSGRTPHC04WIN.dmn1.fmr.com [10.95.12.184]) by msginmsm01vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s0LM4A5K032513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 21 Jan 2014 22:04:10 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm01vapp.fmr.com s0LM4A5K032513 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1390341851; bh=H6GMg3MpNtABZEeKh6v0TsKWU8RE6RLw1gJ2rcm8TUs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=DzxsnJi4bwrRr28Vxh9UXn4b4d/j7y4sqFwtPkgAPNiqrDRJ9d7MX/z7BqIOmAZaZ WKcFg5/4XRANe/gmqiD1D2xUAHXANVGLZxskIEBzXOvcVM3UQg42zN+1bF1CMva680 +uKYDoqWYGvDIDlNC6ictUGQ/ZQNCeGrAMxmtDRI= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.32]) by msgrtphc04win.DMN1.FMR.COM ([10.95.12.184]) with mapi; Tue, 21 Jan 2014 17:04:10 -0500 From: "Popowycz, Alex" To: Franck Martin , "Murray S. Kucherawy" Date: Tue, 21 Jan 2014 17:04:08 -0500 Thread-Topic: Limiting what goes in aggregate reports Thread-Index: Ac8W9LVjJhkcYXWRSxiwt5jjUBePbw== Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <989573323.66252.1390339238171.JavaMail.zimbra@peachymango.org> In-Reply-To: <989573323.66252.1390339238171.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12MSGRTPCCRF2_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 22:04:16 -0000 --_000_9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12MSGRTPCCRF2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG1vcmUgdGhhdOKAmXMgbGVmdCB1cCB0byB0aGUgcmVjZWl2ZXJzIGFzIHRvIHdoYXQgZG9l cy9kb2VzIG5vdCBlbmQgdXAgaW4gdGhlIGFnZ3JlZ2F0ZSByZXBvcnQsIHRoZSBsZXNzIHZhbHVh YmxlIHRob3NlIHJlcG9ydHMgYmVjb21lLiBBcyBpdCBzdGFuZHMgYWxyZWFkeSwgaXTigJlzIGRp ZmZpY3VsdCBlbm91Z2ggdG8gY29tcGFyZSB0aGUgcmVzdWx0cyBjb21pbmcgZnJvbSByZWNlaXZl cnMgdG9kYXkgbGV0IGFsb25lIGhhdmluZyB0aGUgcmVwb3J0cyBiZWNvbWUgZXZlbiBtb3JlIGZy YWdtZW50ZWQgYW5kIGxlc3MgZGV0ZXJtaW5pc3RpYy4gSXMgdGhpcyBzdWdnZXN0aW9uIGJlaW5n IGRyaXZlbiBieSB3b3JrIGVmZm9ydCBjb25jZXJucyAoaW4gY3JlYXRpbmcgYSDigJxjb21wbGV0 ZSBhbmQgYWNjdXJhdGXigJ0gYWdncmVnYXRlIHJlcG9ydD8NCg0KVHJ1ZSwgdGhlIHJlcG9ydGlu ZyByZWNvbW1lbmRhdGlvbnMgYXJlIGZhaXJseSBvcGVuIGluIHRoZSBzcGVjaWZpY2F0aW9uLCBi dXQgYW4gaW50cmluc2ljIHZhbHVlIG9mIERNQVJDIGlzIHJlZHVjZWQgKElNSE8gbWF0ZXJpYWxs eSkgaWYgdGhlIHJlcG9ydHMgYXJlIGRpbHV0ZWQuDQoNCg0KDQpGcm9tOiBkbWFyYyBbbWFpbHRv OmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmFuY2sgTWFydGluDQpTZW50 OiBUdWVzZGF5LCBKYW51YXJ5IDIxLCAyMDE0IDQ6MjEgUE0NClRvOiBNdXJyYXkgUy4gS3VjaGVy YXd5DQpDYzogZG1hcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gTGltaXRp bmcgd2hhdCBnb2VzIGluIGFnZ3JlZ2F0ZSByZXBvcnRzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiAiTXVycmF5IFMuIEt1Y2hlcmF3eSIgPHN1cGVydXNlckBnbWFp bC5jb208bWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20+Pg0KVG86IGRtYXJjQGlldGYub3JnPG1h aWx0bzpkbWFyY0BpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjEsIDIwMTQgMTI6 NTU6MjYgUE0NClN1YmplY3Q6IFtkbWFyYy1pZXRmXSBMaW1pdGluZyB3aGF0IGdvZXMgaW4gYWdn cmVnYXRlIHJlcG9ydHMNCg0KSSd2ZSByZWNlaXZlZCBhIGZlYXR1cmUgcmVxdWVzdCBmb3IgT3Bl bkRNQVJDIHRvIGxpbWl0IHdoYXQgZ29lcyBpbnRvIGFnZ3JlZ2F0ZSByZXBvcnRzLiAgU3BlY2lm aWNhbGx5LCB0aGUgc3VnZ2VzdGlvbiBpcyBub3QgdG8gc3RvcmUgYW55IGRhdGEgcmVnYXJkaW5n IG1lc3NhZ2VzIHRoYXQgcGFzcyB0aGUgRE1BUkMgdGVzdCBhbmQgdGh1cyBvbmx5IHJlcG9ydCBv biB0aGluZ3MgdGhhdCBmYWlsLg0KSSBkb24ndCBiZWxpZXZlIHRoZSBjdXJyZW50IHNwZWNpZmlj YXRpb24gc2F5cyBhbnl0aGluZyByZXF1aXJpbmcgdGhhdCBhbGwgbWVzc2FnZXMgYmUgcmVjb3Jk ZWQsIHNvIEkgdGhpbmsgdGhpcyB3b3VsZG4ndCB2aW9sYXRlIHRoZSBzcGVjaWZpY2F0aW9uLCBi dXQgaXQgbWlnaHQgdmlvbGF0ZSB0aGUgc3Bpcml0IG9mIHdoYXQgd2FzIGludGVuZGVkIG9yIHdo YXQncyBkZXNpcmFibGUgdG8gRG9tYWluIE93bmVycy4NCkNvbW1lbnRzPw0KDQpJIHRoaW5rIGl0 IGlzIHN0YXJ0aW5nIHRvIGJ1aWxkIHRvbyBtdWNoIGNvbXBsZXhpdHkgaW4gd2hhdCByZWNlaXZl cnMgbXVzdCBkbyB0byBnZW5lcmF0ZSBhZ2dyZWdhdGUgcmVwb3J0cy4gV2Ugc2hvdWxkIGtlZXAg aXQgbGlnaHQgZm9yIHJlY2VpdmVycywgaXQgaXMgdXAgdG8gc2VuZGVycyB0byBwcm9jZXNzIHRo ZSBkYXRhLg0KDQpJdCBzZWVtcyBpbXBvcnRhbnQgdG8gbWUgdG8gYmUgYWJsZSB0byBsb29rIGF0 IHRoZSByYXRpbyBwYXNzL2ZhaWwgdG8ga25vdyBpZiB5b3UgaGF2ZSBhIHBoaXNoaW5nIHByb2Js ZW0sIG9yIGlmIHlvdSBoYXZlIHNvbWV0aGluZyBpbiB5b3VyIGluZnJhc3RydWN0dXJlIHRoYXQg d291bGQgcmVqZWN0IHRvbyBtYW55IGdvb2QgZW1haWxzLCBjb21wYXJlZCB0byB5b3VyIHBoaXNo aW5nIHByb2JsZW0sIGlmIHlvdSBtb3ZlIHRvIGFuIGFjdGl2ZSBwb2xpY3kuDQoNCkkgdGhpbmsg dGhlIHNwZWMgc2hvdWxkIGluZGljYXRlLCBpZiBub3QgZG9uZSBhbHJlYWR5LCB0aGF0IHRoZSBy ZWNlaXZlciBTSE9VTEQoTVVTVD8pIHJlcG9ydCBhbGwgZW1haWxzIGluIHRoZSBhZ2dyZWdhdGUg cmVwb3J0LCBidXQgaWYgcGVvcGxlIGRlY2lkZSB0byBnbyBmb3IgdGhpcyBwcm9wb3NlZCBvcHRp b24gdGhlbiBhdCBsZWFzdCBub3RpZnkgaXQgZHVtcGVkIHNvbWUgY2VydGFpbiBjYXRlZ29yaWVz Lg0KDQpIb3dldmVyIGlmIHlvdSBkb24ndCBoYXZlIHRoZSByZXBvcnQgb2YgZW1haWxzIHRoYXQg cGFzcywgaG93IGRvIHlvdSBmaW5kIHNlbmRpbmcgSVBzIHRoYXQgbWF5IGhhdmUgeW91ciBES0lN IGtleT8NCg0KU28gSSdtIG5vdCBmb3IgbGltaXRpbmcgd2hhdCBnb2VzIGluIGFnZ3JlZ2F0ZSBy ZXBvcnRzLg0KDQoNCg0K --_000_9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12MSGRTPCCRF2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAy IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFu Zz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBtb3JlIHRoYXTigJlz IGxlZnQgdXAgdG8gdGhlIHJlY2VpdmVycyBhcyB0byB3aGF0IGRvZXMvZG9lcyBub3QgZW5kIHVw IGluIHRoZSBhZ2dyZWdhdGUgcmVwb3J0LCB0aGUgbGVzcyB2YWx1YWJsZSB0aG9zZSByZXBvcnRz IGJlY29tZS4gQXMgaXQgc3RhbmRzIGFscmVhZHksIGl04oCZcyBkaWZmaWN1bHQgZW5vdWdoIHRv IGNvbXBhcmUgdGhlIHJlc3VsdHMgY29taW5nIGZyb20gcmVjZWl2ZXJzIHRvZGF5IGxldCBhbG9u ZSBoYXZpbmcgdGhlIHJlcG9ydHMgYmVjb21lIGV2ZW4gbW9yZSBmcmFnbWVudGVkIGFuZCBsZXNz IGRldGVybWluaXN0aWMuIElzIHRoaXMgc3VnZ2VzdGlvbiBiZWluZyBkcml2ZW4gYnkgd29yayBl ZmZvcnQgY29uY2VybnMgKGluIGNyZWF0aW5nIGEg4oCcY29tcGxldGUgYW5kIGFjY3VyYXRl4oCd IGFnZ3JlZ2F0ZSByZXBvcnQ/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UcnVlLCB0aGUgcmVwb3J0aW5n IHJlY29tbWVuZGF0aW9ucyBhcmUgZmFpcmx5IG9wZW4gaW4gdGhlIHNwZWNpZmljYXRpb24sIGJ1 dCBhbiBpbnRyaW5zaWMgdmFsdWUgb2YgRE1BUkMgaXMgcmVkdWNlZCAoSU1ITyBtYXRlcmlhbGx5 KSBpZiB0aGUgcmVwb3J0cyBhcmUgZGlsdXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNA aWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RnJhbmNrIE1hcnRpbjxicj48Yj5TZW50Ojwv Yj4gVHVlc2RheSwgSmFudWFyeSAyMSwgMjAxNCA0OjIxIFBNPGJyPjxiPlRvOjwvYj4gTXVycmF5 IFMuIEt1Y2hlcmF3eTxicj48Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW2RtYXJjLWlldGZdIExpbWl0aW5nIHdoYXQgZ29lcyBpbiBhZ2dyZWdhdGUgcmVw b3J0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdiBj bGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQt YWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciBpZD16 d2Nocj48L3NwYW4+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4t bGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+JnF1b3Q7TXVycmF5IFMuIEt1Y2hlcmF3eSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20iPnN1cGVydXNlckBnbWFpbC5jb208L2E+Jmd0Ozxi cj48Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNAaWV0Zi5v cmc8L2E+PGJyPjxiPlNlbnQ6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDIxLCAyMDE0IDEyOjU1OjI2 IFBNPGJyPjxiPlN1YmplY3Q6IDwvYj5bZG1hcmMtaWV0Zl0gTGltaXRpbmcgd2hhdCBnb2VzIGlu IGFnZ3JlZ2F0ZSByZXBvcnRzPG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkhlbHZldGljYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjEyLjBwdDttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkhlbHZl dGljYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5JJ3ZlIHJlY2VpdmVkIGEgZmVhdHVyZSBy ZXF1ZXN0IGZvciBPcGVuRE1BUkMgdG8gbGltaXQgd2hhdCBnb2VzIGludG8gYWdncmVnYXRlIHJl cG9ydHMuJm5ic3A7IFNwZWNpZmljYWxseSwgdGhlIHN1Z2dlc3Rpb24gaXMgbm90IHRvIHN0b3Jl IGFueSBkYXRhIHJlZ2FyZGluZyBtZXNzYWdlcyB0aGF0IHBhc3MgdGhlIERNQVJDIHRlc3QgYW5k IHRodXMgb25seSByZXBvcnQgb24gdGhpbmdzIHRoYXQgZmFpbC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbic+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+SSBkb24ndCBiZWxpZXZlIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gc2F5cyBhbnl0 aGluZyByZXF1aXJpbmcgdGhhdCBhbGwgbWVzc2FnZXMgYmUgcmVjb3JkZWQsIHNvIEkgdGhpbmsg dGhpcyB3b3VsZG4ndCB2aW9sYXRlIHRoZSBzcGVjaWZpY2F0aW9uLCBidXQgaXQgbWlnaHQgdmlv bGF0ZSB0aGUgc3Bpcml0IG9mIHdoYXQgd2FzIGludGVuZGVkIG9yIHdoYXQncyBkZXNpcmFibGUg dG8gRG9tYWluIE93bmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkhlbHZldGljYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Db21tZW50cz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+SSB0aGluayBpdCBpcyBzdGFydGluZyB0byBidWlsZCB0b28gbXVjaCBjb21wbGV4aXR5 IGluIHdoYXQgcmVjZWl2ZXJzIG11c3QgZG8gdG8gZ2VuZXJhdGUgYWdncmVnYXRlIHJlcG9ydHMu IFdlIHNob3VsZCBrZWVwIGl0IGxpZ2h0IGZvciByZWNlaXZlcnMsIGl0IGlzIHVwIHRvIHNlbmRl cnMgdG8gcHJvY2VzcyB0aGUgZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPkl0IHNlZW1zIGltcG9ydGFudCB0byBtZSB0byBiZSBhYmxlIHRvIGxv b2sgYXQgdGhlIHJhdGlvIHBhc3MvZmFpbCB0byBrbm93IGlmIHlvdSBoYXZlIGEgcGhpc2hpbmcg cHJvYmxlbSwgb3IgaWYgeW91IGhhdmUgc29tZXRoaW5nIGluIHlvdXIgaW5mcmFzdHJ1Y3R1cmUg dGhhdCB3b3VsZCByZWplY3QgdG9vIG1hbnkgZ29vZCBlbWFpbHMsIGNvbXBhcmVkIHRvIHlvdXIg cGhpc2hpbmcgcHJvYmxlbSwgaWYgeW91IG1vdmUgdG8gYW4gYWN0aXZlIHBvbGljeS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkkgdGhpbmsgdGhlIHNw ZWMgc2hvdWxkIGluZGljYXRlLCBpZiBub3QgZG9uZSBhbHJlYWR5LCB0aGF0IHRoZSByZWNlaXZl ciBTSE9VTEQoTVVTVD8pIHJlcG9ydCBhbGwgZW1haWxzIGluIHRoZSBhZ2dyZWdhdGUgcmVwb3J0 LCBidXQgaWYgcGVvcGxlIGRlY2lkZSB0byBnbyBmb3IgdGhpcyBwcm9wb3NlZCBvcHRpb24gdGhl biBhdCBsZWFzdCBub3RpZnkgaXQgZHVtcGVkIHNvbWUgY2VydGFpbiBjYXRlZ29yaWVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SG93ZXZlciBpZiB5 b3UgZG9uJ3QgaGF2ZSB0aGUgcmVwb3J0IG9mIGVtYWlscyB0aGF0IHBhc3MsIGhvdyBkbyB5b3Ug ZmluZCBzZW5kaW5nIElQcyB0aGF0IG1heSBoYXZlIHlvdXIgREtJTSBrZXk/PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5TbyBJJ20gbm90IGZvciBsaW1p dGluZyB3aGF0IGdvZXMgaW4gYWdncmVnYXRlIHJlcG9ydHMuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12MSGRTPCCRF2_-- From sweet@secondlook.com Tue Jan 21 14:34:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663F41A0263 for ; Tue, 21 Jan 2014 14:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDaOUF7xqXTo for ; Tue, 21 Jan 2014 14:34:50 -0800 (PST) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CB9461A0256 for ; Tue, 21 Jan 2014 14:34:49 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id p5so3972545vbn.30 for ; Tue, 21 Jan 2014 14:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=2sijxhHWyV4r0mfi6e4eHiKE+SdUJLW/qvbTOmk+a9E=; b=Fb/IdrDm6boqeEpYIvTEiVmsWaCCCPSXzceUx9TVz+WJ/i8l4UMiViz8+2Guc4Yacu Hj8EpU1uBVaSogptDlgPaGiDnG0K2bEdR2GgHXRjnB7FvRn1FZ+KN01SDZBswASHTuk9 S/de3F0ZJ0DagOp/qha+uHxtuS5TyYqPpGiOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=2sijxhHWyV4r0mfi6e4eHiKE+SdUJLW/qvbTOmk+a9E=; b=jMkx1EEJe0VH1fK72voLI4O5LG9u2olmuEfOImMdmmzhKVRRnWcXVUOKVL2pt0WFrz 853zMzIv5pyZIqG40E+aElkOBgeDHWkjIOrR4CV6yaI0CgwcqL6kTLiqq5LzbipgE7V6 xhHErq6gYzJtyvIgDSv8YzoSxFLf5hf+pxKQ31d/TxEnoFBbfkHCdevYT4DrLFlAtYmG fiSlCT1R3qd+HumvYZsXep+EGmlO6olC186sH4LHybIfyduI4K4lzMElKoJjUK2fdyU8 dvCdTrxum71q2mSXyVlUpe9rRez+refBzJpdNfXjuCMhM+YnPQHc/A2NslV/kQtvXOLw 7Vow== X-Gm-Message-State: ALoCoQnaxid+xAwXqhnGxm31iX6HnljJdompKoTtKZ/QpSPFMEfVjgRCDMhhNgrr5Fkg0vMIM94h X-Received: by 10.220.99.72 with SMTP id t8mr16059964vcn.10.1390343689270; Tue, 21 Jan 2014 14:34:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.0.205 with HTTP; Tue, 21 Jan 2014 14:34:29 -0800 (PST) X-Originating-IP: [50.0.88.152] In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <989573323.66252.1390339238171.JavaMail.zimbra@peachymango.org> <9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12@MSGRTPCCRF2WIN.DMN1.FMR.COM> From: John Sweet Date: Tue, 21 Jan 2014 14:34:29 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1d71cb71da404f0829d9f Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 22:34:52 -0000 --001a11c1d71cb71da404f0829d9f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure whether the feature being requested is a) providing the sender with another DMARC tag to specify that they only want aggregate reports to include failures, or b) receivers, at their discretion, being able to choose to only report failures. I can imagine a valid use case for a), but not for b). On Tue, Jan 21, 2014 at 2:04 PM, Popowycz, Alex wrot= e: > The more that=92s left up to the receivers as to what does/does not end u= p > in the aggregate report, the less valuable those reports become. As it > stands already, it=92s difficult enough to compare the results coming fro= m > receivers today let alone having the reports become even more fragmented > and less deterministic. Is this suggestion being driven by work effort > concerns (in creating a =93complete and accurate=94 aggregate report? > > > > True, the reporting recommendations are fairly open in the specification, > but an intrinsic value of DMARC is reduced (IMHO materially) if the repor= ts > are diluted. > > > > > > > > *From:* dmarc [mailto:dmarc-bounces@ietf.org] *On Behalf Of *Franck Marti= n > *Sent:* Tuesday, January 21, 2014 4:21 PM > *To:* Murray S. Kucherawy > *Cc:* dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] Limiting what goes in aggregate reports > > > ------------------------------ > > *From: *"Murray S. Kucherawy" > *To: *dmarc@ietf.org > *Sent: *Tuesday, January 21, 2014 12:55:26 PM > *Subject: *[dmarc-ietf] Limiting what goes in aggregate reports > > > > I've received a feature request for OpenDMARC to limit what goes into > aggregate reports. Specifically, the suggestion is not to store any data > regarding messages that pass the DMARC test and thus only report on thing= s > that fail. > > I don't believe the current specification says anything requiring that al= l > messages be recorded, so I think this wouldn't violate the specification, > but it might violate the spirit of what was intended or what's desirable = to > Domain Owners. > > Comments? > > > > I think it is starting to build too much complexity in what receivers mus= t > do to generate aggregate reports. We should keep it light for receivers, = it > is up to senders to process the data. > > > > It seems important to me to be able to look at the ratio pass/fail to kno= w > if you have a phishing problem, or if you have something in your > infrastructure that would reject too many good emails, compared to your > phishing problem, if you move to an active policy. > > > > I think the spec should indicate, if not done already, that the receiver > SHOULD(MUST?) report all emails in the aggregate report, but if people > decide to go for this proposed option then at least notify it dumped some > certain categories. > > > > However if you don't have the report of emails that pass, how do you find > sending IPs that may have your DKIM key? > > > > So I'm not for limiting what goes in aggregate reports. > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c1d71cb71da404f0829d9f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'm not sure whether the feature being requested = is a) providing the sender with another DMARC tag to specify that they only= want aggregate reports to include failures, or b) receivers, at their disc= retion, being able to choose to only report failures.

I can imagine a valid use case for a), but not for b).


On = Tue, Jan 21, 2014 at 2:04 PM, Popowycz, Alex <Alex.Popowycz@fmr.com> wrote:

The more that= =92s left up to the receivers as to what does/does not end up in the aggreg= ate report, the less valuable those reports become. As it stands already, i= t=92s difficult enough to compare the results coming from receivers today l= et alone having the reports become even more fragmented and less determinis= tic. Is this suggestion being driven by work effort concerns (in creating a= =93complete and accurate=94 aggregate report?

=A0<= /p>

True, the reporting re= commendations are fairly open in the specification, but an intrinsic value = of DMARC is reduced (IMHO materially) if the reports are diluted.=

=A0<= /p>

=A0

=A0<= /p>

From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Franck Ma= rtin
Sent: Tuesday, January 21, 2014 4:21 PM
To: Murray S. Kuch= erawy
Cc: dma= rc@ietf.org
Subject: Re: [dmarc-ietf] Limiting what goes in a= ggregate reports

=A0

From: = "Murray S. Kucherawy" <superuser@gmail.com>
To: dmarc@ietf.o= rg
Sent: Tuesday, January 21, 2014 12:55:26 PM
Subject:= [dmarc-ietf] Limiting what goes in aggregate reports

=A0

I&= #39;ve received a feature request for OpenDMARC to limit what goes into agg= regate reports.=A0 Specifically, the suggestion is not to store any data re= garding messages that pass the DMARC test and thus only report on things th= at fail.

I don't believe the current specification says anythin= g requiring that all messages be recorded, so I think this wouldn't vio= late the specification, but it might violate the spirit of what was intende= d or what's desirable to Domain Owners.

Comments?

= =A0

I think it is starting to build too much complexity in what receivers = must do to generate aggregate reports. We should keep it light for receiver= s, it is up to senders to process the data.

=A0

It seems imp= ortant to me to be able to look at the ratio pass/fail to know if you have = a phishing problem, or if you have something in your infrastructure that wo= uld reject too many good emails, compared to your phishing problem, if you = move to an active policy.

=A0

I think the = spec should indicate, if not done already, that the receiver SHOULD(MUST?) = report all emails in the aggregate report, but if people decide to go for t= his proposed option then at least notify it dumped some certain categories.=

=A0

However if y= ou don't have the report of emails that pass, how do you find sending I= Ps that may have your DKIM key?

=A0

So I'm n= ot for limiting what goes in aggregate reports.

=A0

=A0

=A0


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


--001a11c1d71cb71da404f0829d9f-- From Greg.Colburn@returnpath.com Tue Jan 21 15:22:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC71A0250 for ; Tue, 21 Jan 2014 15:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.935 X-Spam-Level: X-Spam-Status: No, score=-6.935 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, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_CERTIFIED=-3, RCVD_IN_RP_SAFE=-2, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_KE-iVA2gES for ; Tue, 21 Jan 2014 15:22:14 -0800 (PST) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id 468AF1A01BB for ; Tue, 21 Jan 2014 15:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to:cc:subject:references:in-reply-to:content-type:mime-version; s=smtpapi; bh=ePV0VNJYLu6BE9R8Z0Z1KGLw1go=; b=OXc47Ns3qXXyJgGcnn jsWZdmGV0j9BK4//Ka5lYiyJQHwptCVqrAUtfIukg4pMC4AzxpYWu5gV4ePAjlzE Bci1H6fe/kOakrAHInwOLZU5t9DdQOPzfBal07er66B4BAHtrmZ/l9Ggb3ksBsw4 nWO5mw/5wDO6R+WiV0ZRxCC0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to:cc:subject:references:in-reply-to:content-type:mime-version; q=dns; s=smtpapi; b=eQvSxyEpPJ3+5b7gwrWA+A8beK59SmbTkRcVKSHq5zkh eIwpBjw1f4Rj+b8e+oZ+ZQ3HCsnsytxdS7vOiQeDX3vsaXPT30bcBho5+qDBwldO jwUOh1mZTDUDeTjgIOFSADKbXZqSmRVM91xSlLOE4O3wW7ECNaNubPd4hBWo/34= Received: by mf219.sendgrid.net with SMTP id mf219.29727.52DF01251 Tue, 21 Jan 2014 23:22:13 +0000 (UTC) Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by ismtpd-012 (SG) with ESMTP id 143b71c77d0.6452.21daa8 Tue, 21 Jan 2014 23:22:12 +0000 (GMT) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Tue, 21 Jan 2014 16:22:11 -0700 From: Greg Colburn To: John Sweet Date: Tue, 21 Jan 2014 16:22:10 -0700 Thread-Topic: [dmarc-ietf] Limiting what goes in aggregate reports Thread-Index: Ac8W/5wVSd87TjHeQxeAeiEFgSHOOg== Message-ID: References: <989573323.66252.1390339238171.JavaMail.zimbra@peachymango.org> <9495B91F5CA0E24C9161D71CD46E43DB010A0ED6BA12@MSGRTPCCRF2WIN.DMN1.FMR.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5F0BD214B684046AB36DD335146C4C0returnpathcom_" MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5Ixtk9osljJANqDTljvTZ45GsGGX/XITl+lmpfmnbCGE5cs5ysuNxkJbtecsws+DgofcNGreaq6JcBTIOcoQ+8svdzCci6DwW1Adp1JZaZYWQ== Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 23:22:21 -0000 --_000_F5F0BD214B684046AB36DD335146C4C0returnpathcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As others have said before, the value of the total aggregate numbers is sig= nificant. They provide a comparison point to measure scale of malicious or= fraudulent activity. The initial request to the openDMARC list suggests a= solution to a implementation problem that I believe presents a compromise = to the value of the Aggregate Report. "not to store any data regarding messages that pass the DMARC test and thus= only report on things that fail=94 The last line in 7.2 covers this requirement casually. I think that we sho= uld consider strengthening this language in the next rev of the draft. 7.2. Aggregate Reports Visibility comes in the form of daily (or more frequent) Mail Receiver-originated feedback reports that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not. Greg C On Jan 21, 2014, at 3:34 PM, John Sweet > wrote: I'm not sure whether the feature being requested is a) providing the sender= with another DMARC tag to specify that they only want aggregate reports to= include failures, or b) receivers, at their discretion, being able to choo= se to only report failures. I can imagine a valid use case for a), but not for b). On Tue, Jan 21, 2014 at 2:04 PM, Popowycz, Alex > wrote: The more that=92s left up to the receivers as to what does/does not end up = in the aggregate report, the less valuable those reports become. As it stan= ds already, it=92s difficult enough to compare the results coming from rece= ivers today let alone having the reports become even more fragmented and le= ss deterministic. Is this suggestion being driven by work effort concerns (= in creating a =93complete and accurate=94 aggregate report? True, the reporting recommendations are fairly open in the specification, b= ut an intrinsic value of DMARC is reduced (IMHO materially) if the reports = are diluted. From: dmarc [mailto:dmarc-bounces@ietf.org] = On Behalf Of Franck Martin Sent: Tuesday, January 21, 2014 4:21 PM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports ________________________________ From: "Murray S. Kucherawy" > To: dmarc@ietf.org Sent: Tuesday, January 21, 2014 12:55:26 PM Subject: [dmarc-ietf] Limiting what goes in aggregate reports I've received a feature request for OpenDMARC to limit what goes into aggre= gate reports. Specifically, the suggestion is not to store any data regard= ing messages that pass the DMARC test and thus only report on things that f= ail. I don't believe the current specification says anything requiring that all = messages be recorded, so I think this wouldn't violate the specification, b= ut it might violate the spirit of what was intended or what's desirable to = Domain Owners. Comments? I think it is starting to build too much complexity in what receivers must = do to generate aggregate reports. We should keep it light for receivers, it= is up to senders to process the data. It seems important to me to be able to look at the ratio pass/fail to know = if you have a phishing problem, or if you have something in your infrastruc= ture that would reject too many good emails, compared to your phishing prob= lem, if you move to an active policy. I think the spec should indicate, if not done already, that the receiver SH= OULD(MUST?) report all emails in the aggregate report, but if people decide= to go for this proposed option then at least notify it dumped some certain= categories. However if you don't have the report of emails that pass, how do you find s= ending IPs that may have your DKIM key? So I'm not for limiting what goes in aggregate reports. _______________________________________________ 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 --_000_F5F0BD214B684046AB36DD335146C4C0returnpathcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
As others have sa= id before, the value of the total aggregate numbers is significant.  T= hey provide a comparison point to measure scale of malicious or fraudulent = activity.  The initial request to the openDMARC list suggests a soluti= on to a implementation problem that I believe presents a compromise to the = value of the Aggregate Report.

"not to store any data regarding messages = that pass the DMARC test and thus only report on things that fail=94

The l= ast line in 7.2 covers this requirement casually.  I think that we sho= uld consider strengthening this language in the next rev of the draft.

7.2. Aggregate= Reports
   Visibility comes in the form of daily (or more frequent) Mail
   Receiver-originated feedback reports that contain aggregate data on
   message streams relevant to the Domain Owner.  This information
   includes data about messages that passed DMARC authentication as well
   as those that did not.
Greg C

On Jan 21, 2014, at 3:34 PM, John Sweet <sweet@secondlook.com> wrote:

I'm not s= ure whether the feature being requested is a) providing the sender with ano= ther DMARC tag to specify that they only want aggregate reports to include = failures, or b) receivers, at their discretion, being able to choose to onl= y report failures.

I can imagine a valid use case for a), but not for b).


On = Tue, Jan 21, 2014 at 2:04 PM, Popowycz, Alex <Alex.Popowycz@fmr.com> wrote:

The more that=92s = left up to the receivers as to what does/does not end up in the aggregate r= eport, the less valuable those reports become. As it stands already, it=92s= difficult enough to compare the results coming from receivers today let al= one having the reports become even more fragmented and less deterministic. = Is this suggestion being driven by work effort concerns (in creating a =93c= omplete and accurate=94 aggregate report?

 

True, the reporting recomme= ndations are fairly open in the specification, but an intrinsic value of DM= ARC is reduced (IMHO materially) if the reports are diluted.<= /span>

 

&n= bsp;

=  

From: dmarc [mailto:= dmarc-bounces@i= etf.org] On Behalf Of Franck Martin
Sent: Tuesday, January 21, 2014 4:21 PM
To: Murray S. Kuch= erawy
Cc: dma= rc@ietf.org
Subject: Re: [dmarc-ietf] Limiting what goes in a= ggregate reports

 

From: "Murray S. Kucherawy" <superuser@gmail.com>
To: dmarc@ietf.o= rg
Sent: Tuesday, January 21, 2014 12:55:26 PM
Subject:= [dmarc-ietf] Limiting what goes in aggregate reports

 

I'= ve received a feature request for OpenDMARC to limit what goes into aggrega= te reports.  Specifically, the suggestion is not to store any data reg= arding messages that pass the DMARC test and thus only report on things tha= t fail.

I don't believe the current specification says anything re= quiring that all messages be recorded, so I think this wouldn't violate the= specification, but it might violate the spirit of what was intended or wha= t's desirable to Domain Owners.

Comments?

&n= bsp;

I= think it is starting to build too much complexity in what receivers must d= o to generate aggregate reports. We should keep it light for receivers, it = is up to senders to process the data.

 =

It seems = important to me to be able to look at the ratio pass/fail to know if you ha= ve a phishing problem, or if you have something in your infrastructure that= would reject too many good emails, compared to your phishing problem, if y= ou move to an active policy.

 =

I think t= he spec should indicate, if not done already, that the receiver SHOULD(MUST= ?) report all emails in the aggregate report, but if people decide to go fo= r this proposed option then at least notify it dumped some certain categori= es.

 =

However i= f you don't have the report of emails that pass, how do you find sending IP= s that may have your DKIM key?

 =

So I'm no= t for limiting what goes in aggregate reports.

 =

&n= bsp;

 =


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


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

= --_000_F5F0BD214B684046AB36DD335146C4C0returnpathcom_-- From sca@andreasschulze.de Wed Jan 22 04:14:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1431A0444 for ; Wed, 22 Jan 2014 04:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.7 X-Spam-Level: *** X-Spam-Status: No, score=3.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_HELO_NEUTRAL=0.112, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qskgafSlsPhj for ; Wed, 22 Jan 2014 04:14:39 -0800 (PST) Received: from andreasschulze.de (cl-255.muc-02.de.sixxs.net [IPv6:2001:a60:f000:fe::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27E1A0442 for ; Wed, 22 Jan 2014 04:14:39 -0800 (PST) Received: from horde (horde.andreasschulze.de [IPv6:2001:a60:f0b4:e503:e49d:e7ff:fea2:4010]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca) by 9645f8.dyndns.org (Postfix) with ESMTPSA id 3f8QXW4Jv6z259Z for ; Wed, 22 Jan 2014 13:14:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1390392876; bh=+WW7tYbctRJ8KBt4v2SP03Hjrd9lKm6B4FZP/+rEHfc=; h=Date:From:To:Subject:References:In-Reply-To; b=GAHYcttzzWeoU3SvvE/+athoCie23dblnaw2Bxo6ZFTkqQKZz0XkmSzye8GVZ0+5o 8XFdCQh9aUG6OXKn0kyWU1yB44FcAS6AQfBoRr7SF5v/nmLPFyeflCKdfyBcarjZiK exE12VyL5WVoQMlTj386wK24NzrmY6d+YKsfczyAmxBMCq0js/wHygAVFGcgsMpicy 3KQmaM6amSjXI1zPIVYFRdIzqwUb4cWM3+dUGKpbQr4uLhnpDzHuA+K8YKLLsBJa6J iKWgeDSe4QjppfQ3dO10X2R5qk3TQRPAsizhRj0gJDqrZ+fDbdGdHTeLhsYWWOMFko zzDvcjI0UsJTFkCuuNrl3ydonBVYNYbw6Q67/BddFtJkVfJ7vZh49fJMkxeYMViIYe yZovTTQFhj8pVtx75Nam09xSF95bqJ1rV0gR52QCulJTqiwqI2yVZpEEWlCSLh8lTm VB1KgoIRCSE17mo9XxZbQ+0dMP4GbPYpWWcmz6wp80C+9KKLpiXFIcBaMYP0V7dhX6 B2Q6UUuaI/M5OpKHXjHZzR+BLM3oPhoSnD0vkdfKhZJyaHVeCA1+ClzkXVpT/vtmwQ 2tX9wYlt5xZOqM9x65WnUTVQPvVrAbLzVRLMjSuegncSlnRMCxXzpcBEDGiBi1CnRK BohvH+ya6UQfPp2CyaG8AMSE= Received: from idsproxy02.datev.de (idsproxy02.datev.de [2a00:e50:f155:b:5ea7:a80a:962e:e746]) by horde.andreasschulze.de (Horde Framework) with HTTP; Wed, 22 Jan 2014 13:14:30 +0100 Date: Wed, 22 Jan 2014 13:14:30 +0100 Message-ID: <20140122131430.Horde.wqMYWo0ZohuSYgwqkqWtJg2@horde.andreasschulze.de> From: Andreas Schulze To: dmarc@ietf.org References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 12:14:41 -0000 Zitat von "Murray S. Kucherawy" : > I've received a feature request for OpenDMARC to limit what goes into > aggregate reports. Specifically, the suggestion is not to store any data > regarding messages that pass the DMARC test and thus only report on things > that fail. I read the initial "feature request" in and other way: The Requester complains about domains requesting aggregated reports but are (temporary) unable to *receive* them. -> The "queue pollution" was mentioned as a problem. So maybe the spec could say "the operator of a reporting system may decide to temporary not send reports" The reporting software - opendmarc in this case - has no ability to do that today. Simple solution: create the report and temporary discard. I also dislike the idea to exclude data regarding messages that pass the DMARC test. Andreas From roland@rolandturner.com Thu Jan 23 02:33:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444521A03D9 for ; Thu, 23 Jan 2014 02:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnHTbKA4y9Ug for ; Thu, 23 Jan 2014 02:33:52 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1E1A03CD for ; Thu, 23 Jan 2014 02:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Du1WI+/hAzApECAn2V4HsvURpMedd8GVPi1kUGd/UMk=; b=CIY3LYH6/e3Y5f2YGsjrdyWwWoJY+Til9gDurlyxxhBph45Tt5A7ZwHKEFqXvVQ1CDtGkSydRf42ZJV7vwQsU4QQIWgMGXjCZxHo27gNmrtNiPgluDqyMM4bhsJeZosfIG3YzgkZXC70eawdDVMvHrBzAa6iFcEf0GuBPxGfbNM=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=47214 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W6HbW-0000oa-Mf for dmarc@ietf.org; Thu, 23 Jan 2014 10:33:50 +0000 Message-ID: <52E0F00A.2040108@rolandturner.com> Date: Thu, 23 Jan 2014 18:33:46 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040905060704090103030604" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 10:33:54 -0000 This is a multi-part message in MIME format. --------------040905060704090103030604 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Domain owners will of course make use of whatever data they can get their hands on, but for many of the likely analyses the less contaminated/biased/truncated the data is, the better. DMARC as a whole will work better if the only limits to feedback are: * Legal constraints on receivers, if/where they exist * Distrust by receivers of specific domain owners * Throughput problems (domain owner/report receiver's mail-server is overloaded/down) Receivers are of course free to do, or not do, as they wish - even if the spec says otherwise - however I suspect that adding knobs to twiddle that aren't widely useful will complicate the implementation of DMARC for receivers (and indeed, each knob adds decision questions for receivers to resolve thereby adding implementation cost; each on its own is small, but a large enough number invites implementation oversights and errors) and the interpretation of them by domain owners ("in addition to any other oddities, some receivers drop reporting of successes!") and thus diminish the effectiveness of DMARC overall. This is not to say that features to suit receivers shouldn't be made to receiver-side implementations, but I'm inclined to believe that there's a better way to handle this particular issue. If I understand the initial report correctly, the concern is not the sending of "all is well" reports per se, but rather that domain owners/report receivers with broken infrastructure cause reports to get stuck in the receiver's/report sender's outbound queue. The solution to this problem is obvious: don't queue. Inconveniently, implementing this approach has to happen in the receiver's/report sender's outbound MTA unless you're willing to add an SMTP client (with DKIM signing!) to opendmarc. (Details of this discussion belong in another list, I know.) - Roland On 01/22/2014 04:55 AM, Murray S. Kucherawy wrote: > I've received a feature request for OpenDMARC to limit what goes into > aggregate reports. Specifically, the suggestion is not to store any > data regarding messages that pass the DMARC test and thus only report > on things that fail. > > I don't believe the current specification says anything requiring that > all messages be recorded, so I think this wouldn't violate the > specification, but it might violate the spirit of what was intended or > what's desirable to Domain Owners. > > Comments? > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------040905060704090103030604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Domain owners will of course make use of whatever data they can get their hands on, but for many of the likely analyses the less contaminated/biased/truncated the data is, the better. DMARC as a whole will work better if the only limits to feedback are:

  • Legal constraints on receivers, if/where they exist
  • Distrust by receivers of specific domain owners
  • Throughput problems (domain owner/report receiver's mail-server is overloaded/down)

Receivers are of course free to do, or not do, as they wish - even if the spec says otherwise - however I suspect that adding knobs to twiddle that aren't widely useful will complicate the implementation of DMARC for receivers (and indeed, each knob adds decision questions for receivers to resolve thereby adding implementation cost; each on its own is small, but a large enough number invites implementation oversights and errors) and the interpretation of them by domain owners ("in addition to any other oddities, some receivers drop reporting of successes!") and thus diminish the effectiveness of DMARC overall.

This is not to say that features to suit receivers shouldn't be made to receiver-side implementations, but I'm inclined to believe that there's a better way to handle this particular issue. If I understand the initial report correctly, the concern is not the sending of "all is well" reports per se, but rather that domain owners/report receivers with broken infrastructure cause reports to get stuck in the receiver's/report sender's outbound queue. The solution to this problem is obvious: don't queue. Inconveniently, implementing this approach has to happen in the receiver's/report sender's outbound MTA unless you're willing to add an SMTP client (with DKIM signing!) to opendmarc. (Details of this discussion belong in another list, I know.)

- Roland



On 01/22/2014 04:55 AM, Murray S. Kucherawy wrote:
I've received a feature request for OpenDMARC to limit what goes into aggregate reports.  Specifically, the suggestion is not to store any data regarding messages that pass the DMARC test and thus only report on things that fail.

I don't believe the current specification says anything requiring that all messages be recorded, so I think this wouldn't violate the specification, but it might violate the spirit of what was intended or what's desirable to Domain Owners.

Comments?

-MSK


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

--------------040905060704090103030604-- From superuser@gmail.com Thu Jan 23 10:16:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E121A01A4 for ; Thu, 23 Jan 2014 10:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wkIVuSg4Ouw for ; Thu, 23 Jan 2014 10:16:05 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B9DB41A0024 for ; Thu, 23 Jan 2014 10:16:01 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id t61so1568480wes.21 for ; Thu, 23 Jan 2014 10:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LQaDa3+1pvqSKotRgMDFdarh++7PMeMOpSosQpJrlp4=; b=MZaeEc603h4MgC7k1jtHmclQJTruBqxe1a+192mS94caiCMZ4zaY3aCp2H23Hj2zOC KrT/0+D4HKniuvf6mU6x7Hbr2wpecHMlxm1wLYkaxekiFKXXzakX698kmoCCY0oJTHNx 0+svss4Rh2hVEyFYcTPKK7jWRUXFbYziqqsN5itFLOaiKLUpvYx5dBU4IBhTcOV7BEvL qgM9yc8iuHEEigwil6IaoooPYoBT2B4ixgOg5EQ5UOvRPC1gnJBxQwIhbOtVtUwKblzd PfPCNpeIS9CQyZlArQ3OWhuxp/RjLVB/uDqm57b3Tw7SiIL81t04Q0CNzJtAUTW4jKJC 0LAA== MIME-Version: 1.0 X-Received: by 10.194.185.205 with SMTP id fe13mr7693808wjc.23.1390500960290; Thu, 23 Jan 2014 10:16:00 -0800 (PST) Received: by 10.180.98.41 with HTTP; Thu, 23 Jan 2014 10:16:00 -0800 (PST) In-Reply-To: <20140122131430.Horde.wqMYWo0ZohuSYgwqkqWtJg2@horde.andreasschulze.de> References: <20140122131430.Horde.wqMYWo0ZohuSYgwqkqWtJg2@horde.andreasschulze.de> Date: Thu, 23 Jan 2014 10:16:00 -0800 Message-ID: From: "Murray S. Kucherawy" To: Andreas Schulze Content-Type: multipart/alternative; boundary=047d7bd6bc9acc4eda04f0a73b35 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:16:12 -0000 --047d7bd6bc9acc4eda04f0a73b35 Content-Type: text/plain; charset=ISO-8859-1 I don't think we can say anything in DMARC itself about local operational problems, like "If the reports can't be delivered for a while, it's OK to stop generating them." That's really outside of the scope of a protocol specification. On Wed, Jan 22, 2014 at 4:14 AM, Andreas Schulze wrote: > > Zitat von "Murray S. Kucherawy" : > > > I've received a feature request for OpenDMARC to limit what goes into >> aggregate reports. Specifically, the suggestion is not to store any data >> regarding messages that pass the DMARC test and thus only report on things >> that fail. >> > > I read the initial "feature request" in and other way: The Requester > complains about domains > requesting aggregated reports but are (temporary) unable to *receive* them. > -> The "queue pollution" was mentioned as a problem. > > So maybe the spec could say "the operator of a reporting system may decide > to temporary not send reports" > The reporting software - opendmarc in this case - has no ability to do > that today. > Simple solution: create the report and temporary discard. > > I also dislike the idea to exclude data regarding messages that pass the > DMARC test. > > Andreas > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7bd6bc9acc4eda04f0a73b35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think we can say anything in DMARC itself abou= t local operational problems, like "If the reports can't be delive= red for a while, it's OK to stop generating them."=A0 That's r= eally outside of the scope of a protocol specification.


On Wed,= Jan 22, 2014 at 4:14 AM, Andreas Schulze <sca@andreasschulze.de&g= t; wrote:

Zitat von "Murray S. Kucherawy" <superuser@gmail.com>:
<= br>
I've received a feature request for OpenDMARC to limit what goes into aggregate reports. =A0Specifically, the suggestion is not to store any data=
regarding messages that pass the DMARC test and thus only report on things<= br> that fail.

I read the initial "feature request" in and other way: The Reques= ter complains about domains
requesting aggregated reports but are (temporary) unable to *receive* them.=
-> The "queue pollution" was mentioned as a problem.

So maybe the spec could say "the operator of a reporting system may de= cide to temporary not send reports"
The reporting software - opendmarc in this case - has no ability to do that= today.
Simple solution: create the report and temporary discard.

I also dislike the idea to exclude data regarding messages that pass the DM= ARC test.

Andreas


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

--047d7bd6bc9acc4eda04f0a73b35-- From roland@rolandturner.com Thu Jan 23 22:40:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C021A013A for ; Thu, 23 Jan 2014 22:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC1UCd4nk75s for ; Thu, 23 Jan 2014 22:40:39 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 849351A00EA for ; Thu, 23 Jan 2014 22:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=3QUZYhxaldZJ/TK9fKqQ3cgb8//JwWtJ6QHSCqF8/Bg=; b=opKzUBx7hqeFzw113QaKznFxb3IQ3wOAFLjkTKNlPEGmdkj5ivypit6jlpgYXsV9puleEGtYDZo2C3ea9kqzpNrfbdhbuCmLVRQ5xAjC5qM9gII8KWhG4iwsRl452e7GBHCoync0Wdb/+dcXZLexp63sjz8ZDo7ro/MlMPksMXk=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=52066 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W6aRP-0002AO-BK for dmarc@ietf.org; Fri, 24 Jan 2014 06:40:36 +0000 Message-ID: <52E20AE2.7090400@rolandturner.com> Date: Fri, 24 Jan 2014 14:40:34 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <52E0F00A.2040108@rolandturner.com> In-Reply-To: <52E0F00A.2040108@rolandturner.com> Content-Type: multipart/alternative; boundary="------------010102040905040103050301" Subject: Re: [dmarc-ietf] Limiting what goes in aggregate reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 06:40:41 -0000 This is a multi-part message in MIME format. --------------010102040905040103050301 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit A concrete example occurred to me of an analysis which benefits from receiving reasonably accurate success data in addition to failure data: a non-Domain-Owner/non-Sender Report Receiver who is attempting to assess the competence of Domain Owner policy assertions will typically not have direct information about how many messages were sent in total; if success information is excluded by most/all report generators then any numerical analysis will be impossible, or at least very inaccurate. On balance this case may be moot, but for completeness: * For a Report Receiver performing such an analysis for a Domain Owner, the latter is likely to be willing to provide relevant numbers anyway, albeit with greater difficulty and less accuracy. * For the same relationship, visibility of the behaviour - successful and unsuccessful - of ESPs acting on behalf of the Domain Owner is likely to be of particular interest. (This is also true for the case where the Report Receiver and Domain Owner are the same entity.) * A Report Receiver may face a conflict of interest in publishing competence assessments of the same Domain Owners who have requested that feedback be delivered to them in the first place, but equally they may not. Other things being equal, it would appear desirable to foster conditions in which this might happen. None of these are directly helpful to receivers, but they do contribute to the usefulness of DMARC to other honest participants in the email system which is likely to indirectly benefit receivers in much the same sense that providing feedback does in the first place. - Roland On 01/23/2014 06:33 PM, Roland Turner wrote: > Domain owners will of course make use of whatever data they can get > their hands on, but for many of the likely analyses the less > contaminated/biased/truncated the data is, the better. DMARC as a > whole will work better if the only limits to feedback are: > > * Legal constraints on receivers, if/where they exist > * Distrust by receivers of specific domain owners > * Throughput problems (domain owner/report receiver's mail-server is > overloaded/down) > > > Receivers are of course free to do, or not do, as they wish - even if > the spec says otherwise - however I suspect that adding knobs to > twiddle that aren't widely useful will complicate the implementation > of DMARC for receivers (and indeed, each knob adds decision questions > for receivers to resolve thereby adding implementation cost; each on > its own is small, but a large enough number invites implementation > oversights and errors) and the interpretation of them by domain owners > ("in addition to any other oddities, some receivers drop reporting of > successes!") and thus diminish the effectiveness of DMARC overall. > > This is not to say that features to suit receivers shouldn't be made > to receiver-side implementations, but I'm inclined to believe that > there's a better way to handle this particular issue. If I understand > the initial report correctly, the concern is not the sending of "all > is well" reports per se, but rather that domain owners/report > receivers with broken infrastructure cause reports to get stuck in the > receiver's/report sender's outbound queue. The solution to this > problem is obvious: don't queue. Inconveniently, implementing this > approach has to happen in the receiver's/report sender's outbound MTA > unless you're willing to add an SMTP client (with DKIM signing!) to > opendmarc. (Details of this discussion belong in another list, I know.) > > - Roland > > > > On 01/22/2014 04:55 AM, Murray S. Kucherawy wrote: >> I've received a feature request for OpenDMARC to limit what goes into >> aggregate reports. Specifically, the suggestion is not to store any >> data regarding messages that pass the DMARC test and thus only report >> on things that fail. >> >> I don't believe the current specification says anything requiring >> that all messages be recorded, so I think this wouldn't violate the >> specification, but it might violate the spirit of what was intended >> or what's desirable to Domain Owners. >> >> Comments? >> >> -MSK >> >> >> _______________________________________________ >> 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 --------------010102040905040103050301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
A concrete example occurred to me of an analysis which benefits from receiving reasonably accurate success data in addition to failure data: a non-Domain-Owner/non-Sender Report Receiver who is attempting to assess the competence of Domain Owner policy assertions will typically not have direct information about how many messages were sent in total; if success information is excluded by most/all report generators then any numerical analysis will be impossible, or at least very inaccurate.

On balance this case may be moot, but for completeness:

  • For a Report Receiver performing such an analysis for a Domain Owner, the latter is likely to be willing to provide relevant numbers anyway, albeit with greater difficulty and less accuracy.
  • For the same relationship, visibility of the behaviour - successful and unsuccessful - of ESPs acting on behalf of the Domain Owner is likely to be of particular interest. (This is also true for the case where the Report Receiver and Domain Owner are the same entity.)
  • A Report Receiver may face a conflict of interest in publishing competence assessments of the same Domain Owners who have requested that feedback be delivered to them in the first place, but equally they may not. Other things being equal, it would appear desirable to foster conditions in which this might happen.

None of these are directly helpful to receivers, but they do contribute to the usefulness of DMARC to other honest participants in the email system which is likely to indirectly benefit receivers in much the same sense that providing feedback does in the first place.

- Roland



On 01/23/2014 06:33 PM, Roland Turner wrote:
Domain owners will of course make use of whatever data they can get their hands on, but for many of the likely analyses the less contaminated/biased/truncated the data is, the better. DMARC as a whole will work better if the only limits to feedback are:

  • Legal constraints on receivers, if/where they exist
  • Distrust by receivers of specific domain owners
  • Throughput problems (domain owner/report receiver's mail-server is overloaded/down)

Receivers are of course free to do, or not do, as they wish - even if the spec says otherwise - however I suspect that adding knobs to twiddle that aren't widely useful will complicate the implementation of DMARC for receivers (and indeed, each knob adds decision questions for receivers to resolve thereby adding implementation cost; each on its own is small, but a large enough number invites implementation oversights and errors) and the interpretation of them by domain owners ("in addition to any other oddities, some receivers drop reporting of successes!") and thus diminish the effectiveness of DMARC overall.

This is not to say that features to suit receivers shouldn't be made to receiver-side implementations, but I'm inclined to believe that there's a better way to handle this particular issue. If I understand the initial report correctly, the concern is not the sending of "all is well" reports per se, but rather that domain owners/report receivers with broken infrastructure cause reports to get stuck in the receiver's/report sender's outbound queue. The solution to this problem is obvious: don't queue. Inconveniently, implementing this approach has to happen in the receiver's/report sender's outbound MTA unless you're willing to add an SMTP client (with DKIM signing!) to opendmarc. (Details of this discussion belong in another list, I know.)

- Roland



On 01/22/2014 04:55 AM, Murray S. Kucherawy wrote:
I've received a feature request for OpenDMARC to limit what goes into aggregate reports.  Specifically, the suggestion is not to store any data regarding messages that pass the DMARC test and thus only report on things that fail.

I don't believe the current specification says anything requiring that all messages be recorded, so I think this wouldn't violate the specification, but it might violate the spirit of what was intended or what's desirable to Domain Owners.

Comments?

-MSK


_______________________________________________
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

--------------010102040905040103050301-- From prvs=610109668e=george.moje@computershare.com Fri Jan 24 05:18:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD81A0351 for ; Fri, 24 Jan 2014 05:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylics2_0zWYl for ; Fri, 24 Jan 2014 05:18:14 -0800 (PST) Received: from mx0b-0012cb01.pphosted.com (mx0b-0012cb01.pphosted.com [67.231.153.112]) by ietfa.amsl.com (Postfix) with ESMTP id F25881A0348 for ; Fri, 24 Jan 2014 05:18:13 -0800 (PST) Received: from WATAXEXEDGE2.computershare.net ([67.130.98.105]) by m0042339.ppops.net (8.14.5/8.14.5) with ESMTP id s0ODIBIx004346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 24 Jan 2014 05:18:12 -0800 Received: from CSAVEXHUB6.americas.cshare.net (172.21.155.240) by WATAXEXEDGE2.computershare.net (172.21.155.121) with Microsoft SMTP Server id 14.2.342.3; Fri, 24 Jan 2014 08:18:53 -0500 Received: from WATAEXNODE5.americas.cshare.net ([fe80::1950:6e67:c837:d19]) by CSAVEXHUB6.americas.cshare.net ([fe80::cc79:a39f:4de:fae1%11]) with mapi id 14.02.0342.003; Fri, 24 Jan 2014 08:18:10 -0500 From: George Moje To: "'dmarc@ietf.org'" Thread-Topic: DMARC implementation Question Thread-Index: Ac8ZBqj6GuyQl7WRT3uQapm1ZI02hg== Date: Fri, 24 Jan 2014 13:18:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.24.147] Content-Type: multipart/alternative; boundary="_000_C181758BA993114380E766BEF246B5CD0729A5FCWATAEXNODE5amer_" MIME-Version: 1.0 X-CFilter-Loop: Reflected canr2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-24_01:2014-01-24,2014-01-24,1970-01-01 signatures=0 X-Mailman-Approved-At: Sun, 26 Jan 2014 12:03:54 -0800 Subject: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 13:18:50 -0000 --_000_C181758BA993114380E766BEF246B5CD0729A5FCWATAEXNODE5amer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently we are using SPF records but no DKIM. Can we implement DMARC wit= h just SPF records? Thank you George Moje Computershare Technology Services 250 Royall Street, Canton, Massachusetts T 1 781 575 4454 C 1 508 649 9039 www.computershare.com | CERTAINTY | INGENUITY | ADVANTAGE | ***************************************************************************= *** Please visit the following website to read the Computershare legal notice: = http://www.computershare.com/disclaimer/americas/en Veuillez visiter le site Web suivant afin de prendre connaissance de l'avis= juridique de Computershare: http://www.computershare.com/disclaimer/americ= as/fr ***************************************************************************= *** --_000_C181758BA993114380E766BEF246B5CD0729A5FCWATAEXNODE5amer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Currently we are using SPF records but no DKIM. = ; Can we implement DMARC with just SPF records?

 

Thank you

 

George Moje

 

Computershare= Technology Services

250 Royall St= reet, Canton, Massachusetts

T 1 781 575 4454 C 1 508 649 9039
www.computershare.com

|  CERTA= INTY  |  INGENUITY  |  ADVANTAGE  |

 

***************************************************************************= ***
Please visit the following website to read the Computershare legal notice: = http://www.= computershare.com/disclaimer/americas/en

Veuillez visiter le site Web suivant afin de prendre connaissance de l'= avis juridique de Computershare: http://www.computershare.com/disclaimer/americas/fr

***************************************************************************= ***
--_000_C181758BA993114380E766BEF246B5CD0729A5FCWATAEXNODE5amer_-- From franck@peachymango.org Sun Jan 26 12:29:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBB1A004B for ; Sun, 26 Jan 2014 12:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPy3aglBRvnn for ; Sun, 26 Jan 2014 12:29:34 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 682D81A003B for ; Sun, 26 Jan 2014 12:29:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5E7EB3911C2; Sun, 26 Jan 2014 14:29:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbEEEw1fEfDT; Sun, 26 Jan 2014 14:29:32 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4225A3911C5; Sun, 26 Jan 2014 14:29:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2D2CC3911C3; Sun, 26 Jan 2014 14:29:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nm3x7QY80ALb; Sun, 26 Jan 2014 14:29:32 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 154983911C2; Sun, 26 Jan 2014 14:29:32 -0600 (CST) Date: Sun, 26 Jan 2014 14:29:31 -0600 (CST) From: Franck Martin To: George Moje Message-ID: <387588293.4235.1390768171447.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4234_567847023.1390768171447" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC implementation Question Thread-Index: Ac8ZBqj6GuyQl7WRT3uQapm1ZI02huVF6njm Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 20:29:36 -0000 ------=_Part_4234_567847023.1390768171447 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "George Moje" > To: "dmarc@ietf.org" > Sent: Friday, January 24, 2014 5:18:10 AM > Subject: [dmarc-ietf] DMARC implementation Question > Currently we are using SPF records but no DKIM. Can we implement DMARC with > just SPF records? yes,It is SPF OR DKIM not SPF AND DKIM. You need both to max your chance to have a pass, but only one is needed. make sure you are p=none; and have a rua so you get some feedback to first fix your SPF and then later start to DKIM. ------=_Part_4234_567847023.1390768171447 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
From: "George Moje" <George.Moje@computershare.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Sent: Friday, January 24, 2014 5:18:10 AM
Subject: [dmarc-ietf] DMARC implementation Question

Currently we are using SPF records but no DKIM.  Can we implement DMARC with just SPF records?

yes,It is SPF OR DKIM not SPF AND DKIM. You need both to max your chance to have a pass, but only one is needed.

make sure you are p=none; and have a rua so you get some feedback to first fix your SPF and then later start to DKIM.

------=_Part_4234_567847023.1390768171447-- From R.E.Sonneveld@sonnection.nl Mon Jan 27 15:04:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698341A03F8 for ; Mon, 27 Jan 2014 15:04:26 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CQM6M8mIKxk for ; Mon, 27 Jan 2014 15:04:23 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 90F951A03F6 for ; Mon, 27 Jan 2014 15:04:23 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3fCmjt5VBpz1L8g4; Tue, 28 Jan 2014 00:04:18 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3fCmjt3vd9z1L8fN; Tue, 28 Jan 2014 00:04:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 1B641123299; Tue, 28 Jan 2014 00:04:18 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lz1rRotZfSo3; Tue, 28 Jan 2014 00:04:13 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id AB2A91231FB; Tue, 28 Jan 2014 00:04:13 +0100 (CET) Message-ID: <52E6E5ED.8060504@sonnection.nl> Date: Tue, 28 Jan 2014 00:04:13 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: George Moje , "'dmarc@ietf.org'" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090008010602020103000102" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1390863858; bh=aYrm6UOIZQRbEusUD6pSZYGHGN3AKZMaFNZtXDqTF6w=; h=Message-ID:Date:From:To:Subject:From; b=II27r54UDdWpx7GLFEDmbgCkjQDJcbg/qSHmMEpFOdbBrqF1O/ZGXP62EZ7Tk38RL yVos5mI9Y11RmG4+7Ps07emz1NoMZwhUrfiYL0upPU0lY+PZkCFxEfYpfQW+yWOORn +Pi9gJh2g8eShAqrffjhSJBfYS3tJwFIqMPYx6q0= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3fCmjt5VBpz1L8g4 Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:04:26 -0000 This is a multi-part message in MIME format. --------------090008010602020103000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/24/2014 02:18 PM, George Moje wrote: > > Currently we are using SPF records but no DKIM. Can we implement > DMARC with just SPF records? > according to par. 3.1.3 of the DMARC spec (https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base) DMARC assumes an author to setup and apply DKIM signing. Apart from that: be very careful when using only SPF in combination with DMARC: please take into account that for DMARC there's no difference between an SPF -all, ~all and ?all situation. None of them provide a 'pass' for DMARC, if I read the spec correctly. /rolf --------------090008010602020103000102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/24/2014 02:18 PM, George Moje wrote:

Currently we are using SPF records but no DKIM.  Can we implement DMARC with just SPF records?


according to par. 3.1.3 of the DMARC spec (https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base) DMARC assumes an author to setup and apply DKIM signing.

Apart from that: be very careful when using only SPF in combination with DMARC: please take into account that for DMARC there's no difference between an SPF -all, ~all and ?all situation. None of them provide a 'pass' for DMARC, if I read the spec correctly.

/rolf

--------------090008010602020103000102-- From franck@peachymango.org Mon Jan 27 15:45:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89201A03DB for ; Mon, 27 Jan 2014 15:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYlAY2Fw5gH9 for ; Mon, 27 Jan 2014 15:45:20 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id B99DF1A0396 for ; Mon, 27 Jan 2014 15:45:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7B2FC390E54; Mon, 27 Jan 2014 17:45:18 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YvnpjSgJXUw; Mon, 27 Jan 2014 17:45:18 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5DA643910FF; Mon, 27 Jan 2014 17:45:18 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 511283910EC; Mon, 27 Jan 2014 17:45:18 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C7hoGCznRVOz; Mon, 27 Jan 2014 17:45:18 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 326C9390EFE; Mon, 27 Jan 2014 17:45:18 -0600 (CST) Date: Mon, 27 Jan 2014 17:45:17 -0600 (CST) From: Franck Martin To: R E Sonneveld Message-ID: <488678367.715.1390866317515.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <52E6E5ED.8060504@sonnection.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_714_2021145059.1390866317515" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC implementation Question Thread-Index: KlGnn7S/3WEDC9ulgE7vLtszNFToLA== Cc: George Moje , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 23:45:23 -0000 ------=_Part_714_2021145059.1390866317515 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Rolf E. Sonneveld" > To: "George Moje" , "dmarc@ietf.org" > > Sent: Monday, January 27, 2014 3:04:13 PM > Subject: Re: [dmarc-ietf] DMARC implementation Question > On 01/24/2014 02:18 PM, George Moje wrote: > > Currently we are using SPF records but no DKIM. Can we implement DMARC with > > just SPF records? > > according to par. 3.1.3 of the DMARC spec ( > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base ) DMARC assumes > an author to setup and apply DKIM signing. > Apart from that: be very careful when using only SPF in combination with > DMARC: please take into account that for DMARC there's no difference between > an SPF -all, ~all and ?all situation. None of them provide a 'pass' for > DMARC, if I read the spec correctly. No, If the policy is p=none, DMARC should not override the SPF policy (especially for -all), DMARC with p=none, does not change the way the email is treated in regards of SPF or ADSP. If p!=none then DMARC tells the receiver to not action on the SPF policy and tell the receiver to ignore ADSP, as DMARC will now tell how to handle the email. However, regardless of the DMARC p=, DMARC takes the result of the SPF test (pass, soffail, fail,...) and if there is a pass, compare the domain used by SPF for its pass with the domain in the From:. If there is alignment then you have a DMARC pass. You don't need DKIM to have a DMARC pass. you need to do SPF and DKIM on all your emails for p!=none, because in some cases SPF is more suitable than DKIM and vice versa, so you want the benefit of both. ------=_Part_714_2021145059.1390866317515 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



=
From: "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl= >
To: "George Moje" <George.Moje@computershare.com>, "dm= arc@ietf.org" <dmarc@ietf.org>
Sent: Monday, January 27, 20= 14 3:04:13 PM
Subject: Re: [dmarc-ietf] DMARC implementation Ques= tion

On 01/24/2014 02:18 P= M, George Moje wrote:

Currently we = are using SPF records but no DKIM.  Can we implement DMARC with just SPF records?


according to par. 3.1.3 of the DMARC spec (https://datatracker.iet= f.org/doc/draft-kucherawy-dmarc-base) DMARC assumes an author to setup and apply DKIM signing.

Apart from that: be very careful when using only SPF in combination with DMARC: please take into account that for DMARC there's no difference between an SPF -all, ~all and ?all situation. None of them provide a 'pass' for DMARC, if I read the spec correctly.
No,

If the policy is p=3Dnone, DM= ARC should not override the SPF policy (especially for -all), DMARC with p= =3Dnone, does not change the way the email is treated in regards of SPF or = ADSP. If p!=3Dnone then DMARC tells the receiver to not action on the SPF p= olicy and tell the receiver to ignore ADSP, as DMARC will now tell how to h= andle the email.

However, regardless of the DM= ARC p=3D, DMARC takes the result of the SPF test (pass, soffail, fail,...) = and if there is a pass, compare the domain used by SPF for its pass with th= e domain in the From:. If there is alignment then you have a DMARC pass. Yo= u don't need DKIM to have a DMARC pass.

you ne= ed to do SPF and DKIM on all your emails for p!=3Dnone, because in some cas= es SPF is more suitable than DKIM and vice versa, so you want the benefit o= f both.

------=_Part_714_2021145059.1390866317515-- From roland@rolandturner.com Mon Jan 27 21:54:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA25B1A0199 for ; Mon, 27 Jan 2014 21:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 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, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPHBbeRpHrZB for ; Mon, 27 Jan 2014 21:54:32 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id C53E21A00FF for ; Mon, 27 Jan 2014 21:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ey64Nr7esRCxlVh/aJbjykch9QknczTVS8TP0wrSyHo=; b=TyOGcV38glfhFADMV9Co1FWTb5HQjkU7JjrqdLe1zcrwwliKi7U1w4CxB74DXm1fGKRlqVFAPQ4BGRmFOsO1jK61GVaOCIPwE/Ez2zCxiW9AeoQsnGIHweAk3dSfFDsU4CN29Kyn3xGWTlUPkeoF8y0tP6FlYvvD4YcUoSc+/k4=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=45896 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W81cw-0008Kv-TP; Tue, 28 Jan 2014 05:54:27 +0000 Message-ID: <52E74612.3070106@rolandturner.com> Date: Tue, 28 Jan 2014 13:54:26 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: George Moje , "'dmarc@ietf.org'" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070109040305090907050002" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 05:54:33 -0000 This is a multi-part message in MIME format. --------------070109040305090907050002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/24/2014 09:18 PM, George Moje wrote: > Currently we are using SPF records but no DKIM. Can we implement > DMARC with just SPF records? > Absolutely, in fact publishing a DMARC p=none record is a worthwhile step ahead of implementing SPF or DKIM in that it allows you to discover quickly (and to monitor) whether you have serious issues with your deployment. A more important question might be this: what are you aiming to achieve by implementing DMARC? If you've not implemented DKIM, you presumably don't have a spoofing problem at present. - Roland --------------070109040305090907050002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 01/24/2014 09:18 PM, George Moje wrote:

Currently we are using SPF records but no DKIM.  Can we implement DMARC with just SPF records?


Absolutely, in fact publishing a DMARC p=none record is a worthwhile step ahead of implementing SPF or DKIM in that it allows you to discover quickly (and to monitor) whether you have serious issues with your deployment.

A more important question might be this: what are you aiming to achieve by implementing DMARC? If you've not implemented DKIM, you presumably don't have a spoofing problem at present.

- Roland
--------------070109040305090907050002-- From R.E.Sonneveld@sonnection.nl Mon Jan 27 22:52:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0ED1A0257 for ; Mon, 27 Jan 2014 22:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EqHZzaQcYg7 for ; Mon, 27 Jan 2014 22:52:26 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id E2B191A025B for ; Mon, 27 Jan 2014 22:52:24 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3fCz5y02mnz5Mhct; Tue, 28 Jan 2014 07:52:22 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3fCz5x61XZz5Mhc9; Tue, 28 Jan 2014 07:52:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 64A1312329B; Tue, 28 Jan 2014 07:52:21 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0Wj4CYnKlTui; Tue, 28 Jan 2014 07:52:18 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 00B82123263; Tue, 28 Jan 2014 07:52:17 +0100 (CET) Message-ID: <52E753A1.2090302@sonnection.nl> Date: Tue, 28 Jan 2014 07:52:17 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Franck Martin References: <52E6E5ED.8060504@sonnection.nl> <488678367.715.1390866317515.JavaMail.zimbra@peachymango.org> In-Reply-To: <488678367.715.1390866317515.JavaMail.zimbra@peachymango.org> Content-Type: multipart/alternative; boundary="------------010703010008070802070609" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1390891942; bh=+jn7wj2tsRh0WdYBdPB/nm9RNvnOdMu2bFywkxYxFn0=; h=Message-ID:Date:From:To:Subject:From; b=StgGFMj3vG0P5+zDbFeW0PkDIDuCHYnRj6bG1Lv/Cgk1VpM4z5yTQaNsQynmPF4AD KR3+U9RSbiFN2YyEWA3/KQ7LKyV28fms+OB6PN8jT9K2xibb2IS63xFdcw0FNASbb8 sj7VMaknxuiR8D4cvtE7yDjZ4zPObco65JbVhpC0= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3fCz5y02mnz5Mhct Cc: George Moje , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 06:52:30 -0000 This is a multi-part message in MIME format. --------------010703010008070802070609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/28/2014 12:45 AM, Franck Martin wrote: > *From: *"Rolf E. Sonneveld" > > *To: *"George Moje" , > "dmarc@ietf.org" > *Sent: *Monday, January 27, 2014 3:04:13 PM > *Subject: *Re: [dmarc-ietf] DMARC implementation Question > > On 01/24/2014 02:18 PM, George Moje wrote: > > Currently we are using SPF records but no DKIM. Can we > implement DMARC with just SPF records? > > > according to par. 3.1.3 of the DMARC spec > (https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base) > DMARC assumes an author to setup and apply DKIM signing. > > Apart from that: be very careful when using only SPF in > combination with DMARC: please take into account that for DMARC > there's no difference between an SPF -all, ~all and ?all > situation. None of them provide a 'pass' for DMARC, if I read the > spec correctly. > > No, > > If the policy is p=none, DMARC should not override the SPF policy > (especially for -all), DMARC with p=none, does not change the way the > email is treated in regards of SPF or ADSP. If p!=none then DMARC > tells the receiver to not action on the SPF policy and tell the > receiver to ignore ADSP, as DMARC will now tell how to handle the email. Please re-read my message. I didn't mentioned a 'DMARC pass', I mentioned the result of SPF as input to the DMARC decision process. In that regard, neither SPF -all, nor ~all nor ?all give an 'SPF pass' input to DMARC. In addition to that, if the DNS lookup for the SPF record fails, it's up to the receiver to decide to give a tmpfail or a permanent fail. That was the reason I said: be careful when applying the combination SPF + DMARC without DKIM, as it may result in rejection of valid mail (in case p!=none). > > However, regardless of the DMARC p=, DMARC takes the result of the SPF > test (pass, soffail, fail,...) and if there is a pass, compare the > domain used by SPF for its pass with the domain in the From:. If there > is alignment then you have a DMARC pass. You don't need DKIM to have a > DMARC pass. > > you need to do SPF and DKIM on all your emails for p!=none, because in > some cases SPF is more suitable than DKIM and vice versa, so you want > the benefit of both. Right. /rolf --------------010703010008070802070609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/28/2014 12:45 AM, Franck Martin wrote:

From: "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl>
To: "George Moje" <George.Moje@computershare.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Sent: Monday, January 27, 2014 3:04:13 PM
Subject: Re: [dmarc-ietf] DMARC implementation Question

On 01/24/2014 02:18 PM, George Moje wrote:

Currently we are using SPF records but no DKIM.  Can we implement DMARC with just SPF records?


according to par. 3.1.3 of the DMARC spec (https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base) DMARC assumes an author to setup and apply DKIM signing.

Apart from that: be very careful when using only SPF in combination with DMARC: please take into account that for DMARC there's no difference between an SPF -all, ~all and ?all situation. None of them provide a 'pass' for DMARC, if I read the spec correctly.
No,

If the policy is p=none, DMARC should not override the SPF policy (especially for -all), DMARC with p=none, does not change the way the email is treated in regards of SPF or ADSP. If p!=none then DMARC tells the receiver to not action on the SPF policy and tell the receiver to ignore ADSP, as DMARC will now tell how to handle the email.

Please re-read my message. I didn't mentioned a 'DMARC pass', I mentioned the result of SPF as input to the DMARC decision process. In that regard, neither SPF -all, nor ~all nor ?all give an 'SPF pass' input to DMARC. In addition to that, if the DNS lookup for the SPF record fails, it's up to the receiver to decide to give a tmpfail or a permanent fail. That was the reason I said: be careful when applying the combination SPF + DMARC without DKIM, as it may result in rejection of valid mail (in case p!=none).


However, regardless of the DMARC p=, DMARC takes the result of the SPF test (pass, soffail, fail,...) and if there is a pass, compare the domain used by SPF for its pass with the domain in the From:. If there is alignment then you have a DMARC pass. You don't need DKIM to have a DMARC pass.

you need to do SPF and DKIM on all your emails for p!=none, because in some cases SPF is more suitable than DKIM and vice versa, so you want the benefit of both.

Right.

/rolf

--------------010703010008070802070609-- From roland@rolandturner.com Mon Jan 27 23:10:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2B1A01C9 for ; Mon, 27 Jan 2014 23:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5ij2h2W2KfP for ; Mon, 27 Jan 2014 23:10:13 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4871A0161 for ; Mon, 27 Jan 2014 23:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=JckAo1nGUCXbxyojiIYUTggRJSVck3JXXIuPZMprZ1s=; b=gUzWWvG1Ov0uYD5df2zD6C/xO1e8BKYaND0jlDYGWcogSSLZ9PPxZyE3RtGc7LXDAC6VhLAOXkoJladYTsEKj36oYE7g4KnwXj4D4Khzi/otkB3SLJI2sKZOi/y2e/NDluKIMaRXb6DI2iO9KtlABa/WnIvvqCxTz2BAX6NtWzo=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=46932 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W82o4-0008UH-6s; Tue, 28 Jan 2014 07:10:00 +0000 Message-ID: <52E757C7.50600@rolandturner.com> Date: Tue, 28 Jan 2014 15:09:59 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, Franck Martin References: <52E6E5ED.8060504@sonnection.nl> <488678367.715.1390866317515.JavaMail.zimbra@peachymango.org> <52E753A1.2090302@sonnection.nl> In-Reply-To: <52E753A1.2090302@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: George Moje , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Jan 2014 07:10:16 -0000 On 01/28/2014 02:52 PM, Rolf E. Sonneveld wrote: > Please re-read my message. I didn't mentioned a 'DMARC pass', I > mentioned the result of SPF as input to the DMARC decision process. In > that regard, neither SPF -all, nor ~all nor ?all give an 'SPF pass' > input to DMARC. While it is literally true that -all/~all/?all don't yield passes, this is not how most people would interpret your message: it comes across as though you are trying to claim that an SPF record with -all/~all/?all at the end of it can't yield a pass despite that clearly not being true (any SPF pass being a result of an earlier part of the record). In either case, this does not affect DMARC operation. When SPF evaluation passes, DMARC interprets that as a pass (for the 5321.MailFrom domain), regardless of which of -all/~all/?all is used, or even if none of them are used. It would be rather unusual to implement DMARC without DKIM, but is not impossible. I'd suggest that the more important question is what the OP is trying to achieve with DMARC in the first place. Given that they don't have DKIM implemented they presumably don't have a spoofing problem, in which case DMARC is of limited value other than for monitoring (in which case the absence of DKIM isn't a problem). - Roland From R.E.Sonneveld@sonnection.nl Tue Jan 28 15:34:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FB91A0378 for ; Tue, 28 Jan 2014 15:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njDY7pn_ZwqE for ; Tue, 28 Jan 2014 15:34:21 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 271BF1A036C for ; Tue, 28 Jan 2014 15:34:21 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3fDPL16Lq3z5Mhc9; Wed, 29 Jan 2014 00:34:17 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3fDPL159sKz1L8fM; Wed, 29 Jan 2014 00:34:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 3D525123299; Wed, 29 Jan 2014 00:34:16 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BqaLRlb0P58F; Wed, 29 Jan 2014 00:33:58 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id D26FB1231FB; Wed, 29 Jan 2014 00:33:53 +0100 (CET) Message-ID: <52E83E61.70802@sonnection.nl> Date: Wed, 29 Jan 2014 00:33:53 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Roland Turner , Franck Martin References: <52E6E5ED.8060504@sonnection.nl> <488678367.715.1390866317515.JavaMail.zimbra@peachymango.org> <52E753A1.2090302@sonnection.nl> <52E757C7.50600@rolandturner.com> In-Reply-To: <52E757C7.50600@rolandturner.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1390952057; bh=gpDLm+1zGYT2nPhkNKCa55DdKkPFVsz8/N+ntZhBeaE=; h=Message-ID:Date:From:To:Subject:From; b=kqeED8UNhQ4jjTUA1Ih7iEBYLlkRdMQF939LMK9mlPlX8xq7sqHkX3nzTUu69XwNv LXHhPw/WL/lIwSuvCs8Rdq47ORY9oOj2LWdzBCoM/bazgqvYHmx/aZNZVwT8UFfiPL acvPZVePEEl2X5hlr9fctvsz49LwJYlpOsvstXYs= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3fDPL16Lq3z5Mhc9 Cc: George Moje , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:34:24 -0000 On 01/28/2014 08:09 AM, Roland Turner wrote: > On 01/28/2014 02:52 PM, Rolf E. Sonneveld wrote: > >> Please re-read my message. I didn't mentioned a 'DMARC pass', I >> mentioned the result of SPF as input to the DMARC decision process. >> In that regard, neither SPF -all, nor ~all nor ?all give an 'SPF >> pass' input to DMARC. > > While it is literally true that -all/~all/?all don't yield passes, > this is not how most people would interpret your message: it comes > across as though you are trying to claim that an SPF record with > -all/~all/?all at the end of it can't yield a pass despite that > clearly not being true (any SPF pass being a result of an earlier part > of the record). > > In either case, this does not affect DMARC operation. My point is, that SPF is far from perfect and that, when only applying SPF (see OP question) DMARC will cause collateral damage for a small percentage of all mail (typical mail that has been auto-forwarded etc.). For those messages, an SPF -all/~all/?all in itself won't hurt (in general), but DMARC will (due to the SPF result). And while some of you may find 0.5% - 1% lost mail negligible, I don't. If anyone has more accurate figures, please let us all know. > When SPF evaluation passes, DMARC interprets that as a pass (for the > 5321.MailFrom domain), regardless of which of -all/~all/?all is used, > or even if none of them are used. It would be rather unusual to > implement DMARC without DKIM, but is not impossible. Of course it's not impossible, it depends on what percentage of lost mail is acceptable to the sender... > > I'd suggest that the more important question is what the OP is trying > to achieve with DMARC in the first place. Given that they don't have > DKIM implemented they presumably don't have a spoofing problem, in > which case DMARC is of limited value other than for monitoring (in > which case the absence of DKIM isn't a problem). Agreed. /rolf From roland@rolandturner.com Tue Jan 28 18:36:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563061A02E8 for ; Tue, 28 Jan 2014 18:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 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, J_CHICKENPOX_14=0.6, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiAPPFsCkEct for ; Tue, 28 Jan 2014 18:36:27 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 39C911A02D3 for ; Tue, 28 Jan 2014 18:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=NNCmDwZBz45CIyTAIOOz3qLu3cAFr8FpPfdfNXq3VUY=; b=dL5JpacguiGEBVQZTR9ALZimXnSE3Ml/TqEAleIUPkA6I7ce91zdQKrEGmJyIBAuL9r5S+O1Yn6LhFpSVbacdLzc8QWVCxJ4WWQMZ6BgY9JdLxxATuokZGq/REzEKsDnYCc7rdJ7L3wTWYzi6WQbJ/rbPI9AIe/w0kY9jU9Guuo=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=51471 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W8L0l-0000YQ-QI; Wed, 29 Jan 2014 02:36:22 +0000 Message-ID: <52E86923.7090101@rolandturner.com> Date: Wed, 29 Jan 2014 10:36:19 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: George Moje , "'dmarc@ietf.org'" References: <52E74612.3070106@rolandturner.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050409050506090101070107" Subject: Re: [dmarc-ietf] DMARC implementation Question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 02:36:29 -0000 This is a multi-part message in MIME format. --------------050409050506090101070107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Fascinating. It's been apparent for a while that several larger receivers require neighbourly behaviour as a condition for being given the benefit of any doubt; in particular it's taken for granted that you're taking abuse feedback loops and acting on them. This is the first time that I've heard about a comparable insistence relating to DMARC feedback. Are you being asked merely to publish a DMARC record with p=none and rua=somewhere so that feedback can be seen to be sent, or is there an expectation that you'll also improve your authentication coverage? If the latter, you'll almost certainly need to implement DKIM too. - Roland On 01/28/2014 08:32 PM, George Moje wrote: > > Thanks Roland. The major reason is we send bulk mailings to customers > and one hosted email provider in particular blacklists us. They are > basically demanding we do this…or something like it. > > *From:*Roland Turner [mailto:roland@rolandturner.com] > *Sent:* Tuesday, January 28, 2014 12:54 AM > *To:* George Moje; 'dmarc@ietf.org' > *Subject:* Re: [dmarc-ietf] DMARC implementation Question > > On 01/24/2014 09:18 PM, George Moje wrote: > > Currently we are using SPF records but no DKIM. Can we implement > DMARC with just SPF records? > > > Absolutely, in fact publishing a DMARC p=none record is a worthwhile > step ahead of implementing SPF or DKIM in that it allows you to > discover quickly (and to monitor) whether you have serious issues with > your deployment. > > A more important question might be this: what are you aiming to > achieve by implementing DMARC? If you've not implemented DKIM, you > presumably don't have a spoofing problem at present. > > - Roland > > ****************************************************************************** > Please visit the following website to read the Computershare legal > notice: http://www.computershare.com/disclaimer/americas/en > > Veuillez visiter le site Web suivant afin de prendre connaissance de > l'avis juridique de Computershare: > http://www.computershare.com/disclaimer/americas/fr > > ****************************************************************************** --------------050409050506090101070107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Fascinating.

It's been apparent for a while that several larger receivers require neighbourly behaviour as a condition for being given the benefit of any doubt; in particular it's taken for granted that you're taking abuse feedback loops and acting on them. This is the first time that I've heard about a comparable insistence relating to DMARC feedback.

Are you being asked merely to publish a DMARC record with p=none and rua=somewhere so that feedback can be seen to be sent, or is there an expectation that you'll also improve your authentication coverage? If the latter, you'll almost certainly need to implement DKIM too.

- Roland



On 01/28/2014 08:32 PM, George Moje wrote:

Thanks Roland. The major reason is we send bulk mailings to customers and one hosted email provider in particular blacklists us. They are basically demanding we do this…or something like it.

 

From: Roland Turner [mailto:roland@rolandturner.com]
Sent: Tuesday, January 28, 2014 12:54 AM
To: George Moje; 'dmarc@ietf.org'
Subject: Re: [dmarc-ietf] DMARC implementation Question

 

On 01/24/2014 09:18 PM, George Moje wrote:

Currently we are using SPF records but no DKIM.  Can we implement DMARC with just SPF records?


Absolutely, in fact publishing a DMARC p=none record is a worthwhile step ahead of implementing SPF or DKIM in that it allows you to discover quickly (and to monitor) whether you have serious issues with your deployment.

A more important question might be this: what are you aiming to achieve by implementing DMARC? If you've not implemented DKIM, you presumably don't have a spoofing problem at present.

- Roland

******************************************************************************
Please visit the following website to read the Computershare legal notice: http://www.computershare.com/disclaimer/americas/en

Veuillez visiter le site Web suivant afin de prendre connaissance de l'avis juridique de Computershare: http://www.computershare.com/disclaimer/americas/fr

******************************************************************************

--------------050409050506090101070107-- From kurt@roeckx.be Thu Jan 30 14:03:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B71A04B2 for ; Thu, 30 Jan 2014 14:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIMNnkY1mor7 for ; Thu, 30 Jan 2014 14:03:37 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 494D31A0489 for ; Thu, 30 Jan 2014 14:03:35 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id D274E1C215E for ; Thu, 30 Jan 2014 23:03:30 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id A3DC41FE0279; Thu, 30 Jan 2014 23:03:30 +0100 (CET) Date: Thu, 30 Jan 2014 23:03:30 +0100 From: Kurt Roeckx To: dmarc@ietf.org Message-ID: <20140130220330.GA25608@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:03:38 -0000 Hi, I'm pretty new to DMARC, and I'm really confused about this alignment thing. Can someone explain to me why this is needed? SPF is not designed to do anything with the headers. SPF is known to break forwarding if you don't change the mail from in the envelope. So if you properly implement forwarding to work with SPF you change the envelope sender. But now DMARC seems check that the envelope sender matches the header's From, and then claim the SPF check failed because they don't align, while the SPF check could have any other result. This doesn't make any sense to me. Why is this check needed? Why do you want to break forwarding even more? It seems to me that the only thing DMARC is useful for is the reporting part, I can't imagine anybody wanting to run with something other than p=none that cares that about the mails actually reaching their destination. Please don't say that DKIM is a fallback. 90% of the e-mails with DKIM that I receive have a bad DKIM signature. Kurt From fenton@bluepopcorn.net Thu Jan 30 14:10:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647331A04F9 for ; Thu, 30 Jan 2014 14:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLVgotYeA4Kq for ; Thu, 30 Jan 2014 14:10:16 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id DAA001A04EA for ; Thu, 30 Jan 2014 14:10:16 -0800 (PST) Received: from splunge.local ([205.154.255.239]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s0UMACu5029196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jan 2014 14:10:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1391119813; bh=wj6BkKDRj5We6ag4G7kRU/F2tkICMrXlQptEPR0Z5Vw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MzYuSEOHdu0o1bENdeMBwPNCzTTQ4TsK18hWCanWbaQwFqlMD6G4obgtGdbLlaAl9 EcS7YD4SrGB7HL/khfjfLZqI1stcdC3d3S7covZuBVN65S1fGN2wgNONFWFW3m2/7K HM2+cT/HnrEKte3rqXeuHbkaASbr8Mes2GEc0pds= Message-ID: <52EACDBF.2050003@bluepopcorn.net> Date: Thu, 30 Jan 2014 14:10:07 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kurt Roeckx , dmarc@ietf.org References: <20140130220330.GA25608@roeckx.be> In-Reply-To: <20140130220330.GA25608@roeckx.be> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:10:18 -0000 On 1/30/14 2:03 PM, Kurt Roeckx wrote: > Please don't say that DKIM is a fallback. 90% of the e-mails > with DKIM that I receive have a bad DKIM signature. > > Wow, that seems really high. These are legitimate messages? If spoofed messages are failing verification, that's a feature. -Jim From sca@andreasschulze.de Thu Jan 30 14:21:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA881A04FC for ; Thu, 30 Jan 2014 14:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZOQjxzdzyZd for ; Thu, 30 Jan 2014 14:21:37 -0800 (PST) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8B71A1A04DA for ; Thu, 30 Jan 2014 14:21:37 -0800 (PST) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1391120488; bh=2d1Wi1Q7xdJffQzB4W2zzrkpZfauVGirW6JiP9egTi4=; h=Date:From:To:Subject:References:In-Reply-To; b=fjX0OUCFpf/ZVGa8UWFg60NG38pzrRDGEyg6+QHbpM0tkKzMXVHKG6VZc5gDgcRYF kMdiIAnnjlu+hchRy/6Y9qhoG++Y+34FC8PGlo/iataxLryGAlXp1pdlfmlcJs1pat zdLInPd50ou0doL9a2BgqHBZ7OjeaBsYt3ICEP54tYu4XC0WyCpHUWcukn8a5vVZQP 77481sSaShsrAKC+dOWMVgCvQJyVHjv0wStzSujJiR4COfrw6RS39taXMVEiAgXa/H gAmmF9+ReIHisT4nZ4mHKn95GkDLT1rqBoF/v7eCnaneXuBnyLCWLsYniN3LEd9hdo dmL0ZfXH2esq8ctvxYjdTvn0U8rlhdc6nIYq6Ze2b4E0fuMKH+EPkoTXT0UWPtTgkN 7M1xClF/6/M/r+ulspct09D/WCtuhW6vrKiU42yni+P8mcq/7gtPpnh1o9TpxyP/CB fcGIWWstSWUhpTmvxnu5JmJUdnkKgdRmrlOOIMAIVzgdNpFqLhk305Q8bqyY6JO+Ag gtrM+/wNoU+U/GHcKWqvhjZ5Ue/zAOhdT/O23Fbr089z+kg6jT2WqMzIu+yaOQL9eV WpPSB9wDeLMz8niM5QIYelpdztz3DrfNH/CZUoJB3b2JNCccINFB2gsrQvQL35+yov RiSPVpes9zMTReio84BQi3G8= X-Received: line deleted by mout Date: Thu, 30 Jan 2014 23:21:26 +0100 Message-ID: <20140130232126.Horde.SsNVci4XXGKo9OOQkIcWlg1@horde.andreasschulze.de> From: Andreas Schulze To: dmarc@ietf.org References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> In-Reply-To: <52EACDBF.2050003@bluepopcorn.net> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:21:39 -0000 Jim Fenton: > Wow, that seems really high. These are legitimate messages? I guess, he's simply receiving many mailing-lists :-/ Andreas From matt@tnpi.net Thu Jan 30 14:22:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE231A04F4 for ; Thu, 30 Jan 2014 14:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceZTmZRUhcdV for ; Thu, 30 Jan 2014 14:22:35 -0800 (PST) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B21A04CC for ; Thu, 30 Jan 2014 14:22:35 -0800 (PST) Received: (qmail 27387 invoked by uid 1026); 30 Jan 2014 22:22:32 -0000 Received: from c-67-171-0-90.hsd1.wa.comcast.net (HELO [10.0.1.141]) (67.171.0.90) by mail.theartfarm.com (qpsmtpd/0.94) with (AES128-SHA encrypted) ESMTPSA; Thu, 30 Jan 2014 17:22:32 -0500 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.98.1 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:content-transfer-encoding:message-id:references:to; s=mar2013; bh=g3YP9uWNkmuKsmysNHhnKLmgOYqRvlPbqc6+n5EVHj4=; b=fQg84EMkF0bANAFRakB4gk5eYYCIsVzO/Uhj/TST/6COdkHfcJi5Sb3lZPEcfstpSwvwqtEdm+m+BQ/msfaF+njOGLCGPlQKh3LhGFzsmgJYEm6W2KSAI95MezmC9/8KJHv/7Yh64Y0xkvjVOB14X5RmDeEajkqXW/7/5WdKPT8qEKeVEF02VNVbw7S9GyPrKJvlAtGVWEYqrzfSDfIpgPGSLqpYuuiflI/otY4KNTPpJ3oVJ10QHP2O8KQHH1XyvLfE6oKtQbZDclcWKqjyVHqYe7sv26DlZ7yRaByI73Vlj4UT3cmewQQHRTB15P+pbZHN8Swk+339oN+Mmbtzrw== X-HELO: [10.0.1.141] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Matt Simerson In-Reply-To: <20140130220330.GA25608@roeckx.be> Date: Thu, 30 Jan 2014 14:22:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140130220330.GA25608@roeckx.be> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1827) Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:22:37 -0000 On Jan 30, 2014, at 2:03 PM, Kurt Roeckx wrote: > Hi, > Please don't say that DKIM is a fallback. 90% of the e-mails > with DKIM that I receive have a bad DKIM signature. Interesting. My experience is just the opposite. I should also note that 90% of emails get rejected long before I try to = validate the DKIM signature.=20 Matt From kurt@roeckx.be Thu Jan 30 14:23:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736051A04F4 for ; Thu, 30 Jan 2014 14:23:25 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id takxEFD4oWIR for ; Thu, 30 Jan 2014 14:23:24 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D21A04CC for ; Thu, 30 Jan 2014 14:23:24 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 5E2791C215E; Thu, 30 Jan 2014 23:23:20 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 40EA51FE0279; Thu, 30 Jan 2014 23:23:20 +0100 (CET) Date: Thu, 30 Jan 2014 23:23:20 +0100 From: Kurt Roeckx To: Jim Fenton Message-ID: <20140130222320.GB25641@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EACDBF.2050003@bluepopcorn.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:23:25 -0000 On Thu, Jan 30, 2014 at 02:10:07PM -0800, Jim Fenton wrote: > On 1/30/14 2:03 PM, Kurt Roeckx wrote: > > Please don't say that DKIM is a fallback. 90% of the e-mails > > with DKIM that I receive have a bad DKIM signature. > Wow, that seems really high. These are legitimate messages? Yes, those are real messages. Kurt From franck@peachymango.org Thu Jan 30 14:39:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5A11A04DA for ; Thu, 30 Jan 2014 14:39:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CWSOHS1uxTu for ; Thu, 30 Jan 2014 14:39:52 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D01A039C for ; Thu, 30 Jan 2014 14:39:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6DC0B3983E8; Thu, 30 Jan 2014 16:39:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxYpVfpSHNDJ; Thu, 30 Jan 2014 16:39:49 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 50193398459; Thu, 30 Jan 2014 16:39:49 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 42918398458; Thu, 30 Jan 2014 16:39:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tYL82oSpaqSM; Thu, 30 Jan 2014 16:39:49 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 156023983E8; Thu, 30 Jan 2014 16:39:49 -0600 (CST) Date: Thu, 30 Jan 2014 16:39:48 -0600 (CST) From: Franck Martin To: Kurt Roeckx Message-ID: <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: dmarc and forwarding Thread-Index: cwAnl+Zafp2nIw26cisTgDmaz9pdIw== Cc: Jim Fenton , dmarc@ietf.org Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:39:54 -0000 ----- Original Message ----- > From: "Kurt Roeckx" > To: "Jim Fenton" > Cc: dmarc@ietf.org > Sent: Thursday, January 30, 2014 2:23:20 PM > Subject: Re: [dmarc-ietf] dmarc and forwarding > > On Thu, Jan 30, 2014 at 02:10:07PM -0800, Jim Fenton wrote: > > On 1/30/14 2:03 PM, Kurt Roeckx wrote: > > > Please don't say that DKIM is a fallback. 90% of the e-mails > > > with DKIM that I receive have a bad DKIM signature. > > Wow, that seems really high. These are legitimate messages? > > Yes, those are real messages. > It seems to me that all the emails sent to you go via first an email gateway before landing on your mail server Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D21A04CC for ; Thu, 30 Jan 2014 14:23:24 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 5E2791C215E; Thu, 30 Jan 2014 23:23:20 +0100 (CET) And the MX for your domain seems to confirm that It is not uncommon to find gateways that rewrite the message therefore breaking DKIM. Please request defiant.e-webshops.eu to not modify the email while in transit (likely just changing the encoding) From kurt@roeckx.be Thu Jan 30 14:51:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EA71A04DD for ; Thu, 30 Jan 2014 14:51:58 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idxOTOOZZi2C for ; Thu, 30 Jan 2014 14:51:57 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id F3EA91A04DE for ; Thu, 30 Jan 2014 14:51:56 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 20C751C215E; Thu, 30 Jan 2014 23:51:53 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 099F91FE0279; Thu, 30 Jan 2014 23:51:52 +0100 (CET) Date: Thu, 30 Jan 2014 23:51:52 +0100 From: Kurt Roeckx To: Franck Martin Message-ID: <20140130225152.GA27685@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jim Fenton , dmarc@ietf.org Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:51:58 -0000 On Thu, Jan 30, 2014 at 04:39:48PM -0600, Franck Martin wrote: > > > > > ----- Original Message ----- > > From: "Kurt Roeckx" > > To: "Jim Fenton" > > Cc: dmarc@ietf.org > > Sent: Thursday, January 30, 2014 2:23:20 PM > > Subject: Re: [dmarc-ietf] dmarc and forwarding > > > > On Thu, Jan 30, 2014 at 02:10:07PM -0800, Jim Fenton wrote: > > > On 1/30/14 2:03 PM, Kurt Roeckx wrote: > > > > Please don't say that DKIM is a fallback. 90% of the e-mails > > > > with DKIM that I receive have a bad DKIM signature. > > > Wow, that seems really high. These are legitimate messages? > > > > Yes, those are real messages. > > > > It seems to me that all the emails sent to you go via first an email gateway before landing on your mail server It seems to me that this part of the discussion is not useful at all, and doesn't answer any of the questions I had. It's also not important where or why it breaks, since I suspect this nothing that is new. But I'm also pretty sure it's none of my hosts that break it. If you really feel like discussing this I suggest we take that to somewhere else. PS: I strongly suggest you all stop using anything lower than 2048 bit to do DKIM. Kurt From superuser@gmail.com Thu Jan 30 15:53:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3BB1A04DB for ; Thu, 30 Jan 2014 15:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErAUxWodQ1m9 for ; Thu, 30 Jan 2014 15:53:55 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7F1A04DD for ; Thu, 30 Jan 2014 15:53:55 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kq14so3770072pab.17 for ; Thu, 30 Jan 2014 15:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vOb3vV1XGFSrk3C0imPe2mwRoJfPtRtHo+x7WfCsG74=; b=uIQu1dDRHwO5KEdOlnku3Nniq8iRxooF0OfmerRUBhP3qyf0FygB7Th+vS03NyhBeo PN4CYCDtDGH8j6wFLwrBhWuSDKAcizhtvq4ONT1r/JIm7eTBEZ6B3SSB1cb0KuecAM/Z zYexuY11oYesBJccIuI4uD2CxzvFlcbJApdLePQQWDaNgj5J5AaSQyGK1vZfR2xYoUN5 YIEG5+GbIJZLEP0dgCy9IsrhtlVQFg58tj/3CWj8LddRW9uGpg7/DlgB2Sc+7osJh3rF XOIjrCT2j/Sq9eDkSlSXUM3hAlAN1htYRJFBuOihJlsnSaGexBhpnGmp51VOi2skDeWn OmLg== MIME-Version: 1.0 X-Received: by 10.66.118.71 with SMTP id kk7mr17403181pab.14.1391126032008; Thu, 30 Jan 2014 15:53:52 -0800 (PST) Received: by 10.66.234.105 with HTTP; Thu, 30 Jan 2014 15:53:51 -0800 (PST) In-Reply-To: <20140130225152.GA27685@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> Date: Thu, 30 Jan 2014 15:53:51 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Roeckx Content-Type: multipart/alternative; boundary=e89a8ffbad05f9ce2504f138c4a6 Cc: Jim Fenton , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 23:53:56 -0000 --e89a8ffbad05f9ce2504f138c4a6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 30, 2014 at 2:51 PM, Kurt Roeckx wrote: > > It seems to me that this part of the discussion is not useful at > all, and doesn't answer any of the questions I had. It's also not > important where or why it breaks, since I suspect this nothing > that is new. But I'm also pretty sure it's none of my hosts that > break it. If you really feel like discussing this I suggest we > take that to somewhere else. > > I don't agree, since DMARC is predicated in part on the notion that DKIM has become sufficiently reliable in general as to be a viable building block upon which to build things like DMARC. Your question is based on the idea that your experience is the opposite. Naturally, we're curious. I believe the questions you're getting are actually attempts to help. Are you sure swatting their hands is the right response? -MSK --e89a8ffbad05f9ce2504f138c4a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 30, 2014 at 2:51 PM, Kurt Roeckx <kurt@roeckx.be= > wrote:

It seems to me that this part of the discussion is not useful at
all, and doesn't answer any of the questions I had. =A0It's also no= t
important where or why it breaks, since I suspect this nothing
that is new. =A0But I'm also pretty sure it's none of my hosts that=
break it. =A0If you really feel like discussing this I suggest we
take that to somewhere else.


I don't agree, since DMARC is pred= icated in part on the notion that DKIM has become sufficiently reliable in = general as to be a viable building block upon which to build things like DM= ARC.=A0 Your question is based on the idea that your experience is the oppo= site.=A0 Naturally, we're curious.

I believe the questions you're getting are actually atte= mpts to help.=A0 Are you sure swatting their hands is the right response?
-MSK

--e89a8ffbad05f9ce2504f138c4a6-- From kurt@roeckx.be Thu Jan 30 16:17:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2A1A051E for ; Thu, 30 Jan 2014 16:17:38 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE_aHtGfOQd6 for ; Thu, 30 Jan 2014 16:17:36 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8555B1A051F for ; Thu, 30 Jan 2014 16:17:36 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 9F8EF1C215E; Fri, 31 Jan 2014 01:17:32 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6F5621FE077A; Fri, 31 Jan 2014 01:17:32 +0100 (CET) Date: Fri, 31 Jan 2014 01:17:32 +0100 From: Kurt Roeckx To: "Murray S. Kucherawy" Message-ID: <20140131001732.GA29928@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jim Fenton , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 00:17:38 -0000 On Thu, Jan 30, 2014 at 03:53:51PM -0800, Murray S. Kucherawy wrote: > I don't agree, since DMARC is predicated in part on the notion that DKIM > has become sufficiently reliable in general as to be a viable building > block upon which to build things like DMARC. Your question is based on the > idea that your experience is the opposite. Naturally, we're curious. > > I believe the questions you're getting are actually attempts to help. Are > you sure swatting their hands is the right response? It's my understanding that in general about 90% of the DKIM mails have a bad signature. It's also my understanding that were DKIM tends to fail, SPF tends to work and the other way around. But DMARC seems to combining the two in such a way it's more than likely to have a failure as result instead of a pass. Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant. Kurt From kurt@roeckx.be Thu Jan 30 16:23:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5CB1A04F1 for ; Thu, 30 Jan 2014 16:23:25 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spu2ipqNGqn6 for ; Thu, 30 Jan 2014 16:23:24 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9D1A04EE for ; Thu, 30 Jan 2014 16:23:24 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 6427F1C215E for ; Fri, 31 Jan 2014 01:23:20 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 4CA601FE077A; Fri, 31 Jan 2014 01:23:20 +0100 (CET) Date: Fri, 31 Jan 2014 01:23:20 +0100 From: Kurt Roeckx To: dmarc@ietf.org Message-ID: <20140131002320.GB29928@roeckx.be> References: <20140130220330.GA25608@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140130220330.GA25608@roeckx.be> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 00:23:26 -0000 On Thu, Jan 30, 2014 at 11:03:30PM +0100, Kurt Roeckx wrote: > Hi, > > I'm pretty new to DMARC, and I'm really confused about this > alignment thing. Can someone explain to me why this is needed? I a question that might be related. If I send a mail from domain A to B, and B forwards it to C after rewriting the enveloppe, and both A and B have DMARC set up to receive reports, should C send a report to both A and B? Kurt From roland@rolandturner.com Thu Jan 30 18:39:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59C31A04F3 for ; Thu, 30 Jan 2014 18:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 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, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PUm_IM6B3r1 for ; Thu, 30 Jan 2014 18:39:04 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id F1D261A04F1 for ; Thu, 30 Jan 2014 18:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=peyOIFJiFYvlKGQ8MAb3t8cf24DSM29Tr1EHNsrdAGI=; b=XggcSF6gvXTexfd4l4Kmq/6JVQzJFFjMPvWgFNQvg8CNayGNhEbXCWPiZUZUYJQVlkS21uY8VAc4FWkRGSx6vIe6gk0PZcvM7ePoXuQvg3LoWJLBW9WS1fmkB6DgUlJgWjO7Ib4fbYKo2n0DhBMyUr+ktD0eibayKr/TdC6o0h4=; Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=222.165.46.240; iprev=pass policy.iprev=222.165.46.240 (cm240.theta46.maxonline.com.sg) Received: from [222.165.46.240] (port=39040 helo=[10.1.132.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W940O-00021G-83; Fri, 31 Jan 2014 02:38:58 +0000 Message-ID: <52EB0CBF.9020607@rolandturner.com> Date: Fri, 31 Jan 2014 10:38:55 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kurt Roeckx , dmarc@ietf.org References: <20140130220330.GA25608@roeckx.be> In-Reply-To: <20140130220330.GA25608@roeckx.be> Content-Type: multipart/alternative; boundary="------------030908000101020004000406" Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 02:39:08 -0000 This is a multi-part message in MIME format. --------------030908000101020004000406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Kurt, On 01/31/2014 06:03 AM, Kurt Roeckx wrote: > Hi, > > I'm pretty new to DMARC, and I'm really confused about this > alignment thing. Can someone explain to me why this is needed? Loosely speaking, DMARC's objective is to frustrate spoofing. The relevant domain is therefore the one in the email address that end-users see, which is almost always the 5322.From address rather than the 5321.MailFrom address. On the face of it, this is therefore a job for DKIM rather than SPF, however at the time that DMARC was developed DKIM coverage was minimal (somewhere under 5% of legitimate email) while SPF already covered the majority of legitimate email (somewhere above 60%, depending whose numbers you look at). Consequently, it was sensible to look into ways to make use of the existing SPF deployment to progress DMARC's objective. The obvious problem was that SPF doesn't test the 5322.From domain, however in direct delivery cases it is common for SPF to pass and for the 5321.MailFrom domain and the 5322.From domain to "match" (either be the same, or obviously belong to the same organisation), in which case an SPF pass could reasonably be considered sufficient basis for treating the message as authentic. To understand why an alignment rule was required in the first place, consider what could happen without one: a spoofer could send the following and arrange appropriate DNS records for SPF to pass: MAIL FROM: ... From: PayPal however this should not be considered authentic: the end-user would see it as a message from PayPal when, clearly, it's not. To understand why an alignment rule rather than an exact match, consider this case: MAIL FROM: ... From: Good Guy An SPF pass for marketing.goodguy.example is ordinarily sufficient reason for considering this message authentic for goodguy.example. That said, some Domain Owners don't want to operate this way, so DMARC includes the means for them to use different policies for different sub-domains. > SPF is not designed to do anything with the headers. SPF is known > to break forwarding if you don't change the mail from in the > envelope. So if you properly implement forwarding to work with > SPF you change the envelope sender. I'd suggest being careful with the use words that impart a judgemental slant: forwarders who aren't changing the return path in order to help SPF work aren't doing anything "improper", they're simply doing what they're doing. It is in the interests of Domain Owners and receivers who want to tackle the spoofing problem to deal with the world as it as, rather than pretend a simplified form that would make their lives easier; forwarders who don't point return paths to themselves are part of the real world. (It is not usually sensible to respond to tone, I'm addressing it in this case it appears to be affecting your understanding of the facts.) At the time the SPF was developed, it was assumed that it was reasonable to "require" each forwarder in a forwarding path to take responsibility for what they forwarded by pointing return paths at themselves. This fell down for two reasons: * Depending upon every forwarder in the world to implement your experiment in order for it to succeed turns out to be foolishly impractical. * Formalising a way to do this (SRS) that didn't itself create a new abuse vector ended up failing to achieve what was intended because of the impracticality of return paths containing the entire reverse path (count the Received: headers in messages in your archive sometime...) so it fell to just two hops (SRS0 and SRS1) anyway. Consequently, the approach that you're describing as "proper" is impractical, dangerous, or both. For this reason, almost no-one does it. > But now DMARC seems check that > the envelope sender matches the header's From, and then claim the > SPF check failed because they don't align, while the SPF check > could have any other result. DMARC makes no claim about whether SPF passes or fails. SPF's passing or failing is an _*input*_ to DMARC, not an output. For the reasons explained above, an SPF pass for a domain not aligned to the 5322.From domain is simply treated by DMARC as not being evidence of message authenticity. > This doesn't make any sense to me. > Why is this check needed? Why do you want to break forwarding > even more? Nothing about this breaks - nor even affects - forwarding. (Note that this observation holds true even in a hypothetical environment in which changing the return path is considered a normal part of forwarding: a receiver who privileges a forwarded message simply because SPF passes as a result of the return path changing is inviting spoofers to pretend to forward their attacks, per the spoofer.example example above.) > It seems to me that the only thing DMARC is useful for is the > reporting part, I can't imagine anybody wanting to run with > something other than p=none that cares that about the mails > actually reaching their destination. As a Domain Owner, if you're not being heavily spoofed then you should not use p=(quarantine|reject). These two policies carry a non-zero risk of message loss - albeit a far smaller risk than you appear to assume - so it needs to be the case that the benefit that you're gaining in frustrating spoofing exceeds the cost in having a tiny fraction of your messages go away. DMARC is not the FUSSP, it is a pragmatic tool that solves a very large, very expensive problem for a small class of Domain Owners and - eventually - a large class of receivers. Like many useful tools it has side-effects, so there are trade-offs to consider in deciding whether and how to use it. For the rest of us, the reporting provided by p=none is a useful monitoring tool for a range of other uses. > Please don't say that DKIM is a fallback. It is SPF that is the fallback, not DKIM. SPF is only used by DMARC at all because of the limited adoption of DKIM and broad adoption of SPF at the time that DMARC was developed. The complexity that using SPF introduces would otherwise not have been warranted. > 90% of the e-mails > with DKIM that I receive have a bad DKIM signature. This suggests one (or more) of the following: * You are including spoofed email in that number. If so, this is hardly a critique of DKIM! * You are including email forwarded by "non-participating" MLMs (RFC 6377) or other forwarders which alter messages in transit in ways which break DKIM. The need to special-case these is well-understood; look for a ReasonCode of mailing-list (or similar) in aggregate reports. Fortunately these are small in number, not moving much and are not an effective vector for spoofers. * Per Frank's suggestion, the problem may be at your own MX. If so, note that the relevant question for DMARC is whether DKIM passes at the point where it reaches the MX. This is part of the reason for Authentication-Results headers; subject to various trust and security constraints, they can be used to perform decision making downstream. * Your DKIM deployment is broken. (Possible, particularly if you're (a) evaluating downstream of your MX and (b) your MX is altering messages in such a way as to invalidate many DKIM signatures. Another possibility is a DNS resolver issue.) * Your DKIM implementation is broken. This is improbable but worth checking. On 01/31/2014 08:17 AM, Kurt Roeckx wrote: > It's my understanding that in general about 90% of the DKIM mails > have a bad signature. Give or take the points above, your understanding is simply not correct. See http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.html for recent real-world data. In fact just over three quarters of legitimate email has a valid DKIM signature on it. > It's also my understanding that were DKIM > tends to fail, SPF tends to work and the other way around. But > DMARC seems to combining the two in such a way it's more than > likely to have a failure as result instead of a pass. As above, that's not correct: * DMARC doesn't affect SPF and DKIM results. * What it does do is apply SPF passes wherever they can reasonably be applied in determining that a message is from whom it tells the end-user it's from (i.e. 5322.From). > Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant. Fair enough. Note that the reason that people are addressing what you are seeing is that you specifically raised what you're seeing ("90% of the e-mails with DKIM that I receive have a bad DKIM signature") as though it were, in fact, relevant. On 01/31/2014 08:23 AM, Kurt Roeckx wrote: > I a question that might be related. If I send a mail from domain A to > B, and B forwards it to C after rewriting the enveloppe, and both A > and B have DMARC set up to receive reports, should C send a report to > both A and B? No, DMARC reports are sent to the address specified by the Domain Owner of the domain appearing in the 5322.From address. A forwarder who is rewriting the envelope isn't affecting this. I hope that this makes things a little clearer? - Roland --------------030908000101020004000406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hi Kurt,

On 01/31/2014 06:03 AM, Kurt Roeckx wrote:
Hi,

I'm pretty new to DMARC, and I'm really confused about this
alignment thing.  Can someone explain to me why this is needed?

Loosely speaking, DMARC's objective is to frustrate spoofing. The relevant domain is therefore the one in the email address that end-users see, which is almost always the 5322.From address rather than the 5321.MailFrom address.

On the face of it, this is therefore a job for DKIM rather than SPF, however at the time that DMARC was developed DKIM coverage was minimal (somewhere under 5% of legitimate email) while SPF already covered the majority of legitimate email (somewhere above 60%, depending whose numbers you look at). Consequently, it was sensible to look into ways to make use of the existing SPF deployment to progress DMARC's objective. The obvious problem was that SPF doesn't test the 5322.From domain, however in direct delivery cases it is common for SPF to pass and for the 5321.MailFrom domain and the 5322.From domain to "match" (either be the same, or obviously belong to the same organisation), in which case an SPF pass could reasonably be considered sufficient basis for treating the message as authentic.

To understand why an alignment rule was required in the first place, consider what could happen without one: a spoofer could send the following and arrange appropriate DNS records for SPF to pass:

MAIL FROM: <noreply@spoofer.example>
...
From: PayPal <someone@paypal.com>

however this should not be considered authentic: the end-user would see it as a message from PayPal when, clearly, it's not.

To understand why an alignment rule rather than an exact match, consider this case:

MAIL FROM: <noreply@marketing.goodguy.example>
...
From: Good Guy <someone@goodguy.example>

An SPF pass for marketing.goodguy.example is ordinarily sufficient reason for considering this message authentic for goodguy.example. That said, some Domain Owners don't want to operate this way, so DMARC includes the means for them to use different policies for different sub-domains.

SPF is not designed to do anything with the headers.  SPF is known
to break forwarding if you don't change the mail from in the
envelope.  So if you properly implement forwarding to work with
SPF you change the envelope sender.

I'd suggest being careful with the use words that impart a judgemental slant: forwarders who aren't changing the return path in order to help SPF work aren't doing anything "improper", they're simply doing what they're doing. It is in the interests of Domain Owners and receivers who want to tackle the spoofing problem to deal with the world as it as, rather than pretend a simplified form that would make their lives easier; forwarders who don't point return paths to themselves are part of the real world.

(It is not usually sensible to respond to tone, I'm addressing it in this case it appears to be affecting your understanding of the facts.)

At the time the SPF was developed, it was assumed that it was reasonable to "require" each forwarder in a forwarding path to take responsibility for what they forwarded by pointing return paths at themselves. This fell down for two reasons:
  • Depending upon every forwarder in the world to implement your experiment in order for it to succeed turns out to be foolishly impractical.
  • Formalising a way to do this (SRS) that didn't itself create a new abuse vector ended up failing to achieve what was intended because of the impracticality of return paths containing the entire reverse path (count the Received: headers in messages in your archive sometime...) so it fell to just two hops (SRS0 and SRS1) anyway.

Consequently, the approach that you're describing as "proper" is impractical, dangerous, or both. For this reason, almost no-one does it.

But now DMARC seems check that
the envelope sender matches the header's From, and then claim the
SPF check failed because they don't align, while the SPF check
could have any other result.

DMARC makes no claim about whether SPF passes or fails. SPF's passing or failing is an input to DMARC, not an output. For the reasons explained above, an SPF pass for a domain not aligned to the 5322.From domain is simply treated by DMARC as not being evidence of message authenticity.

This doesn't make any sense to me.
Why is this check needed?  Why do you want to break forwarding
even more?

Nothing about this breaks - nor even affects - forwarding.

(Note that this observation holds true even in a hypothetical environment in which changing the return path is considered a normal part of forwarding: a receiver who privileges a forwarded message simply because SPF passes as a result of the return path changing is inviting spoofers to pretend to forward their attacks, per the spoofer.example example above.)

It seems to me that the only thing DMARC is useful for is the
reporting part, I can't imagine anybody wanting to run with
something other than p=none that cares that about the mails
actually reaching their destination.

As a Domain Owner, if you're not being heavily spoofed then you should not use p=(quarantine|reject). These two policies carry a non-zero risk of message loss - albeit a far smaller risk than you appear to assume - so it needs to be the case that the benefit that you're gaining in frustrating spoofing exceeds the cost in having a tiny fraction of your messages go away. DMARC is not the FUSSP, it is a pragmatic tool that solves a very large, very expensive problem for a small class of Domain Owners and - eventually - a large class of receivers. Like many useful tools it has side-effects, so there are trade-offs to consider in deciding whether and how to use it.

For the rest of us, the reporting provided by p=none is a useful monitoring tool for a range of other uses.

Please don't say that DKIM is a fallback.

It is SPF that is the fallback, not DKIM.

SPF is only used by DMARC at all because of the limited adoption of DKIM and broad adoption of SPF at the time that DMARC was developed. The complexity that using SPF introduces would otherwise not have been warranted.

90% of the e-mails
with DKIM that I receive have a bad DKIM signature.

This suggests one (or more) of the following:

  • You are including spoofed email in that number. If so, this is hardly a critique of DKIM!
  • You are including email forwarded by "non-participating" MLMs (RFC 6377) or other forwarders which alter messages in transit in ways which break DKIM. The need to special-case these is well-understood; look for a ReasonCode of mailing-list (or similar) in aggregate reports. Fortunately these are small in number, not moving much and are not an effective vector for spoofers.
  • Per Frank's suggestion, the problem may be at your own MX. If so, note that the relevant question for DMARC is whether DKIM passes at the point where it reaches the MX. This is part of the reason for Authentication-Results headers; subject to various trust and security constraints, they can be used to perform decision making downstream.
  • Your DKIM deployment is broken. (Possible, particularly if you're (a) evaluating downstream of your MX and (b) your MX is altering messages in such a way as to invalidate many DKIM signatures. Another possibility is a DNS resolver issue.)
  • Your DKIM implementation is broken. This is improbable but worth checking.

On 01/31/2014 08:17 AM, Kurt Roeckx wrote:
It's my understanding that in general about 90% of the DKIM mails
have a bad signature.

Give or take the points above, your understanding is simply not correct. See http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.html for recent real-world data.

In fact just over three quarters of legitimate email has a valid DKIM signature on it.

It's also my understanding that were DKIM
tends to fail, SPF tends to work and the other way around.  But
DMARC seems to combining the two in such a way it's more than
likely to have a failure as result instead of a pass.

As above, that's not correct:
  • DMARC doesn't affect SPF and DKIM results.
  • What it does do is apply SPF passes wherever they can reasonably be applied in determining that a message is from whom it tells the end-user it's from (i.e. 5322.From).

Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant.

Fair enough.

Note that the reason that people are addressing what you are seeing is that you specifically raised what you're seeing ("90% of the e-mails with DKIM that I receive have a bad DKIM signature") as though it were, in fact, relevant.

On 01/31/2014 08:23 AM, Kurt Roeckx wrote:

I a question that might be related. If I send a mail from domain A to B, and B forwards it to C after rewriting the enveloppe, and both A and B have DMARC set up to receive reports, should C send a report to both A and B?

No, DMARC reports are sent to the address specified by the Domain Owner of the domain appearing in the 5322.From address. A forwarder who is rewriting the envelope isn't affecting this.

I hope that this makes things a little clearer?

- Roland
--------------030908000101020004000406-- From superuser@gmail.com Thu Jan 30 19:17:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D248F1A0527 for ; Thu, 30 Jan 2014 19:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeDWvnGl0ABV for ; Thu, 30 Jan 2014 19:17:51 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DC2681A0526 for ; Thu, 30 Jan 2014 19:17:50 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id m15so7717090wgh.2 for ; Thu, 30 Jan 2014 19:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cs0clwDC+q5mY3TvBOBPImxxqB9YW1TYjolkqSLYhB0=; b=0CGZejSguVSiK9KNw8R+zwbVWuniVGOh+CGVr/C6ZIpi5Gv8tBy0CL4ol+vM+qaAyy xrhXzaYAOMyVXz2gtJDwt+21xALKJK7oO1H5u0boJeHFMYt/EVHLBxwOt6YC9DseOXVw VQUu2n2bQ13hwMlExc6BwHhZjPBvtd6CrnpbOpQzBsdS+2ckHAgzYZ4WvkZA8wbI3yPX uZoDHSmG7yt7Rav3wqhpAczYKx1rgnk7LWiAuFAD7S9Ke906PJ/MG1wxd7ep7IkyVU9V rL4f77UVWEJQswJeL6Ls5p8qZzMIts3ObI5E3x7T7Q0MhkVysAzGD8x2FApMELxCzog4 FAcg== MIME-Version: 1.0 X-Received: by 10.180.187.16 with SMTP id fo16mr25499874wic.26.1391138266928; Thu, 30 Jan 2014 19:17:46 -0800 (PST) Received: by 10.180.98.41 with HTTP; Thu, 30 Jan 2014 19:17:46 -0800 (PST) In-Reply-To: <20140131001732.GA29928@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <20140131001732.GA29928@roeckx.be> Date: Thu, 30 Jan 2014 19:17:46 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Roeckx Content-Type: multipart/alternative; boundary=001a11c266c43bdc3d04f13b9e03 Cc: Jim Fenton , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 03:17:53 -0000 --001a11c266c43bdc3d04f13b9e03 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 30, 2014 at 4:17 PM, Kurt Roeckx wrote: > It's my understanding that in general about 90% of the DKIM mails > have a bad signature. > This seems to contradict the experience of most other operators. I'm at a loss to understand why this is out of bounds for this conversation. It's also my understanding that were DKIM > tends to fail, SPF tends to work and the other way around. > > This part is consistent with most operator experience as I understand it. > But > DMARC seems to combining the two in such a way it's more than > likely to have a failure as result instead of a pass. > In what way? Specifically, why "more than likely"? That's certainly true in your particular case where DKIM has such a low success rate, but there is ample anecdotal evidence that it is a sound premise most everywhere else. > > Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant. > > I find that rather an unfortunate position, especially since it interferes with our ability to answer your questions. -MSK --001a11c266c43bdc3d04f13b9e03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 30, 2014 at 4:17 PM, Kurt Roeckx <kurt@roeckx.be= > wrote:
It's my understanding that in general about 90% of the DKIM mails
have a bad signature.

This seems to con= tradict the experience of most other operators.=A0 I'm at a loss to und= erstand why this is out of bounds for this conversation.

=A0 It's also my understanding that were DKIM
tends to fail, SPF tends to work and the other way around.


This part is consistent with most operator experien= ce as I understand it.
=A0
=A0 But
DMARC seems to combining the two in such a way it's more than
likely to have a failure as result instead of a pass.
=
In what way?=A0 Specifically, why "more than likely&quo= t;?=A0 That's certainly true in your particular case where DKIM has suc= h a low success rate, but there is ample anecdotal evidence that it is a so= und premise most everywhere else.
=A0

Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant.

I find that rather an unfortunate positio= n, especially since it interferes with our ability to answer your questions= .

-MSK
--001a11c266c43bdc3d04f13b9e03-- From mjones@agari.com Thu Jan 30 22:38:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2F11A054D for ; Thu, 30 Jan 2014 22:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nc9BZ3jtpwC for ; Thu, 30 Jan 2014 22:38:22 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C5A261A0543 for ; Thu, 30 Jan 2014 22:38:22 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 20so21539367yks.4 for ; Thu, 30 Jan 2014 22:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pb4Wpfw2Zw4NkBmpPZjqzZZgy3yB2mwg12VofrpaerM=; b=IewUxS82+DVZVE2DsmkPIQ9HJulx1qdIdyrWPC5TGxiEAw0XNWH7wfJMyxQS/bpiGc yi4taer+30S/FmyU+ARc/WQsuXBDAktwLYj1MVMxEDU+YFRQ5o+ONejcNmLUY0gnwuGz 1TSs/Od/PkwiVxsEXPk2cdDBXE4Cve6ygzOGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pb4Wpfw2Zw4NkBmpPZjqzZZgy3yB2mwg12VofrpaerM=; b=HSDDgbBHU+8AAiNQcpwrN9C8QeOCCy7LAuwjPSNeBGv3PKaEK5C6/ZLs4LZObsJTNy epP0qerEdQT9q+61J1AIfI6TJxa1NmC81L5ggIWedd8O40IZcKC65nN1z9FCTvy1PRLo nQFeHaJ2ul6Q/F8PnuUawBQAc48fgKMfJvCCjzTApcdKgVJ21iFGpgOYSyRBjuTuT/nK mgzXandDKxVSh9JQ1YK55vI3SlrUx/u1kVeEN3OqjHDs6CEoPIOkxOluRTIYA5Cqu0tJ 2jv8Cuw/3n+GPFN132dPfn92JqQdQFjZP0xn3WYp0KTUzJPvmz+UqipmJpInV0noWZ8Q qE/A== X-Gm-Message-State: ALoCoQmmAInxfSRpEQfNomoR6LfhFdaXGsYld8dHhNSgzmy/9L0Ga0wWesNv1jSl/SlMRGhrAhpF MIME-Version: 1.0 X-Received: by 10.236.151.198 with SMTP id b46mr17728794yhk.3.1391150299000; Thu, 30 Jan 2014 22:38:19 -0800 (PST) Received: by 10.170.36.213 with HTTP; Thu, 30 Jan 2014 22:38:18 -0800 (PST) In-Reply-To: References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <20140131001732.GA29928@roeckx.be> Date: Thu, 30 Jan 2014 22:38:18 -0800 Message-ID: From: Mike Jones To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=20cf301cc5aa66cabf04f13e6bbc Cc: Kurt Roeckx Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 06:38:25 -0000 --20cf301cc5aa66cabf04f13e6bbc Content-Type: text/plain; charset=ISO-8859-1 Kurt and all, Here are some statistics my company has on DKIM over the last 30 days. (Note: We are a DMARC report aggregator and analytics company so these stats cover all of the DMARC reports received for thousands of domains.) % of all messages signed by DKIM = 97.79% % of signed messages which pass DKIM = 99.57% sample size = over 100 billion messages Of course we are aggregating reports for organizations implementing DMARC, so the percentage of messages signed may be skewed. But it is clear that of the messages which are signed, the percentage which pass is drastically different than the numbers you see. I think the data supports some issue on your side with the DKIM evaluation, whether it be an email gateway modifying signed message content before your server or something else. We also see that domains with a good implementations of SPF and DKIM consistently see DMARC pass rates in excess of 99.99% of their legitimate messages. Roland gave an excellent explanation of the reason for the alignment requirement the DMARC specifies. One point in his reply I will disagree on though is that domains without a current spoofing problem should not implement a DMARC quarantine or reject policy. This thing about spoofing is that one never knows when one will become a victim. We often see domains that go periods of time without a spoofing issue and then are hit hard on one day. If the your domain has excellent SPF and DKIM with a high overall DMARC pass rate, you have fully analyzed your DMARC reports to understand the risk of failures due to mailing lists or forwarding, and everything looks good then why not protect yourself from future attacks with a DMARC quarantine or reject? Thanks, Mike On Thu, Jan 30, 2014 at 7:17 PM, Murray S. Kucherawy wrote: > On Thu, Jan 30, 2014 at 4:17 PM, Kurt Roeckx wrote: > >> It's my understanding that in general about 90% of the DKIM mails >> have a bad signature. >> > > This seems to contradict the experience of most other operators. I'm at a > loss to understand why this is out of bounds for this conversation. > > It's also my understanding that were DKIM >> tends to fail, SPF tends to work and the other way around. >> >> > This part is consistent with most operator experience as I understand it. > > >> But >> DMARC seems to combining the two in such a way it's more than >> likely to have a failure as result instead of a pass. >> > > In what way? Specifically, why "more than likely"? That's certainly true > in your particular case where DKIM has such a low success rate, but there > is ample anecdotal evidence that it is a sound premise most everywhere else. > > >> >> Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant. >> >> > I find that rather an unfortunate position, especially since it interferes > with our ability to answer your questions. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --20cf301cc5aa66cabf04f13e6bbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kurt and all,
=
Here are some statistics my company has on DKIM over the last 30 = days.=A0 (Note: We are a DMARC report aggregator and analytics company so t= hese stats cover all of the DMARC reports received for thousands of domains= .)

% of all messages signed by DKIM =3D 97.79%
% of signed = messages which pass DKIM =3D 99.57%
sample size =3D over 100 billi= on messages

Of course we are aggregating reports for organizat= ions implementing DMARC, so the percentage of messages signed may be skewed= .=A0 But it is clear that of the messages which are signed, the percentage = which pass is drastically different than the numbers you see.=A0 I think th= e data supports some issue on your side with the DKIM evaluation, whether i= t be an email gateway modifying signed message content before your server o= r something else.

We also see that domains with a good implementations of SPF and D= KIM consistently see DMARC pass rates in excess of 99.99% of their legitima= te messages.

Roland gave an excellent explanation of the reas= on for the alignment requirement the DMARC specifies.=A0 One point in his r= eply I will disagree on though is that domains without a current spoofing p= roblem should not implement a DMARC quarantine or reject policy.=A0 This th= ing about spoofing is that one never knows when one will become a victim.= =A0 We often see domains that go periods of time without a spoofing issue a= nd then are hit hard on one day.=A0 If the your domain has excellent SPF an= d DKIM with a high overall DMARC pass rate, you have fully analyzed your DM= ARC reports to understand the risk of failures due to mailing lists or forw= arding, and everything looks good then why not protect yourself from future= attacks with a DMARC quarantine or reject?=A0

Thanks,
Mike


On Thu, Jan 30, 2014 at 7:17 PM, Murray S. Kucherawy= <superuser@gmail.com> wrote:
On Thu, J= an 30, 2014 at 4:17 PM, Kurt Roeckx <kurt@roeckx.be> wrote:
It's my understanding that in general about 90% of the DKIM mails
have a bad signature.

This seems = to contradict the experience of most other operators.=A0 I'm at a loss = to understand why this is out of bounds for this conversation.

=A0 It's also my understanding that were DKIM
tends to fail, SPF tends to work and the other way around.


This part is consistent with most operator ex= perience as I understand it.
=A0
=A0 But
DMARC seems to combining the two in such a way it's more than
likely to have a failure as result instead of a pass.
=
In what way?=A0 Specifically, why "more than like= ly"?=A0 That's certainly true in your particular case where DKIM h= as such a low success rate, but there is ample anecdotal evidence that it i= s a sound premise most everywhere else.
=A0

Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant.

I find that rather an unfortunate p= osition, especially since it interferes with our ability to answer your que= stions.

-MSK

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


--20cf301cc5aa66cabf04f13e6bbc-- From matt@tnpi.net Thu Jan 30 22:52:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398891A0553 for ; Thu, 30 Jan 2014 22:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhL5fdktnnFX for ; Thu, 30 Jan 2014 22:52:06 -0800 (PST) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 952741A0550 for ; Thu, 30 Jan 2014 22:52:06 -0800 (PST) Received: (qmail 47392 invoked by uid 1026); 31 Jan 2014 06:52:03 -0000 Received: from c-67-171-0-90.hsd1.wa.comcast.net (HELO [10.0.1.141]) (67.171.0.90) by mail.theartfarm.com (qpsmtpd/0.94) with (AES128-SHA encrypted) ESMTPSA; Fri, 31 Jan 2014 01:52:03 -0500 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.98.1 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:content-transfer-encoding:message-id:references:to; s=mar2013; bh=kEirEmjMpaJ2yaMtvHGW/ucTo1ny0hHoI+1xHsB8S5k=; b=J2nVKZHvW3VJJ11W740wPdM0jWfVPofJ/2SBgIHC3QUODR5viSlI4OSQ+9+vTMYzf41xRAATDUSb8N40n9KaJ95PLyWxpRk3E+f8itvDuWb4ouV3qLcCQTvhUWlmFCMSGFdaEAStG2VjrwZfpfjXgivJa0vm2i73UgITaBgft7llFSRCcfco4WxGaTWSsfzsuHmPGphfupV0f1FyeKAUEB991fPPhNYkjBA8fazOM25Yz29MqQJJQfrQRFddqhoj73tdXR7E9FpPNtHd4RCKCHPvrbWTd921VQVtsLq2JGNKN3kPg2HW5gruY571TW1PjZkGla1wySSOIOEJcJ64ag== X-HELO: [10.0.1.141] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Matt Simerson In-Reply-To: Date: Thu, 30 Jan 2014 22:52:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <20140131001732.GA29928@roeckx.be> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1827) Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 06:52:08 -0000 On Jan 30, 2014, at 10:38 PM, Mike Jones wrote: > One point in his reply I will disagree on though is that domains = without a current spoofing problem should not implement a DMARC = quarantine or reject policy. This thing about spoofing is that one = never knows when one will become a victim. We often see domains that go = periods of time without a spoofing issue and then are hit hard on one = day. If the your domain has excellent SPF and DKIM with a high overall = DMARC pass rate, you have fully analyzed your DMARC reports to = understand the risk of failures due to mailing lists or forwarding, and = everything looks good then why not protect yourself from future attacks = with a DMARC quarantine or reject? =20 +1 Matt= From smj@crash.com Fri Jan 31 00:01:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9A1A056E for ; Fri, 31 Jan 2014 00:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT1o_fTtmhus for ; Fri, 31 Jan 2014 00:01:10 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7611A04FA for ; Fri, 31 Jan 2014 00:01:10 -0800 (PST) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s0V80vnl021621 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 31 Jan 2014 00:01:03 -0800 (PST) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s0V80vnl021621 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1391155263; bh=vvETdmvx0gJEuakPBB1QFfkWmDzNdiiHH4DzMqZA+hU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=A7Yqla0rSuXaelAa7jtoXMPPHwnnE8egLEyBtgd+Zyt7Jl9yN3HtySpEkBFXegS/1 U+DSAyqAj4zwCjWQogjvhUemVNr6muhoSk0SSzME8o7zKmhe9JaKPW7gda/MoibAqm O1ciHewRSM+bIRD6I9DTpFIV/sNSr9ZyEK0Xu/gc= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <52EB583B.7050103@crash.com> Date: Fri, 31 Jan 2014 00:00:59 -0800 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <20140131001732.GA29928@roeckx.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 31 Jan 2014 00:01:03 -0800 (PST) Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 08:01:11 -0000 On 01/30/2014 10:38 PM, Mike Jones wrote: > > [The] thing about spoofing is that one never knows when one will > become a victim. We often see domains that go periods of time without > a spoofing issue and then are hit hard on one day. I'd like to reinforce this point from experience as a domain owner. At a major financial institution, we put SPF "-all" and DMARC "p=reject" records on some domains that had been retired a several years earlier. These domains seldom saw more than 1,000 messages per month - again, none from or authorized by the owning organization - but they were prominent names you would recognize, and this seemed like a prudent precaution. Sure enough, one holiday weekend somebody tried to send over 1.75 million messages using one of these domains. While we surely weren't receiving reports from every domain receiving the spoofed messages, from the receivers that did report - including Microsoft, AOL, Google, and Yahoo - over 99.5% of those messages never reached an inbox. And I can tell you, we did not see blocking rates that high from similar domains where we had not put DMARC policies in place, no matter how lame the fraudulent messages were. --Steve. From sca@andreasschulze.de Fri Jan 31 10:38:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FB21A1F5F for ; Fri, 31 Jan 2014 10:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xa6wKQhG1o9 for ; Fri, 31 Jan 2014 10:38:33 -0800 (PST) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4BF1A046F for ; Fri, 31 Jan 2014 10:38:32 -0800 (PST) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1391193504; bh=qknwGIDwU+t1NdM+toQTCAczDaC8kTMAKLEc7wvQ00Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=M0iqXHN0jE+epaagVyOSa5ObiDugvVJLj5glY71zlnRa6Lz/V5ChG3Z6VvK7GKZdK wwDHp0YxXyQhqtB9jZc/gXb7Yr5APJAMUtQ8TGuaVDH9xI6QFFhBii6C6OZkcdWfPS rwkyJI47Bat2SMdFJ/CS48atgyI7zlka2aZcoE1yQBIIzgK/hxBsmccNQG00k1i5aG Lh4OyEAMNexEADzjilrPF+PUvrW0Gt1Ouz1jRCowKe9b8NxFHJoGTcXZN4OyqoBRts 7Krh1vzGYPSeCMA2dEpZCzY4MPVhtDbml20EQZ5FGTN1Hrb41G/e7iuxWML3L+19bn Bmqn5YVpghec7nLC2PD5W6r6sPB4XVO/NfR7i1JB6+MBpzpljalmtIOZp8NjwW0khy LkDaYgsBl1/hAPsXHHQjrFKA6vmq+wQzWFsSATYQoln31bRmWAr4Fbm2F5rT1kEYZs O+TpGOarDiG4JzjSL4o6Jp2egKryOxTWp4ry7eT446LPx+/yL84y+p5jkUgV2Q5qzk Fp9LcI0t1HBVPX+U60dzB0q2Jc5v3VYGTuSQ6dkO3V54MPjDrtVxHne28gWKsoUJ1K G3vMRh6tzp3mvrhtIVAAq3WqeYNxrOofAjAsQs+4TPwimmbe60Uvyb7t7x2GOUKDMs GEsobEh3Va7rP7tAB1OdgV5Q= X-Received: line deleted by mout Date: Fri, 31 Jan 2014 19:38:20 +0100 From: Andreas Schulze To: Mike Jones Message-ID: <20140131183820.GC23649@solar.andreasschulze.de> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <20140131001732.GA29928@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GPG-Key-ID: 0xA7DBA67F X-GPG-Fingerprint: 14C1 39A8 CE6D 6BE0 28C6 5652 03B5 6793 A7DB A67F X-GPG-Public-Key: http://9645f8.dyndns.org/a7dba67f.asc X-Location: Germany, Earth User-Agent: mutt Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 18:38:34 -0000 Mike Jones: > % of all messages signed by DKIM = 97.79% > % of signed messages which pass DKIM = 99.57% > sample size = over 100 billion messages Mike, my "real life" looks a little more unsigned. On 300k messages per day I have only 30% signed. But from these 100k ~90% pass DKIM. Andreas From superuser@gmail.com Fri Jan 31 11:50:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AE51A0478 for ; Fri, 31 Jan 2014 11:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn0jErgUwgFD for ; Fri, 31 Jan 2014 11:50:09 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 64F901A0464 for ; Fri, 31 Jan 2014 11:50:09 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so9517567wgh.28 for ; Fri, 31 Jan 2014 11:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4rbDgdLnc2lJn3GgoqLdO/w+yt6Tj5gZUn7KQ+k/9Ik=; b=i2b9Baiq6rqTe/dM3ndDz6FiM3yunJzxEm7TJtyPN/CkaabEhSZ1ztXwa5GIp+uj1K OGAPmIKdUh9PCtJ2mjEWJ7iZDj/c+ErZVHaS3zWnluqr4AH0cKUctB8gpnQ879mT29jU 2AEtn3ir20dSL3qqrmlvnbhXV0TYjkFO9TsEYvigPuw1sry911kjm/xSsUojdD4DnKu2 3L2Gt+lYh/kV+uE9jWONJD/uXRpXhFbWaq5KgHtQBiz3cmLSdBGv6xcZrW2BT/zU6pia iKutOuVAapSDZcmmNc+ux/3eknbfV4xlxY3untDfn31Ns+GLaxcpw76He8MWYSrye/tH lNXw== MIME-Version: 1.0 X-Received: by 10.180.187.16 with SMTP id fo16mr164553wic.26.1391197805201; Fri, 31 Jan 2014 11:50:05 -0800 (PST) Received: by 10.180.98.41 with HTTP; Fri, 31 Jan 2014 11:50:05 -0800 (PST) In-Reply-To: <20140131183820.GC23649@solar.andreasschulze.de> References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <20140131001732.GA29928@roeckx.be> <20140131183820.GC23649@solar.andreasschulze.de> Date: Fri, 31 Jan 2014 11:50:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: Andreas Schulze Content-Type: multipart/alternative; boundary=001a11c266c4fdd0de04f1497add Cc: "dmarc@ietf.org" , Mike Jones Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Jan 2014 19:50:11 -0000 --001a11c266c4fdd0de04f1497add Content-Type: text/plain; charset=ISO-8859-1 OpenDKIM stats, last six months: http://www.opendkim.org/stats/report.html Pass rate is pretty high across all of our reporting sites as well. -MSK On Fri, Jan 31, 2014 at 10:38 AM, Andreas Schulze wrote: > Mike Jones: > > % of all messages signed by DKIM = 97.79% > > % of signed messages which pass DKIM = 99.57% > > sample size = over 100 billion messages > > Mike, > > my "real life" looks a little more unsigned. > On 300k messages per day I have only 30% signed. > But from these 100k ~90% pass DKIM. > > Andreas > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a11c266c4fdd0de04f1497add Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OpenDKIM stats, last six months:

http://www.opendkim.org/stat= s/report.html

Pass rate is pretty high across all of our r= eporting sites as well.

-MSK



On Fri, Jan 31, 2014 at 10:38 AM, Andreas Schulze <sc= a@andreasschulze.de> wrote:
Mike Jones:
> % of all messages signed by DKIM =3D 97.79%
> % of signed messages which pass DKIM =3D 99.57%
> sample size =3D over 100 billion messages

Mike,

my "real life" looks a little more unsigned.
On 300k messages per day I have only 30% signed.
But from these 100k ~90% pass DKIM.

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

--001a11c266c4fdd0de04f1497add-- From kurt@roeckx.be Fri Jan 31 17:33:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8BA1ACCE0 for ; Fri, 31 Jan 2014 17:33:50 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir3cJtUFjpYy for ; Fri, 31 Jan 2014 17:33:47 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8652B1ACCDE for ; Fri, 31 Jan 2014 17:33:47 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 105811C215C; Sat, 1 Feb 2014 02:33:43 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id D6A081FE0262; Sat, 1 Feb 2014 02:33:42 +0100 (CET) Date: Sat, 1 Feb 2014 02:33:42 +0100 From: Kurt Roeckx To: Roland Turner Message-ID: <20140201013342.GA24125@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EB0CBF.9020607@rolandturner.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 01:33:51 -0000 On Fri, Jan 31, 2014 at 10:38:55AM +0800, Roland Turner wrote: > Hi Kurt, > > On 01/31/2014 06:03 AM, Kurt Roeckx wrote: > >Hi, > > > >I'm pretty new to DMARC, and I'm really confused about this > >alignment thing. Can someone explain to me why this is needed? > > Loosely speaking, DMARC's objective is to frustrate spoofing. The > relevant domain is therefore the one in the email address that > end-users see, which is almost always the 5322.From address rather > than the 5321.MailFrom address. I do understand what the objective is. But my current understanding of it that it will break e-mail in various cases that I care about, and I think we should try to do everything we can to minimize mails wrongly getting rejected. > On the face of it, this is therefore a job for DKIM rather than SPF, > however at the time that DMARC was developed DKIM coverage was > minimal (somewhere under 5% of legitimate email) while SPF already > covered the majority of legitimate email (somewhere above 60%, > depending whose numbers you look at). Consequently, it was sensible > to look into ways to make use of the existing SPF deployment to > progress DMARC's objective. The obvious problem was that SPF doesn't > test the 5322.From domain, however in direct delivery cases it is > common for SPF to pass and for the 5321.MailFrom domain and the > 5322.From domain to "match" (either be the same, or obviously belong > to the same organisation), in which case an SPF pass could > reasonably be considered sufficient basis for treating the message > as authentic. I'd like to point out that DKIM just certifies that a mail passed on a certain domain. For instance messages send to the IETF list are signed by the IETF, but that doesn't mean that the IETF wrote the original mail, just that it passed on their mail server. They also changed the envelope from, setting it to dmarc-bounces@ietf.org. They also set up SPF, and so both SPF and DKIM could result in a pass. So I could have every reason to believe that this really is a mail from an IETF list. But I'm not sure what DMARC is now saying or supposed to say about this. I think it only cares about what is in the header from, it might see that SPF has a pass, but it's going to say that it doesn't allign with the header from. What is unclear to me is what the result of that should be. Is it just going to ignore this SPF result? Will it result in an SPF fail even though it was really a pass? How does this affect the result of DMARC? You can also forget about DKIM passing. The mail actually has 2 DKIM signatures, one from you and one from the IETF. As far as I understand it, DMARC should ignore that one from the IETF because it's not aligned, but could look at yours. But your mail was changed by the mailinglist software, and so will say that that resulted in a failed checked. (opendkim only seems to have generated 1 Authentication-Results header, for the IETF, while it probably should have generated 2, and I might not even have check that your signaure is valid or not.) So in the end DMARC will say your mail is not authentic, and it failed because DKIM failed to verify when only considering it to be aligned with the header from. And as I understand it, there is no way for you to prevent that. > To understand why an alignment rule was required in the first place, > consider what could happen without one: a spoofer could send the > following and arrange appropriate DNS records for SPF to pass: > > MAIL FROM: > ... > From: PayPal > > > however this should not be considered authentic: the end-user would > see it as a message from PayPal when, clearly, it's not. That more seem to be a reason for DKIM to be aligned with the header from than SPF to be aligned with it. > >SPF is not designed to do anything with the headers. SPF is known > >to break forwarding if you don't change the mail from in the > >envelope. So if you properly implement forwarding to work with > >SPF you change the envelope sender. > > I'd suggest being careful with the use words that impart a > judgemental slant: forwarders who aren't changing the return path in > order to help SPF work aren't doing anything "improper", they're > simply doing what they're doing. It is in the interests of Domain > Owners and receivers who want to tackle the spoofing problem to deal > with the world as it as, rather than pretend a simplified form that > would make their lives easier; forwarders who don't point return > paths to themselves are part of the real world. I'm not claiming that people forwarding mails should do this, and it was never my intention to say so. All I'm saying is that if you don't do it you might break someone else's SPF. > It is SPF that is the fallback, not DKIM. > > SPF is only used by DMARC at all because of the limited adoption of > DKIM and broad adoption of SPF at the time that DMARC was developed. > The complexity that using SPF introduces would otherwise not have > been warranted. So are you saying that you wouldn't add SPF anymore to it now? Or maybe differently? > On 01/31/2014 08:17 AM, Kurt Roeckx wrote: > >It's my understanding that in general about 90% of the DKIM mails > >have a bad signature. > > Give or take the points above, your understanding is simply not > correct. See http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.html > for recent real-world data. Which makes no claim about how many signatures pass or fail. > In fact just over three quarters of legitimate email has a valid > DKIM signature on it. That's not what it's saying. It says that they have a signature, not that it's valid or not. It also makes not claim about reports they get back of how many checks fail. > >It's also my understanding that were DKIM > >tends to fail, SPF tends to work and the other way around. But > >DMARC seems to combining the two in such a way it's more than > >likely to have a failure as result instead of a pass. > > As above, that's not correct: > > * DMARC doesn't affect SPF and DKIM results. Maybe a better word would be ignore? But then I'm not really sure. But the result I get back say that SPF failed while there is no "-all" SPF record. I think it is at least misleading. Kurt From roland@rolandturner.com Fri Jan 31 20:04:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A31A1F56 for ; Fri, 31 Jan 2014 20:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTD_jYGF3UfE for ; Fri, 31 Jan 2014 20:04:51 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2162E1A052C for ; Fri, 31 Jan 2014 20:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=02HsNtmEaWbPKjayPvnQTT5Z/5PuFTiKfKli6cE+40Q=; b=KZhICR7Ctvgu6r+36aXzKn1enqG9F9nwD6bcSv/uy8Ra0HzhYLCZqvdU8+da/rWBPOHakQ4U/C4n12tgWUlcLFbj3MdpCwoMD184IfUbBkgJvK7GrKssjDA4fJ+BVPvXxeJt2Ui7O5DCzMMgs0+MbHFn7Q9UF0lL/Zlzd9EgQEg=; Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=222.165.46.240; iprev=pass policy.iprev=222.165.46.240 (cm240.theta46.maxonline.com.sg) Received: from [222.165.46.240] (port=34404 helo=[10.1.132.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W9Rox-0002Xz-Ke for dmarc@ietf.org; Sat, 01 Feb 2014 04:04:46 +0000 Message-ID: <52EC725B.1050809@rolandturner.com> Date: Sat, 01 Feb 2014 12:04:43 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> <20140201013342.GA24125@roeckx.be> In-Reply-To: <20140201013342.GA24125@roeckx.be> Content-Type: multipart/alternative; boundary="------------050401090805020405060605" Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 04:04:55 -0000 This is a multi-part message in MIME format. --------------050401090805020405060605 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/01/2014 09:33 AM, Kurt Roeckx wrote: > I do understand what the objective is. But my current understanding of > it that it will break e-mail in various cases that I care about, and I > think we should try to do everything we can to minimize mails wrongly > getting rejected. It might help if you were to provide concrete examples of the cases which are concerning you. (If you mean the dmarc-ietf list case then your concern is unwarranted: DMARC doesn't address lists of this type.) Your concern is widely shared, so much so that mechanism for providing Domain Owners with visibility of [potential] message loss is arguably DMARC's primary contribution, the absence of a practical comparable mechanism in SPF or any comparable mechanism in DomainKeys and ADSP being why -all, o=- and dkim=discardable are rarely asserted and widely ignored. > I'd like to point out that DKIM just certifies that a mail passed on a > certain domain. For instance messages send to the IETF list are signed > by the IETF, but that doesn't mean that the IETF wrote the original > mail, just that it passed on their mail server. They also changed the > envelope from, setting it to dmarc-bounces@ietf.org. They also set up > SPF, and so both SPF and DKIM could result in a pass. So I could have > every reason to believe that this really is a mail from an IETF list. > But I'm not sure what DMARC is now saying or supposed to say about this. "Non-participating" MLMs (RFC 6377) are outside DMARC's scope. > I think it only cares about what is in the header from, A few of your comments - and this one in particular - suggest that you've forgotten some of the details of the specification which spells this stuff out very clearly; may I suggest re-reading it? (Yes, DMARC deals exclusively with the domain in the 5322.From) > it might see that SPF has a pass, but it's going to say that it > doesn't allign with the header from. What is unclear to me is what the > result of that should be. Is it just going to ignore this SPF result? DMARC is going to ignore it, yes. > Will it result in an SPF fail even though it was really a pass? No, DMARC does not alter SPF. If SPF passes, it does so with or without DMARC being present. What DMARC does do is decide when to make use of an SPF pass; in particular it only does so when the SPF domain and 5322.From domain are aligned. Note that a DMARC implementation therefore has to deal with two separate interpretations of an SPF result: * The domain name and result from the authentication mechanism itself; this is the auth_results section of an aggregate report. * The relevance of the underlying results to a DMARC policy evaluation; this is the policy_evaluated section of an aggregate report. Any time the SPF domain is unaligned a fail will appear here, even if SPF passed (and therefore shows a pass in the auth_results section). Note further that DMARC is also selective about its use of DKIM, except that the DKIM d= must match from 5322.From domain exactly (merely being aligned isn't enough). The same two interpretations must therefore be understood and they appear in the same two places in the aggregate report as above. > How does this affect the result of DMARC? You can also forget about > DKIM passing. The mail actually has 2 DKIM signatures, one from you > and one from the IETF. As far as I understand it, DMARC should ignore > that one from the IETF because it's not aligned, but could look at > yours. But your mail was changed by the mailinglist software, and so > will say that that resulted in a failed checked. (opendkim only seems > to have generated 1 Authentication-Results header, for the IETF, while > it probably should have generated 2, and I might not even have check > that your signaure is valid or not.) Right. As above, this is all outside DMARC's scope. > So in the end DMARC will say your mail is not authentic, Not exactly: DMARC doesn't make determinations about authenticity, it merely proposes dispositions. The Domain Owner may request a specific disposition for messages which don't pass either of DMARC's authentication approaches, it is up to receivers to make a call about what they want to do when they reach this point. In general they'll honour it unless one of the following applies: * The message was forwarded by a mailing list or other forwarder that is known by the receiver to not be a useful vector for spoofers. In this case the policy_evaluated section will contain a disposition of none and a reason section, typically of type trusted_forwarder or mailing_list. * The Domain Owner is one that the receiver believes to be incompetent (or doesn't believe to be competent). * Some other local override to deal with some local issue (e.g. DMARC evaluation happening a second time in a situation known to break DKIM.) How these decisions work are specifically outside DMARC's scope, they are local operational choices. >> To understand why an alignment rule was required in the first place, >> consider what could happen without one: a spoofer could send the >> following and arrange appropriate DNS records for SPF to pass: >> >> MAIL FROM: >> ... >> From: PayPal >> >> >> however this should not be considered authentic: the end-user would >> see it as a message from PayPal when, clearly, it's not. > That more seem to be a reason for DKIM to be aligned with the > header from than SPF to be aligned with it. I'm not sure how that's relevant. All that I'm saying that in this situation, DMARC should not (and indeed does not) treat an SPF pass as a pass for DMARC's purposes. > >>> SPF is not designed to do anything with the headers. SPF is known >>> to break forwarding if you don't change the mail from in the >>> envelope. So if you properly implement forwarding to work with >>> SPF you change the envelope sender. >> I'd suggest being careful with the use words that impart a >> judgemental slant: forwarders who aren't changing the return path in >> order to help SPF work aren't doing anything "improper", they're >> simply doing what they're doing. It is in the interests of Domain >> Owners and receivers who want to tackle the spoofing problem to deal >> with the world as it as, rather than pretend a simplified form that >> would make their lives easier; forwarders who don't point return >> paths to themselves are part of the real world. > I'm not claiming that people forwarding mails should do this, and > it was never my intention to say so. OK. > All I'm saying is that if > you don't do it you might break someone else's SPF. Sure. This has been well understood since SPF was devised and was the reason for SRS which - as I pointed out earlier - turned into an exercise in demonstrating that SPF and forwarding are probably infeasible to combine. Per my earlier comments, SPF is only relevant to DMARC in the direct-delivery case. > >> It is SPF that is the fallback, not DKIM. >> >> SPF is only used by DMARC at all because of the limited adoption of >> DKIM and broad adoption of SPF at the time that DMARC was developed. >> The complexity that using SPF introduces would otherwise not have >> been warranted. > So are you saying that you wouldn't add SPF anymore to it now? Or > maybe differently? It's an interesting question. Technology development tends to be path-dependent, so we don't generally get to answer this sort of question meaningfully. I'd suggest that even if we'd gotten to the current levels of SPF and DKIM penetration with DMARC's feedback (improbable) there is still enough additional value in SPF at present to warrant its inclusion if DMARC were designed today. If DKIM penetration continues its present growth this value may diminish to the point of being irrelevant. Whether this leads to pressure to remove SPF from DMARC's inputs is an open question. > >> On 01/31/2014 08:17 AM, Kurt Roeckx wrote: >>> It's my understanding that in general about 90% of the DKIM mails >>> have a bad signature. >> Give or take the points above, your understanding is simply not >> correct. See http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.html >> for recent real-world data. > Which makes no claim about how many signatures pass or fail. > >> In fact just over three quarters of legitimate email has a valid >> DKIM signature on it. > That's not what it's saying. It says that they have a signature, not > that it's valid or not. Your dedication to the idea that there's some problem with DKIM signing and verification is admirable, but misplaced. It might help to note that DMARC is not a hypothetical system that's being offered for discussion, it's already had several years of use doing what it was designed to achieve (disrupting spoofing without disrupting legitimate email), and doing so reliably. In the particular case of Google's numbers, the bit you missed was "91.4% of non-spam emails sent to Gmail users come from authenticated senders". This is not just a DKIM signature or SPF record being present, this is one or both actually passing for more than 90% of the legitimate email received by Gmail. The numbers that you are seeing in your environment are nowhere near typical. I proposed earlier a list of likely causes, all of them in your control. > >>> It's also my understanding that were DKIM >>> tends to fail, SPF tends to work and the other way around. But >>> DMARC seems to combining the two in such a way it's more than >>> likely to have a failure as result instead of a pass. >> As above, that's not correct: >> >> * DMARC doesn't affect SPF and DKIM results. > Maybe a better word would be ignore? But then I'm not really > sure. Re-read the spec? > But the result I get back say that SPF failed while there > is no "-all" SPF record. I think it is at least misleading. That's not misleading, it's broken. If you'd share the example, the relevant people are likely to want to fix it (assuming of course that you're not confusing auth_results with policy_evaluted). - Roland --------------050401090805020405060605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 02/01/2014 09:33 AM, Kurt Roeckx wrote:

I do understand what the objective is. But my current understanding of it that it will break e-mail in various cases that I care about, and I think we should try to do everything we can to minimize mails wrongly getting rejected.

It might help if you were to provide concrete examples of the cases which are concerning you. (If you mean the dmarc-ietf list case then your concern is unwarranted: DMARC doesn't address lists of this type.)

Your concern is widely shared, so much so that mechanism for providing Domain Owners with visibility of [potential] message loss is arguably DMARC's primary contribution, the absence of a practical comparable mechanism in SPF or any comparable mechanism in DomainKeys and ADSP being why -all, o=- and dkim=discardable are rarely asserted and widely ignored.

I'd like to point out that DKIM just certifies that a mail passed on a certain domain. For instance messages send to the IETF list are signed by the IETF, but that doesn't mean that the IETF wrote the original mail, just that it passed on their mail server. They also changed the envelope from, setting it to dmarc-bounces@ietf.org. They also set up SPF, and so both SPF and DKIM could result in a pass. So I could have every reason to believe that this really is a mail from an IETF list. But I'm not sure what DMARC is now saying or supposed to say about this.

"Non-participating" MLMs (RFC 6377) are outside DMARC's scope.

I think it only cares about what is in the header from,

A few of your comments - and this one in particular - suggest that you've forgotten some of the details of the specification which spells this stuff out very clearly; may I suggest re-reading it?

(Yes, DMARC deals exclusively with the domain in the 5322.From)

it might see that SPF has a pass, but it's going to say that it doesn't allign with the header from. What is unclear to me is what the result of that should be. Is it just going to ignore this SPF result?

DMARC is going to ignore it, yes.

Will it result in an SPF fail even though it was really a pass?

No, DMARC does not alter SPF. If SPF passes, it does so with or without DMARC being present. What DMARC does do is decide when to make use of an SPF pass; in particular it only does so when the SPF domain and 5322.From domain are aligned. Note that a DMARC implementation therefore has to deal with two separate interpretations of an SPF result:
  • The domain name and result from the authentication mechanism itself; this is the auth_results section of an aggregate report.
  • The relevance of the underlying results to a DMARC policy evaluation; this is the policy_evaluated section of an aggregate report. Any time the SPF domain is unaligned a fail will appear here, even if SPF passed (and therefore shows a pass in the auth_results section).

Note further that DMARC is also selective about its use of DKIM, except that the DKIM d= must match from 5322.From domain exactly (merely being aligned isn't enough). The same two interpretations must therefore be understood and they appear in the same two places in the aggregate report as above.

How does this affect the result of DMARC? You can also forget about DKIM passing. The mail actually has 2 DKIM signatures, one from you and one from the IETF. As far as I understand it, DMARC should ignore that one from the IETF because it's not aligned, but could look at yours. But your mail was changed by the mailinglist software, and so will say that that resulted in a failed checked. (opendkim only seems to have generated 1 Authentication-Results header, for the IETF, while it probably should have generated 2, and I might not even have check that your signaure is valid or not.)

Right. As above, this is all outside DMARC's scope.

So in the end DMARC will say your mail is not authentic,

Not exactly: DMARC doesn't make determinations about authenticity, it merely proposes dispositions. The Domain Owner may request a specific disposition for messages which don't pass either of DMARC's authentication approaches, it is up to receivers to make a call about what they want to do when they reach this point. In general they'll honour it unless one of the following applies:

  • The message was forwarded by a mailing list or other forwarder that is known by the receiver to not be a useful vector for spoofers. In this case the policy_evaluated section will contain a disposition of none and a reason section, typically of type trusted_forwarder or mailing_list.
  • The Domain Owner is one that the receiver believes to be incompetent (or doesn't believe to be competent).
  • Some other local override to deal with some local issue (e.g. DMARC evaluation happening a second time in a situation known to break DKIM.)

How these decisions work are specifically outside DMARC's scope, they are local operational choices.

To understand why an alignment rule was required in the first place,
consider what could happen without one: a spoofer could send the
following and arrange appropriate DNS records for SPF to pass:

   MAIL FROM: <noreply@spoofer.example>
   ...
   From: PayPal <someone@paypal.com>


however this should not be considered authentic: the end-user would
see it as a message from PayPal when, clearly, it's not.

That more seem to be a reason for DKIM to be aligned with the
header from than SPF to be aligned with it.

I'm not sure how that's relevant. All that I'm saying that in this situation, DMARC should not (and indeed does not) treat an SPF pass as a pass for DMARC's purposes.


SPF is not designed to do anything with the headers.  SPF is known
to break forwarding if you don't change the mail from in the
envelope.  So if you properly implement forwarding to work with
SPF you change the envelope sender.

I'd suggest being careful with the use words that impart a
judgemental slant: forwarders who aren't changing the return path in
order to help SPF work aren't doing anything "improper", they're
simply doing what they're doing. It is in the interests of Domain
Owners and receivers who want to tackle the spoofing problem to deal
with the world as it as, rather than pretend a simplified form that
would make their lives easier; forwarders who don't point return
paths to themselves are part of the real world.

I'm not claiming that people forwarding mails should do this, and
it was never my intention to say so.

OK.

All I'm saying is that if
you don't do it you might break someone else's SPF.

Sure. This has been well understood since SPF was devised and was the reason for SRS which - as I pointed out earlier - turned into an exercise in demonstrating that SPF and forwarding are probably infeasible to combine.

Per my earlier comments, SPF is only relevant to DMARC in the direct-delivery case.


It is SPF that is the fallback, not DKIM.

SPF is only used by DMARC at all because of the limited adoption of
DKIM and broad adoption of SPF at the time that DMARC was developed.
The complexity that using SPF introduces would otherwise not have
been warranted.

So are you saying that you wouldn't add SPF anymore to it now?  Or
maybe differently?

It's an interesting question. Technology development tends to be path-dependent, so we don't generally get to answer this sort of question meaningfully. I'd suggest that even if we'd gotten to the current levels of SPF and DKIM penetration with DMARC's feedback (improbable) there is still enough additional value in SPF at present to warrant its inclusion if DMARC were designed today. If DKIM penetration continues its present growth this value may diminish to the point of being irrelevant. Whether this leads to pressure to remove SPF from DMARC's inputs is an open question.


On 01/31/2014 08:17 AM, Kurt Roeckx wrote:

It's my understanding that in general about 90% of the DKIM mails
have a bad signature.

Give or take the points above, your understanding is simply not
correct. See http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.html
for recent real-world data.

Which makes no claim about how many signatures pass or fail.


In fact just over three quarters of legitimate email has a valid
DKIM signature on it.

That's not what it's saying.  It says that they have a signature, not
that it's valid or not.

Your dedication to the idea that there's some problem with DKIM signing and verification is admirable, but misplaced. It might help to note that DMARC is not a hypothetical system that's being offered for discussion, it's already had several years of use doing what it was designed to achieve (disrupting spoofing without disrupting legitimate email), and doing so reliably.

In the particular case of Google's numbers, the bit you missed was "91.4% of non-spam emails sent to Gmail users come from authenticated senders". This is not just a DKIM signature or SPF record being present, this is one or both actually passing for more than 90% of the legitimate email received by Gmail. The numbers that you are seeing in your environment are nowhere near typical. I proposed earlier a list of likely causes, all of them in your control.


It's also my understanding that were DKIM
tends to fail, SPF tends to work and the other way around.  But
DMARC seems to combining the two in such a way it's more than
likely to have a failure as result instead of a pass.

As above, that's not correct:

 * DMARC doesn't affect SPF and DKIM results.

Maybe a better word would be ignore?  But then I'm not really
sure.

Re-read the spec?

But the result I get back say that SPF failed while there
is no "-all" SPF record.  I think it is at least misleading.

That's not misleading, it's broken. If you'd share the example, the relevant people are likely to want to fix it (assuming of course that you're not confusing auth_results with policy_evaluted).

- Roland
--------------050401090805020405060605--