From rocketraman@gmail.com Mon Sep 2 15:43:01 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666EC21F9983 for ; Mon, 2 Sep 2013 15:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlgBhNhRAeLX for ; Mon, 2 Sep 2013 15:43:00 -0700 (PDT) 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 ADF6821F9974 for ; Mon, 2 Sep 2013 15:43:00 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id s9so8498030iec.7 for ; Mon, 02 Sep 2013 15:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=o0p7ZeDFRxD98COQxEtZfDGl23cEOtqiftFFXfm0Nb4=; b=PG9nBIbAiA+TGh2h6R2GUkdBQlLvWlUHClFtG20KCwpqaoknyhOV+czvUR3JIBA2d6 q0+95Zkz/eUA7pVtOtJSKNePAQkp9VWuj2B3xZX+lSsH81McV21LJsru9KZzNyT8l/NA fjOK5Nb2+ECILfSxwXjbOg5YgODGuKx+dUicaGhH6R9R6ebmOm0BGjob0bOu450burUy xA/J8ge4cDtQrM/bcYeZHFzPx4YojU/CSwPS48PVOu30ZwqKTy2eP8jKo0/5b1e853CC NVmZ8+sg+OKVegS/HMDU0ZVlyLrUit4oKz0wLCPcZLmhvi+BmS+KvpppegYVRUwe1HOK rZIw== X-Received: by 10.50.124.10 with SMTP id me10mr13601493igb.40.1378161780190; Mon, 02 Sep 2013 15:43:00 -0700 (PDT) Received: from mail.rocketraman.com (CPEc86000c77d08-CM602ad06d1aa0.cpe.net.cable.rogers.com. [174.112.193.137]) by mx.google.com with ESMTPSA id pk8sm27021221igb.6.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 02 Sep 2013 15:42:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.rocketraman.com (Postfix) with ESMTP id B28FD1DE075F for ; Mon, 2 Sep 2013 18:42:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at rocketraman.com Received: from mail.rocketraman.com ([127.0.0.1]) by localhost (mail.rocketraman.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt53CtDQFkq7 for ; Mon, 2 Sep 2013 18:42:57 -0400 (EDT) Received: from [192.168.1.6] (edison.rocketraman.com [192.168.1.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.rocketraman.com (Postfix) with ESMTPS for ; Mon, 2 Sep 2013 18:42:57 -0400 (EDT) Message-ID: <52251471.8070001@gmail.com> Date: Mon, 02 Sep 2013 18:42:57 -0400 From: Raman Gupta User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 22:46:13 -0000 I encountered a use case recently with an auto-generated email with RFC5322.From domain foo.com, sent from a host in domain bar.com. Because the email was auto-generated by sieve, it contained a null return path. The host in bar.com is a valid SPF sender for domain foo.com. DMARC failed the SPF check despite the valid SPF, since the RFC5322.From address was not aligned with the domain bar.com extracted from the HELO/EHLO. A valid way to circumvent this problem is to use DKIM signing, aligned with foo.com, in which case DMARC is designed to ignore the SPF failure and pass overall. However, I do think this is a valid situation which the SPF alignment rules should consider. I hope I have explained this sufficiently. Thank you to Steven Jones and Scott Kitterman and others on the dmarc-discuss list for clarifying the situation presented here. Regards, Raman Gupta Principal VIVO Systems From dcrocker@gmail.com Wed Sep 11 14:55:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C083111E8140 for ; Wed, 11 Sep 2013 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSRtMF1X28FU for ; Wed, 11 Sep 2013 14:55:11 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6021E80A9 for ; Wed, 11 Sep 2013 14:55:10 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id f4so10064964oah.11 for ; Wed, 11 Sep 2013 14:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zXKsrcsLv7b5jOLURBy+5jY/uTIVQZPMzO+0Z0PnMTk=; b=D7NR6aF4BSUNZsaEiFpABTn3ozDA8f6qYrCYORhVOVcgZQY8GEY2ysxNrT5a3Wscxl tyfxi1HJx9VSSpGGwZ1x1mywmXot/c3aMWiWAOPuCMlc46ptjerrBf66GbNVWoLMq6OF BNg5gd7whe591JIa3oJ1tpQatxe7WwsbKH5K4uYlR72IezmkAvoBV4jM1Kg/4SdBPIV3 yiR7h7BY8Nw8nfBaqKQRJ/+QQgO7XuFi0B8m62ZiQDa3Ct+fmyEa96uhUOtXOg/AQwaI nb+MWDM/vU32OcBxeVlym9KIaqbIf1S6WofT/2vMQ4UjQxK1qTZlcxt6SYzRPamFU+GH PuYg== X-Received: by 10.182.28.134 with SMTP id b6mr3538553obh.27.1378936489291; Wed, 11 Sep 2013 14:54:49 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id r3sm369605oep.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 14:54:48 -0700 (PDT) Message-ID: <5230E691.1030703@gmail.com> Date: Wed, 11 Sep 2013 14:54:25 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 21:55:32 -0000 Folks, G'day. DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617, August 2009) is currently an IETF Proposed Standard. It appears to have little or no community traction, after 4 years. In fact, my impression is that it has been actively rejected by the community. Especially given an effort like DMARC, it would simplify the landscape -- that is, avoid possible confusion -- if ADSP were deprecated. So I'd like to ask for comment about an effort to move RFC 5617 to Historical status. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pmidge@messagebus.com Wed Sep 11 15:43:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C615711E8106 for ; Wed, 11 Sep 2013 15:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH0hBZNADXCh for ; Wed, 11 Sep 2013 15:43:43 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AACE311E8102 for ; Wed, 11 Sep 2013 15:43:43 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so9739884pbb.34 for ; Wed, 11 Sep 2013 15:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagebus.com; s=mail; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; bh=zFABvnD5jxmVsdEGUJLdeWMh0k9ncOtZX4YSu7CoDJs=; b=bW61VQt5BZw3DmCq7TP0BRQPjv1RGFDt6EpG/BS8kcWvMONsv91fqJzQKPYMInzmit S0+BYf8K1+b+AHoZXQwcwSFPoDMauAIMCJERra/ZkG8MmfIwjDjEFK62/L/BjzZ7EjBB Au4VYejjEt2sqOETaoq+y4piNWM0YZs7YPYgM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=zFABvnD5jxmVsdEGUJLdeWMh0k9ncOtZX4YSu7CoDJs=; b=RN/CjdCgzs5rQ8djQy6ohDwUmaVeuH2SM9/9A/BQYBVYZPSAXmLeRQSGJTESDkwN3x V271CeXBZqUQoAOv5pZSWDB3h8xXUC0wmzy7uhmLwezB3Y4MmqwJBc3X2OsFd94ueqiv PSXO4iGfp382y00jjjA0wNEcEjULiCWjToJbvIJt3NzC2s8RVWchqBGhko39ghDgeQxe L32z2+q53cjqlAE4kzWpoe/EMgvi/6htsvlcsv5do5X/lYI8M7YmyVOkiRNTPZSsz2Uw 918QwNbxM7GGhG/0h20lbfiyll+fB7JnfO3rkKykNgeBl++A+kRiPcPhBGHoiolRUTr1 inRg== X-Gm-Message-State: ALoCoQkQ2rx0g505vQHvqRatw4ttkD+KwUC8fHDTmwiG6sIFBMnHvfTgiSRU31dzjzwJQtj9rXj5 X-Received: by 10.68.137.231 with SMTP id ql7mr4303837pbb.37.1378939423401; Wed, 11 Sep 2013 15:43:43 -0700 (PDT) Received: from [172.16.10.169] (75-147-138-229-SFBA.hfc.comcastbusiness.net. [75.147.138.229]) by mx.google.com with ESMTPSA id yg3sm6065204pab.16.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Sep 2013 15:43:42 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Wed, 11 Sep 2013 15:43:37 -0700 From: Paul Midgen To: Dave Crocker , "dmarc@ietf.org" Message-ID: Thread-Topic: [dmarc-ietf] ADSP to Historic? In-Reply-To: <5230E691.1030703@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3461759021_8750179" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 22:43:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3461759021_8750179 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit do you just need votes in support or something else? my vote in support: +1 to historical. awaiting instructions on "something else". ;) -p From: Dave Crocker Date: Wednesday, September 11, 2013 2:54 PM To: "dmarc@ietf.org" Subject: [dmarc-ietf] ADSP to Historic? > Folks, > > G'day. > > DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) > (RFC 5617, August 2009) is currently an IETF Proposed Standard. > > It appears to have little or no community traction, after 4 years. In > fact, my impression is that it has been actively rejected by the community. > > Especially given an effort like DMARC, it would simplify the landscape > -- that is, avoid possible confusion -- if ADSP were deprecated. > > So I'd like to ask for comment about an effort to move RFC 5617 to > Historical status. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --B_3461759021_8750179 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
do you just need votes in sup= port or something else?

my vote in support: +1 to h= istorical.

awaiting instructions on "something else= ". ;)

-p

From: Dave Crocker <dcr= ocker@gmail.com>
Date: Wedn= esday, September 11, 2013 2:54 PM
To: "dmarc@ietf.org" <dmarc@ietf.org>
Su= bject: [dmarc-ietf] ADSP to Historic?

Folks,
G'day.

DomainKeys Identified Mail (DKIM= ) Author Domain Signing Practices (ADSP)
(RFC 5617, August 2009) = is currently an IETF Proposed Standard.

It appears = to have little or no community traction, after 4 years.  In
=
fact, my impression is that it has been actively rejected by the commun= ity.

Especially given an effort like DMARC, it woul= d simplify the landscape
-- that is, avoid possible confusion -- = if ADSP were deprecated.

So I'd like to ask for com= ment about an effort to move RFC 5617 to
Historical status.
=

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
=
_______________________________________________
dmarc mailing= list
https://www.ietf.org/= mailman/listinfo/dmarc

--B_3461759021_8750179-- From dcrocker@gmail.com Wed Sep 11 16:04:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD211E815B for ; Wed, 11 Sep 2013 16:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMbBQsrNuWh5 for ; Wed, 11 Sep 2013 16:04:07 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 606D211E8106 for ; Wed, 11 Sep 2013 16:04:07 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id es8so9222698obc.14 for ; Wed, 11 Sep 2013 16:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tKvB60WYPp4lkHH7uR0kQrXq3jJ5oBm0UsZpL6JMji4=; b=tKUlF0Tmn4iQ0w2vc0cSnnawkODAT00fWRJMs/zzqGQ+OeIiG8C8Q1wAa1RMaSJxmJ dDHQREE5ApxoN/xrXiS5cj3EYvulbRqLIVSOtnLDXIDdzdiad+IVSQk5Zu06hCNw3bDP gAwDqrS2IStRtw8SCsxn0LKiyRa3UosUKWwluFU7i2HPgqvg31FeBQlS99M1LxBg3wPT jdmmLD5uInxRMQxHlWpMlqE1LbPAtRJpa5ikO5r1uzVv78D++EFg/+QUMC4Y8ToLrdXY +sqmngjwecO5NvfVy54zxEHP+9wGje+tWRWTjQbpbP3eMOn5BBmNvQasxBzRFDl8t607 qW3A== X-Received: by 10.182.143.103 with SMTP id sd7mr3711311obb.70.1378940644835; Wed, 11 Sep 2013 16:04:04 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id u3sm831834oeq.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 16:04:03 -0700 (PDT) Message-ID: <5230F6CC.20902@gmail.com> Date: Wed, 11 Sep 2013 16:03:40 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Midgen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 23:04:08 -0000 On 9/11/2013 3:43 PM, Paul Midgen wrote: > do you just need votes in support or something else? > > my vote in support: +1 to historical. > > awaiting instructions on "something else". ;) just looking for initial reactions, to judge whether to make the formal request. a +/- 1 certainly qualifies. thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pmidge@messagebus.com Wed Sep 11 16:11:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC9A11E81C5 for ; Wed, 11 Sep 2013 16:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szUJyME5YYzd for ; Wed, 11 Sep 2013 16:11:43 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 168D811E8186 for ; Wed, 11 Sep 2013 16:11:43 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so264961pab.38 for ; Wed, 11 Sep 2013 16:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagebus.com; s=mail; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=A+N6ssd0LSYowD05fFtD8Rt4vzTT7rwnHJliz2dmG/I=; b=YNySRzMfE59GqDx5bkMfSDZeg73QbvPuwzM+cJsJwxaWYdSor4fyeu20wfQRHRCGt/ WBC4dHVkmafqUloiolvkyz1pdhQHIAQzfEGlDEkwTz4wF+dgKYr9yevytSV40eMniIH0 LcMjK++nnMvU9bAKlC5dEY6syndIBeHdzimNs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=A+N6ssd0LSYowD05fFtD8Rt4vzTT7rwnHJliz2dmG/I=; b=Jc2yFc5Ws04vCss1nwDHRSKJNNWYQs7wR36RKk3WMjM4IHV7+dGzLtT5reper8lNQw dD6NhbtLZJYwX8G33jyUod7Y/tZSHG/hH+ckl3xi5CRMShqcG2pcOgGvkTmPj5wQaaxl oEWc0Ng66tlcbEGYiMXUvLquU1ZbZKZ5dCWfRSeNzs+HKlMORb19UVR6Ns2KETk9HWwX gF2bEPh4pANfNQWmiNZM/nT8OEp3MEQOss4NtRlkRIVNdX4ga5TmXlUUDo48EdDCsvuv a0hx7KWejSfjfHj6UGXO9dXVH+xkNmAKrOlfhgtetrHecw85iKETBXmJHPjFILNi4W8G px3Q== X-Gm-Message-State: ALoCoQmVEihyvPrquBzCgWoxpeck9t4OXk+V885DSDAn2enyf7qnRvo8RdeX4jwq2JoXX3WRiXSj X-Received: by 10.68.219.104 with SMTP id pn8mr4384405pbc.81.1378941102572; Wed, 11 Sep 2013 16:11:42 -0700 (PDT) Received: from [172.16.10.169] (75-147-138-229-SFBA.hfc.comcastbusiness.net. [75.147.138.229]) by mx.google.com with ESMTPSA id lm2sm6231201pab.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Sep 2013 16:11:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Wed, 11 Sep 2013 16:11:36 -0700 From: Paul Midgen To: Dave Crocker Message-ID: Thread-Topic: [dmarc-ietf] ADSP to Historic? In-Reply-To: <5230F6CC.20902@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3461760701_8844859" Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 23:11:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3461760701_8844859 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ok. i know this area can be a polarizing issue, but when i planned the SPF implementation at hotmail a few years ago, i also researched the use of ADSP on our inbound mail and found that ADSP records existed for less than 0.003% of traffic where it would ostensibly have been used, and that any effect it would have had was utterly and indisputably dwarfed first by an internal domain policy system, then by DMARC. in my case it was hello nail, meet coffin. disclaimers: i am no longer a hotmail employee. that data is now at least 2 years old. there is a good chance that i'm off by a zero in either direction (not that it matters much in this case). if you want current data to bolster your case i can connect you offline with some former colleagues. From: Dave Crocker Date: Wednesday, September 11, 2013 4:03 PM To: Paul Midgen Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? > On 9/11/2013 3:43 PM, Paul Midgen wrote: >> do you just need votes in support or something else? >> >> my vote in support: +1 to historical. >> >> awaiting instructions on "something else". ;) > > > just looking for initial reactions, to judge whether to make the formal > request. a +/- 1 certainly qualifies. > > thanks. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --B_3461760701_8844859 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
ok. i know this area can be a= polarizing issue, but when i planned the SPF implementation at hotmail a fe= w years ago, i also researched the use of ADSP on our inbound mail and found= that ADSP records existed for less than 0.003% of traffic where it would os= tensibly have been used, and that any effect it would have had was utterly a= nd indisputably dwarfed first by an internal domain policy system, then by D= MARC.

in my case it was hello nail, meet coffin.

disclaimers: i am no longer a hotmail employee= . that data is now at least 2 years old. there is a good chance that i'm off= by a zero in either direction (not that it matters much in this case). if y= ou want current data to bolster your case i can connect you offline with som= e former colleagues.

From: <= /span> Dave Crocker <dcrocker@gmail.c= om>
Date: Wednesday, Septem= ber 11, 2013 4:03 PM
To: Paul Midg= en <pmidge@messagebus.com><= br>Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] AD= SP to Historic?




 --B_3461760701_8844859-- From sweet@secondlook.com Wed Sep 11 22:34:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1A421F9F34 for ; Wed, 11 Sep 2013 22:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi0CeCzJWUlb for ; Wed, 11 Sep 2013 22:34:07 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 500EF21F9F31 for ; Wed, 11 Sep 2013 22:34:07 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so10115120pbc.17 for ; Wed, 11 Sep 2013 22:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=subject:references:from:content-type:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version; bh=VU5u4cOl7UL4X+8D14jqlQZrjr9qYOTcTArEwlLdGw0=; b=k55UNJWguEnZkPZKVDSpltEmmf5nAjUwNTksTE84VEZ5L+x9fFKWNTRLqwlxP2baDZ w2Y+zcn0rD6QC+RRKXxBiH67iEiSJTqeUfw3VA3ye2IjhGFKF+1yO8fDaT9WoeDitCoV iIa1e1xp43vuZecDgJX+MLLBVALeaW5gTj1DM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=VU5u4cOl7UL4X+8D14jqlQZrjr9qYOTcTArEwlLdGw0=; b=LfhOjB4hvfgdjM+pT/Lw+SpZJBDiQix0FpJHnPMdsiK2Q/eg2DMntl+dokLCgYIoe7 LaNEixFw6FoAS5aZalmfoNwNupsxpbrydk5o7XW6jRf0NcUj7kX+t+bGHOJObAPPKMUk aKnmPysoQpzU7wOxaMJ4UOTR/RgGRlEYI1ewNEvxCmUAenaT1P49pLIIYaGg/qy9/UOV DJLDaU6E0Gf8S936Eax3SY6HBflVXjMep4v9puJO3VqqDfiDDbZHa9vWCDyMDnNu/4UL pDFdAxfYWCqpW5BN4xTH3CflX7a8jeaP8TSkgIWbSldq8E9r4B5+L3Z6Qpj4Rzx0TKRk fB1g== X-Gm-Message-State: ALoCoQndlRYRoP1jGlDvui/gJrx3rMQHWGp6KoqcZlkT6KAo/PnR228uAL9g5KirpAPZy4FRI1lL X-Received: by 10.66.251.1 with SMTP id zg1mr1121411pac.160.1378964043793; Wed, 11 Sep 2013 22:34:03 -0700 (PDT) Received: from [192.168.0.123] (50-0-158-65.dsl.dynamic.sonic.net. [50.0.158.65]) by mx.google.com with ESMTPSA id xn12sm8039057pac.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 22:34:02 -0700 (PDT) References: <5230E691.1030703@gmail.com> From: John Sweet Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9B206) In-Reply-To: <5230E691.1030703@gmail.com> Message-Id: Date: Wed, 11 Sep 2013 22:34:07 -0700 To: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 05:34:07 -0000 On Sep 11, 2013, at 2:54 PM, Dave Crocker wrote: > So I'd like to ask for comment about an effort to move RFC 5617 to Histori= cal status. Yes, please. Maybe a wake? I feel like there should be a wake. ADSP, we hardly knew ye. From sca@andreasschulze.de Thu Sep 12 03:33:01 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3530A21E809F for ; Thu, 12 Sep 2013 03:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmxCr6MaTmJJ for ; Thu, 12 Sep 2013 03:32:56 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id B819211E815F for ; Thu, 12 Sep 2013 03:32:56 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1378981669; atpsh=sha256; atps=andreasschulze.de; r=y; bh=LjSTq/Mh2l+wg6P9DpRqwn+7Eq/ZoIoGZRJpSlzfcTs=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Thu,=2012=20Sep=202013=2012:27:40=20+0200|From:=20Andreas =20Schulze=20|To:=20dmarc@ietf.org|Subject: =20Re:=20[dmarc-ietf]=20ADSP=20to=20Historic?|References:=20<5230E 691.1030703@gmail.com>|In-Reply-To:=20<5230E691.1030703@gmail.com> ; b=pnALtn4ofLV/Egs87XU5wtYJ/O1URjg2cQThlIhGT5QXf3tn01fGml1mj0a4UVi1C 4A3HBS+kEq5uLe0fiD4wWPcQ8SKbyzPRsqIep7T6y7DFy4+NCZO7+PCwk/Z6XlUiyS icTuj4dzfvPkmM9KQqcRG5y2MK5tIx5+za2fxI6MgBkfHhO9oF7tPIBbmsdwICSEr7 OhF8HRp9aVJWMdWQmTfVTXF5LBWNZX+tA1Zg4vBtmyWHJOlmo94kLY/2tlJAlBLYE+ OgF1BEzE1PmJWLnsYvlBFKGXZGOazk5nQDldPC50imcoU93hew3FVdPGtwryDSIGcl CITulsLPQB4xmU0W3xmp1PcwSKWaChxtK/FVkXGJsb1eePqn37q/R4N+SUCuMhPgey 2xL84qfT6mmdB4HP58OhBAEWE3KSN3nFEcvG+DcZQYXZudBhEIJWwxQ1a2ZK4Cjsze khbV01ppQZaAh5QKwrHzr1tKYQppVnDj0uovkueeezhx9aUaLnJILVi5hiUuFKy0UW DAQYHCV0x7/y+0sqhNtgZLXIuL2KEEmhbcp+gnM93gz94wTe8vx6DwqxtBrCpwOik9 fzxBZ96V9t7mn1Vr1w1Tla4OqbPeGQkF9Q6CuAInW58BgG4LLVS+icldXa8nwKVWrq 5z3oHAqf4DhYA1vz6PUsUtLA= X-Received: line deleted by mout Date: Thu, 12 Sep 2013 12:27:40 +0200 Message-ID: <20130912122740.Horde.UIoemboI2ulrh_QQFP_hRg4@horde.andreasschulze.de> From: Andreas Schulze To: dmarc@ietf.org References: <5230E691.1030703@gmail.com> In-Reply-To: <5230E691.1030703@gmail.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 10:33:01 -0000 Zitat von Dave Crocker : > So I'd like to ask for comment about an effort to move RFC 5617 to > Historical status. I just removed all my _adsp records from dns. Some of them where disabled anyway since I started using dmarc. so +1 for historical. Andreas From olgag@google.com Thu Sep 12 07:08:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541BE21E80B7 for ; Thu, 12 Sep 2013 07:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTpaKsacWVEv for ; Thu, 12 Sep 2013 07:08:30 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B521E80FA for ; Thu, 12 Sep 2013 07:08:20 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp18so547995obc.8 for ; Thu, 12 Sep 2013 07:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EoYXKyqyoF6MukmZbGQuRW0FQ6IiZ11qtxjNmF5w7c8=; b=ZAng6OBae6V7DWUBme2+s3uTYL4UAL2jcU/ngW2hZzN6tONWreoxSC8ogPCu1Csv03 ibtmLyaAUMLwrRmn+fA6cETiiODfxPAMNPZxPIKXLg5x01LmhfhlSM5q55z+edGj/qHl t5SlT4YFAYfjOskl4nAVjdiypF6+cIgmF3gB9dzJHYBB+V8WzEp3ZcHgrZQGW562p7qS 3IE7K1v1fXbANGfkzF/oeUkBSsaRsKMkHDm9LCcNDakEzXNGJWWCIYbeWdnGRP6OTKyu +ItbKZ91N05Vpllyda+eh+MAjKe+yG7CeOCmDKOAdfPBeIcw3SQBQpsCh+g5kn5nUZ0X rwDg== 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=EoYXKyqyoF6MukmZbGQuRW0FQ6IiZ11qtxjNmF5w7c8=; b=H4G4uVrj8isZFG5FMnaK66DtgVR6U/M6q9/W3f9TRfsv8YSdIC4n4cO7qBih+EmrXc z7TbTeH7I1ILozTevjWa9GzpgiMh6Ok3DUugWeWsERkTFe9AdMq+M2ZW0KvgFzDhOQN2 qNcoQCDHRTK4jEoAiJXezJ+06t70c8lTuU44llW0cBYBUYmDBnuyJqPeUAeuN37pexQ9 SSIMfZ52i0or9EFEP6BcrB/QgT3eFv1fh0+C8Uz/mJdGigRppQqHoA5D5ECIIJZR4R0+ GSg1QhMMBjkPyNVHSuxutz6bPRWEhd0Gom4SaR1P+B0PP36dPEE9zkEnhkl0V1/HptIl d3DA== X-Gm-Message-State: ALoCoQmuxUJWEJDW3SlZOKlQ2UTHejvxxTk03r3tAalWL7iW7omvryZdxpf2K+r0WFwcBRDTlB+RjBafE4kzcuj+4p1BTtMsVN8b0+eYO4Fy4IYgIC29OCKVsKpwxKWnA5rxSOXv1SGAYQcfUprbzKsIrn9KXnMFwa69QMZofF34VgDSRfNJWPqoBFY5rJpWxQ+jvay/UoPa MIME-Version: 1.0 X-Received: by 10.60.56.3 with SMTP id w3mr6889294oep.37.1378994893691; Thu, 12 Sep 2013 07:08:13 -0700 (PDT) Received: by 10.182.130.229 with HTTP; Thu, 12 Sep 2013 07:08:13 -0700 (PDT) In-Reply-To: <5230E691.1030703@gmail.com> References: <5230E691.1030703@gmail.com> Date: Thu, 12 Sep 2013 07:08:13 -0700 Message-ID: From: Olga Gavrylyako To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c20a72c9349d04e63044fd Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:08:31 -0000 --001a11c20a72c9349d04e63044fd Content-Type: text/plain; charset=ISO-8859-1 +1 for historical. In Gmail we already deprecated ADSP-related code. On Wed, Sep 11, 2013 at 2:54 PM, Dave Crocker wrote: > Folks, > > G'day. > > DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) > (RFC 5617, August 2009) is currently an IETF Proposed Standard. > > It appears to have little or no community traction, after 4 years. In > fact, my impression is that it has been actively rejected by the community. > > Especially given an effort like DMARC, it would simplify the landscape -- > that is, avoid possible confusion -- if ADSP were deprecated. > > So I'd like to ask for comment about an effort to move RFC 5617 to > Historical status. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ______________________________**_________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/**listinfo/dmarc > --001a11c20a72c9349d04e63044fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 for historical. In Gmail we already deprecated ADSP-rel= ated code.


On Wed, Sep 11, 2013 at 2:54 PM, Dave Crocker <= dcrocker@gmail.com<= /a>> wrote:
Folks,

G'day.

DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (R= FC 5617, August 2009) is currently an IETF Proposed Standard.

It appears to have little or no community traction, after 4 years. =A0In fa= ct, my impression is that it has been actively rejected by the community.
Especially given an effort like DMARC, it would simplify the landscape -- t= hat is, avoid possible confusion -- if ADSP were deprecated.

So I'd like to ask for comment about an effort to move RFC 5617 to Hist= orical status.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--001a11c20a72c9349d04e63044fd-- From krishvi@microsoft.com Thu Sep 12 07:33:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1B311E818B for ; Thu, 12 Sep 2013 07:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGNO5PJHZWF8 for ; Thu, 12 Sep 2013 07:33:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 020B611E814D for ; Thu, 12 Sep 2013 07:33:04 -0700 (PDT) Received: from BY2PR03MB176.namprd03.prod.outlook.com (10.242.36.153) by BY2PR03MB176.namprd03.prod.outlook.com (10.242.36.153) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 12 Sep 2013 14:33:02 +0000 Received: from BY2PR03MB176.namprd03.prod.outlook.com ([169.254.8.142]) by BY2PR03MB176.namprd03.prod.outlook.com ([169.254.8.142]) with mapi id 15.00.0775.005; Thu, 12 Sep 2013 14:33:02 +0000 From: Krish Vitaldevara To: Paul Midgen , Dave Crocker Thread-Topic: [dmarc-ietf] ADSP to Historic? Thread-Index: AQHOrzmmUDWJM6sVSUWEGKMtLdCf35nBIkGAgAAFmgCAAAI4AIABAV3w Date: Thu, 12 Sep 2013 14:33:02 +0000 Message-ID: <45fdef4ea64040dab19d929727669d3d@BY2PR03MB176.namprd03.prod.outlook.com> References: <5230F6CC.20902@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.6.73.196] x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(199002)(189002)(15202345003)(76482001)(69226001)(19580395003)(19580405001)(83322001)(53806001)(54316002)(56776001)(66066001)(33646001)(50986001)(79102001)(77982001)(81342001)(51856001)(59766001)(81816001)(80022001)(54356001)(47976001)(47736001)(63696002)(81686001)(46102001)(81542001)(83072001)(76796001)(74662001)(31966008)(47446002)(74502001)(74316001)(16236675002)(80976001)(15975445006)(74876001)(4396001)(76576001)(77096001)(74366001)(56816003)(49866001)(19609705001)(65816001)(76786001)(19300405004)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB176; H:BY2PR03MB176.namprd03.prod.outlook.com; CLIP:24.6.73.196; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_45fdef4ea64040dab19d929727669d3dBY2PR03MB176namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:33:10 -0000 --_000_45fdef4ea64040dab19d929727669d3dBY2PR03MB176namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. And Paul, the numbers didn't change much there. From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of P= aul Midgen Sent: Wednesday, September 11, 2013 4:12 PM To: Dave Crocker Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ADSP to Historic? ok. i know this area can be a polarizing issue, but when i planned the SPF = implementation at hotmail a few years ago, i also researched the use of ADS= P on our inbound mail and found that ADSP records existed for less than 0.0= 03% of traffic where it would ostensibly have been used, and that any effec= t it would have had was utterly and indisputably dwarfed first by an intern= al domain policy system, then by DMARC. in my case it was hello nail, meet coffin. disclaimers: i am no longer a hotmail employee. that data is now at least 2= years old. there is a good chance that i'm off by a zero in either directi= on (not that it matters much in this case). if you want current data to bol= ster your case i can connect you offline with some former colleagues. From: Dave Crocker > Date: Wednesday, September 11, 2013 4:03 PM To: Paul Midgen > Cc: "dmarc@ietf.org" > Subject: Re: [dmarc-ietf] ADSP to Historic? On 9/11/2013 3:43 PM, Paul Midgen wrote: do you just need votes in support or something else? my vote in support: +1 to historical. awaiting instructions on "something else". ;) just looking for initial reactions, to judge whether to make the formal request. a +/- 1 certainly qualifies. thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --_000_45fdef4ea64040dab19d929727669d3dBY2PR03MB176namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.

 <= /p>

And Paul, the numbers did= n’t change much there.

 <= /p>

 

From: dmarc-= bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of Paul Midgen
Sent: Wednesday, September 11, 2013 4:12 PM
To: Dave Crocker
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP to Historic?

 

ok. i know this area can be a= polarizing issue, but when i planned the SPF implementation at hotmail a f= ew years ago, i also researched the use of ADSP on our inbound mail and found that ADSP records existed for less than 0.003% of traffic w= here it would ostensibly have been used, and that any effect it would have = had was utterly and indisputably dwarfed first by an internal domain policy= system, then by DMARC.

 

in my case it was hello nail,= meet coffin.

 

disclaimers: i am no longer a hotmail employee. that data is now at= least 2 years old. there is a good chance that i'm off by a zero in either direc= tion (not that it matters much in this case). if you want current data to b= olster your case i can connect you offline with some former colleagues.

 

From: Dave Crocker <dcrocker@gmail.com>
Date: Wednesday, September 11, 2013 4:03 PM
To: Paul Midgen <pmidge@= messagebus.com>
Cc: "dmarc@ietf.org"= <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] ADSP to Historic?

 

On 9/11/2013 3:43 PM, Paul Mi= dgen wrote:

do you just need votes in sup= port or something else?

 

my vote in support: +1 to= historical.

 

awaiting instructions on &quo= t;something else". ;)

 

 

just looking for initial reac= tions, to judge whether to make the formal

request.  a +/-= 1 certainly qualifies.

 

thanks.

 

d/

--

Dave Crocker

Brandenburg InternetWorking

bbiw.net

 

--_000_45fdef4ea64040dab19d929727669d3dBY2PR03MB176namprd03pro_-- From R.E.Sonneveld@sonnection.nl Thu Sep 12 08:26:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8678821E8104 for ; Thu, 12 Sep 2013 08:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9uy5u0PfYoE for ; Thu, 12 Sep 2013 08:26:16 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id B8A6821E81F2 for ; Thu, 12 Sep 2013 08:25:48 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3cbP1t3lZBz1L8fB; Thu, 12 Sep 2013 17:25:38 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3cbP1t2Wz8z5Mhcc; Thu, 12 Sep 2013 17:25:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id EEB441231E3; Thu, 12 Sep 2013 17:25:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id twGerHfoxSmM; Thu, 12 Sep 2013 17:25:31 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id C90B91231DE; Thu, 12 Sep 2013 17:25:31 +0200 (CEST) Message-ID: <5231DCEB.4000200@sonnection.nl> Date: Thu, 12 Sep 2013 17:25:31 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dave Crocker References: <5230E691.1030703@gmail.com> In-Reply-To: <5230E691.1030703@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1378999538; bh=L0ZlySd6Aq/9i1oEQ42k/dizRW66s90M4V/+zWOsCD0=; h=Message-ID:Date:From:To:Subject:From; b=GVrUqhAP6xdcqKqjIwgj+aCJMg5rsT58CayCtRCht37C6+jlHegUUN1FP9Hv3o9tg Dvyn/bzcOyCjP0CIPhgvl5lc7+SqicQHP/2qSJfk3YvuyGjO8+se0t/xDuJVZ8PXka upiQtIHj9dfsI+qJtrmujEfYu6w3vcMAeF4KaKQs= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3cbP1t3lZBz1L8fB Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:26:37 -0000 On 09/11/2013 11:54 PM, Dave Crocker wrote: > Folks, > > G'day. > > DomainKeys Identified Mail (DKIM) Author Domain Signing Practices > (ADSP) (RFC 5617, August 2009) is currently an IETF Proposed Standard. > > It appears to have little or no community traction, after 4 years. In > fact, my impression is that it has been actively rejected by the > community. > > Especially given an effort like DMARC, it would simplify the landscape > -- that is, avoid possible confusion -- if ADSP were deprecated. > > So I'd like to ask for comment about an effort to move RFC 5617 to > Historical status. +1 for moving it to Historic. /rolf From smj@crash.com Thu Sep 12 08:39:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1DD21E8107 for ; Thu, 12 Sep 2013 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsh0qy14SdM3 for ; Thu, 12 Sep 2013 08:38:55 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [72.52.75.15]) by ietfa.amsl.com (Postfix) with ESMTP id 15E3E21F8416 for ; Thu, 12 Sep 2013 08:38:40 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id r8CFcU3A000484 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Sep 2013 08:38:36 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com r8CFcU3A000484 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1379000316; bh=qPCt0cwSjxuAdqAE1JRFr8FoE5bYBBfw1YUTLR9V61E=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=C7J+YFAECnCJ1esRS3oX6f5ygf5cRSNWi2Vt9JXX0vHchDBA9wVc+40aA2Ce/Zx+w 556GwZQ8Dd2+x6s+hUHFFaH4bLDGVmqZwTF4qD7yO9XFzJEGxmnK3D8zLhyqueOSAg wdCBdlAlFDmrifDkifuj+/jbwyiAIbaHOs+sxnRg= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be abort.crash.com Message-ID: <5231DFF2.10904@crash.com> Date: Thu, 12 Sep 2013 08:38:26 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <5230F6CC.20902@gmail.com> <45fdef4ea64040dab19d929727669d3d@BY2PR03MB176.namprd03.prod.outlook.com> In-Reply-To: <45fdef4ea64040dab19d929727669d3d@BY2PR03MB176.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------070804030305000706090205" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 12 Sep 2013 08:38:36 -0700 (PDT) Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:39:09 -0000 This is a multi-part message in MIME format. --------------070804030305000706090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/12/2013 07:33 AM, Krish Vitaldevara wrote: > > +1. > > And Paul, the numbers didn't change much there. > > +1 provided the data supports it. I know Microsoft sees an enormous volume, but I would still suggest getting some additional, corroborating sources to support any formal application. But you probably had that in mind already any way... --S. --------------070804030305000706090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/12/2013 07:33 AM, Krish Vitaldevara wrote:

+1.

 

And Paul, the numbers didn’t change much there.

 


+1 provided the data supports it. I know Microsoft sees an enormous volume, but I would still suggest getting some additional, corroborating sources to support any formal application. But you probably had that in mind already any way...

--S.
--------------070804030305000706090205-- From matt@tnpi.net Thu Sep 12 08:39:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0E611E8242 for ; Thu, 12 Sep 2013 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWAaNFDqzFB5 for ; Thu, 12 Sep 2013 08:39:06 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 639B621E80D1 for ; Thu, 12 Sep 2013 08:38:48 -0700 (PDT) Received: (qmail 45251 invoked by uid 1026); 12 Sep 2013 15:38:44 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.127]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Thu, 12 Sep 2013 11:38:44 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@tnpi.net; iprev=pass X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=references:mime-version:in-reply-to:content-type:content-transfer-encoding:message-id:cc:from:subject:date:to; s=mar2013; bh=EWcVkzdlMNLFHmaVC9hM7UyjQHpEOkRt/o9Sz2/waj4=; b=iT6dhsFW3nUm3q58qKhOfFUINKaRIJIdX1CctFTdVV2y1Vskcwo7z+11wFBwzgQn9w1NTMCLNZpFxrc84BaceybVKUP8XnlqH/oIrfQD1d86QzBXdlYuSq4dVCZyiCflHu8hzMIRTn/3buteWSxt+jvIrDKSZRHqIN0nSqeQjHGGvFp2LmeAJ++UqLp2FKd54nkaxBj50Fi7nKFVjEX2jKawsd5K8rak1rvoE6lqnpbpPPeSXHFBbvuDmAUYmFwoMKHgQwdIoa3dSu2NlT0qOUkTTKWi0CAMuPy/V/uvaqvbC61/tN9ZWVSsRlFtnUJaim/gdFVajP0H+P4JisiwHA== X-HELO: [10.0.1.127] References: <5230F6CC.20902@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5230F6CC.20902@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Matt Simerson Date: Thu, 12 Sep 2013 08:38:42 -0700 To: Dave Crocker Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:39:23 -0000 +1 On Sep 11, 2013, at 4:03 PM, Dave Crocker wrote: > On 9/11/2013 3:43 PM, Paul Midgen wrote: >> do you just need votes in support or something else? >>=20 >> my vote in support: +1 to historical. >>=20 >> awaiting instructions on "something else". ;) >=20 > just looking for initial reactions, to judge whether to make the formal re= quest. a +/- 1 certainly qualifies. >=20 > thanks. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From zwicky@yahoo-inc.com Thu Sep 12 08:39:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D7411E8272 for ; Thu, 12 Sep 2013 08:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AM3R31nUL7B for ; Thu, 12 Sep 2013 08:39:23 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDC311E8234 for ; Thu, 12 Sep 2013 08:38:53 -0700 (PDT) Received: from GQ1-EX10-CAHT08.y.corp.yahoo.com (gq1-ex10-caht08.corp.gq1.yahoo.com [10.73.118.87]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r8CFbL26072918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 08:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1379000243; bh=//k5qkeAgKL2LGz8Psv3DGaAKbX/mMLSTF5wMYR95gY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:Content-Type: MIME-Version; b=IFC9icU8wF6i+x2mws0tm736MLlUR3UDYS4GMPcrt3kpc7v3WKx1im8iByI0WHfuk mGoLzrfmHaSoEb/9a847N8+UMTu6Ky0c5YTUyW5hR+eVGzHlg+0J1uDi4fl2d/nUSs Xa6ssiTxOsUv+b/6EcPOSg3o3atmQcl8wMF+GfNI= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT08.y.corp.yahoo.com ([fe80::1da1:7b65:cb46:5de4%16]) with mapi id 14.03.0158.001; Thu, 12 Sep 2013 08:37:20 -0700 From: Elizabeth Zwicky To: Krish Vitaldevara , Paul Midgen , Dave Crocker Thread-Topic: [dmarc-ietf] ADSP to Historic? Thread-Index: AQHOrzn0lDr21FFbW0OHldmWKeITFpnBl5mAgAAFmgCAAAI4AIABAXIA//+cnAA= Date: Thu, 12 Sep 2013 15:37:20 +0000 Message-ID: In-Reply-To: <45fdef4ea64040dab19d929727669d3d@BY2PR03MB176.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [216.145.54.7] Content-Type: multipart/alternative; boundary="_000_CE572D2AD2858zwickyyahooinccom_" MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 000242011 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:39:30 -0000 --_000_CE572D2AD2858zwickyyahooinccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1. The only uptake we've noticed is from people who complain that the name= returns a non-TXT non-fail for yahoo.com (which the standard says is a leg= itimate case meaning "there is no ADSP record here, move on"). So uptake lo= oks both minimal and buggy. Elizabeth From: Krish Vitaldevara > Date: Thursday, September 12, 2013 7:33 AM To: Paul Midgen >, Dave= Crocker > Cc: "dmarc@ietf.org" > Subject: Re: [dmarc-ietf] ADSP to Historic? +1. And Paul, the numbers didn=92t change much there. From: dmarc-bounces@ietf.org [mailto:dmarc-b= ounces@ietf.org] On Behalf Of Paul Midgen Sent: Wednesday, September 11, 2013 4:12 PM To: Dave Crocker Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ADSP to Historic? ok. i know this area can be a polarizing issue, but when i planned the SPF = implementation at hotmail a few years ago, i also researched the use of ADS= P on our inbound mail and found that ADSP records existed for less than 0.0= 03% of traffic where it would ostensibly have been used, and that any effec= t it would have had was utterly and indisputably dwarfed first by an intern= al domain policy system, then by DMARC. in my case it was hello nail, meet coffin. disclaimers: i am no longer a hotmail employee. that data is now at least 2= years old. there is a good chance that i'm off by a zero in either directi= on (not that it matters much in this case). if you want current data to bol= ster your case i can connect you offline with some former colleagues. From: Dave Crocker > Date: Wednesday, September 11, 2013 4:03 PM To: Paul Midgen > Cc: "dmarc@ietf.org" > Subject: Re: [dmarc-ietf] ADSP to Historic? On 9/11/2013 3:43 PM, Paul Midgen wrote: do you just need votes in support or something else? my vote in support: +1 to historical. awaiting instructions on "something else". ;) just looking for initial reactions, to judge whether to make the formal request. a +/- 1 certainly qualifies. thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --_000_CE572D2AD2858zwickyyahooinccom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6BEBC7B0AA5F064AA1D8DF6E47413B96@yforest.corp.yahoo.com> Content-Transfer-Encoding: quoted-printable
+1. The only uptake we've noticed is from people who complain that= the name returns a non-TXT non-fail for yahoo.com (which the standard says= is a legitimate case meaning "there is no ADSP record here, move on&q= uot;). So uptake looks both minimal and buggy.

Elizab= eth

From: Krish Vitaldevara <krishvi@microsoft.com>
Date: Thursday, September 12, 2013 = 7:33 AM
To: Paul Midgen <pmidge@messagebus.com>, Dave Crocker <<= a href=3D"mailto:dcrocker@gmail.com">dcrocker@gmail.com>
Cc: "dmarc@ietf.org" <dma= rc@ietf.org>
Subject: Re: [dmarc-ietf] ADSP to H= istoric?

+1.

 

And Paul, the numbers didn=92t cha= nge much there.

 

&= nbsp;

From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of Paul Midgen
Sent: Wednesday, September 11, 2013 4:12 PM
To: Dave Crocker
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP to Historic?

 

ok. i know this area can be a polarizing issu= e, but when i planned the SPF implementation at hotmail a few years ago, i = also researched the use of ADSP on our inbound mail and found that ADSP records existed for less than 0.003% of t= raffic where it would ostensibly have been used, and that any effect it wou= ld have had was utterly and indisputably dwarfed first by an internal domai= n policy system, then by DMARC.

 

in my case it was hello nail, meet coffin.

 

disclaimers: i am no lon= ger a hotmail employee. that data is now at least 2 years old. there is a good chance that i'm off by a zero in eit= her direction (not that it matters much in this case). if you want current = data to bolster your case i can connect you offline with some former collea= gues.

 

From: Dave Crocker <dc= rocker@gmail.com>
Date: Wednesday, September 11, 2013 4:03 PM
To: Paul Midgen <pmidge@= messagebus.com>
Cc: "dmarc@ietf.org"= <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] ADSP to Historic?

 

On 9/11/2013 3:43 PM, Paul Midgen wrote:=

do you just need votes in support or somethin= g else?

 

my vote in support: +1 to historical.

 

awaiting instructions on "something else= ". ;)

 

 

just looking for initial reactions, to judge = whether to make the formal

request.  a +/- 1 certainly qua= lifies.

 

thanks.

 

d/

--

Dave Crocker

Brandenburg InternetWorking=

bbiw.net

 

 --_000_CE572D2AD2858zwickyyahooinccom_-- From tim@eudaemon.net Thu Sep 12 21:21:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB7A21E80FB for ; Thu, 12 Sep 2013 21:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oiq6Cgyw088M for ; Thu, 12 Sep 2013 21:21:38 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id AD04C21E8100 for ; Thu, 12 Sep 2013 21:21:38 -0700 (PDT) Received: from [10.183.47.224] (151.sub-70-210-5.myvzw.com [70.210.5.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 0A357CB52 for ; Thu, 12 Sep 2013 16:18:40 -0400 (EDT) References: <5230F6CC.20902@gmail.com> From: Tim Draegen Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B350) In-Reply-To: <5230F6CC.20902@gmail.com> Message-Id: <35741E3D-CF95-4DBB-9CCD-0B4F17DB8436@eudaemon.net> Date: Thu, 12 Sep 2013 16:18:04 -0400 To: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [dmarc-ietf] ADSP to Historic? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 04:21:44 -0000 +1 Bonus pluses for inserting some forward reference so that naive ADSP de= ployers know where to go next. =3D- Tim On Sep 11, 2013, at 7:03 PM, Dave Crocker wrote: >=20 > just looking for initial reactions, to judge whether to make the formal re= quest. a +/- 1 certainly qualifies. From steve@mrmays.com Sat Sep 14 01:54:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9CC21E80A8 for ; Sat, 14 Sep 2013 01:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pMhxNsbVsSk for ; Sat, 14 Sep 2013 01:54:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4093711E813D for ; Sat, 14 Sep 2013 01:54:19 -0700 (PDT) Received: from BY2PR08MB110.namprd08.prod.outlook.com (10.242.38.141) by BY2PR08MB110.namprd08.prod.outlook.com (10.242.38.141) with Microsoft SMTP Server (TLS) id 15.0.775.9; Sat, 14 Sep 2013 08:54:16 +0000 Received: from BY2PR08MB110.namprd08.prod.outlook.com ([169.254.11.8]) by BY2PR08MB110.namprd08.prod.outlook.com ([169.254.11.8]) with mapi id 15.00.0775.005; Sat, 14 Sep 2013 08:54:16 +0000 From: Steve Mays To: "dmarc@ietf.org" Thread-Topic: Thoughts on the DMARC spec Thread-Index: AQHOsSf96L1oZggykkiqJbu9r+UCgw== Date: Sat, 14 Sep 2013 08:54:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.126.194.6] x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(76264002)(83072001)(31966008)(63696002)(74876001)(19580405001)(83322001)(74502001)(79102001)(81816001)(47446002)(54356001)(81686001)(74662001)(56816003)(76482001)(74366001)(54316002)(76176001)(19580395003)(80976001)(76786001)(76796001)(36756003)(16236675002)(47736001)(49866001)(50986001)(47976001)(59766001)(77982001)(4396001)(77096001)(56776001)(53806001)(81342001)(51856001)(74706001)(69226001)(81542001)(66066001)(65816001)(80022001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR08MB110; H:BY2PR08MB110.namprd08.prod.outlook.com; CLIP:76.126.194.6; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE59724360C32stevemrmayscom_" MIME-Version: 1.0 X-OriginatorOrg: mrmays.com Subject: [dmarc-ietf] Thoughts on the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 08:56:23 -0000 --_000_CE59724360C32stevemrmayscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable General Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As an email sending professional and long time corporate receiver operator,= I've been looking for something to help manage unauthorized sending practi= ces. Commonly used protocols such as SPF and DKIM are absolutely essential= . However, the challenge to the receiver is to receive clean and unequivoc= al information from the sender (or those that ask a sender to act on their = behalf) as to what to do with mail that fails one or both of SPF/DKIM. We = have lived with the receiver having to come up with that answer and then ha= ving the unauthorized sender simply move on to the next gaming of the syste= m. DMARC presents a new tool in the fight against unauthorized sending that is= quite welcome. As a sender, I talked personally to major receivers about = the need for the sending community to do a better job working with the rece= ivers. Simply put, its great to tell receivers when they can just delete u= nauthorized mail as it reduces their workload and the risk that a user of t= heir system gets mail that should never have arrived. By using DMARC, send= ers and receivers work together to fight unauthorized mail which is no long= er just a prank or hacktivists but is instead a vehicle for real crimes to = be committed using the good name of a reputable sender. I've been on the ph= one with receivers working through my results to learn how we can both defe= nd against unauthorized mail. This presents an opportunity for cooperation= that was rare in previous years. Participating DMARC data providers give senders all the information they ne= ed to understand trends in unauthorized mail; what IPs/blocks/domains/serve= rs/providers provide havens for this activity and can assist in preventing = and shutting down those operations. I've been proud of my work with sender= s, receivers and the DMARC group and believe that it provides the best mech= anism to prevent/slow/limit and report trends on authorized mail. Some questions that I have been asked to consider: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Do you feel that the overall specification is useful for the intended= purpose? * Absolutely and I'Ve used it in commercial practice to great effect= , helping customers spot and cut out unauthorized senders. * The ability to start off in monitoring/reporting only mode is a gr= eat learning opportunity. As confidence builds, the standard provides for = a greater percentage of mail to be intercepted and removed. Combining the = "mode" with "percentage" gives excellent controls to allow all parties to s= lowly move to enforcing 100% of all mail. * URI feedback mechanisms allow for various protocols such as HTTP a= nd SMTP. This allows for flexible report reception. 2. Does support already exist for the specification? For example, do yo= u know of existing deployments that rely on the current specification? * Yes! Message Bus has 100% of its customers on DMARC and works with= dmarcian to provide real knowledge of the problem areas and how bad they a= re. For example, its good to know but may not require (or may!) action if = 100 out of 10MM mails came from a forwarder or unauthorized server. * I did find unauthorized brand use, deliberate spoofing (thanks to = NetEase from China), obvious stolen accounts, phishing and spearphishing an= d many other attacks in the forensic data stream * DMARC really does allow us to address the fact that unauthorized m= ail senders attempt to make the "display name/address" actually match who i= s sending the mail and so gets to the heart of the attack against unsophist= icated users which has worked so well for them in years past (so long as th= at name contains an email address) 3. Are there critical aspects of the specification that need to be modif= ied prior to it being a published standard? * I do not believe so. I feel that we have worked the major issues = out in the last several years of maawg.org meetings and having put it into = commercial practice find it to be sufficient. 4. Are there aspects of the specification that can be modified (e.g. by = additional extensions) to improve it after it has been published as a stand= ard? * We have discussed protecting the email receivers/DMARC reporting g= enerators from obvious attempts to overwhelm their ability to gather and re= port data which would blind the entire community and allow for other types = of attack and this would be great to address in a robust manner. Allowing = the email receiver/report generator some control to limit DoS of their repo= rting system would mean a more reliable system that stays alive during deli= berate attack. 5. Does the specification as written provide a clear, precise, and accur= ate description of the steps necessary to implement the specification? * Yes it does. * Further, the dmarc.org team has worked diligently to provide a sen= dmail compliant mail filter or "milter" which gives a running code example = and executable for actually checking incoming mail against the DMARC specif= ication and DNS entries. When combined with the excellent XML Schema and e= xamples in the spec and that fact that the team addressed my specific conce= rn of having no examples of multiple "rua" and "ruf" destinations (see B.2.= 4), I am well satisfied with the spec. 6. Would you feel comfortable supporting it being published as a standar= d, or are do you have any additional reservations you would like to see add= ressed before you would support it? * I have no reservations with it being published. * I would like to thank the DMARG.org team and all of the participat= ing parties such as Yahoo, NetEase, AOL (who has helped me a LOT!), Tim Dra= gen for his dmarcian site. The community around DMARC.org has won over the= hard to please maawg.org crowd and the spec is in active use and on the wa= y to being the de-facto standard in the email community which is a testamen= t to the dedication and quality of the team and this spec. -- Steve Mays steve@mrmays.com cell: 415-385-4918 --_000_CE59724360C32stevemrmayscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8E9BDC716D76DD40A2A144F60C031148@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
General Comments:
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
As an email sending pr= ofessional and long time corporate receiver operator, I've been lookin= g for something to help manage unauthorized sending practices. &n= bsp;Commonly used protocols such as SPF and DKIM are absolutely essential.  However, the challenge to the receiver is to receive clea= n and unequivocal information from the sender (or those that ask a sender t= o act on their behalf) as to what to do with mail that fails one or both of= SPF/DKIM.  We have lived with the receiver having to come up with that answer and then having the unauthori= zed sender simply move on to the next gaming of the system.  

DMARC presents a new t= ool in the fight against unauthorized sending that is quite welcome.  = As a sender, I talked personally to major receivers about&nb= sp;the need for the sending community to do a better job working with the receivers.  Simply put, its great to tell receivers whe= n they can just delete unauthorized mail as it reduces their work= load and the risk that a user of their system gets mail that should never h= ave arrived.  By using DMARC, senders and receivers work together to fight unauthorized mail which is no longer just a pr= ank or hacktivists but is instead a vehicle for real crimes to be committed= using the good name of a reputable sender. I've been on the phone wit= h receivers working through my results to learn how we can both defend against unauthorized mail.  This present= s an opportunity for cooperation that was rare in previous years.

Participating DMARC da= ta providers give senders all the information they need to understand trend= s in unauthorized mail; what IPs/blocks/domains/servers/providers provide h= avens for this activity and can assist in preventing and shutting down those operations.  I've been proud of= my work with senders, receivers and the DMARC group and believe that it pr= ovides the best mechanism to prevent/slow/limit and report trends on author= ized mail.

Some questions t= hat I have been asked to consider:
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  1. Do you feel that the overall specification is useful for the inten= ded purpose?
    1. Absolutely and I'V= e used it in commercial practice to great effect, helping custome= rs spot and cut out unauthorized senders.
    2. The ability to start off in monitoring/report= ing only mode is a great learning opportunity.  As confidence builds, the stand= ard provides for a greater percentage of mail to be intercepted and removed.  Combining the "mode"= ; with "percentage" gives excellent controls to allow all parties= to slowly move to enforcing 100% of all mail.
    3. URI feedback mech= anisms allow for various protocols such as HTTP and SMTP.  This allows= for flexible report reception.
  2. Does support already exist for the specification?  For e= xample, do you know of existing deployments that rely on the current specif= ication?
    1. Yes! Message Bus has 10= 0% of its customers on DMARC and works with dmarcian to provide real knowle= dge of the problem areas and how bad they are.  For example, its good = to know but may not require (or may!) action if 100 out of 10MM mails came from a forwarder or unauthorized server. &nb= sp;
    2. I did fi= nd unauthorized brand use, deliberate spoofing (thanks to NetEase from Chin= a), obvious stolen accounts, phishing and spearphishing and many other atta= cks in the forensic data stream
    3. DMARC really does allow us to address the fact that u= nauthorized mail senders attempt to make the "display name/address&quo= t; actually match who is sending the mail and so gets to the heart of the a= ttack against unsophisticated users which has worked so well for them in years past (so long as that nam= e contains an email address)
  3. Are there critical aspects of the specification that need to = be modified prior to it being a published standard?
    1. I do not believe s= o.  I feel that we have worked the major issues out in the last s= everal years of maawg.org meetings and having put it into commercial practi= ce find it to be sufficient.
  4. Are there aspects of the specification that can be modified (= e.g. by additional extensions) to improve it after it has been published as= a standard?
    1. We have discussed prote= cting the email receivers/DMARC reporting generators from obvious attempts = to overwhelm their ability to gather and report data which would blind the = entire community and allow for other types of attack and this would be great to address in a robust manner= .  Allowing the email receiver/report generator some control to limit = DoS of their reporting system would mean a more reliable system that stays = alive during deliberate attack.
  5. Does the specification as written provide a clear, precise, a= nd accurate description of the steps necessary to implement the specificati= on?
    1. Yes it does. 
    2. Further, the dmarc.org team has worked diligently to = provide a sendmail compliant mail filter or "milter" which gives = a running code example and executable for actually checking incoming mail a= gainst the DMARC specification and DNS entries.  When combined with the excellen= t XML Schema and examples in the spec and that fact that the team addressed= my specific concern of having no examples of multiple "rua" and = "ruf" destinations (see B.2.4), I am well satisfie= d with the spec.
  6. Would you feel comfortable supporting it being published as a= standard, or are do you have any additional reservations you would like to= see addressed before you would support it?
    1. I have no re= servations with it being published.
    2. I would like to thank the DMARG.o= rg team and all of the participating parties such as Yahoo, NetEase, AOL (w= ho has helped me a LOT!), Tim Dragen for his dmarcian site.  The commu= nity around DMARC.org has won over the hard to please maawg.org crowd and the spec is in active use = and on the way to being the de-facto standard in the email community which = is a testament to the dedication and quality of the team and this= spec. 

--
Steve Mays
steve@mrmays.com
cell: 415-385-4918=

--_000_CE59724360C32stevemrmayscom_-- From robert@turnpikelabs.com Sun Sep 15 13:34:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4E11E81D0 for ; Sun, 15 Sep 2013 13:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.175 X-Spam-Level: ** X-Spam-Status: No, score=2.175 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtBQQsa91ESd for ; Sun, 15 Sep 2013 13:34:04 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3683411E81C6 for ; Sun, 15 Sep 2013 13:34:03 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z5so3545272lbh.37 for ; Sun, 15 Sep 2013 13:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turnpikelabs.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Wsucpu133i1dr8mkrqU1grT5iCxkci1tsfBMTzckHnA=; b=mHCV3jM/Ps4PFbYv/uA/tqUihj23YK9oOL9tjMViu9yAeZg2vGsMxPXS/tCheqisDg NzErkVAiIlrMk7yHQ/R1yjL8jFjq27BZhD8dOZjIGsdY5SAUqnPySGv5yYCVA/XLhndQ gz7hkxixZpSkFipEr7TT03UyLuDlw4tTwzUEc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Wsucpu133i1dr8mkrqU1grT5iCxkci1tsfBMTzckHnA=; b=aH1dSVrAJgX+msP8TmjnKx7jvKdYNOBR7UCh4Cae7yYCnA8I7279UpwgNFBMgfj4VC Vk0640WXwWB1SPW+guwLFYHZRjxsphukAvnwAnq/zVwQzZ8cgDQfVAFjUdZaQBUzODi0 SWwZ+b0k82Tf0gQdHpLGSS8GxA+B8gOFpHK2HImInuKh/DgGtXAZ/VLXuDJb0bh0cw99 FaAx7cs4Ia+CURJSwvbfdjQTdaXq6L1ZDG+Cbb7HKH9ZVt546t62XIZRDDDnaENyeqCs JEqNnB2aKNT2RpPKAJfb0MvD4tYOF8JiSW9R7wMeUZgOEFF95UPJwrM7dJA3VJjRDzee 0KFw== X-Gm-Message-State: ALoCoQlG1M9UlJyzSzjOw/6rnNYdRtRaUsZUjYu6SuXVvJb/RxZxpc6yKegUbscMRvuc9Yfe1y/0 MIME-Version: 1.0 X-Received: by 10.112.156.166 with SMTP id wf6mr21942099lbb.13.1379277241649; Sun, 15 Sep 2013 13:34:01 -0700 (PDT) Received: by 10.112.236.40 with HTTP; Sun, 15 Sep 2013 13:34:01 -0700 (PDT) X-Originating-IP: [173.8.130.202] Date: Sun, 15 Sep 2013 13:34:01 -0700 Message-ID: From: Robert Pickup To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a11c18e7a09189704e672021a X-Mailman-Approved-At: Mon, 16 Sep 2013 12:33:53 -0700 Subject: [dmarc-ietf] Thoughts on the DMARC Specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 20:36:00 -0000 --001a11c18e7a09189704e672021a Content-Type: text/plain; charset=ISO-8859-1 *Thoughts on the DMARC specification* I am the founder of Truedomain Inc, an authentication intermediary and a founding member of the DMARC initiative. I have been active with email authentication for over a decade and have created and brought to market products and services that address email spoofing, spam and phishing. The DMARC specification was created with cooperation of the largest senders, receivers and intermediaries. It demonstrates the value of the specification by having these organizations working together to find an easy to implement solution the adequately addresses the needs of each player within the email ecosystem. * Do you feel that the overall specification is useful for the intended purpose? * Absolutely. First, the specification provides a mechanism with which to understand the many email streams being sent using an organization's domain. Second, it provides a mechanism to publish a policy so receivers can action email accordingly based on the authentication results. This has the benefit of being able to protect senders, receivers and the intended recipients from receiving spam and in particular, phishing attempts. *Does support already exist for the specification? For example, do you know of existing deployments that rely on the current specification?* DMARC is fully supported by the largest email receivers including Yahoo, AOL, Gmail and Outlook. Many financial institutions utilize DMARC to gain a better understanding of where their email is being sent from to ensure all of their email is being authenticated. Without DMARC this would be almost impossible to achieve. *Are there critical aspects of the specification that need to be modified prior to it being a published standard?* No. The current specification addresses the key issues of being able to identify and understand multiple email streams and protect against spoofed emails being delivered. *Are there aspects of the specification that can be modified (e.g. by additional extensions) to improve it after it has been published as a standard?* Potentially, but as outlined above, the specification meets the requirements it was intended to address. *Does the specification as written provide a clear, precise, and accurate description of the steps necessary to implement the specification?* Yes. There is already significant adoption of the specification which demonstrates its ease of implementation for both senders and receivers. *Would you feel comfortable supporting it being published as a standard, or are do you have any additional reservations you would like to see addressed before you would support it?* Absolutely. I do not have any reservations, as the specification is doing the job it was intended to do. Robert Pickup Founder, Truedomain Inc 415 490 8146 --001a11c18e7a09189704e672021a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thoughts on the DMARC specification

=
I am the founder of Truedomain Inc, an authentication intermediary and a fo= unding member of the DMARC initiative. I have been active with email authen= tication for over a decade and have created and brought to market products = and services that address email spoofing, spam and phishing.=A0
=
The DMARC specification was created with cooperation of the large= st senders, receivers and intermediaries. It demonstrates the value of the = specification by having these organizations working together to find an eas= y to implement solution the adequately addresses the needs of each player w= ithin the email ecosystem.=A0

Do you feel that the overall specification is useful fo= r the intended purpose?

Absolutely. =A0First, the specification provides a mechanism with which to= understand the many email streams being sent using an organization's d= omain. Second, it provides a mechanism to publish a policy so receivers can= action email accordingly based on the authentication results. This has the= benefit of being able to protect senders, receivers and the intended recip= ients from receiving spam and in particular, phishing attempts.

<= b style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">Doe= s support already exist for the specification? =A0For example, do you know = of existing deployments that rely on the current specification?

DMARC is fully supported by the largest email receivers including= Yahoo, AOL, Gmail and Outlook. Many financial institutions utilize DMARC t= o gain a better understanding of where their email is being sent from to en= sure all of their email is being authenticated. Without DMARC this would be= almost impossible to achieve.

Are there critical aspects of the specification that need to be modi= fied prior to it being a published standard?

No. The current specification addresses the key issues of being able to ide= ntify and understand multiple email streams and protect against spoofed ema= ils being delivered. =A0

Are there aspects of the specification that can be modified (e.g. by= additional extensions) to improve it after it has been published as a stan= dard?

Potentially, but as outlined above, the specification meets the r= equirements it was intended to address.

Does the specification as written provide a clear, precise, and accu= rate description of the steps necessary to implement the specification?=

Yes. There is already significant adoption of the specification w= hich demonstrates its ease of implementation for both senders and receivers= .
=
Would you feel comfortable supporting it being published as a standa= rd, or are do you have any additional reservations you would like to see ad= dressed before you would support it?
=
Absolutely. I do not have any reservations, as the specification = is doing the job it was intended to do. =A0
=
Robert Pickup
Founder, Truedomain Inc
415 490 8146

--001a11c18e7a09189704e672021a-- From sklist@kitterman.com Mon Sep 16 16:45:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9626B21F9D7D for ; Mon, 16 Sep 2013 16:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL3YIv-c+lGw for ; Mon, 16 Sep 2013 16:45:47 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1521F9D42 for ; Mon, 16 Sep 2013 16:45:47 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6FFF520E40EF; Mon, 16 Sep 2013 19:45:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379375145; bh=KpNvGeUA2pc4HXKQ8XvMSs9KAeihQ08lbWBDCjGmjIE=; h=From:To:Subject:Date:From; b=HLzo8bu8sOPVacfNtN0DwLy/nomUx40sfyR29AeiC6m6NMzEDHsktOr0QqonJ6dGe 476YPu9XANaV7VX46pHwl4EPhYHGsU9k9nlTfeEgiLpBEzW8ZVYX/ATBq2wWs3lGH0 GejgpwhQf9KvVlWvo/C/2nhtAw8W3thukputyVMc= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 546B920E40C4; Mon, 16 Sep 2013 19:45:44 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Mon, 16 Sep 2013 19:45:44 -0400 Message-ID: <1510357.FYKYMNnRCL@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 23:45:52 -0000 The recent discussion about moving ADSP to historical brought up the issue of people being inadvertently unsubscribed from mailing lists due to rejecting mail that failed ADSP tests. AIUI, the following would happen: - A user at a domain that signs DKIM and has an ADSP "discardable" policy published sends a mail to a mailing list. - Like most mailing lists, the mail gets munged and the signature is broken. - At the border MTA of the domain of a subscriber that checks ADSP, it is determined that the message fails ADSP and bounces/rejects it. - Rejects/bounces from this user accumulate in the list manager and eventually they get unsubscribed for excessive bounces. There are arguably several things done wrong here: - Sending user: why are you sending mail to a ML with an ADSP protected domain. - Receiving border MTA: why are you bouncing/rejecting and not discarding? So in theory, this should be fine, but it's not. This (assuming I got it right) is one of the arguments for moving ADSP to Historic (since it's not only lightly used, it's known to cause damage when it does. I got to thinking about this and asked myself how DMARC might be better in than ADSP in this situation, and as far as I can tell, it's not. Most mailing lists use their own Mail From, so even if SPF passes on the mailing list message, it won't have identity alignment. Did I miss something? Scott K From franck@peachymango.org Mon Sep 16 17:05:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E442211E8156 for ; Mon, 16 Sep 2013 17:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmphVEjpMo-h for ; Mon, 16 Sep 2013 17:05:00 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3C33A11E80D5 for ; Mon, 16 Sep 2013 17:05:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id E55323901D5; Mon, 16 Sep 2013 19:04:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU7cAllw-qM9; Mon, 16 Sep 2013 19:04:59 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id BF4743901D6; Mon, 16 Sep 2013 19:04:59 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B1BCD3901D5; Mon, 16 Sep 2013 19:04:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vD8BheXkrjNU; Mon, 16 Sep 2013 19:04:59 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 90D513901D2; Mon, 16 Sep 2013 19:04:59 -0500 (CDT) Date: Mon, 16 Sep 2013 19:04:57 -0500 (CDT) From: Franck Martin To: Scott Kitterman Message-ID: <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1510357.FYKYMNnRCL@scott-latitude-e6320> 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.4_GA_5737 (ZimbraWebClient - FF23 (Mac)/8.0.4_GA_5737) Thread-Topic: ADSP Related Mailing List Unsubscriptions Considerations For DMARC Thread-Index: Pqg7hrJ9rbDdszGV7XF8wTme73VCZA== Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 00:05:16 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Monday, September 16, 2013 4:45:44 PM > Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC > > The recent discussion about moving ADSP to historical brought up the issue of > people being inadvertently unsubscribed from mailing lists due to rejecting > mail that failed ADSP tests. > > AIUI, the following would happen: > > - A user at a domain that signs DKIM and has an ADSP "discardable" policy > published sends a mail to a mailing list. > > - Like most mailing lists, the mail gets munged and the signature is broken. > > - At the border MTA of the domain of a subscriber that checks ADSP, it is > determined that the message fails ADSP and bounces/rejects it. > > - Rejects/bounces from this user accumulate in the list manager and > eventually they get unsubscribed for excessive bounces. > > There are arguably several things done wrong here: > > - Sending user: why are you sending mail to a ML with an ADSP protected > domain. Because you can... You can't control all your users and it is hard to know when an email address is the one of a mailing list... As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too... > > - Receiving border MTA: why are you bouncing/rejecting and not discarding? Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question) > > So in theory, this should be fine, but it's not. This (assuming I got it > right) is one of the arguments for moving ADSP to Historic (since it's not > only lightly used, it's known to cause damage when it does. > > I got to thinking about this and asked myself how DMARC might be better in > than ADSP in this situation, and as far as I can tell, it's not. Most > mailing > lists use their own Mail From, so even if SPF passes on the mailing list > message, it won't have identity alignment. > > Did I miss something? Yes, ;) Why the mailing list software would consider such a bounce as a hard bounce, while it is clearly not and identified as such with extended smtp error codes. For instance, EZMLM handles this better than Mailman by sending probes before unsubscribing members. As a receiver, how do I know I'm dealing with a mailing list? Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems. I'm not trying here to provide answers but just describe the problem space. From roland@rolandturner.com Mon Sep 16 19:50:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA22611E831C for ; Mon, 16 Sep 2013 19:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDmW7rtWRDpV for ; Mon, 16 Sep 2013 19:50:38 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3511E8310 for ; Mon, 16 Sep 2013 19:50:36 -0700 (PDT) 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=3RKl6t9pRfAWqzSzjZiLAg3XGoUW5MwEOgRqDRdtIqQ=; b=pp/EGx8roA3mpmfWOy3hgSvmPveq+RvY8NTTyNtJ3oatn6OVDTUV9ojRfzwycbc0E4fmsWa6ubRBfZBger0YeMIgs1gaLBMm4xYhmxsGIC6dY5NymaqVPk8Mv5nCQ1vdw8dwL792XEhJOhEX6oBlpnt62ALOs79cXIIbQrSUKTs=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=58026 helo=[10.100.1.108]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VLlN3-0002TF-Ha for dmarc@ietf.org; Tue, 17 Sep 2013 02:50:35 +0000 Message-ID: <5237C378.6030807@rolandturner.com> Date: Tue, 17 Sep 2013 10:50:32 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> In-Reply-To: <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> Content-Type: multipart/alternative; boundary="------------000804070606010109040208" Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 02:52:33 -0000 This is a multi-part message in MIME format. --------------000804070606010109040208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/17/2013 08:04 AM, Franck Martin wrote: > ----- Original Message ----- >> From: "Scott Kitterman" >> To: dmarc@ietf.org >> Sent: Monday, September 16, 2013 4:45:44 PM >> Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC >> >> The recent discussion about moving ADSP to historical brought up the issue of >> people being inadvertently unsubscribed from mailing lists due to rejecting >> mail that failed ADSP tests. Time to rush in where angels fear to tread :-) >> AIUI, the following would happen: >> >> - A user at a domain that signs DKIM and has an ADSP "discardable" policy >> published sends a mail to a mailing list. >> >> - Like most mailing lists, the mail gets munged and the signature is broken. >> >> - At the border MTA of the domain of a subscriber that checks ADSP, it is >> determined that the message fails ADSP and bounces/rejects it. >> >> - Rejects/bounces from this user accumulate in the list manager and >> eventually they get unsubscribed for excessive bounces. Yes, and much the same scenario can arise for DMARC. >> There are arguably several things done wrong here: >> >> - Sending user: why are you sending mail to a ML with an ADSP protected >> domain. > Because you can... You can't control all your users and it is hard to know when an email address is the one of a mailing list... > As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too... +1 This is a domain-owner's choice. They take their chances with the consequences of course. What we're not able to do is provide a child-safe environment in which there are no trade-offs and where actions have no consequences. > >> - Receiving border MTA: why are you bouncing/rejecting and not discarding? This is not "wrong", as the spec acknowledges (draft-kucherawy-dmarc-base-01 15.4). There are strong arguments in favour of both SMTP refusal (5xx response) and silent discard (2xx response, then delete the message); different receivers will make different choices. This dilemma is part of why mailing lists complicate the "let's authenticate everything" desire that many people share. Bouncing (2xx response, followed by generating and sending a new DSN to the RFC5321.MailFrom) arguably is wrong - or at least unwise - because it contributes to backscatter risk however, again, this is a receiver's choice and some receivers may still do this. > Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question) I don't think that was Scott's question; p=reject is a proposal by the domain owner to the receiver refuse/discard/bounce at receiver's discretion messages which fail both authentication methods. Scott appeared to me to be positioning anything other than silent discard as being "wrong" for p=reject. The DMARC spec makes clear that this is not so. >> So in theory, this should be fine, but it's not. This (assuming I got it >> right) is one of the arguments for moving ADSP to Historic (since it's not >> only lightly used, it's known to cause damage when it does. Barry or Dave may correct me on this, but the argument for moving ADSP to historic is simply that its use is negligible (and perhaps that having it retain a standards status may lead unwitting implementers astray) and - in light of DMARC's adoption - unlikely ever to grow. There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various protective and softening mechanisms: rua/ruf, p=quarantine, pct), but this is more the driver for the adoption of DMARC than the argument for moving ADSP to historic. >> I got to thinking about this and asked myself how DMARC might be better in >> than ADSP in this situation, and as far as I can tell, it's not. In the sense that DMARC provides rua/ruf to improve a domain owner's situational awareness and decision making, DMARC actually is [marginally] better than ADSP in this situation, however this is the wrong question. Interoperating with [existing] mailing lists is not part of the goals of either protocol, consequently the failure to do so is not a large concern. It would be nice if it were straight-forward (or even possible) for this level of interoperability to exist, but no-one can currently see a way for this to work. This is largely because all technically viable approaches require all mailing list operators to implement them ahead of evidence that they're appropriate. Like everybody else, their budget for speculatively expending resources in the hope that they might fix other people's problems is rather small. The practical upshot is that any receiver implementing DMARC filtering requires an accurate database of mailing list servers which host lists to which the receiver's users are subscribed. This is untidy but workable and, again, is not a large concern because it doesn't impede DMARC's objective. >> Most >> mailing >> lists use their own Mail From, so even if SPF passes on the mailing list >> message, it won't have identity alignment. >> >> Did I miss something? > Yes, ;) > > Why the mailing list software would consider such a bounce as a hard bounce, while it is clearly not and identified as such with extended smtp error codes. For instance, EZMLM handles this better than Mailman by sending probes before unsubscribing members. That's clever; I'd wondered how it was avoiding the problem. > As a receiver, how do I know I'm dealing with a mailing list? As part of your ongoing monitoring and assessing of mailstreams... > Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems. "Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a list must avoid doing _*all*_ of those things. I'd suggest that there is a way forward and not too much need to worry about it: * In the short term, receivers are likely to need to maintain a database of list servers from which authentication failures can be ignored. It would be helpful for such receivers to report this to domain owners as reason={forwarded|trusted_forwarder|mailing_list}. * As receiver adoption proceeds, it may be the case that mailing-list mapping is of sufficiently low importance to enough receivers that list operators start to see real (rather than hypothetical) benefit in addressing this, in which case any of the following will work, at the list operator's discretion: o Leave the message sufficiently unaltered to still pass DKIM o Replace the RFC5322.From with something that points to the list operator o Reject submissions from domains with p=reject (or reject only those where the list's changes break the DKIM signature on the message in question; noting that the signer determines what is signed and therefore a given message's DKIM signature may break for a given list, where others' wouldn't) As with domain-owner use of p=reject on domains that aren't heavily spoofed, or even the potential use of DMARC filtering by a receiver without a mailing-list/forwarder database, the use or not of the practices above by list operators should be positioned as "here's a way to make this work if you wish to" not "you are irresponsible if you don't do this". - Roland --------------000804070606010109040208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 09/17/2013 08:04 AM, Franck Martin wrote:

----- Original Message -----

From: "Scott Kitterman" <sklist@kitterman.com>
To: dmarc@ietf.org
Sent: Monday, September 16, 2013 4:45:44 PM
Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC

The recent discussion about moving ADSP to historical brought up the issue of
people being inadvertently unsubscribed from mailing lists due to rejecting
mail that failed ADSP tests.

Time to rush in where angels fear to tread :-)

AIUI, the following would happen:

 - A user at a domain that signs DKIM and has an ADSP "discardable" policy
published sends a mail to a mailing list.

 - Like most mailing lists, the mail gets munged and the signature is broken.

 - At the border MTA of the domain of a subscriber that checks ADSP, it is
determined that the message fails ADSP and bounces/rejects it.

 - Rejects/bounces from this user accumulate in the list manager and
eventually they get unsubscribed for excessive bounces.

Yes, and much the same scenario can arise for DMARC.

There are arguably several things done wrong here:

 - Sending user: why are you sending mail to a ML with an ADSP protected
domain.

Because you can... You can't control all your users and it is hard to know when an email address is the one of a mailing list...
As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too...

+1

This is a domain-owner's choice. They take their chances with the consequences of course. What we're not able to do is provide a child-safe environment in which there are no trade-offs and where actions have no consequences.


 - Receiving border MTA: why are you bouncing/rejecting and not discarding?

This is not "wrong", as the spec acknowledges (draft-kucherawy-dmarc-base-01 15.4). There are strong arguments in favour of both SMTP refusal (5xx response) and silent discard (2xx response, then delete the message); different receivers will make different choices. This dilemma is part of why mailing lists complicate the "let's authenticate everything" desire that many people share.

Bouncing (2xx response, followed by generating and sending a new DSN to the RFC5321.MailFrom) arguably is wrong - or at least unwise - because it contributes to backscatter risk however, again, this is a receiver's choice and some receivers may still do this.

Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question)

I don't think that was Scott's question; p=reject is a proposal by the domain owner to the receiver refuse/discard/bounce at receiver's discretion messages which fail both authentication methods. Scott appeared to me to be positioning anything other than silent discard as being "wrong" for p=reject. The DMARC spec makes clear that this is not so.


      

        
So in theory, this should be fine, but it's not.  This (assuming I got it
right) is one of the arguments for moving ADSP to Historic (since it's not
only lightly used, it's known to cause damage when it does.

      

    

    

    Barry or Dave may correct me on this, but the argument for moving
    ADSP to historic is simply that its use is negligible (and perhaps
    that having it retain a standards status may lead unwitting
    implementers astray) and - in light of DMARC's adoption - unlikely
    ever to grow. There is more harm in ADSP than in
    DMARC (because DMARC adds various protective and softening
    mechanisms: rua/ruf, p=quarantine, pct), but this is more the driver
    for the adoption of DMARC than the argument for moving ADSP to
    historic.

    

    

      

        
I got to thinking about this and asked myself how DMARC might be better in
than ADSP in this situation, and as far as I can tell, it's not.

      

    

    

    In the sense that DMARC provides rua/ruf to improve a domain owner's
    situational awareness and decision making, DMARC actually is
    [marginally] better than ADSP in this situation, however this is the
    wrong question. Interoperating with [existing] mailing lists is not
    part of the goals of either protocol, consequently the failure to do
    so is not a large concern.

    

    It would be nice if it were straight-forward (or even possible) for
    this level of interoperability to exist, but no-one can currently
    see a way for this to work. This is largely because all technically
    viable approaches require all mailing list operators to implement
    them ahead of evidence that they're appropriate. Like everybody
    else, their budget for speculatively expending resources in the hope
    that they might fix other people's problems is rather small. The
    practical upshot is that any receiver implementing DMARC filtering
    requires an accurate database of mailing list servers which host
    lists to which the receiver's users are subscribed. This is untidy
    but workable and, again, is not a large concern because it doesn't
    impede DMARC's objective.

    

    

      

        
  Most
mailing
lists use their own Mail From, so even if SPF passes on the mailing list
message, it won't have identity alignment.

Did I miss something?


      

      
Yes, ;) 

Why the mailing list software would consider such a bounce as a hard bounce, while it is clearly not and identified as such with extended smtp error codes. For instance, EZMLM handles this better than Mailman by sending probes before unsubscribing members.

    

    

    That's clever; I'd wondered how it was avoiding the problem.

    

    

      
As a receiver, how do I know I'm dealing with a mailing list?

    

    

    As part of your ongoing monitoring and assessing of mailstreams...

    

    

      
Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems.

    

    

    "Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage,
    a list must avoid doing all of those things.

    

    I'd suggest that there is a way forward and not too much need to
    worry about it:

    
    
      
  • In the short term, receivers are likely to need to maintain a
        database of list servers from which authentication failures can
        be ignored. It would be helpful for such receivers to report
        this to domain owners as
        reason={forwarded|trusted_forwarder|mailing_list}.
    • 
      
  • As receiver adoption proceeds, it may be the case that
        mailing-list mapping is of sufficiently low importance to enough
        receivers that list operators start to see real (rather than
        hypothetical) benefit in addressing this, in which case any of
        the following will work, at the list operator's discretion:
    • 
      
      
        
    • Leave the message sufficiently unaltered to still pass DKIM
      • 
        
    • Replace the RFC5322.From with something that points to the
          list operator
      • 
        
    • Reject submissions from domains with p=reject (or reject
          only those where the list's changes break the DKIM signature
          on the message in question; noting that the signer determines
          what is signed and therefore a given message's DKIM signature
          may break for a given list, where others' wouldn't)
      
        
      • 
      
    
    

    

    As with domain-owner use of p=reject on domains that aren't heavily
    spoofed, or even the potential use of DMARC filtering by a receiver
    without a mailing-list/forwarder database, the use or not of the
    practices above by list operators should be positioned as "here's a
    way to make this work if you wish to" not "you are irresponsible if
    you don't do this". 

    

    - Roland

  


--------------000804070606010109040208--

From matt.simerson@gmail.com  Mon Sep 16 18:49:37 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C309611E825D for ; Mon, 16 Sep 2013 18:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99G1fgd+lACI for ; Mon, 16 Sep 2013 18:49:37 -0700 (PDT)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2178021F9CE7 for ; Mon, 16 Sep 2013 18:49:37 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id y10so4845437pdj.39 for ; Mon, 16 Sep 2013 18:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=htzfCOXlhBJtjgwrpb0memPmzdWapsltW3JMtSpj0Fs=; b=ER2SqO6zN3JBUX5Un/xDGPGZlcgnLXPki6vO+aQQhdRqsy+2iZLCGSm3NEsm3yjK2O lMqlrhG0wZFPVHoV60AMfCiOd0mUUFGGs+4g47maNOksNj4DrFzACwa9fjtLgxcy842x yIkN7+K6pOjKc1f99RozwpWL8O6kST5vNsyC0AU2rBlUaBQ3QuUyBUh2n8z8z3NAathH M0KypRXDGwlBt2gDRmcdVHWIc7Goy4laD3ZOn3zMyZmyGZ6FOpftg3xiUuUIO1P7hQk4 k2BnGWwWeiJD2jPUbaCrL1kSKnT497T4c88rIHGtnnGDY9HX2m2k+VBMB+dTkae+Puki zO8A==
X-Received: by 10.66.231.42 with SMTP id td10mr5638425pac.144.1379382576689; Mon, 16 Sep 2013 18:49:36 -0700 (PDT)
Received: from [10.0.1.141] (c-76-121-98-64.hsd1.wa.comcast.net. [76.121.98.64]) by mx.google.com with ESMTPSA id wp8sm34356781pbc.26.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 18:49:35 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Matt Simerson 
In-Reply-To: <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>
Date: Mon, 16 Sep 2013 18:49:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9052E9C1-4955-4C75-8230-545C76823341@gmail.com>
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>  <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>
To: Franck Martin 
X-Mailer: Apple Mail (2.1510)
X-Mailman-Approved-At: Mon, 16 Sep 2013 21:21:38 -0700
Cc: dmarc@ietf.org, Scott Kitterman 
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 01:50:28 -0000

On Sep 16, 2013, at 5:04 PM, Franck Martin  =
wrote:

> ----- Original Message -----
>> From: "Scott Kitterman" 
>> To: dmarc@ietf.org
>> Sent: Monday, September 16, 2013 4:45:44 PM
>> Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	=
Considerations For DMARC
>>=20
>> - Receiving border MTA: why are you bouncing/rejecting and not =
discarding?
>=20
> Because they are told to do so by the policy, but with DMARC they can =
overwrite the result, while it is not possible with ADSP (see what is a =
mailing list question)
>=20
>> So in theory, this should be fine, but it's not.  This (assuming I =
got it
>> right) is one of the arguments for moving ADSP to Historic (since =
it's not
>> only lightly used, it's known to cause damage when it does.
>>=20
>> I got to thinking about this and asked myself how DMARC might be =
better in
>> than ADSP in this situation, and as far as I can tell, it's not.  =
Most
>> mailing
>> lists use their own Mail From, so even if SPF passes on the mailing =
list
>> message, it won't have identity alignment.
>>=20
>> Did I miss something?
>=20
> Yes, ;)=20
>=20
> Why the mailing list software would consider such a bounce as a hard =
bounce, while it is clearly not and identified as such with extended =
smtp error codes. For instance, EZMLM handles this better than Mailman =
by sending probes before unsubscribing members.

+1

> Why MLM have to break DKIM?

They don't. (Rhetorical question, I know.)

> It seems the lists at apache.org do not break DKIM on transit and do =
not suffer these problems.
> I'm not trying here to provide answers but just describe the problem =
space.


Most everyone on this list knows, but I'll state once more for the =
archives:

Passing DKIM signed messages through mailing lists without invalidating =
the DKIM signature typically requires just two config changes to the =
mailing list: disable subject prefixes and cease adding list footers.

List footers typically have list info and sub/unsub instructions =
appended to every message. This is typical on EZMLM lists and less so on =
Mailman lists, which instead send a list reminder email to the =
participants once a month.=20

Subject prefixes rewrite the Subject: line, inserting the list name:

  Subject: [list-name] Why do mailing lists break DKIM?

Matt


From roland@rolandturner.com  Mon Sep 16 21:29:01 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E424711E81AF for ; Mon, 16 Sep 2013 21:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.843
X-Spam-Level: 
X-Spam-Status: No, score=0.843 tagged_above=-999 required=5 tests=[AWL=-1.413,  BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJj0KUr6QZa7 for ; Mon, 16 Sep 2013 21:28:57 -0700 (PDT)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id EBFA111E81A6 for ; Mon, 16 Sep 2013 21:28:56 -0700 (PDT)
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=DDEVAnlPCtmaV0f+TjgrCxpeg+AlvtSoEVFoTEufauk=;  b=PxwRwOJOuP14pfpbU3mujfDmnsdmKzFLWLuMFUWU8VjO6liVp5fiQ5FKDC3/CBXx+UUo1BvGPWkOeHSlXvLp4BwJ7+78N17M5xeO21MewizGJDJPBSBlL5q59ix/0DYHbUHWviAVgjtmJ2LKMLlK3Ky38zErSOGK4Nte12UcZb8=;
Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133
Received: from [116.12.149.133] (port=59057 helo=[10.100.1.108]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VLmu6-00051v-SY for dmarc@ietf.org; Tue, 17 Sep 2013 04:28:55 +0000
Message-ID: <5237DA7D.5090701@rolandturner.com>
Date: Tue, 17 Sep 2013 12:28:45 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: dmarc@ietf.org
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>  <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>
In-Reply-To: <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>
Content-Type: multipart/mixed; boundary="------------010508020401000308030505"
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 04:29:02 -0000

This is a multi-part message in MIME format.
--------------010508020401000308030505
Content-Type: multipart/alternative;
 boundary="------------040003090604010202080300"


--------------040003090604010202080300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09/17/2013 08:04 AM, Franck Martin wrote:

> ----- Original Message -----
>> From: "Scott Kitterman"
>> To:dmarc@ietf.org
>> Sent: Monday, September 16, 2013 4:45:44 PM
>> Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
>>
>> The recent discussion about moving ADSP to historical brought up the issue of
>> people being inadvertently unsubscribed from mailing lists due to rejecting
>> mail that failed ADSP tests.

Time to rush in where angels fear to tread :-)

>> AIUI, the following would happen:
>>
>>   - A user at a domain that signs DKIM and has an ADSP "discardable" policy
>> published sends a mail to a mailing list.
>>
>>   - Like most mailing lists, the mail gets munged and the signature is broken.
>>
>>   - At the border MTA of the domain of a subscriber that checks ADSP, it is
>> determined that the message fails ADSP and bounces/rejects it.
>>
>>   - Rejects/bounces from this user accumulate in the list manager and
>> eventually they get unsubscribed for excessive bounces.

Yes, and much the same scenario can arise for DMARC.

>> There are arguably several things done wrong here:
>>
>>   - Sending user: why are you sending mail to a ML with an ADSP protected
>> domain.
> Because you can... You can't control all your users and it is hard to know when an email address is the one of a mailing list...
> As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too...

+1

This is a domain-owner's choice. They take their chances with the 
consequences of course. What we're not able to do is provide a 
child-safe environment in which there are no trade-offs and where 
actions have no consequences.

>
>>   - Receiving border MTA: why are you bouncing/rejecting and not discarding?

This is not "wrong", as the spec acknowledges 
(draft-kucherawy-dmarc-base-01 
 15.4). There 
are strong arguments in favour of both SMTP refusal (5xx response) and 
silent discard (2xx response, then delete the message); different 
receivers will make different choices. This dilemma is part of why 
mailing lists complicate the "let's authenticate everything" desire that 
many people share.

Bouncing (2xx response, followed by generating and sending a new DSN to 
the RFC5321.MailFrom) arguably is wrong - or at least unwise - because 
it contributes to backscatter risk however, again, this is a receiver's 
choice and some receivers may still do this.

> Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question)

I don't think that was Scott's question; p=reject is a proposal by the 
domain owner to the receiver refuse/discard/bounce at receiver's 
discretion messages which fail both authentication methods. Scott 
appeared to me to be positioning anything other than silent discard as 
being "wrong" for p=reject. The DMARC spec makes clear that this is not so.

>> So in theory, this should be fine, but it's not.  This (assuming I got it
>> right) is one of the arguments for moving ADSP to Historic (since it's not
>> only lightly used, it's known to cause damage when it does.

Barry or Dave may correct me on this, but the argument for moving ADSP 
to historic is simply that its use is negligible (and perhaps that 
having it retain a standards status may lead unwitting implementers 
astray) and - in light of DMARC's adoption - unlikely ever to grow. 
There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various 
protective and softening mechanisms: rua/ruf, p=quarantine, pct), but 
this is more the driver for the adoption of DMARC than the argument for 
moving ADSP to historic.

>> I got to thinking about this and asked myself how DMARC might be better in
>> than ADSP in this situation, and as far as I can tell, it's not.

In the sense that DMARC provides rua/ruf to improve a domain owner's 
situational awareness and decision making, DMARC actually is 
[marginally] better than ADSP in this situation, however this is the 
wrong question. Interoperating with [existing] mailing lists is not part 
of the goals of either protocol, consequently the failure to do so is 
not a large concern.

It would be nice if it were straight-forward (or even possible) for this 
level of interoperability to exist, but no-one can currently see a way 
for this to work. This is largely because all technically viable 
approaches require all mailing list operators to implement them ahead of 
evidence that they're appropriate. Like everybody else, their budget for 
speculatively expending resources in the hope that they might fix other 
people's problems is rather small. The practical upshot is that any 
receiver implementing DMARC filtering requires an accurate database of 
mailing list servers which host lists to which the receiver's users are 
subscribed. This is untidy but workable and, again, is not a large 
concern because it doesn't impede DMARC's objective.

>>    Most
>> mailing
>> lists use their own Mail From, so even if SPF passes on the mailing list
>> message, it won't have identity alignment.
>>
>> Did I miss something?
> Yes, ;)
>
> Why the mailing list software would consider such a bounce as a hard bounce, while it is clearly not and identified as such with extended smtp error codes. For instance, EZMLM handles this better than Mailman by sending probes before unsubscribing members.

That's clever; I'd wondered how it was avoiding the problem.

> As a receiver, how do I know I'm dealing with a mailing list?

As part of your ongoing monitoring and assessing of mailstreams...

> Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems.

"Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a 
list must avoid doing _*all*_ of those things.

I'd suggest that there is a way forward and not too much need to worry 
about it:

  * In the short term, receivers are likely to need to maintain a
    database of list servers from which authentication failures can be
    ignored. It would be helpful for such receivers to report this to
    domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
  * As receiver adoption proceeds, it may be the case that mailing-list
    mapping is of sufficiently low importance to enough receivers that
    list operators start to see real (rather than hypothetical) benefit
    in addressing this, in which case any of the following will work, at
    the list operator's discretion:
      o Leave the message sufficiently unaltered to still pass DKIM
      o Replace the RFC5322.From with something that points to the list
        operator
      o Reject submissions from domains with p=reject (or reject only
        those where the list's changes break the DKIM signature on the
        message in question; noting that the signer determines what is
        signed and therefore a given message's DKIM signature may break
        for a given list, where others' wouldn't)


As with domain-owner use of p=reject on domains that aren't heavily 
spoofed, or even the potential use of DMARC filtering by a receiver 
without a mailing-list/forwarder database, the use or not of the 
practices above by list operators should be positioned as "here's a way 
to make this work if you wish to" not "you are irresponsible if you 
don't do this".

- Roland

--------------040003090604010202080300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/17/2013 08:04 AM, Franck Martin
      wrote:

      

    

    

      
----- Original Message -----


      

        
From: "Scott Kitterman" <sklist@kitterman.com>
To: dmarc@ietf.org
Sent: Monday, September 16, 2013 4:45:44 PM
Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC

The recent discussion about moving ADSP to historical brought up the issue of
people being inadvertently unsubscribed from mailing lists due to rejecting
mail that failed ADSP tests.

      

    

    

    Time to rush in where angels fear to tread :-)

    

    

      

        
AIUI, the following would happen:

 - A user at a domain that signs DKIM and has an ADSP "discardable" policy
published sends a mail to a mailing list.

 - Like most mailing lists, the mail gets munged and the signature is broken.

 - At the border MTA of the domain of a subscriber that checks ADSP, it is
determined that the message fails ADSP and bounces/rejects it.

 - Rejects/bounces from this user accumulate in the list manager and
eventually they get unsubscribed for excessive bounces.

      

    

    

    Yes, and much the same scenario can arise for DMARC.

    

    

      

        
There are arguably several things done wrong here:

 - Sending user: why are you sending mail to a ML with an ADSP protected
domain.


      

      
Because you can... You can't control all your users and it is hard to know when an email address is the one of a mailing list...
As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too...

    

    

    +1

    

    This is a domain-owner's choice. They take their chances with the
    consequences of course. What we're not able to do is provide a
    child-safe environment in which there are no trade-offs and where
    actions have no consequences.

    

    


      

        
 - Receiving border MTA: why are you bouncing/rejecting and not discarding?


      

    

    

    This is not "wrong", as the spec acknowledges (draft-kucherawy-dmarc-base-01
    15.4). There are strong arguments in favour of both SMTP refusal
    (5xx response) and silent discard (2xx response, then delete the
    message); different receivers will make different choices. This
    dilemma is part of why mailing lists complicate the "let's
    authenticate everything" desire that many people share.

    

    Bouncing (2xx response, followed by generating and sending a new DSN
    to the RFC5321.MailFrom) arguably is wrong - or at least unwise -
    because it contributes to backscatter risk however, again, this is a
    receiver's choice and some receivers may still do this.

    

    

      
Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question)

    

    

    I don't think that was Scott's question; p=reject is a proposal by
    the domain owner to the receiver refuse/discard/bounce at receiver's
    discretion messages which fail both authentication methods. Scott
    appeared to me to be positioning anything other than silent discard
    as being "wrong" for p=reject. The DMARC spec makes clear that this
    is not so.

    

    

      

        
So in theory, this should be fine, but it's not.  This (assuming I got it
right) is one of the arguments for moving ADSP to Historic (since it's not
only lightly used, it's known to cause damage when it does.

      

    

    

    Barry or Dave may correct me on this, but the argument for moving
    ADSP to historic is simply that its use is negligible (and perhaps
    that having it retain a standards status may lead unwitting
    implementers astray) and - in light of DMARC's adoption - unlikely
    ever to grow. There is more harm in ADSP than in
    DMARC (because DMARC adds various protective and softening
    mechanisms: rua/ruf, p=quarantine, pct), but this is more the driver
    for the adoption of DMARC than the argument for moving ADSP to
    historic.

    

    

      

        
I got to thinking about this and asked myself how DMARC might be better in
than ADSP in this situation, and as far as I can tell, it's not.

      

    

    

    In the sense that DMARC provides rua/ruf to improve a domain owner's
    situational awareness and decision making, DMARC actually is
    [marginally] better than ADSP in this situation, however this is the
    wrong question. Interoperating with [existing] mailing lists is not
    part of the goals of either protocol, consequently the failure to do
    so is not a large concern.

    

    It would be nice if it were straight-forward (or even possible) for
    this level of interoperability to exist, but no-one can currently
    see a way for this to work. This is largely because all technically
    viable approaches require all mailing list operators to implement
    them ahead of evidence that they're appropriate. Like everybody
    else, their budget for speculatively expending resources in the hope
    that they might fix other people's problems is rather small. The
    practical upshot is that any receiver implementing DMARC filtering
    requires an accurate database of mailing list servers which host
    lists to which the receiver's users are subscribed. This is untidy
    but workable and, again, is not a large concern because it doesn't
    impede DMARC's objective.

    

    

      

        
  Most
mailing
lists use their own Mail From, so even if SPF passes on the mailing list
message, it won't have identity alignment.

Did I miss something?


      

      
Yes, ;) 

Why the mailing list software would consider such a bounce as a hard bounce, while it is clearly not and identified as such with extended smtp error codes. For instance, EZMLM handles this better than Mailman by sending probes before unsubscribing members.

    

    

    That's clever; I'd wondered how it was avoiding the problem.

    

    

      
As a receiver, how do I know I'm dealing with a mailing list?

    

    

    As part of your ongoing monitoring and assessing of mailstreams...

    

    

      
Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems.

    

    

    "Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage,
    a list must avoid doing all of those things.

    

    I'd suggest that there is a way forward and not too much need to
    worry about it:

    
    
      
  • In the short term, receivers are likely to need to maintain a
        database of list servers from which authentication failures can
        be ignored. It would be helpful for such receivers to report
        this to domain owners as
        reason={forwarded|trusted_forwarder|mailing_list}.
    • 
      
  • As receiver adoption proceeds, it may be the case that
        mailing-list mapping is of sufficiently low importance to enough
        receivers that list operators start to see real (rather than
        hypothetical) benefit in addressing this, in which case any of
        the following will work, at the list operator's discretion:
    • 
      
      
        
    • Leave the message sufficiently unaltered to still pass DKIM
      • 
        
    • Replace the RFC5322.From with something that points to the
          list operator
      • 
        
    • Reject submissions from domains with p=reject (or reject
          only those where the list's changes break the DKIM signature
          on the message in question; noting that the signer determines
          what is signed and therefore a given message's DKIM signature
          may break for a given list, where others' wouldn't)
      
        
      • 
      
    
    

    

    As with domain-owner use of p=reject on domains that aren't heavily
    spoofed, or even the potential use of DMARC filtering by a receiver
    without a mailing-list/forwarder database, the use or not of the
    practices above by list operators should be positioned as "here's a
    way to make this work if you wish to" not "you are irresponsible if
    you don't do this". 

    

    - Roland

  


--------------040003090604010202080300--

--------------010508020401000308030505
Content-Type: text/plain; charset=UTF-8;
 name="Attached Message Part"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Attached Message Part"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZG1hcmMg
bWFpbGluZyBsaXN0CmRtYXJjQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1hcmMKCg==
--------------010508020401000308030505--

From sklist@kitterman.com  Mon Sep 16 21:33:51 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D744111E81B0 for ; Mon, 16 Sep 2013 21:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.85
X-Spam-Level: 
X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[AWL=-1.591,  BAYES_50=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH1DAdStqXWb for ; Mon, 16 Sep 2013 21:33:47 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5413A11E81A6 for ; Mon, 16 Sep 2013 21:33:46 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 809C720E40EF; Tue, 17 Sep 2013 00:33:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379392424; bh=hX37+Xw5MrAIhoVz6QX8ri97+Qj83/fGyBogkVbG+pM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aICQ1VYRQlb+kJkocF3JAZGKl/PU1nCBxVuPCxDx+7ltw4QIA6dU90hL9cIl5O83X h/naxLiFW44m0OGFJWKZ67ZLlbR7YAL1/CLz3fMLGGSJJldRUAHiLU9tPO1/bap86k Cmc4GFdC5+ATrRK7EicV9l1ramqWON3IFuPicfhw=
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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 5EE9B20E40C4;  Tue, 17 Sep 2013 00:33:44 -0400 (EDT)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Tue, 17 Sep 2013 00:33:40 -0400
Message-ID: <1945650.hcHt8AHrK6@scott-latitude-e6320>
User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; )
In-Reply-To: <5237C378.6030807@rolandturner.com>
References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> <5237C378.6030807@rolandturner.com>
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] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 04:33:52 -0000

On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:
> On 09/17/2013 08:04 AM, Franck Martin wrote:
> > ----- Original Message -----
> > 
> >> From: "Scott Kitterman" 
> >> To: dmarc@ietf.org
> >> Sent: Monday, September 16, 2013 4:45:44 PM
> >> Subject: [dmarc-ietf] ADSP Related Mailing List
> >> Unsubscriptions	Considerations For DMARC
> >> 
> >> The recent discussion about moving ADSP to historical brought up the
> >> issue of people being inadvertently unsubscribed from mailing lists due
> >> to rejecting mail that failed ADSP tests.
> 
> Time to rush in where angels fear to tread :-)
> 
> >> AIUI, the following would happen:
> >>   - A user at a domain that signs DKIM and has an ADSP "discardable"
> >>   policy published sends a mail to a mailing list.
> >> 
> >>   - Like most mailing lists, the mail gets munged and the signature is
> >>   broken.
> >>   
> >>   - At the border MTA of the domain of a subscriber that checks ADSP, it
> >>   is determined that the message fails ADSP and bounces/rejects it.
> >> 
> >>   - Rejects/bounces from this user accumulate in the list manager and
> >>  eventually they get unsubscribed for excessive bounces.
> 
> Yes, and much the same scenario can arise for DMARC.
> 
> >> There are arguably several things done wrong here:
> >>   - Sending user: why are you sending mail to a ML with an ADSP protected
> >> 
> >> domain.
> > 
> > Because you can... You can't control all your users and it is hard to know
> > when an email address is the one of a mailing list... As for the argument
> > you should not put an ADSP on a domain with users, well, any domain from
> > a targeted entity becomes eventually a target that needs protection
> > too...
> +1

Sure.  I only mention that because some people's answer is that 
adsp=discardable or dmarc p=reject is only for domains without actual users 
(.e.g transactional mail).

> This is a domain-owner's choice. They take their chances with the
> consequences of course. What we're not able to do is provide a
> child-safe environment in which there are no trade-offs and where
> actions have no consequences.

Email authentication is only for domains that don't need mailing lists?  
Personally, I've got no problem with an SPF -all record.  I've had one since 
2004.  OTOH, p=reject would be very problematic.  I don't have a lot of 
personal correspondence in my local domains with people using services that 
are providing bulk feedback reports.  Something more than 99% of the traffic I 
see in my reports in mailing list traffic.

> >>   - Receiving border MTA: why are you bouncing/rejecting and not
> >>   discarding?
> 
> This is not "wrong", as the spec acknowledges
> (draft-kucherawy-dmarc-base-01
>  15.4). There
> are strong arguments in favour of both SMTP refusal (5xx response) and
> silent discard (2xx response, then delete the message); different
> receivers will make different choices. This dilemma is part of why
> mailing lists complicate the "let's authenticate everything" desire that
> many people share.

We're in the middle of the ADSP part of the argument here and it was written 
differently.  Personally, I find silent discards to be abhorrent.  They 
interfere with the reliability and consistency of the mail system, but that's 
perhaps just me.  I certainly won't argue for them.

> Bouncing (2xx response, followed by generating and sending a new DSN to
> the RFC5321.MailFrom) arguably is wrong - or at least unwise - because
> it contributes to backscatter risk however, again, this is a receiver's
> choice and some receivers may still do this.

Too much of this and they'll find their bounces get them blacklisted.

> > Because they are told to do so by the policy, but with DMARC they can
> > overwrite the result, while it is not possible with ADSP (see what is a
> > mailing list question)
> I don't think that was Scott's question; p=reject is a proposal by the
> domain owner to the receiver refuse/discard/bounce at receiver's
> discretion messages which fail both authentication methods. Scott
> appeared to me to be positioning anything other than silent discard as
> being "wrong" for p=reject. The DMARC spec makes clear that this is not so.

No.  Here I'm still talking about ADSP.  It's similar to, but not identical to 
DMARC.

> >> So in theory, this should be fine, but it's not.  This (assuming I got it
> >> right) is one of the arguments for moving ADSP to Historic (since it's
> >> not
> >> only lightly used, it's known to cause damage when it does.
> 
> Barry or Dave may correct me on this, but the argument for moving ADSP
> to historic is simply that its use is negligible (and perhaps that
> having it retain a standards status may lead unwitting implementers
> astray) and - in light of DMARC's adoption - unlikely ever to grow.
> There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various
> protective and softening mechanisms: rua/ruf, p=quarantine, pct), but
> this is more the driver for the adoption of DMARC than the argument for
> moving ADSP to historic.

I think the potential for harm is identical.  If it's concerning for ADSP, it 
should be concerning for DMARC.  DMARC does have a few more knobs to turn, but 
if you don't want mail that fails authentication sent to the receiving user, 
you have to use p=reject and that has the exact same problem with mailing list 
subscriptions that ADSP does.

> >> I got to thinking about this and asked myself how DMARC might be better
> >> in
> >> than ADSP in this situation, and as far as I can tell, it's not.
> 
> In the sense that DMARC provides rua/ruf to improve a domain owner's
> situational awareness and decision making, DMARC actually is
> [marginally] better than ADSP in this situation, however this is the
> wrong question. Interoperating with [existing] mailing lists is not part
> of the goals of either protocol, consequently the failure to do so is
> not a large concern.

Ah, so DMARC is only for domains without real users?

> It would be nice if it were straight-forward (or even possible) for this
> level of interoperability to exist, but no-one can currently see a way
> for this to work. This is largely because all technically viable
> approaches require all mailing list operators to implement them ahead of
> evidence that they're appropriate. Like everybody else, their budget for
> speculatively expending resources in the hope that they might fix other
> people's problems is rather small. The practical upshot is that any
> receiver implementing DMARC filtering requires an accurate database of
> mailing list servers which host lists to which the receiver's users are
> subscribed. This is untidy but workable and, again, is not a large
> concern because it doesn't impede DMARC's objective.

Workable for who?  Probably for large providers that can do it via data 
mining.  I don't even know all the mailing lists I'm subscribed to let alone 
everyone who uses my domains.

> >>    Most mailing
> >> lists use their own Mail From, so even if SPF passes on the mailing list
> >> message, it won't have identity alignment.
> >> 
> >> Did I miss something?
> > 
> > Yes, ;)
> > 
> > Why the mailing list software would consider such a bounce as a hard
> > bounce, while it is clearly not and identified as such with extended smtp
> > error codes. For instance, EZMLM handles this better than Mailman by
> > sending probes before unsubscribing members.
> That's clever; I'd wondered how it was avoiding the problem.
> 
> > As a receiver, how do I know I'm dealing with a mailing list?
> 
> As part of your ongoing monitoring and assessing of mailstreams...
> 
> > Why MLM have to break DKIM? It seems the lists at apache.org do not break
> > DKIM on transit and do not suffer these problems.
> "Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a
> list must avoid doing _*all*_ of those things.
> 
> I'd suggest that there is a way forward and not too much need to worry
> about it:
> 
>   * In the short term, receivers are likely to need to maintain a
>     database of list servers from which authentication failures can be
>     ignored. It would be helpful for such receivers to report this to
>     domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
>   * As receiver adoption proceeds, it may be the case that mailing-list
>     mapping is of sufficiently low importance to enough receivers that
>     list operators start to see real (rather than hypothetical) benefit
>     in addressing this, in which case any of the following will work, at
>     the list operator's discretion:
>       o Leave the message sufficiently unaltered to still pass DKIM
>       o Replace the RFC5322.From with something that points to the list
>         operator
>       o Reject submissions from domains with p=reject (or reject only
>         those where the list's changes break the DKIM signature on the
>         message in question; noting that the signer determines what is
>         signed and therefore a given message's DKIM signature may break
>         for a given list, where others' wouldn't)
> 
> 
> As with domain-owner use of p=reject on domains that aren't heavily
> spoofed, or even the potential use of DMARC filtering by a receiver
> without a mailing-list/forwarder database, the use or not of the
> practices above by list operators should be positioned as "here's a way
> to make this work if you wish to" not "you are irresponsible if you
> don't do this".

DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and I can 
think of two that don't break DKIM signatures (and not even this one).  I 
think the idea that mailing lists are going to do anything more for DKIM than 
add their own signatures is wishful thinking, certainly not supported by my 
experience.

I don't have a good solution either, but I'm also not convinced with what 
looks to me like a lot of handwaving.  We KNOW it was a problem with ADSP and 
while I really like things about DMARC like the feedback mechanisms, I don't 
think it's meaningfully different from ADSP in this regard and it will somehow 
have to be addressed.

Scott K

From R.E.Sonneveld@sonnection.nl  Tue Sep 17 15:25:01 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A549A11E85EB for ; Tue, 17 Sep 2013 15:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level: 
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-1.965, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1lZ9aOnq2Wg for ; Tue, 17 Sep 2013 15:24:57 -0700 (PDT)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id F15B011E82F1 for ; Tue, 17 Sep 2013 15:24:51 -0700 (PDT)
Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3cff5F5Mrwz1L8ff; Wed, 18 Sep 2013 00:24:49 +0200 (CEST)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3cff5F3grrz5Mhcg; Wed, 18 Sep 2013 00:24:49 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id F3872123187; Wed, 18 Sep 2013 00:24:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Vg4up6NsGkvl; Wed, 18 Sep 2013 00:24:43 +0200 (CEST)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 11F0012312A; Wed, 18 Sep 2013 00:24:43 +0200 (CEST)
Message-ID: <5238D6AA.2050005@sonnection.nl>
Date: Wed, 18 Sep 2013 00:24:42 +0200
From: "Rolf E. Sonneveld" 
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Scott Kitterman 
References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> <5237C378.6030807@rolandturner.com> <1945650.hcHt8AHrK6@scott-latitude-e6320>
In-Reply-To: <1945650.hcHt8AHrK6@scott-latitude-e6320>
Content-Type: multipart/alternative; boundary="------------050809000902050403090508"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1379456689; bh=DQa7T+HnbKVaWBR3MGxcXDow6FEP+q8hbUD8s/KCtNI=; h=Message-ID:Date:From:To:Subject:From; b=YCPEjLVSQQP1HW0/wPrY50CksNdZhjAVvFiNvd+GZD1rVbhITU9XiUOGzLLr2pwwf ZYQl47S5ZdBxzBzEI1mhlE9Fr+9vpaU6qOCakBJ5/xAmo1rgLd3+m6kCxzPzR2UiRt HX47maTp5L64Jb/+ma2tauVyKwYwhhTkCrhP1vOk=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3cff5F5Mrwz1L8ff
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 22:25:01 -0000

This is a multi-part message in MIME format.
--------------050809000902050403090508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/17/2013 06:33 AM, Scott Kitterman wrote:

> On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:

[...]

>
>> This is not "wrong", as the spec acknowledges
>> (draft-kucherawy-dmarc-base-01
>>  15.4). There
>> are strong arguments in favour of both SMTP refusal (5xx response) and
>> silent discard (2xx response, then delete the message); different
>> receivers will make different choices. This dilemma is part of why
>> mailing lists complicate the "let's authenticate everything" desire that
>> many people share.
> We're in the middle of the ADSP part of the argument here and it was written
> differently.  Personally, I find silent discards to be abhorrent.  They
> interfere with the reliability and consistency of the mail system, but that's
> perhaps just me.

You're not alone on this one: silently discarding mail cannot be 
explained to the ordinary end-user of the e-mail eco-system. See [1] and 
various opinions in [2]. RFC5321 section 6.2 addresses these concerns as 
follows:

    As discussed inSection 7.8    andSection 7.9    below, dropping mail
    without notification of the sender is permitted in practice.
    However, it is extremely dangerous and violates a long tradition and
    community expectations that mail is either delivered or returned.  If
    silent message-dropping is misused, it could easily undermine
    confidence in the reliability of the Internet's mail systems.  So
    silent dropping of messages should be considered only in those cases
    where there is very high confidence that the messages are seriously
    fraudulent or otherwise inappropriate.


Apart from some corner cases (small organizations) neither sending mail 
eco-system nor receiving mail eco-system is able to adequately and 
reliably determine which messages are handled by a MLM and which are 
not. And even if one finds a way to determine this, it certainly will 
not be scalable to the entire Internet. With that in mind, the question 
is: is option 2 of par 15.4 of the DMARC base spec ('silent discard') 
contradicting the above quoted principle as stated in RFC5321, or not?

>    I certainly won't argue for them.
>
>> Bouncing (2xx response, followed by generating and sending a new DSN to
>> the RFC5321.MailFrom) arguably is wrong - or at least unwise - because
>> it contributes to backscatter risk however, again, this is a receiver's
>> choice and some receivers may still do this.
> Too much of this and they'll find their bounces get them blacklisted.
>
>>> Because they are told to do so by the policy, but with DMARC they can
>>> overwrite the result, while it is not possible with ADSP (see what is a
>>> mailing list question)
>> I don't think that was Scott's question; p=reject is a proposal by the
>> domain owner to the receiver refuse/discard/bounce at receiver's
>> discretion messages which fail both authentication methods. Scott
>> appeared to me to be positioning anything other than silent discard as
>> being "wrong" for p=reject. The DMARC spec makes clear that this is not so.
> No.  Here I'm still talking about ADSP.  It's similar to, but not identical to
> DMARC.
>
>>>> So in theory, this should be fine, but it's not.  This (assuming I got it
>>>> right) is one of the arguments for moving ADSP to Historic (since it's
>>>> not
>>>> only lightly used, it's known to cause damage when it does.
>> Barry or Dave may correct me on this, but the argument for moving ADSP
>> to historic is simply that its use is negligible (and perhaps that
>> having it retain a standards status may lead unwitting implementers
>> astray) and - in light of DMARC's adoption - unlikely ever to grow.
>> There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various
>> protective and softening mechanisms: rua/ruf, p=quarantine, pct), but
>> this is more the driver for the adoption of DMARC than the argument for
>> moving ADSP to historic.
> I think the potential for harm is identical.  If it's concerning for ADSP, it
> should be concerning for DMARC.  DMARC does have a few more knobs to turn, but
> if you don't want mail that fails authentication sent to the receiving user,
> you have to use p=reject and that has the exact same problem with mailing list
> subscriptions that ADSP does.

Correct.



>
>>>> I got to thinking about this and asked myself how DMARC might be better
>>>> in
>>>> than ADSP in this situation, and as far as I can tell, it's not.
>> In the sense that DMARC provides rua/ruf to improve a domain owner's
>> situational awareness and decision making, DMARC actually is
>> [marginally] better than ADSP in this situation, however this is the
>> wrong question. Interoperating with [existing] mailing lists is not part
>> of the goals of either protocol, consequently the failure to do so is
>> not a large concern.

> Ah, so DMARC is only for domains without real users?
>
>> It would be nice if it were straight-forward (or even possible) for this
>> level of interoperability to exist, but no-one can currently see a way
>> for this to work. This is largely because all technically viable
>> approaches require all mailing list operators to implement them ahead of
>> evidence that they're appropriate. Like everybody else, their budget for
>> speculatively expending resources in the hope that they might fix other
>> people's problems is rather small. The practical upshot is that any
>> receiver implementing DMARC filtering requires an accurate database of
>> mailing list servers which host lists to which the receiver's users are
>> subscribed. This is untidy but workable and, again, is not a large
>> concern because it doesn't impede DMARC's objective.
> Workable for who?  Probably for large providers that can do it via data
> mining.  I don't even know all the mailing lists I'm subscribed to let alone
> everyone who uses my domains.

+1.

>
>>>>     Most mailing
>>>> lists use their own Mail From, so even if SPF passes on the mailing list
>>>> message, it won't have identity alignment.
>>>>
>>>> Did I miss something?
>>> Yes, ;)
>>>
>>> Why the mailing list software would consider such a bounce as a hard
>>> bounce, while it is clearly not and identified as such with extended smtp
>>> error codes. For instance, EZMLM handles this better than Mailman by
>>> sending probes before unsubscribing members.
>> That's clever; I'd wondered how it was avoiding the problem.
>>
>>> As a receiver, how do I know I'm dealing with a mailing list?
>> As part of your ongoing monitoring and assessing of mailstreams...
>>
>>> Why MLM have to break DKIM? It seems the lists at apache.org do not break
>>> DKIM on transit and do not suffer these problems.
>> "Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a
>> list must avoid doing _*all*_ of those things.
>>
>> I'd suggest that there is a way forward and not too much need to worry
>> about it:
>>
>>    * In the short term, receivers are likely to need to maintain a
>>      database of list servers from which authentication failures can be
>>      ignored. It would be helpful for such receivers to report this to
>>      domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
>>    * As receiver adoption proceeds, it may be the case that mailing-list
>>      mapping is of sufficiently low importance to enough receivers that
>>      list operators start to see real (rather than hypothetical) benefit
>>      in addressing this, in which case any of the following will work, at
>>      the list operator's discretion:
>>        o Leave the message sufficiently unaltered to still pass DKIM
>>        o Replace the RFC5322.From with something that points to the list
>>          operator
>>        o Reject submissions from domains with p=reject (or reject only
>>          those where the list's changes break the DKIM signature on the
>>          message in question; noting that the signer determines what is
>>          signed and therefore a given message's DKIM signature may break
>>          for a given list, where others' wouldn't)
>>
>>
>> As with domain-owner use of p=reject on domains that aren't heavily
>> spoofed, or even the potential use of DMARC filtering by a receiver
>> without a mailing-list/forwarder database, the use or not of the
>> practices above by list operators should be positioned as "here's a way
>> to make this work if you wish to" not "you are irresponsible if you
>> don't do this".
> DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and I can
> think of two that don't break DKIM signatures (and not even this one).  I
> think the idea that mailing lists are going to do anything more for DKIM than
> add their own signatures is wishful thinking, certainly not supported by my
> experience.
>
> I don't have a good solution either, but I'm also not convinced with what
> looks to me like a lot of handwaving.  We KNOW it was a problem with ADSP and
> while I really like things about DMARC like the feedback mechanisms, I don't
> think it's meaningfully different from ADSP in this regard and it will somehow
> have to be addressed.

As ADSP has been adopted by the IETF as standards track document, the 
question is: are there any new insights/ regarding this problem in 
relation to DMARC? If not, it makes little sense redoing the entire 
MLM/ADSP discussion for MLM/DMARC?

Don't get me wrong: in my opinion new standards have to interoperate 
with the current Internet, so the existence of MLM's and the way most of 
them operate at this moment, can't be ignored. Using special domains for 
'DMARC signed mail' to prevent damage may be a good advise, but 
companies may want to 'protect' their main (and most well-known) 
domains, with which they also send transactional and IPM as well.

Then the next question is: is it worth standardizing DMARC within the 
IETF? Obviously it already is a _de facto_ standard, why should we aim 
at making it a _de jure_ standard as well?

I for myself have not yet found the answer to this question.

/rolf

[1] 
http://www.macworld.com/article/2029570/silent-email-filtering-makes-icloud-an-unreliable-option.html
[2] http://www.webhostingtalk.com/showthread.php?t=1227028


--------------050809000902050403090508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/17/2013 06:33 AM, Scott Kitterman
      wrote:

      

    

    

      
On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:

    

    

    [...]

    

    


      

        
This is not "wrong", as the spec acknowledges
(draft-kucherawy-dmarc-base-01
<http://www.ietf.org/id/draft-kucherawy-dmarc-base-01.txt> 15.4). There
are strong arguments in favour of both SMTP refusal (5xx response) and
silent discard (2xx response, then delete the message); different
receivers will make different choices. This dilemma is part of why
mailing lists complicate the "let's authenticate everything" desire that
many people share.


      

      
We're in the middle of the ADSP part of the argument here and it was written 
differently.  Personally, I find silent discards to be abhorrent.  They 
interfere with the reliability and consistency of the mail system, but that's 
perhaps just me.

    

    

    You're not alone on this one: silently discarding mail cannot be
    explained to the ordinary end-user of the e-mail eco-system. See [1]
    and various opinions in [2]. RFC5321 section 6.2 addresses these
    concerns as follows:

    

    
   As discussed in Section 7.8 and Section 7.9 below, dropping mail
   without notification of the sender is permitted in practice.
   However, it is extremely dangerous and violates a long tradition and
   community expectations that mail is either delivered or returned.  If
   silent message-dropping is misused, it could easily undermine
   confidence in the reliability of the Internet's mail systems.  So
   silent dropping of messages should be considered only in those cases
   where there is very high confidence that the messages are seriously
   fraudulent or otherwise inappropriate.

    

    Apart from some corner cases (small organizations) neither sending
    mail eco-system nor receiving mail eco-system is able to adequately
    and reliably determine which messages are handled by a MLM and which
    are not. And even if one finds a way to determine this, it certainly
    will not be scalable to the entire Internet. With that in mind, the
    question is: is option 2 of par 15.4 of the DMARC base spec ('silent
    discard') contradicting the above quoted principle as stated in
    RFC5321, or not?

      

    

      
  I certainly won't argue for them.



      

        
Bouncing (2xx response, followed by generating and sending a new DSN to
the RFC5321.MailFrom) arguably is wrong - or at least unwise - because
it contributes to backscatter risk however, again, this is a receiver's
choice and some receivers may still do this.


      

      
Too much of this and they'll find their bounces get them blacklisted.



      

        

          
Because they are told to do so by the policy, but with DMARC they can
overwrite the result, while it is not possible with ADSP (see what is a
mailing list question)


        

        
I don't think that was Scott's question; p=reject is a proposal by the
domain owner to the receiver refuse/discard/bounce at receiver's
discretion messages which fail both authentication methods. Scott
appeared to me to be positioning anything other than silent discard as
being "wrong" for p=reject. The DMARC spec makes clear that this is not so.


      

      
No.  Here I'm still talking about ADSP.  It's similar to, but not identical to 
DMARC.



      

        

          

            
So in theory, this should be fine, but it's not.  This (assuming I got it
right) is one of the arguments for moving ADSP to Historic (since it's
not
only lightly used, it's known to cause damage when it does.


          

        

        
Barry or Dave may correct me on this, but the argument for moving ADSP
to historic is simply that its use is negligible (and perhaps that
having it retain a standards status may lead unwitting implementers
astray) and - in light of DMARC's adoption - unlikely ever to grow.
There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various
protective and softening mechanisms: rua/ruf, p=quarantine, pct), but
this is more the driver for the adoption of DMARC than the argument for
moving ADSP to historic.


      

      
I think the potential for harm is identical.  If it's concerning for ADSP, it 
should be concerning for DMARC.  DMARC does have a few more knobs to turn, but 
if you don't want mail that fails authentication sent to the receiving user, 
you have to use p=reject and that has the exact same problem with mailing list 
subscriptions that ADSP does.

    

    

    Correct.

    

    

      

    

      



      

        

          

            
I got to thinking about this and asked myself how DMARC might be better
in
than ADSP in this situation, and as far as I can tell, it's not.


          

        

        
In the sense that DMARC provides rua/ruf to improve a domain owner's
situational awareness and decision making, DMARC actually is
[marginally] better than ADSP in this situation, however this is the
wrong question. Interoperating with [existing] mailing lists is not part
of the goals of either protocol, consequently the failure to do so is
not a large concern.

      

    

    

    

      

        

      

      
Ah, so DMARC is only for domains without real users?



      

        
It would be nice if it were straight-forward (or even possible) for this
level of interoperability to exist, but no-one can currently see a way
for this to work. This is largely because all technically viable
approaches require all mailing list operators to implement them ahead of
evidence that they're appropriate. Like everybody else, their budget for
speculatively expending resources in the hope that they might fix other
people's problems is rather small. The practical upshot is that any
receiver implementing DMARC filtering requires an accurate database of
mailing list servers which host lists to which the receiver's users are
subscribed. This is untidy but workable and, again, is not a large
concern because it doesn't impede DMARC's objective.


      

      
Workable for who?  Probably for large providers that can do it via data 
mining.  I don't even know all the mailing lists I'm subscribed to let alone 
everyone who uses my domains.

    

    

    +1.

    

    

      



      

        

          

            
   Most mailing
lists use their own Mail From, so even if SPF passes on the mailing list
message, it won't have identity alignment.

Did I miss something?


          

          
Yes, ;)

Why the mailing list software would consider such a bounce as a hard
bounce, while it is clearly not and identified as such with extended smtp
error codes. For instance, EZMLM handles this better than Mailman by
sending probes before unsubscribing members.


        

        
That's clever; I'd wondered how it was avoiding the problem.



        

          
As a receiver, how do I know I'm dealing with a mailing list?


        

        
As part of your ongoing monitoring and assessing of mailstreams...



        

          
Why MLM have to break DKIM? It seems the lists at apache.org do not break
DKIM on transit and do not suffer these problems.


        

        
"Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a
list must avoid doing _*all*_ of those things.

I'd suggest that there is a way forward and not too much need to worry
about it:

  * In the short term, receivers are likely to need to maintain a
    database of list servers from which authentication failures can be
    ignored. It would be helpful for such receivers to report this to
    domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
  * As receiver adoption proceeds, it may be the case that mailing-list
    mapping is of sufficiently low importance to enough receivers that
    list operators start to see real (rather than hypothetical) benefit
    in addressing this, in which case any of the following will work, at
    the list operator's discretion:
      o Leave the message sufficiently unaltered to still pass DKIM
      o Replace the RFC5322.From with something that points to the list
        operator
      o Reject submissions from domains with p=reject (or reject only
        those where the list's changes break the DKIM signature on the
        message in question; noting that the signer determines what is
        signed and therefore a given message's DKIM signature may break
        for a given list, where others' wouldn't)


As with domain-owner use of p=reject on domains that aren't heavily
spoofed, or even the potential use of DMARC filtering by a receiver
without a mailing-list/forwarder database, the use or not of the
practices above by list operators should be positioned as "here's a way
to make this work if you wish to" not "you are irresponsible if you
don't do this".


      

      
DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and I can 
think of two that don't break DKIM signatures (and not even this one).  I 
think the idea that mailing lists are going to do anything more for DKIM than 
add their own signatures is wishful thinking, certainly not supported by my 
experience.

I don't have a good solution either, but I'm also not convinced with what 
looks to me like a lot of handwaving.  We KNOW it was a problem with ADSP and 
while I really like things about DMARC like the feedback mechanisms, I don't 
think it's meaningfully different from ADSP in this regard and it will somehow 
have to be addressed.

    

    

    As ADSP has been adopted by the IETF as standards track document,
    the question is: are there any new insights/ regarding this problem
    in relation to DMARC? If not, it makes little sense redoing the
    entire MLM/ADSP discussion for MLM/DMARC?

    

    Don't get me wrong: in my opinion new standards have to interoperate
    with the current Internet, so the existence of MLM's and the way
    most of them operate at this moment, can't be ignored. Using special
    domains for 'DMARC signed mail' to prevent damage may be a good
    advise, but companies may want to 'protect' their main (and most
    well-known) domains, with which they also send transactional and IPM
    as well.

    

    Then the next question is: is it worth standardizing DMARC within
    the IETF? Obviously it already is a _de facto_ standard, why should
    we aim at making it a _de jure_ standard as well?

    

    I for myself have not yet found the answer to this question.

    

    /rolf

    

    [1]
http://www.macworld.com/article/2029570/silent-email-filtering-makes-icloud-an-unreliable-option.html

    [2] http://www.webhostingtalk.com/showthread.php?t=1227028

    

  


--------------050809000902050403090508--

From sklist@kitterman.com  Tue Sep 17 17:02:34 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15E11E8654 for ; Tue, 17 Sep 2013 17:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.255
X-Spam-Level: **
X-Spam-Status: No, score=2.255 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGn0M9jHYHja for ; Tue, 17 Sep 2013 17:02:33 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0411E81F4 for ; Tue, 17 Sep 2013 17:02:33 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 5E363D04088; Tue, 17 Sep 2013 20:02:32 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379462552; bh=ng3UM8kHUqwdPW8+EXRa3uePdx1JChb+pwHrgo6w7TY=; h=In-Reply-To:References:Subject:From:Date:To:From; b=XwoggrlLti4fsXaKsVYJ40NlPLnIacreuXy55eOaynTijQQHyfA+SP9dNdoXR1u5Z di2HF5h5q73ECbRluMDXH/2pBs748uAp9m1n6IDJvuiVc51IXTOoE6bPr32GsZvIh4 4+TlBiHlnBlSvwfGG+frTOfsA0XuWB0Mbt7H1ge0=
Received: from [IPV6:2600:1003:b029:6b90:59ce:2883:1935:4814] (unknown [IPv6:2600:1003:b029:6b90:59ce:2883:1935:4814]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ECF91D04041;  Tue, 17 Sep 2013 20:02:31 -0400 (EDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <5238D6AA.2050005@sonnection.nl>
References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> <5237C378.6030807@rolandturner.com> <1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Tue, 17 Sep 2013 20:02:59 -0400
To: dmarc@ietf.org
Message-ID: <3ed5439c-3241-4808-bcb8-916b10eca07b@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 00:02:34 -0000

"Rolf E. Sonneveld"  wrote:
>On 09/17/2013 06:33 AM, Scott Kitterman wrote:
>
>> On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:
>
>[...]
>
>>
>>> This is not "wrong", as the spec acknowledges
>>> (draft-kucherawy-dmarc-base-01
>>>  15.4).
>There
>>> are strong arguments in favour of both SMTP refusal (5xx response)
>and
>>> silent discard (2xx response, then delete the message); different
>>> receivers will make different choices. This dilemma is part of why
>>> mailing lists complicate the "let's authenticate everything" desire
>that
>>> many people share.
>> We're in the middle of the ADSP part of the argument here and it was
>written
>> differently.  Personally, I find silent discards to be abhorrent. 
>They
>> interfere with the reliability and consistency of the mail system,
>but that's
>> perhaps just me.
>
>You're not alone on this one: silently discarding mail cannot be 
>explained to the ordinary end-user of the e-mail eco-system. See [1]
>and 
>various opinions in [2]. RFC5321 section 6.2 addresses these concerns
>as 
>follows:
>
>As discussed inSection 7.8 
>  andSection 7.9 
>  below, dropping mail
>    without notification of the sender is permitted in practice.
>   However, it is extremely dangerous and violates a long tradition and
>  community expectations that mail is either delivered or returned.  If
>    silent message-dropping is misused, it could easily undermine
>    confidence in the reliability of the Internet's mail systems.  So
>   silent dropping of messages should be considered only in those cases
>    where there is very high confidence that the messages are seriously
>    fraudulent or otherwise inappropriate.
>
>
>Apart from some corner cases (small organizations) neither sending mail
>
>eco-system nor receiving mail eco-system is able to adequately and 
>reliably determine which messages are handled by a MLM and which are 
>not. And even if one finds a way to determine this, it certainly will 
>not be scalable to the entire Internet. With that in mind, the question
>
>is: is option 2 of par 15.4 of the DMARC base spec ('silent discard') 
>contradicting the above quoted principle as stated in RFC5321, or not?
>
>>    I certainly won't argue for them.
>>
>>> Bouncing (2xx response, followed by generating and sending a new DSN
>to
>>> the RFC5321.MailFrom) arguably is wrong - or at least unwise -
>because
>>> it contributes to backscatter risk however, again, this is a
>receiver's
>>> choice and some receivers may still do this.
>> Too much of this and they'll find their bounces get them blacklisted.
>>
>>>> Because they are told to do so by the policy, but with DMARC they
>can
>>>> overwrite the result, while it is not possible with ADSP (see what
>is a
>>>> mailing list question)
>>> I don't think that was Scott's question; p=reject is a proposal by
>the
>>> domain owner to the receiver refuse/discard/bounce at receiver's
>>> discretion messages which fail both authentication methods. Scott
>>> appeared to me to be positioning anything other than silent discard
>as
>>> being "wrong" for p=reject. The DMARC spec makes clear that this is
>not so.
>> No.  Here I'm still talking about ADSP.  It's similar to, but not
>identical to
>> DMARC.
>>
>>>>> So in theory, this should be fine, but it's not.  This (assuming I
>got it
>>>>> right) is one of the arguments for moving ADSP to Historic (since
>it's
>>>>> not
>>>>> only lightly used, it's known to cause damage when it does.
>>> Barry or Dave may correct me on this, but the argument for moving
>ADSP
>>> to historic is simply that its use is negligible (and perhaps that
>>> having it retain a standards status may lead unwitting implementers
>>> astray) and - in light of DMARC's adoption - unlikely ever to grow.
>>> There is _*more*_ harm in ADSP than in DMARC (because DMARC adds
>various
>>> protective and softening mechanisms: rua/ruf, p=quarantine, pct),
>but
>>> this is more the driver for the adoption of DMARC than the argument
>for
>>> moving ADSP to historic.
>> I think the potential for harm is identical.  If it's concerning for
>ADSP, it
>> should be concerning for DMARC.  DMARC does have a few more knobs to
>turn, but
>> if you don't want mail that fails authentication sent to the
>receiving user,
>> you have to use p=reject and that has the exact same problem with
>mailing list
>> subscriptions that ADSP does.
>
>Correct.
>
>
>
>>
>>>>> I got to thinking about this and asked myself how DMARC might be
>better
>>>>> in
>>>>> than ADSP in this situation, and as far as I can tell, it's not.
>>> In the sense that DMARC provides rua/ruf to improve a domain owner's
>>> situational awareness and decision making, DMARC actually is
>>> [marginally] better than ADSP in this situation, however this is the
>>> wrong question. Interoperating with [existing] mailing lists is not
>part
>>> of the goals of either protocol, consequently the failure to do so
>is
>>> not a large concern.
>
>> Ah, so DMARC is only for domains without real users?
>>
>>> It would be nice if it were straight-forward (or even possible) for
>this
>>> level of interoperability to exist, but no-one can currently see a
>way
>>> for this to work. This is largely because all technically viable
>>> approaches require all mailing list operators to implement them
>ahead of
>>> evidence that they're appropriate. Like everybody else, their budget
>for
>>> speculatively expending resources in the hope that they might fix
>other
>>> people's problems is rather small. The practical upshot is that any
>>> receiver implementing DMARC filtering requires an accurate database
>of
>>> mailing list servers which host lists to which the receiver's users
>are
>>> subscribed. This is untidy but workable and, again, is not a large
>>> concern because it doesn't impede DMARC's objective.
>> Workable for who?  Probably for large providers that can do it via
>data
>> mining.  I don't even know all the mailing lists I'm subscribed to
>let alone
>> everyone who uses my domains.
>
>+1.
>
>>
>>>>>     Most mailing
>>>>> lists use their own Mail From, so even if SPF passes on the
>mailing list
>>>>> message, it won't have identity alignment.
>>>>>
>>>>> Did I miss something?
>>>> Yes, ;)
>>>>
>>>> Why the mailing list software would consider such a bounce as a
>hard
>>>> bounce, while it is clearly not and identified as such with
>extended smtp
>>>> error codes. For instance, EZMLM handles this better than Mailman
>by
>>>> sending probes before unsubscribing members.
>>> That's clever; I'd wondered how it was avoiding the problem.
>>>
>>>> As a receiver, how do I know I'm dealing with a mailing list?
>>> As part of your ongoing monitoring and assessing of mailstreams...
>>>
>>>> Why MLM have to break DKIM? It seems the lists at apache.org do not
>break
>>>> DKIM on transit and do not suffer these problems.
>>> "Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage,
>a
>>> list must avoid doing _*all*_ of those things.
>>>
>>> I'd suggest that there is a way forward and not too much need to
>worry
>>> about it:
>>>
>>>    * In the short term, receivers are likely to need to maintain a
>>>      database of list servers from which authentication failures can
>be
>>>      ignored. It would be helpful for such receivers to report this
>to
>>>      domain owners as
>reason={forwarded|trusted_forwarder|mailing_list}.
>>>    * As receiver adoption proceeds, it may be the case that
>mailing-list
>>>      mapping is of sufficiently low importance to enough receivers
>that
>>>      list operators start to see real (rather than hypothetical)
>benefit
>>>      in addressing this, in which case any of the following will
>work, at
>>>      the list operator's discretion:
>>>        o Leave the message sufficiently unaltered to still pass DKIM
>>>        o Replace the RFC5322.From with something that points to the
>list
>>>          operator
>>>        o Reject submissions from domains with p=reject (or reject
>only
>>>          those where the list's changes break the DKIM signature on
>the
>>>          message in question; noting that the signer determines what
>is
>>>          signed and therefore a given message's DKIM signature may
>break
>>>          for a given list, where others' wouldn't)
>>>
>>>
>>> As with domain-owner use of p=reject on domains that aren't heavily
>>> spoofed, or even the potential use of DMARC filtering by a receiver
>>> without a mailing-list/forwarder database, the use or not of the
>>> practices above by list operators should be positioned as "here's a
>way
>>> to make this work if you wish to" not "you are irresponsible if you
>>> don't do this".
>> DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and
>I can
>> think of two that don't break DKIM signatures (and not even this
>one).  I
>> think the idea that mailing lists are going to do anything more for
>DKIM than
>> add their own signatures is wishful thinking, certainly not supported
>by my
>> experience.
>>
>> I don't have a good solution either, but I'm also not convinced with
>what
>> looks to me like a lot of handwaving.  We KNOW it was a problem with
>ADSP and
>> while I really like things about DMARC like the feedback mechanisms,
>I don't
>> think it's meaningfully different from ADSP in this regard and it
>will somehow
>> have to be addressed.
>
>As ADSP has been adopted by the IETF as standards track document, the 
>question is: are there any new insights/ regarding this problem in 
>relation to DMARC? If not, it makes little sense redoing the entire 
>MLM/ADSP discussion for MLM/DMARC?
>
>Don't get me wrong: in my opinion new standards have to interoperate 
>with the current Internet, so the existence of MLM's and the way most
>of 
>them operate at this moment, can't be ignored. Using special domains
>for 
>'DMARC signed mail' to prevent damage may be a good advise, but 
>companies may want to 'protect' their main (and most well-known) 
>domains, with which they also send transactional and IPM as well.
>
>Then the next question is: is it worth standardizing DMARC within the 
>IETF? Obviously it already is a _de facto_ standard, why should we aim 
>at making it a _de jure_ standard as well?
>
>I for myself have not yet found the answer to this question.
>
>/rolf
>
>[1] 
>http://www.macworld.com/article/2029570/silent-email-filtering-makes-icloud-an-unreliable-option.html
>[2] http://www.webhostingtalk.com/showthread.php?t=1227028

I think DMARC is widely enough used that it's worth documenting.  Along with that, I think it is critical to give operators guidance about the risks associated with p=reject for different domain usage patterns. 

Scott K

From matt@tnpi.net  Tue Sep 17 18:27:21 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513B011E81FF for ; Tue, 17 Sep 2013 18:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=0.398,  BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qctFVI3KlTbE for ; Tue, 17 Sep 2013 18:27:17 -0700 (PDT)
Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5311E816E for ; Tue, 17 Sep 2013 18:27:16 -0700 (PDT)
Received: (qmail 49604 invoked by uid 1026); 18 Sep 2013 01:27:15 -0000
Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.141]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Tue, 17 Sep 2013 21:27:15 -0400
Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass
X-Virus-Checked: by ClamAV 0.97.8 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:cc:content-transfer-encoding:message-id:references:to; s=mar2013; bh=PZpv8AA7UOdfBeQjUbmV52Smb9Q1iQqCVOmD5j6WJ9Y=; b=NIcXNYOQLEcjTWTEgTats8SxFq3CRDR4n8oAwaMfViBSLA3Rpu5vO5noa1y9iM3cXpmov8JN9a3sjGuLHySFVGDTKuNv0I1Y0Kysa0Dm0Q8ybkzjWANDDxdov37bbAJDpxG4uj+vsNY1vNCUaUE62Q6aJ7P9BdeYHgoSjGR12iGJeCBkhIK6MNi4j7Ixvcp91JKu6ZqgfVEwuV+BG2V1PEN4V7O/JhdKxiQpdiYJ769PRNhHLbDtaLpDNPxG8jH+cL93CQPF1NJTR3ZcsyiiO6rNexE+KZQi2agiu3ufAPyPIkOL+V/ss9LMRaAmsMb5j+oC/R5+TfXCCenfTwuIBw==
X-HELO: [10.0.1.141]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Matt Simerson 
In-Reply-To: <3ed5439c-3241-4808-bcb8-916b10eca07b@email.android.com>
Date: Tue, 17 Sep 2013 18:27:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E723719-264D-49B2-86C8-5F3392386E90@tnpi.net>
References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> <5237C378.6030807@rolandturner.com> <1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl> <3ed5439c-3241-4808-bcb8-916b10eca07b@email.android.com>
To: Scott Kitterman 
X-Mailer: Apple Mail (2.1510)
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 01:27:21 -0000

>> Then the next question is: is it worth standardizing DMARC within the=20=

>> IETF? Obviously it already is a _de facto_ standard, why should we =
aim=20
>> at making it a _de jure_ standard as well?
>>=20
>> I for myself have not yet found the answer to this question.
>>=20
>> /rolf
>>=20
>> [1]=20
>> =
http://www.macworld.com/article/2029570/silent-email-filtering-makes-iclou=
d-an-unreliable-option.html
>> [2] http://www.webhostingtalk.com/showthread.php?t=3D1227028
>=20
> I think DMARC is widely enough used that it's worth documenting.  =
Along with that, I think it is critical to give operators guidance about =
the risks associated with p=3Dreject for different domain usage =
patterns.=20

+1

Matt=

From roland@rolandturner.com  Sun Sep 22 07:02:33 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ADA21F9F19 for ; Sun, 22 Sep 2013 07:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.442
X-Spam-Level: **
X-Spam-Status: No, score=2.442 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOZyg+yK0nyq for ; Sun, 22 Sep 2013 07:02:28 -0700 (PDT)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0521F93F3 for ; Sun, 22 Sep 2013 07:02:27 -0700 (PDT)
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=pxXGwC+dlFAkoHD8N3JgyARQpSwdOm+Dn7RwpJ3e/NE=;  b=mImwiIE06jW8rfu5wAKnZeZrfm34/Zfr//pxgje4st6TX6NizHYa63dezwtfIIES6da9KGTAmviJY13Wwg+jwTwIM9quA7OUkbETA7sK3xAm+tn1DOEZiYJ+vxzVj/ZIh3V05taQwGREIYWSji3L42cpK1YABQPCgRc141gD0YA=;
Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=116.86.208.48; iprev=pass policy.iprev=116.86.208.48 (cm48.beta208.maxonline.com.sg)
Received: from [116.86.208.48] (port=42838 helo=[10.1.132.105]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VNkEx-00031e-Ja for dmarc@ietf.org; Sun, 22 Sep 2013 14:02:25 +0000
Message-ID: <523EF86F.7070703@rolandturner.com>
Date: Sun, 22 Sep 2013 22:02:23 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dmarc@ietf.org
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>	<2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>	<5237C378.6030807@rolandturner.com> <1945650.hcHt8AHrK6@scott-latitude-e6320>
In-Reply-To: <1945650.hcHt8AHrK6@scott-latitude-e6320>
Content-Type: multipart/alternative; boundary="------------070502040905020807070703"
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 14:02:33 -0000

This is a multi-part message in MIME format.
--------------070502040905020807070703
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09/17/2013 12:33 PM, Scott Kitterman wrote:

> On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:
>> On 09/17/2013 08:04 AM, Franck Martin wrote:
>>> ----- Original Message -----
>>>
>>>> From: "Scott Kitterman" 
>>>> To: dmarc@ietf.org
>>>> Sent: Monday, September 16, 2013 4:45:44 PM
>>>> Subject: [dmarc-ietf] ADSP Related Mailing List
>>>> Unsubscriptions	Considerations For DMARC
>>>>
>>>> There are arguably several things done wrong here:
>>>>    - Sending user: why are you sending mail to a ML with an ADSP protected
>>>>
>>>> domain.
>>> Because you can... You can't control all your users and it is hard to know
>>> when an email address is the one of a mailing list... As for the argument
>>> you should not put an ADSP on a domain with users, well, any domain from
>>> a targeted entity becomes eventually a target that needs protection
>>> too...
>> +1
> Sure.  I only mention that because some people's answer is that
> adsp=discardable or dmarc p=reject is only for domains without actual users
> (.e.g transactional mail).

Understood, but note that talking about what DMARC (or ADSP) "is for" is 
ambiguous and leads to a lot of heat as people vigorously talk past each 
other. It can refer to at least:

  * What problem DMARC was designed to [and does] help solve.
  * What other situations DMARC can be used in.
  * What other situations DMARC can be used in without causing serious
    collateral damage.


Depending upon the context, these three meanings (and perhaps others) 
give rise to multiple distinct positions; overlooking the ambiguity in 
the term creates considerable confusion.

>
>> This is a domain-owner's choice. They take their chances with the
>> consequences of course. What we're not able to do is provide a
>> child-safe environment in which there are no trade-offs and where
>> actions have no consequences.
> Email authentication is only for domains that don't need mailing lists?

I didn't say anything like that.

> Personally, I've got no problem with an SPF -all record.  I've had one since
> 2004.  OTOH, p=reject would be very problematic.  I don't have a lot of
> personal correspondence in my local domains with people using services that
> are providing bulk feedback reports.  Something more than 99% of the traffic I
> see in my reports in mailing list traffic.

Apologies, I don't follow how this bears on the discussion.

>
>>> Because they are told to do so by the policy, but with DMARC they can
>>> overwrite the result, while it is not possible with ADSP (see what is a
>>> mailing list question)
>> I don't think that was Scott's question; p=reject is a proposal by the
>> domain owner to the receiver refuse/discard/bounce at receiver's
>> discretion messages which fail both authentication methods. Scott
>> appeared to me to be positioning anything other than silent discard as
>> being "wrong" for p=reject. The DMARC spec makes clear that this is not so.
> No.  Here I'm still talking about ADSP.  It's similar to, but not identical to
> DMARC.

On re-reading I see that, but note that it's still relevant for the next 
step in your argument ("asked myself how DMARC might be better in than 
ADSP in this situation, and as far as I can tell, it's not"): DMARC does 
not require silent discard.

>>>> So in theory, this should be fine, but it's not.  This (assuming I got it
>>>> right) is one of the arguments for moving ADSP to Historic (since it's
>>>> not
>>>> only lightly used, it's known to cause damage when it does.
>> Barry or Dave may correct me on this, but the argument for moving ADSP
>> to historic is simply that its use is negligible (and perhaps that
>> having it retain a standards status may lead unwitting implementers
>> astray) and - in light of DMARC's adoption - unlikely ever to grow.
>> There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various
>> protective and softening mechanisms: rua/ruf, p=quarantine, pct), but
>> this is more the driver for the adoption of DMARC than the argument for
>> moving ADSP to historic.
> I think the potential for harm is identical.  If it's concerning for ADSP, it
> should be concerning for DMARC.

DMARC has similarities with ADSP, but as you acknowledge above, it's not 
the same. The differences are material.

> DMARC does have a few more knobs to turn, but
> if you don't want mail that fails authentication sent to the receiving user,
> you have to use p=reject and that has the exact same problem with mailing list
> subscriptions that ADSP does.

Noting that we're talking about a very narrow situation (and yes, now 
that I look at it, your choice of Subject: points this out) that both 
ADSP and DMARC authors accept is beyond their reach (both protocols are 
expected to reduce the problems that they address, not to magically 
solve them without side-effects), meaning that the broader argument is 
not being addressed:

  * DMARC provides domain owners with visibility of this situation ahead
    of a decision to switch on p=reject, ADSP does not. This materially
    changes the situation. It allows a domain owner to make informed
    choices, rather than guess, to plan appropriate trade-offs, to
    monitor the situation on an ongoing basis and to discover unexpected
    consequences as and when they arise.
  * DMARC makes concrete (through override reasons of forwarded,
    trusted_forwarder and mailing_list) reasons for receiver's
    discretion which ADSP did not. As a practical matter the exercise of
    discretion is required in either case, but DMARC raises it to a
    recognised element of the protocol rather than an invisible activity.


So, even for the narrow situation that you're asking about, DMARC does 
considerably better than ADSP.

>>>> I got to thinking about this and asked myself how DMARC might be better
>>>> in
>>>> than ADSP in this situation, and as far as I can tell, it's not.
>> In the sense that DMARC provides rua/ruf to improve a domain owner's
>> situational awareness and decision making, DMARC actually is
>> [marginally] better than ADSP in this situation, however this is the
>> wrong question. Interoperating with [existing] mailing lists is not part
>> of the goals of either protocol, consequently the failure to do so is
>> not a large concern.
> Ah, so DMARC is only for domains without real users?

As above, you're falling into the ambiguity around "is for" (the 
different meanings listed above lead to different answers to your question).

>
>> It would be nice if it were straight-forward (or even possible) for this
>> level of interoperability to exist, but no-one can currently see a way
>> for this to work. This is largely because all technically viable
>> approaches require all mailing list operators to implement them ahead of
>> evidence that they're appropriate. Like everybody else, their budget for
>> speculatively expending resources in the hope that they might fix other
>> people's problems is rather small. The practical upshot is that any
>> receiver implementing DMARC filtering requires an accurate database of
>> mailing list servers which host lists to which the receiver's users are
>> subscribed. This is untidy but workable and, again, is not a large
>> concern because it doesn't impede DMARC's objective.
> Workable for who?  Probably for large providers that can do it via data
> mining.  I don't even know all the mailing lists I'm subscribed to let alone
> everyone who uses my domains.

The "data mining" isn't all that difficult: mailing list servers stick 
out like a sore thumb (moderate to high sustained message volume, very 
low spam rates, very high authentication failure rates), are small in 
number and move rarely if at all. For receivers too small to perform 
even this level of analysis I'd suggest that the analytics required are 
simpler than are required to, for example, maintain an IP address 
blocklist, so there's an opportunity for reputation services to help 
small receivers sort this out.

I am interested to understand whether you're proposing a specific 
improvement; are you?

>
>> I'd suggest that there is a way forward and not too much need to worry
>> about it:
>>
>>    * In the short term, receivers are likely to need to maintain a
>>      database of list servers from which authentication failures can be
>>      ignored. It would be helpful for such receivers to report this to
>>      domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
>>    * As receiver adoption proceeds, it may be the case that mailing-list
>>      mapping is of sufficiently low importance to enough receivers that
>>      list operators start to see real (rather than hypothetical) benefit
>>      in addressing this, in which case any of the following will work, at
>>      the list operator's discretion:
>>        o Leave the message sufficiently unaltered to still pass DKIM
>>        o Replace the RFC5322.From with something that points to the list
>>          operator
>>        o Reject submissions from domains with p=reject (or reject only
>>          those where the list's changes break the DKIM signature on the
>>          message in question; noting that the signer determines what is
>>          signed and therefore a given message's DKIM signature may break
>>          for a given list, where others' wouldn't)
>>
>>
>> As with domain-owner use of p=reject on domains that aren't heavily
>> spoofed, or even the potential use of DMARC filtering by a receiver
>> without a mailing-list/forwarder database, the use or not of the
>> practices above by list operators should be positioned as "here's a way
>> to make this work if you wish to" not "you are irresponsible if you
>> don't do this".
> DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and I can
> think of two that don't break DKIM signatures (and not even this one).  I
> think the idea that mailing lists are going to do anything more for DKIM than
> add their own signatures is wishful thinking, certainly not supported by my
> experience.

Agreed. As I said, "As receiver adoption proceeds, it may be the case". 
It would be wishful thinking to assume that this was going to happen, my 
point was simply that it need not be a concern.

> I don't have a good solution either, but I'm also not convinced with what
> looks to me like a lot of handwaving.  We KNOW it was a problem with ADSP and
> while I really like things about DMARC like the feedback mechanisms, I don't
> think it's meaningfully different from ADSP in this regard and it will somehow
> have to be addressed.

The feedback mechanism materially changes the situation. It's analogous 
to the difference between sailing an ocean-going ship equipped only with 
a compass ("keep sailing west, we'll hit Canada eventually") and sailing 
one equipped with a GPS receiver (accurately following a series of 
waypoints that can't be directly perceived by human senses); they're 
both sailing, but the risks are drastically reduced when you have feedback.

The underlying "problem" (widespread, reasonable behaviour of mailing 
list operators) isn't going away any time soon. Until/unless mailing 
list operators see benefit in expending resource to help the process run 
more smoothly, it's unreasonable to expect them to do so; conseqiently 
my money is on receivers working out how to deal with this and, perhaps, 
reputation services helping smaller receivers to make better decisions.

- Roland

--------------070502040905020807070703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/17/2013 12:33 PM, Scott Kitterman
      wrote:

      

    

    

      
On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:


      

        
On 09/17/2013 08:04 AM, Franck Martin wrote:


        

          
----- Original Message -----



          

            
From: "Scott Kitterman" <sklist@kitterman.com>
To: dmarc@ietf.org
Sent: Monday, September 16, 2013 4:45:44 PM
Subject: [dmarc-ietf] ADSP Related Mailing List
Unsubscriptions	Considerations For DMARC

There are arguably several things done wrong here:
  - Sending user: why are you sending mail to a ML with an ADSP protected

domain.


          

        

        

          
Because you can... You can't control all your users and it is hard to know
when an email address is the one of a mailing list... As for the argument
you should not put an ADSP on a domain with users, well, any domain from
a targeted entity becomes eventually a target that needs protection
too...


        

        
+1


      

      
Sure.  I only mention that because some people's answer is that 
adsp=discardable or dmarc p=reject is only for domains without actual users 
(.e.g transactional mail).

    

    

    Understood, but note that talking about what DMARC (or ADSP) "is
    for" is ambiguous and leads to a lot of heat as people vigorously
    talk past each other. It can refer to at least:

    

    
    
      
  • What problem DMARC was designed to [and does] help solve.
    • 
      
  • What other situations DMARC can be used in.
    • 
      
  • What other situations DMARC can be used in without causing
        serious collateral damage.
    • 
    

    

    Depending upon the context, these three meanings (and perhaps
    others) give rise to multiple distinct positions; overlooking the
    ambiguity in the term creates considerable confusion.

    

    


      

        
This is a domain-owner's choice. They take their chances with the
consequences of course. What we're not able to do is provide a
child-safe environment in which there are no trade-offs and where
actions have no consequences.


      

      
Email authentication is only for domains that don't need mailing lists?  

    

    

    I didn't say anything like that.

    

    

      
Personally, I've got no problem with an SPF -all record.  I've had one since 
2004.  OTOH, p=reject would be very problematic.  I don't have a lot of 
personal correspondence in my local domains with people using services that 
are providing bulk feedback reports.  Something more than 99% of the traffic I 
see in my reports in mailing list traffic.

    

    

    Apologies, I don't follow how this bears on the discussion.

    

    


      

        

          
Because they are told to do so by the policy, but with DMARC they can
overwrite the result, while it is not possible with ADSP (see what is a
mailing list question)


        

        
I don't think that was Scott's question; p=reject is a proposal by the
domain owner to the receiver refuse/discard/bounce at receiver's
discretion messages which fail both authentication methods. Scott
appeared to me to be positioning anything other than silent discard as
being "wrong" for p=reject. The DMARC spec makes clear that this is not so.


      

      
No.  Here I'm still talking about ADSP.  It's similar to, but not identical to 
DMARC.

    

    

    On re-reading I see that, but note that it's still relevant for the
    next step in your argument ("asked myself how DMARC might be better
    in than ADSP in this situation, and as far as I can tell, it's not"):
    DMARC does not require silent discard.

    

    

      

      

        

          

            
So in theory, this should be fine, but it's not.  This (assuming I got it
right) is one of the arguments for moving ADSP to Historic (since it's
not
only lightly used, it's known to cause damage when it does.


          

        

        
Barry or Dave may correct me on this, but the argument for moving ADSP
to historic is simply that its use is negligible (and perhaps that
having it retain a standards status may lead unwitting implementers
astray) and - in light of DMARC's adoption - unlikely ever to grow.
There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various
protective and softening mechanisms: rua/ruf, p=quarantine, pct), but
this is more the driver for the adoption of DMARC than the argument for
moving ADSP to historic.


      

      
I think the potential for harm is identical.  If it's concerning for ADSP, it 
should be concerning for DMARC.

    

    

    DMARC has similarities with ADSP, but as you acknowledge above, it's
    not the same. The differences are material.

    

    

      
DMARC does have a few more knobs to turn, but 
if you don't want mail that fails authentication sent to the receiving user, 
you have to use p=reject and that has the exact same problem with mailing list 
subscriptions that ADSP does.

    

    

    Noting that we're talking about a very narrow situation (and yes,
    now that I look at it, your choice of Subject: points this out) that
    both ADSP and DMARC authors accept is beyond their reach (both
    protocols are expected to reduce the problems that they address, not
    to magically solve them without side-effects), meaning that the
    broader argument is not being addressed:

    
    
      
  • DMARC provides domain owners with visibility of this situation
        ahead of a decision to switch on p=reject, ADSP does not. This
        materially changes the situation. It allows a domain owner to
        make informed choices, rather than guess, to plan appropriate
        trade-offs, to monitor the situation on an ongoing basis and to
        discover unexpected consequences as and when they arise.
    
      
    • 
      
  • DMARC makes concrete (through override reasons of forwarded,
        trusted_forwarder and mailing_list) reasons for receiver's
        discretion which ADSP did not. As a practical matter the
        exercise of discretion is required in either case, but DMARC
        raises it to a recognised element of the protocol rather than an
        invisible activity.
    
      
    • 
    

    

    So, even for the narrow situation that you're asking about, DMARC
    does considerably better than ADSP.

    

    

      

        

          

            
I got to thinking about this and asked myself how DMARC might be better
in
than ADSP in this situation, and as far as I can tell, it's not.


          

        

        
In the sense that DMARC provides rua/ruf to improve a domain owner's
situational awareness and decision making, DMARC actually is
[marginally] better than ADSP in this situation, however this is the
wrong question. Interoperating with [existing] mailing lists is not part
of the goals of either protocol, consequently the failure to do so is
not a large concern.


      

      
Ah, so DMARC is only for domains without real users?

    

    

    As above, you're falling into the ambiguity around "is for" (the
    different meanings listed above lead to different answers to your
    question).

    

    


      

        
It would be nice if it were straight-forward (or even possible) for this
level of interoperability to exist, but no-one can currently see a way
for this to work. This is largely because all technically viable
approaches require all mailing list operators to implement them ahead of
evidence that they're appropriate. Like everybody else, their budget for
speculatively expending resources in the hope that they might fix other
people's problems is rather small. The practical upshot is that any
receiver implementing DMARC filtering requires an accurate database of
mailing list servers which host lists to which the receiver's users are
subscribed. This is untidy but workable and, again, is not a large
concern because it doesn't impede DMARC's objective.


      

      
Workable for who?  Probably for large providers that can do it via data 
mining.  I don't even know all the mailing lists I'm subscribed to let alone 
everyone who uses my domains.

    

    

    The "data mining" isn't all that difficult: mailing list servers
    stick out like a sore thumb (moderate to high sustained message
    volume, very low spam rates, very high authentication failure
    rates), are small in number and move rarely if at all. For receivers
    too small to perform even this level of analysis I'd suggest that
    the analytics required are simpler than are required to, for
    example, maintain an IP address blocklist, so there's an opportunity
    for reputation services to help small receivers sort this out.

    

    I am interested to understand whether you're proposing a specific
    improvement; are you?

    

    


      

        
I'd suggest that there is a way forward and not too much need to worry
about it:

  * In the short term, receivers are likely to need to maintain a
    database of list servers from which authentication failures can be
    ignored. It would be helpful for such receivers to report this to
    domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
  * As receiver adoption proceeds, it may be the case that mailing-list
    mapping is of sufficiently low importance to enough receivers that
    list operators start to see real (rather than hypothetical) benefit
    in addressing this, in which case any of the following will work, at
    the list operator's discretion:
      o Leave the message sufficiently unaltered to still pass DKIM
      o Replace the RFC5322.From with something that points to the list
        operator
      o Reject submissions from domains with p=reject (or reject only
        those where the list's changes break the DKIM signature on the
        message in question; noting that the signer determines what is
        signed and therefore a given message's DKIM signature may break
        for a given list, where others' wouldn't)


As with domain-owner use of p=reject on domains that aren't heavily
spoofed, or even the potential use of DMARC filtering by a receiver
without a mailing-list/forwarder database, the use or not of the
practices above by list operators should be positioned as "here's a way
to make this work if you wish to" not "you are irresponsible if you
don't do this".


      

      
DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and I can 
think of two that don't break DKIM signatures (and not even this one).  I 
think the idea that mailing lists are going to do anything more for DKIM than 
add their own signatures is wishful thinking, certainly not supported by my 
experience.

    

    

    Agreed. As I said, "As receiver adoption proceeds, it may be the
    case". It would be wishful thinking to assume that this was going to
    happen, my point was simply that it need not be a concern.

    

    

      
I don't have a good solution either, but I'm also not convinced with what 
looks to me like a lot of handwaving.  We KNOW it was a problem with ADSP and 
while I really like things about DMARC like the feedback mechanisms, I don't 
think it's meaningfully different from ADSP in this regard and it will somehow 
have to be addressed.

    

    

    The feedback mechanism materially changes the situation. It's
    analogous to the difference between sailing an ocean-going ship
    equipped only with a compass ("keep sailing west, we'll hit Canada
    eventually") and sailing one equipped with a GPS receiver
    (accurately following a series of waypoints that can't be directly
    perceived by human senses); they're both sailing, but the risks are
    drastically reduced when you have feedback.

    

    The underlying "problem" (widespread, reasonable behaviour of
    mailing list operators) isn't going away any time soon. Until/unless
    mailing list operators see benefit in expending resource to help the
    process run more smoothly, it's unreasonable to expect them to do
    so; conseqiently my money is on receivers working out how to deal
    with this and, perhaps, reputation services helping smaller
    receivers to make better decisions.

    

    - Roland

  


--------------070502040905020807070703--

From roland@rolandturner.com  Sun Sep 22 07:20:25 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E521F9E9F for ; Sun, 22 Sep 2013 07:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.129
X-Spam-Level: *
X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[AWL=1.313,  BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjmAmaMlPlnm for ; Sun, 22 Sep 2013 07:20:21 -0700 (PDT)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDBA21F93F8 for ; Sun, 22 Sep 2013 07:20:21 -0700 (PDT)
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:CC:To:MIME-Version:From:Date:Message-ID; bh=+iV3lPgbMcTk2XMPuRhNGMejJGh6cfoHzPzpc8M8YDc=;  b=pKhmgceLkO4LgADgahwI5ExNAiAMUscx5n8z8XycZYAE+rsBlcEUDX3DxbBd4mjAY4rU7Y/urfvfm2xvUKTYr8SW3wgiWTeOWRfwtck+n5yoMGt1VSLcJzBLJT7Ajo20wTSn6+tbxbUP5aJaCoME/u1xSOCbKMkt39ZS4D1WILg=;
Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=116.86.208.48; iprev=pass policy.iprev=116.86.208.48 (cm48.beta208.maxonline.com.sg)
Received: from [116.86.208.48] (port=42893 helo=[10.1.132.105]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VNkWB-00032O-P8; Sun, 22 Sep 2013 14:20:14 +0000
Message-ID: <523EFC9B.5030400@rolandturner.com>
Date: Sun, 22 Sep 2013 22:20:11 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: R.E.Sonneveld@sonnection.nl, Scott Kitterman 
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>	<2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>	<5237C378.6030807@rolandturner.com>	<1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl>
In-Reply-To: <5238D6AA.2050005@sonnection.nl>
Content-Type: multipart/alternative; boundary="------------030702060406060605010101"
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 14:20:26 -0000

This is a multi-part message in MIME format.
--------------030702060406060605010101
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09/18/2013 06:24 AM, Rolf E. Sonneveld wrote:

> RFC5321 section 6.2 addresses these concerns as follows:
>
>     As discussed inSection 7.8    andSection 7.9    below, dropping mail
>     without notification of the sender is permitted in practice.
>     However, it is extremely dangerous and violates a long tradition and
>     community expectations that mail is either delivered or returned.  If
>     silent message-dropping is misused, it could easily undermine
>     confidence in the reliability of the Internet's mail systems.  So
>     silent dropping of messages should be considered only in those cases
>     where there is very high confidence that the messages are seriously
>     fraudulent or otherwise inappropriate.
>
> Apart from some corner cases (small organizations) neither sending 
> mail eco-system nor receiving mail eco-system is able to adequately 
> and reliably determine which messages are handled by a MLM and which 
> are not. And even if one finds a way to determine this, it certainly 
> will not be scalable to the entire Internet. With that in mind, the 
> question is: is option 2 of par 15.4 of the DMARC base spec ('silent 
> discard') contradicting the above quoted principle as stated in 
> RFC5321, or not?

The DMARC spec does not stipulate how a receiver is to implement 
rejection. 15.4 does discuss the trade-off. It might be appropriate to 
insert references to the document sections that you point out.

> As ADSP has been adopted by the IETF as standards track document, the 
> question is: are there any new insights/ regarding this problem in 
> relation to DMARC? If not, it makes little sense redoing the entire 
> MLM/ADSP discussion for MLM/DMARC?

There is no reason to redo the discussion.

> Don't get me wrong: in my opinion new standards have to interoperate 
> with the current Internet, so the existence of MLM's and the way most 
> of them operate at this moment, can't be ignored. Using special 
> domains for 'DMARC signed mail' to prevent damage may be a good 
> advise, but companies may want to 'protect' their main (and most 
> well-known) domains, with which they also send transactional and IPM 
> as well.

This would be a desirable additional benefit of DMARC adoption. It would 
appear that it rests critically upon how receivers go about dealing with 
mailing lists, which for smaller receivers probably means whether viable 
reputation services appear.

> Then the next question is: is it worth standardizing DMARC within the 
> IETF? Obviously it already is a _de facto_ standard, why should we aim 
> at making it a _de jure_ standard as well?
>
> I for myself have not yet found the answer to this question.

People with a longer experience with IETF process may offer a better 
answer, but I'd suggest RFC 2026 
 4.1.1 offers an approach:

> A Proposed Standard specification is generally stable, has resolved
> known design choices, is believed to be well-understood, has received
> significant community review, and appears to enjoy enough community
> interest to be considered valuable.  However, further experience
> might result in a change or even retraction of the specification
> before it advances.

It would appear that DMARC meets this with room to spare. Barry has 
already stated what additional input he's seeking, but the community 
interest test would appear to be the one relevant to your question and 
I'd suggest that it's been more than met.

- Roland

--------------030702060406060605010101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/18/2013 06:24 AM, Rolf E.
      Sonneveld wrote:

      

    

    

      
      
RFC5321 section 6.2 addresses these
        concerns as follows:

      

      

      
   As discussed in Section 7.8 and Section 7.9 below, dropping mail
   without notification of the sender is permitted in practice.
   However, it is extremely dangerous and violates a long tradition and
   community expectations that mail is either delivered or returned.  If
   silent message-dropping is misused, it could easily undermine
   confidence in the reliability of the Internet's mail systems.  So
   silent dropping of messages should be considered only in those cases
   where there is very high confidence that the messages are seriously
   fraudulent or otherwise inappropriate.

      

      Apart from some corner cases (small organizations) neither sending
      mail eco-system nor receiving mail eco-system is able to
      adequately and reliably determine which messages are handled by a
      MLM and which are not. And even if one finds a way to determine
      this, it certainly will not be scalable to the entire Internet.
      With that in mind, the question is: is option 2 of par 15.4 of the
      DMARC base spec ('silent discard') contradicting the above quoted
      principle as stated in RFC5321, or not?

    

    

    The DMARC spec does not stipulate how a receiver is to implement
    rejection. 15.4 does discuss the trade-off. It might be appropriate
    to insert references to the document sections that you point out.

    

    

      As ADSP has been adopted by the IETF as standards track document,
      the question is: are there any new insights/ regarding this
      problem in relation to DMARC? If not, it makes little sense
      redoing the entire MLM/ADSP discussion for MLM/DMARC?

    

    

    There is no reason to redo the discussion.

    

    

      Don't get me wrong: in my opinion new standards have to
      interoperate with the current Internet, so the existence of MLM's
      and the way most of them operate at this moment, can't be ignored.
      Using special domains for 'DMARC signed mail' to prevent damage
      may be a good advise, but companies may want to 'protect' their
      main (and most well-known) domains, with which they also send
      transactional and IPM as well.

    

    

    This would be a desirable additional benefit of DMARC adoption. It
    would appear that it rests critically upon how receivers go about
    dealing with mailing lists, which for smaller receivers probably
    means whether viable reputation services appear.

    

    

      Then the next question is: is it worth standardizing DMARC within
      the IETF? Obviously it already is a _de facto_ standard, why
      should we aim at making it a _de jure_ standard as well?

      

      I for myself have not yet found the answer to this question.

    

    

    People with a longer experience with IETF process may offer a better
    answer, but I'd suggest RFC 2026
    4.1.1 offers an approach:

    

    

      
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable.  However, further experience
might result in a change or even retraction of the specification
before it advances.

    

    

    It would appear that DMARC meets this with room to spare. Barry has
    already stated what additional input he's seeking, but the community
    interest test would appear to be the one relevant to your question
    and I'd suggest that it's been more than met.

    

    - Roland

  


--------------030702060406060605010101--

From roland@rolandturner.com  Sun Sep 22 07:21:39 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0163221F9F80 for ; Sun, 22 Sep 2013 07:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.435
X-Spam-Level: 
X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=1.564,  BAYES_00=-2.599, J_CHICKENPOX_16=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKz0KK43fJ2D for ; Sun, 22 Sep 2013 07:21:34 -0700 (PDT)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2B821F93F8 for ; Sun, 22 Sep 2013 07:21:31 -0700 (PDT)
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:To:MIME-Version:From:Date:Message-ID; bh=UYFfFQPx2UCG1bzibENH5r09a/JvoU8N4M67NHYEmck=;  b=gl3UozXWuFKdNmZMjTvk6LSYQcJ9uCZKujyQ06vEelWUFSrJDBdkS8EcjM74e+CWzADEkxwUZMbPQLSQVsCzG3LAD5Ks902tj51TDXgxsoxWN3sYVJ6b5r/hgY6W0Gn3NfgrSVFjcW39c9pqXYc5g5axG5biIZcKkrwJWThXkhc=;
Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=116.86.208.48; iprev=pass policy.iprev=116.86.208.48 (cm48.beta208.maxonline.com.sg)
Received: from [116.86.208.48] (port=42898 helo=[10.1.132.105]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VNkXK-00032W-EH for dmarc@ietf.org; Sun, 22 Sep 2013 14:21:22 +0000
Message-ID: <523EFCE2.9040507@rolandturner.com>
Date: Sun, 22 Sep 2013 22:21:22 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dmarc@ietf.org
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>	<2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>	<5237C378.6030807@rolandturner.com>	<1945650.hcHt8AHrK6@scott-latitude-e6320>	<5238D6AA.2050005@sonnection.nl> <3ed5439c-3241-4808-bcb8-916b10eca07b@email.android.com>
In-Reply-To: <3ed5439c-3241-4808-bcb8-916b10eca07b@email.android.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 14:21:39 -0000

On 09/18/2013 08:02 AM, Scott Kitterman wrote:

> I think DMARC is widely enough used that it's worth documenting. Along 
> with that, I think it is critical to give operators guidance about the 
> risks associated with p=reject for different domain usage patterns.

+1

- Roland

From dcrocker@gmail.com  Sun Sep 22 07:35:39 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A8821F9D65 for ; Sun, 22 Sep 2013 07:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIYAkGJI+lSS for ; Sun, 22 Sep 2013 07:35:38 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF321F9D56 for ; Sun, 22 Sep 2013 07:35:37 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id e14so4676250iej.34 for ; Sun, 22 Sep 2013 07:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=inVlHQEa4BwR1BOs5Ur0fhBvyE0F+3SwrL+cmBUApvo=; b=SQ2neL3nJblZfpLuOFtb5y4kL2SSqBhkAGZdZY6PnZN7m10Kepcg+ES3RMeRb3CUiw P6Bc3I/iAFU+K1GDWC6HSih+DAddbN7wj5LZJk9JQ2Wf8rOlDswVuXubUUUGz1GYYvJe dQwqCopo5tqCn05QBY/NgN9cRuafzIMfjzhDalCfCxDuGBffZTjnrKKu4VL9b/x0x4QI Uti0H1cQcB9LLHC5z3aG9oZJsO/ggrieoTg9v0HVzECCSNQwHawrfjk+yHDjmwUt2Q3C W+ArdALhViNjCauH+U6D7JDaqb5rhcikWQTq30xWfD5zTudiMCDKXmPxgjaJuzMYkE51 /kTA==
X-Received: by 10.42.190.17 with SMTP id dg17mr768316icb.44.1379860529448; Sun, 22 Sep 2013 07:35:29 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id i11sm13395038igh.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 07:35:28 -0700 (PDT)
Message-ID: <523F0005.9090102@gmail.com>
Date: Sun, 22 Sep 2013 07:34:45 -0700
From: Dave Crocker 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: dmarc@ietf.org
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>	<2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>	<5237C378.6030807@rolandturner.com>	<1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl> <523EFC9B.5030400@rolandturner.com>
In-Reply-To: <523EFC9B.5030400@rolandturner.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 14:35:39 -0000

On 9/16/2013 9:33 PM, Scott Kitterman wrote:
 >> This is a domain-owner's choice. They take their chances with the
 >> consequences of course. What we're not able to do is provide a
 >> child-safe environment in which there are no trade-offs and where
 >> actions have no consequences.
 >
 > Email authentication is only for domains that don't need mailing
 > lists?

The question jumps from the specifics of DMARC (or DKIM or SPF) into a 
much, much more general point.  The problem with any logic that might be 
trying to justify that generality here is that these bits of technology 
offer very specific /kinds/ of email authentication.  In fact as we keep 
seeing, the distinctive nature of their specific authentications is 
often missed by folk.

In other words, an assessment of any one (or even all 3) of these 
doesn't permit making the more general assessment about any and all 
forms of email authentication.  (Nor do I read Roland's text as having 
attempted that.)



On 9/22/2013 7:20 AM, Roland Turner wrote:
>> Then the next question is: is it worth standardizing DMARC within the
>> IETF? Obviously it already is a _de facto_ standard, why should we aim
>> at making it a _de jure_ standard as well?
>>
>> I for myself have not yet found the answer to this question.
>
> People with a longer experience with IETF process may offer a better
> answer, but I'd suggest RFC 2026
>  4.1.1 offers an approach:


(Just for clarity, the IETF does not produce "de jure" standards.  It 
has no enforcement authority, which is what is meant by the term.  Note 
the opening paragraph to RFC 2026, which cites "voluntary adherence". 
These days, it's perhaps classed as "formal", but that's quite different.)

/Why/ a group wants to pursue IETF standardization is a meta-question 
that, frankly, the IETF itself doesn't really doesn't answer, except 
perhaps indirectly.  Referring again to RFC 2026, the last paragraph in 
Section 1.1:

      "In general, an Internet Standard is a specification that is stable
    and well-understood, is technically competent, has multiple,
    independent, and interoperable implementations with substantial
    operational experience, enjoys significant public support, and is
    recognizably useful in some or all parts of the Internet."

So I'd say that a good motivation for seeking IETF standardization to 
obtain this formal assessment.  In other words, it further vets an 
existing specification, as well as essentially handing change control 
for the specification over to the IETF.  (This latter point doesn't 
actually require standardization, but it is a real side-effect.)

d/



-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From R.E.Sonneveld@sonnection.nl  Mon Sep 23 14:14:48 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF521F9FC8 for ; Mon, 23 Sep 2013 14:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.275
X-Spam-Level: 
X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.324,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nN4Ai2pGF9W for ; Mon, 23 Sep 2013 14:14:44 -0700 (PDT)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D44EC21F9F9D for ; Mon, 23 Sep 2013 14:14:43 -0700 (PDT)
Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3ckJFY0zv1z1L8f7; Mon, 23 Sep 2013 23:14:41 +0200 (CEST)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3ckJFX6svhz5MhcZ; Mon, 23 Sep 2013 23:14:40 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 97F2E123135; Mon, 23 Sep 2013 23:14:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aBMWG5jtIKDZ; Mon, 23 Sep 2013 23:14:31 +0200 (CEST)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id AB2D6123054; Mon, 23 Sep 2013 23:14:31 +0200 (CEST)
Message-ID: <5240AF37.5030902@sonnection.nl>
Date: Mon, 23 Sep 2013 23:14:31 +0200
From: "Rolf E. Sonneveld" 
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dave Crocker 
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>	<2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>	<5237C378.6030807@rolandturner.com>	<1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl> <523EFC9B.5030400@rolandturner.com> <523F0005.9090102@gmail.com>
In-Reply-To: <523F0005.9090102@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1379970881; bh=QWNQHv/PBvdW27Ho2AGEChCpsu7eYLbFHM9ivPifOcQ=; h=Message-ID:Date:From:To:Subject:From; b=CBbr5j4pHX9JKJUAZSwk5WSUzzp8dOpPXgwYUM5ok6X6EAKVcUCcGl2VoWNVgcgAB oLZnecNFwhzHw/ojWJI6qvN6gHIpWpD15YgF0rpjqLQYr+P3vQdwNynwcF/EjtL5sD 11KYHrDJKazFD6JTWPaN2pfixhaioZwsKVyf+g6Q=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3ckJFY0zv1z1L8f7
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Sep 2013 21:14:48 -0000

On 09/22/2013 04:34 PM, Dave Crocker wrote:
> On 9/16/2013 9:33 PM, Scott Kitterman wrote:
> >> This is a domain-owner's choice. They take their chances with the
> >> consequences of course. What we're not able to do is provide a
> >> child-safe environment in which there are no trade-offs and where
> >> actions have no consequences.
> >
> > Email authentication is only for domains that don't need mailing
> > lists?
>
> The question jumps from the specifics of DMARC (or DKIM or SPF) into a 
> much, much more general point.  The problem with any logic that might 
> be trying to justify that generality here is that these bits of 
> technology offer very specific /kinds/ of email authentication.  In 
> fact as we keep seeing, the distinctive nature of their specific 
> authentications is often missed by folk.
>
> In other words, an assessment of any one (or even all 3) of these 
> doesn't permit making the more general assessment about any and all 
> forms of email authentication.  (Nor do I read Roland's text as having 
> attempted that.)
>
>
>
> On 9/22/2013 7:20 AM, Roland Turner wrote:
>>> Then the next question is: is it worth standardizing DMARC within the
>>> IETF? Obviously it already is a _de facto_ standard, why should we aim
>>> at making it a _de jure_ standard as well?
>>>
>>> I for myself have not yet found the answer to this question.
>>
>> People with a longer experience with IETF process may offer a better
>> answer, but I'd suggest RFC 2026
>>  4.1.1 offers an approach:
>
>
> (Just for clarity, the IETF does not produce "de jure" standards. It 
> has no enforcement authority, which is what is meant by the term.

There seems to be quite some controversy about the terms "de jure" and 
"de facto", see for example:

http://electronicdesign.com/embedded/what-s-difference-between-de-jure-and-de-facto-standards

including the Discussion that follows the article. It was not my 
intention to start a discussion here on these words, so I apologize for 
having used this terminology.

>   Note the opening paragraph to RFC 2026, which cites "voluntary 
> adherence". These days, it's perhaps classed as "formal", but that's 
> quite different.)

Please note that more and more governments create lists of standards, 
which must be used by these government's agencies and organizations, 
when building new IT solutions, purchasing new software etc. [1]. Quite 
a number of these standards are IETF standards. See [2], [3] and [4]. 
With that in mind, the IETF standards become more and more 'mandatory' 
(to not use the word "de jure") to use for many organizations worldwide. 
I have been involved in submitting DKIM for the Dutch list 'Comply or 
Explain' and I can assure you that it definitely makes a difference when 
a standard is an IETF standard or not. This is due to the criteria that 
are used (open standardization process, decisions by consensus, publicly 
available etc.).

> /Why/ a group wants to pursue IETF standardization is a meta-question 
> that, frankly, the IETF itself doesn't really doesn't answer, except 
> perhaps indirectly.  Referring again to RFC 2026, the last paragraph 
> in Section 1.1:
>
>      "In general, an Internet Standard is a specification that is stable
>    and well-understood, is technically competent, has multiple,
>    independent, and interoperable implementations with substantial
>    operational experience, enjoys significant public support, and is
>    recognizably useful in some or all parts of the Internet."

Apart from stable and well-understood, all of these characteristics 
already apply to DMARC. In addition to that I doubt whether the 
individual submission with AD sponsorship will aid in improving the 
understanding of the protocol, or in gaining significant public support.

>
> So I'd say that a good motivation for seeking IETF standardization to 
> obtain this formal assessment.  In other words, it further vets an 
> existing specification, as well as essentially handing change control 
> for the specification over to the IETF.  (This latter point doesn't 
> actually require standardization, but it is a real side-effect.)

The good thing of standardization of DMARC within IETF, IMHO, is that in 
the long term it will improve stability of the standard, which is due to 
the fact that change control is handed over to the IETF. So basically 
I'm in favour of standardizing DMARC within the IETF, but I hope the 
chosen path will not minimize the influence that IETF can have on this 
standard, as there seems to be only one 'Last Call' between the 
DMARC-as-it-is-now and the IETF standard DMARC (or will there be more 
moments that consensus is sought?).

/rolf

[1] 
http://en.wikibooks.org/wiki/FOSS_Open_Standards/Government_National_Open_Standards_Policies_and_Initiatives
[2] http://dre.pt/pdf1sdip/2012/11/21600/0646006465.pdf (Portugese)
[3] 
http://www.computerweekly.com/blogs/public-sector/2011/10/open-standards-uk-dithers-whil.html
[4] 
https://lijsten.forumstandaardisatie.nl/lijsten/open-standaarden?lijst=Pas%20toe%20of%20leg%20uit&status[]=Opgenomen&pagetitle=pastoeof 
(Dutch)



From dcrocker@gmail.com  Mon Sep 23 14:35:57 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DCA21F9C0A for ; Mon, 23 Sep 2013 14:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw5R0EIxrn4B for ; Mon, 23 Sep 2013 14:35:56 -0700 (PDT)
Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E3FF421F92B5 for ; Mon, 23 Sep 2013 14:35:41 -0700 (PDT)
Received: by mail-oa0-f43.google.com with SMTP id f4so1240651oah.30 for ; Mon, 23 Sep 2013 14:35:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5FX8wQgNJzhxLdDZQtLyr5m/X/un8vyUKHsye4Und94=; b=D6MPWllN9xiJzKaJXpz6GdZxJI82Lfs8n+Q4TfvM+pE7ZUHnanYN3igtNAYuLdpvt2 jGWZVHCaOanWQEvaIWlPfgWyZIzaAx9DVu4BncMRRfY45hP+fpE4jLEMS6IDQjEorSj0 ilgEx+3gDlPQYAqmH+5zPcgyE8mygsvPTLB8rD8k/XgUMeheLD7m7G+yxOQ106WIDb3C 7Rv3DwvUZcoFYvpGu2DNJeGM8ojTftvHN63mYGApTeuGjgDHXzwu2FrekyRbwPNSAvuS jlcv0dVvqjrADEecb82Sztd6OASQgvz/0B9oXpjYHo83W+GJRcj3fnwAf8w3e4IBdsuJ rNMg==
X-Received: by 10.60.93.105 with SMTP id ct9mr3740093oeb.42.1379972129557; Mon, 23 Sep 2013 14:35:29 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id j9sm17097119oef.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 14:35:28 -0700 (PDT)
Message-ID: <5240B3FA.1050409@gmail.com>
Date: Mon, 23 Sep 2013 14:34:50 -0700
From: Dave Crocker 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: R.E.Sonneveld@sonnection.nl
References: <1510357.FYKYMNnRCL@scott-latitude-e6320>	<2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org>	<5237C378.6030807@rolandturner.com>	<1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl> <523EFC9B.5030400@rolandturner.com> <523F0005.9090102@gmail.com> <5240AF37.5030902@sonnection.nl>
In-Reply-To: <5240AF37.5030902@sonnection.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 21:35:57 -0000

On 9/23/2013 2:14 PM, Rolf E. Sonneveld wrote:
> There seems to be quite some controversy about the terms "de jure" and
> "de facto", see for example:
>
> http://electronicdesign.com/embedded/what-s-difference-between-de-jure-and-de-facto-standards

I don't think there is much 'controversy' at all, actually, although 
it's clear there is some confusion, with some folk.  The article itself 
seems in line with my own comment, as does the discussion comment after 
the article.


> Please note that more and more governments create lists of standards,

Indeed they do, but that doesn't automatically make the standard de 
jure.  A government can be a customer, like any other.  Customers have 
requirements.

Rather, as the article explores, de jure standards are required by 
actual law or regulation a government purchasing requirements list 
doesn't rise quite that high -- not just for use by the body making the 
requirement, such as the government for itself, but for use by others.


> With that in mind, the IETF standards become more and more 'mandatory'
> (to not use the word "de jure") to use for many organizations worldwide.

A highly successful de facto standard gets that way incrementally, by 
many independent decisions.  After a while, yes, it takes on a degree -- 
possibly a very high degree -- of obligatory use, possibly even embodied 
in regulation.  At that point, one can refer to a de facto standard's 
having become de jure, I suppose.

The important point for work in the IETF is that there is /never/ any 
guaranteed success.  For each piece of work we do, we have to target 
success by incremental adoption, through many independent decisions. 
This is fundamentally different from knowing that a spec will get used 
because there is a legal regulation demanding it.

All work in the IETF is delivered with the goal of achieving de facto 
acceptance.  /Eventual/ de jure status is just icing on the success cake.


>> /Why/ a group wants to pursue IETF standardization is a meta-question
>> that, frankly, the IETF itself doesn't really doesn't answer, except
>> perhaps indirectly.  Referring again to RFC 2026, the last paragraph
>> in Section 1.1:
>>
>>      "In general, an Internet Standard is a specification that is stable
>>    and well-understood, is technically competent, has multiple,
>>    independent, and interoperable implementations with substantial
>>    operational experience, enjoys significant public support, and is
>>    recognizably useful in some or all parts of the Internet."
>
> Apart from stable and well-understood, all of these characteristics
> already apply to DMARC.

Well, there's the fact of those condition, but there is a separate 
question of their perception.  Evaluation by the IETF can constitute a 
presumably rigorous and independent review for those characteristics.


> In addition to that I doubt whether the
> individual submission with AD sponsorship will aid in improving the
> understanding of the protocol, or in gaining significant public support.

Possibly they can and will.  Possibly they can and will improve the 
document writing.  Additional reviews often produce surprising results. 
  I'm not expecting anyone to come up with a surprising flaw in the 
protocol, but I don't have any trouble believing the document can be 
improved.  Most specs documents can benefit that way.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From sm@resistor.net  Mon Sep 23 15:12:52 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB321F9C4C for ; Mon, 23 Sep 2013 15:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.739
X-Spam-Level: 
X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRE9r2S3MKiD for ; Mon, 23 Sep 2013 15:12:51 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7166721F92E7 for ; Mon, 23 Sep 2013 15:12:51 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8NMCiKc014939; Mon, 23 Sep 2013 15:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379974370; bh=JYZ+yib4Fabb8pwwq0BHT8Gd0aHdFEiuPs1bZgwzyo4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mqp4ngILK//8/RgaRcG3KXhzdXrtHZt2oB6uo9key0rT5RJx2zActOpwlsQeBbRfw sE/86pdJN8DU2y4e6c1H8OcuEdR029fcfj/t+e2S4htEzZbg1nhgdBLFtXIyeBx33j DjuuIJ07nU409eAeIwkP9YKxDYa9W3RyL8rYLL94=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379974370; i=@resistor.net; bh=JYZ+yib4Fabb8pwwq0BHT8Gd0aHdFEiuPs1bZgwzyo4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=au20BytW42mixyBDTvtzvj9h6ywWyw0QT9GwOnsvBedf+ppr5lQ+Lyo6b7lOiwOqU cpWLNyX9MAcLVAZj7Ug+efql/ZhuNtzlRoMqS1DekHL8Ecln89kyOyd16uAWy4PET0 tzz3hk1Qxieq1Ajq/mhvSx9d8GS32d4JMUKgc+DI=
Message-Id: <6.2.5.6.2.20130923141910.0cf77888@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 23 Sep 2013 15:10:37 -0700
To: R.E.Sonneveld@sonnection.nl
From: SM 
In-Reply-To: <5240AF37.5030902@sonnection.nl>
References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> <5237C378.6030807@rolandturner.com> <1945650.hcHt8AHrK6@scott-latitude-e6320> <5238D6AA.2050005@sonnection.nl> <523EFC9B.5030400@rolandturner.com> <523F0005.9090102@gmail.com> <5240AF37.5030902@sonnection.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: dmarc@ietf.org
Subject: [dmarc-ietf] Standardization (was: ADSP Related Mailing List Unsubscriptions Considerations For DMARC)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 22:12:52 -0000

Hi Rolf,
At 14:14 23-09-2013, Rolf E. Sonneveld wrote:
>Please note that more and more governments create lists of 
>standards, which must be used by these government's agencies and 
>organizations, when building new IT solutions, purchasing new 
>software etc. [1]. Quite a number of these standards are IETF 
>standards. See [2], [3] and [4]. With that in mind, the IETF 
>standards become more and more 'mandatory' (to not use the word "de 
>jure") to use for many organizations worldwide. I have been involved 
>in submitting DKIM for the Dutch list 'Comply or Explain' and I can 
>assure you that it definitely makes a difference when a standard is 
>an IETF standard or not. This is due to the criteria that are used 
>(open standardization process, decisions by consensus, publicly 
>available etc.).

Agreed.

The regulatory framework works differently in some jurisdictions.  It 
is easier to get a specification adopted when it is an IETF standard.

Regards,
-sm 


From franck@peachymango.org  Wed Sep 25 14:44:22 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7B321F9E54 for ; Wed, 25 Sep 2013 14:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level: 
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TO+VVhkUpaS for ; Wed, 25 Sep 2013 14:44:16 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDFB21F9E3F for ; Wed, 25 Sep 2013 14:44:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id DFC7739001A for ; Wed, 25 Sep 2013 16:44:14 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IXE-5CfVLys for ; Wed, 25 Sep 2013 16:44:14 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AEA7F39002A for ; Wed, 25 Sep 2013 16:44:14 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9EB37390024 for ; Wed, 25 Sep 2013 16:44:14 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id h6V21LmZoHbT for ; Wed, 25 Sep 2013 16:44:14 -0500 (CDT)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 290AD39008B for ; Wed, 25 Sep 2013 16:44:14 -0500 (CDT)
Date: Wed, 25 Sep 2013 16:44:13 -0500 (CDT)
From: Franck Martin 
To: dmarc@ietf.org
Message-ID: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org>
In-Reply-To: <784935001.120210.1380145222455.JavaMail.zimbra@peachymango.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_120389_1986599948.1380145453452"
X-Originating-IP: [69.28.149.129]
X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737)
Thread-Topic: text correction on DMARC spec re reporting DNS record
Thread-Index: rGV1EesGjrnnA37JPCyhJtJQHrgg+A==
Subject: [dmarc-ietf] text correction on DMARC spec re reporting DNS record
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 21:44:22 -0000

------=_Part_120389_1986599948.1380145453452
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Section 7.1 Verifying External Destinations 

3rd paragraph from the end of the section. 

"The Domain Owner confirming via the DNS that it wishes to receive 
reports can use a wildcard DNS record to confirm that it is willing 
to receive reports for any domain. For example, a TXT resource 
record at "*._report._dmarc.example.com" containing at least 
"v=DMARC1" confirms that example.com is willing to receive DMARC 
reports for any child domain." 

Should be 

"The report receiver confirming via the DNS that it wishes to receive 
reports can use a wildcard DNS record to confirm that it is willing 
to receive reports for any domain. For example, a TXT resource 
record at "*._report._dmarc.example.com" containing at least 
"v=DMARC1" confirms that example.com is willing to receive DMARC 
reports for any domain." 

------=_Part_120389_1986599948.1380145453452
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Section 7.1  Verifying External Destinat=
ions

3rd paragraph from the end of the section.
<=
br>
"The Domain Owner confirming via the DNS that it wishes to receive=

 reports can use a wildcard DNS record to confirm that it is willi=
ng
 to receive reports for any domain.  For example, a TXT res=
ource
 record at "*._report._dmarc.example.com" containing at least=

 "v=3DDMARC1" confirms that example.com is willing to receive DMAR=
C
 reports for any child domain."

Should b=
e

"The report receiver confirming via the DNS =
that it wishes to receive
 reports can use a wildcard DNS record to=
 confirm that it is willing
 to receive reports for any domain.&nbs=
p; For example, a TXT resource
 record at "*._report._dmarc.example=
.com" containing at least
 "v=3DDMARC1" confirms that example.com i=
s willing to receive DMARC
 reports for any domain."

------=_Part_120389_1986599948.1380145453452--

From R.E.Sonneveld@sonnection.nl  Wed Sep 25 15:22:52 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1521F9DB8 for ; Wed, 25 Sep 2013 15:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.379
X-Spam-Level: *
X-Spam-Status: No, score=1.379 tagged_above=-999 required=5 tests=[AWL=-4.411,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYEmIioQyYPJ for ; Wed, 25 Sep 2013 15:22:41 -0700 (PDT)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11521F99ED for ; Wed, 25 Sep 2013 15:22:17 -0700 (PDT)
Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3clYfb1Sc2z1L8fc; Thu, 26 Sep 2013 00:22:15 +0200 (CEST)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3clYfb0GnTz1L8fM; Thu, 26 Sep 2013 00:22:15 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id CB1541231DB; Thu, 26 Sep 2013 00:22:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9-uIX-RQLFEz; Thu, 26 Sep 2013 00:22:07 +0200 (CEST)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 905021231C8; Thu, 26 Sep 2013 00:22:07 +0200 (CEST)
Message-ID: <5243620F.9010500@sonnection.nl>
Date: Thu, 26 Sep 2013 00:22:07 +0200
From: "Rolf E. Sonneveld" 
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Franck Martin 
References: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org>
In-Reply-To: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org>
Content-Type: multipart/alternative; boundary="------------030508040101090307040805"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1380147735; bh=lE2dGuPKUXEJYEu59r3AyYnVxtLkCwAswY/UuiebqMY=; h=Message-ID:Date:From:To:Subject:From; b=UcnGSccLfUcrPr6KZ7SYz6QHnVROC+s+FN79G8BMgpxyEOcjMSsETwnNNS9LuDuVC SH+4b5OzwC1QmV5Rgiu1YyFdxrmcP8ZGEeYu8hXGkgeuY9EUlI/9Jk9rlf6o+AWwQs 4SDOrClF2l1toNkcXeEn3NrnqISTAWGCShNjXNGc=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3clYfb1Sc2z1L8fc
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] text correction on DMARC spec re reporting DNS record
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 25 Sep 2013 22:22:52 -0000

This is a multi-part message in MIME format.
--------------030508040101090307040805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/25/2013 11:44 PM, Franck Martin wrote:
> Section 7.1  Verifying External Destinations
>
> 3rd paragraph from the end of the section.
>
> "The Domain Owner confirming via the DNS that it wishes to receive
>  reports can use a wildcard DNS record to confirm that it is willing
>  to receive reports for any domain.  For example, a TXT resource
>  record at "*._report._dmarc.example.com" containing at least
>  "v=DMARC1" confirms that example.com is willing to receive DMARC
>  reports for any child domain."
>
> Should be
>
> "The report receiver confirming via the DNS that it wishes to receive
>  reports can use a wildcard DNS record to confirm that it is willing
>  to receive reports for any domain.  For example, a TXT resource
>  record at "*._report._dmarc.example.com" containing at least
>  "v=DMARC1" confirms that example.com is willing to receive DMARC
>  reports for any domain."

Report receivers and domain owners are two different functions. And 
although both functions can be assigned to a single person, in general 
one cannot say (imho) that a report receiver is able to do something 
(confirm willingness to receive reports) in DNS.

What about:

"The Domain Owner of the domain of a Report Receiver who is willing
to receive reports for any domain, can use a wildcard DNS record. For
example, a TXT resource record at "*._report._dmarc.example.com"
containing at least "v=DMARC1" confirms that example.com is willing
to receive DMARC reports for any child domain."

And BTW: I do believe that 'child domain' here is not correct 
terminology: the wildcard indicates any domain on the Internet, which 
can have "rua" or "ruf" tags that points to this domain.

Example: domainA.com has rua tag that points to a receiver in 
domainC.com and domainB.com has also a rua tag that points to a receiver 
in domainC.com. Then it is possible to have:

domainA.com._report._dmarc.domainC.com
and
domainB.com._report._dmarc.domainC.com

but is is also possible to use the wildcard construct:

*._report._dmarc.domainC.com

But domainA.com and domainB.com are not child domains of domainC.com.

This makes me wonder: is the DMARC spec at dmarc.org the one that will 
need to be reviewed, or will a new version be presented (during Last 
Call?). And are comments like Franck's and mine already welcome, or do 
we have to wait until a new version will be released for an official 
round of review?

/rolf

--------------030508040101090307040805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 09/25/2013 11:44 PM, Franck Martin
      wrote:

    

    

      

        
Section 7.1  Verifying External Destinations

          


          

          3rd paragraph from the end of the section.

          


          

          "The Domain Owner confirming via the DNS that it wishes to
          receive

           reports can use a wildcard DNS record to confirm that it is
          willing

           to receive reports for any domain.  For example, a TXT
          resource

           record at "*._report._dmarc.example.com" containing at least

           "v=DMARC1" confirms that example.com is willing to receive
          DMARC

           reports for any child domain."

        


        

        
Should be

        

        


        

        
"The report receiver confirming via the DNS that it wishes
          to receive

           reports can use a wildcard DNS record to confirm that it is
          willing

           to receive reports for any domain.  For example, a TXT
          resource

           record at "*._report._dmarc.example.com" containing at least

           "v=DMARC1" confirms that example.com is willing to receive
          DMARC

           reports for any domain."

      

    

    

    Report receivers and domain owners are two different functions. And
    although both functions can be assigned to a single person, in
    general one cannot say (imho) that a report receiver is able to do
    something (confirm willingness to receive reports) in DNS.

    

    What about:

    

    "The Domain Owner of the domain of a Report Receiver who is willing
    

    to receive reports for any domain, can use a wildcard DNS record.
    For 

    example, a TXT resource record at "*._report._dmarc.example.com" 

    containing at least "v=DMARC1" confirms that example.com is willing
    

    to receive DMARC reports for any child domain."

    

    And BTW: I do believe that 'child domain' here is not correct
    terminology: the wildcard indicates any domain on the Internet,
    which can have "rua" or "ruf" tags that points to this domain.

    

    Example: domainA.com has rua tag that points to a receiver in
    domainC.com and domainB.com has also a rua tag that points to a
    receiver in domainC.com. Then it is possible to have:

    

    domainA.com._report._dmarc.domainC.com

    and

    domainB.com._report._dmarc.domainC.com

    

    but is is also possible to use the wildcard construct:

    

    *._report._dmarc.domainC.com

    

    But domainA.com and domainB.com are not child domains of
    domainC.com.

    

    This makes me wonder: is the DMARC spec at dmarc.org the one that
    will need to be reviewed, or will a new version be presented (during
    Last Call?). And are comments like Franck's and mine already
    welcome, or do we have to wait until a new version will be released
    for an official round of review?

    

    /rolf

  


--------------030508040101090307040805--

From matt@tnpi.net  Wed Sep 25 16:31:11 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27CA11E8111 for ; Wed, 25 Sep 2013 16:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2E0MYz8tW47 for ; Wed, 25 Sep 2013 16:31:07 -0700 (PDT)
Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDB311E80E0 for ; Wed, 25 Sep 2013 16:31:05 -0700 (PDT)
Received: (qmail 18089 invoked by uid 1026); 25 Sep 2013 23:31:03 -0000
Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.141]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Wed, 25 Sep 2013 19:31:03 -0400
Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass
X-Virus-Checked: by ClamAV 0.97.8 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:cc:content-transfer-encoding:message-id:references:to; s=mar2013; bh=3HVbFJEHgeUWUAwZQTjnZp0p/bEIbPL89o/FGNC4iYI=; b=vBUXgnM3f99YtWf9AMbbNkReemuWcb7+PmJ63UI49JJT1myRuu5OVK+BvFtd+YH16wzBFhmYDa7Xe0SYZensp7IE7jaUA2+hAlPWj031wo3fKOovEKvXZ6AdWoET4rLqPAVsbeOG2wYG00x0kjYZKQDfNEhkpYGYSdF1BIip1emLnQU/GX6HSz54v85iSsI9w1FNwsfxHQIGOSWO1TXaL9QqYwAT9nIbgaz3hie7TZ5NZq6sLEBMtowkiRkW/WKQ4vtodYQ4womTDwnzNnploDKuPXlklgTqDN7jKVzOz9HAWRFmsXX/FUUTXLNOvoU08gRpMLVnt1w3+Yu+ZhPxAg==
X-HELO: [10.0.1.141]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Matt Simerson 
In-Reply-To: <5243620F.9010500@sonnection.nl>
Date: Wed, 25 Sep 2013 16:31:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <507BB779-6542-4ED1-BE2D-95E332EC12CE@tnpi.net>
References: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org> <5243620F.9010500@sonnection.nl>
To: R.E.Sonneveld@sonnection.nl
X-Mailer: Apple Mail (2.1510)
Cc: dmarc@ietf.org, Franck Martin 
Subject: Re: [dmarc-ietf] text correction on DMARC spec re reporting DNS record
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 23:31:11 -0000

On Sep 25, 2013, at 3:22 PM, "Rolf E. Sonneveld" =
 wrote:

> On 09/25/2013 11:44 PM, Franck Martin wrote:
>> Section 7.1  Verifying External Destinations
>>=20
>> 3rd paragraph from the end of the section.
>>=20
>> "The Domain Owner confirming via the DNS that it wishes to receive
>>  reports can use a wildcard DNS record to confirm that it is willing
>>  to receive reports for any domain.  For example, a TXT resource
>>  record at "*._report._dmarc.example.com" containing at least
>>  "v=3DDMARC1" confirms that example.com is willing to receive DMARC
>>  reports for any child domain."
>>=20
>> Should be
>>=20
>> "The report receiver confirming via the DNS that it wishes to receive
>>  reports can use a wildcard DNS record to confirm that it is willing
>>  to receive reports for any domain.  For example, a TXT resource
>>  record at "*._report._dmarc.example.com" containing at least
>>  "v=3DDMARC1" confirms that example.com is willing to receive DMARC
>>  reports for any domain."
>=20
> Report receivers and domain owners are two different functions. And =
although both functions can be assigned to a single person, in general =
one cannot say (imho) that a report receiver is able to do something =
(confirm willingness to receive reports) in DNS.

-1

> What about:
>=20
> "The Domain Owner of the domain of a Report Receiver who is willing=20
> to receive reports for any domain, can use a wildcard DNS record. For=20=

> example, a TXT resource record at "*._report._dmarc.example.com"=20
> containing at least "v=3DDMARC1" confirms that example.com is willing=20=

> to receive DMARC reports for any child domain."
>=20
> And BTW: I do believe that 'child domain' here is not correct =
terminology: the wildcard indicates any domain on the Internet, which =
can have "rua" or "ruf" tags that points to this domain.

+1

Agreed, the term 'child domain' is misleading to the point of being =
factually wrong. The asterisk will match any domain name, including a =
parent or even a tld.

Matt=

From roland@rolandturner.com  Wed Sep 25 18:39:49 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BBC11E80E6 for ; Wed, 25 Sep 2013 18:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=1.297,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDpN4XW0e4-3 for ; Wed, 25 Sep 2013 18:39:45 -0700 (PDT)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 095C611E80FB for ; Wed, 25 Sep 2013 18:39:42 -0700 (PDT)
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=Kbc2b8w/2joeqg6/JBCT+KvhUGECHQ8rLuw4gfGm1co=;  b=Vnr6zdy74J/t7Ldk1jAWLn2FPW4CyuMqI7rpLh5Atxe6WQYwq048I2yfWvU4iOHGzJnVq8mqu2hbCm61zIBZ7ksyOaGOTajjzJ74d1vvYs6tYfUjK75IHE9VBsdF1TVCXSFDua0VEp6FrnR5UCxWKSQE1jyaLaJWc7HVothlp1g=;
Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133
Received: from [116.12.149.133] (port=54233 helo=[10.100.1.108]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VP0YH-0005lU-Ap; Thu, 26 Sep 2013 01:39:35 +0000
Message-ID: <52439054.3040005@rolandturner.com>
Date: Thu, 26 Sep 2013 09:39:32 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Matt Simerson , R.E.Sonneveld@sonnection.nl
References: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org>	<5243620F.9010500@sonnection.nl> <507BB779-6542-4ED1-BE2D-95E332EC12CE@tnpi.net>
In-Reply-To: <507BB779-6542-4ED1-BE2D-95E332EC12CE@tnpi.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dmarc@ietf.org, Franck Martin 
Subject: Re: [dmarc-ietf] text correction on DMARC spec re reporting DNS record
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 01:39:50 -0000

On 09/26/2013 07:31 AM, Matt Simerson wrote:

> On Sep 25, 2013, at 3:22 PM, "Rolf E. Sonneveld"  wrote:
>
>> On 09/25/2013 11:44 PM, Franck Martin wrote:
>>> Section 7.1  Verifying External Destinations
>>>
>>> 3rd paragraph from the end of the section.
>>>
>>> "The Domain Owner confirming via the DNS that it wishes to receive
>>>   reports can use a wildcard DNS record to confirm that it is willing
>>>   to receive reports for any domain.  For example, a TXT resource
>>>   record at "*._report._dmarc.example.com" containing at least
>>>   "v=DMARC1" confirms that example.com is willing to receive DMARC
>>>   reports for any child domain."
>>>
>>> Should be
>>>
>>> "The report receiver confirming via the DNS that it wishes to receive
>>>   reports can use a wildcard DNS record to confirm that it is willing
>>>   to receive reports for any domain.  For example, a TXT resource
>>>   record at "*._report._dmarc.example.com" containing at least
>>>   "v=DMARC1" confirms that example.com is willing to receive DMARC
>>>   reports for any domain."
>> Report receivers and domain owners are two different functions. And although both functions can be assigned to a single person, in general one cannot say (imho) that a report receiver is able to do something (confirm willingness to receive reports) in DNS.

Rolf, are you suggesting that the [already deployed, working] mechanism 
described in 7.1 whereby a putative report receiver can purportedly do 
that exact thing (confirm willingness to receive, via DNS) is 
unworkable? Something else?

>
>> And BTW: I do believe that 'child domain' here is not correct terminology: the wildcard indicates any domain on the Internet, which can have "rua" or "ruf" tags that points to this domain.
> +1
>
> Agreed, the term 'child domain' is misleading to the point of being factually wrong. The asterisk will match any domain name, including a parent or even a tld.

Agreed, it looks as though the wildcard and "specific child" cases have 
been merged incorrectly.

- Roland

From R.E.Sonneveld@sonnection.nl  Thu Sep 26 01:15:45 2013
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D758821E8089 for ; Thu, 26 Sep 2013 01:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.826
X-Spam-Level: 
X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.773,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoQ6FfAHc+eK for ; Thu, 26 Sep 2013 01:15:39 -0700 (PDT)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id E887621F9371 for ; Thu, 26 Sep 2013 01:15:37 -0700 (PDT)
Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3clpq91fDNz1L8fM; Thu, 26 Sep 2013 10:15:33 +0200 (CEST)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3clpq907Kkz5Mhcg; Thu, 26 Sep 2013 10:15:33 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id BC6F2123135; Thu, 26 Sep 2013 10:15:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3CC4wOk6vWAu; Thu, 26 Sep 2013 10:15:25 +0200 (CEST)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 2B2F71230FC; Thu, 26 Sep 2013 10:15:25 +0200 (CEST)
Message-ID: <5243ED1C.8040207@sonnection.nl>
Date: Thu, 26 Sep 2013 10:15:24 +0200
From: "Rolf E. Sonneveld" 
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Roland Turner 
References: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org>	<5243620F.9010500@sonnection.nl> <507BB779-6542-4ED1-BE2D-95E332EC12CE@tnpi.net> <52439054.3040005@rolandturner.com>
In-Reply-To: <52439054.3040005@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=1380183333; bh=jbiRMaifSfZ6wFbGkY7/+WOF744Yh3FVldfA9gWS14A=; h=Message-ID:Date:From:To:Subject:From; b=TcSAIjNwfYlYd2GCS+L99TB9iQNklA5zb7tABi4S/0iglE80KgrT+Z5IXYLNtPUpD 0pJjQQuyttqhQIrw02nIXsCzFPQ1Bht05sPRp8m4WfWUHoR5/GVmGXDE9UdDKLLRYg ntTOArJQoJtdD04QgbpZkQDAVr9EyvExObS5Is80=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3clpq91fDNz1L8fM
Cc: dmarc@ietf.org, Matt Simerson , Franck Martin 
Subject: Re: [dmarc-ietf] text correction on DMARC spec re reporting DNS record
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: R.E.Sonneveld@sonnection.nl
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 08:15:45 -0000

Hi, Roland,

On 09/26/2013 03:39 AM, Roland Turner wrote:
> On 09/26/2013 07:31 AM, Matt Simerson wrote:
>
>> On Sep 25, 2013, at 3:22 PM, "Rolf E. Sonneveld" 
>>  wrote:
>>
>>> On 09/25/2013 11:44 PM, Franck Martin wrote:
>>>> Section 7.1  Verifying External Destinations
>>>>
>>>> 3rd paragraph from the end of the section.
>>>>
>>>> "The Domain Owner confirming via the DNS that it wishes to receive
>>>>   reports can use a wildcard DNS record to confirm that it is willing
>>>>   to receive reports for any domain.  For example, a TXT resource
>>>>   record at "*._report._dmarc.example.com" containing at least
>>>>   "v=DMARC1" confirms that example.com is willing to receive DMARC
>>>>   reports for any child domain."
>>>>
>>>> Should be
>>>>
>>>> "The report receiver confirming via the DNS that it wishes to receive
>>>>   reports can use a wildcard DNS record to confirm that it is willing
>>>>   to receive reports for any domain.  For example, a TXT resource
>>>>   record at "*._report._dmarc.example.com" containing at least
>>>>   "v=DMARC1" confirms that example.com is willing to receive DMARC
>>>>   reports for any domain."
>>> Report receivers and domain owners are two different functions. And 
>>> although both functions can be assigned to a single person, in 
>>> general one cannot say (imho) that a report receiver is able to do 
>>> something (confirm willingness to receive reports) in DNS.
>
> Rolf, are you suggesting that the [already deployed, working] 
> mechanism described in 7.1 whereby a putative report receiver can 
> purportedly do that exact thing (confirm willingness to receive, via 
> DNS) is unworkable? 

No.

> Something else?

The text I proposed is in the category 'minor improvements'. As "[...] 
The mission of the IETF is to produce high quality, relevant technical 
and engineering documents [...]" (RFC3935, BCP95) the proposed text is 
an attempt to differentiate between the various roles that exists in any 
medium to large organization.

All in all, when trying to come up with some text I realized that it 
would help when some 'domain' definitions would be added to the DMARC 
spec, to address the various sorts of domains there are in the context 
of DMARC. I'd suggest to move the currently present Domain definitions 
from the intro of chapter 3 to a separate paragraph ("3.1 Domain 
Definitions", for example) and add definitions for:

- Author Domain
- Submission Domain (see RFC5598, par 4.1.4, discussion on RFC5321.MailFrom)
- Receiver Domain
- Report Receiver Domain

and then use these names/definitions throughout the document.

I'd be happy to come up with some text, but maybe it's better to wait 
for the formal review phase?

/rolf