From nobody Mon Apr 1 00:03:43 2019 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 13D94120046 for ; Mon, 1 Apr 2019 00:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECAF8sHdf_xZ for ; Mon, 1 Apr 2019 00:03:37 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100093.outbound.protection.outlook.com [40.107.10.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5C212003F for ; Mon, 1 Apr 2019 00:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VVAnl45hLuOMExW6WsyQx1yIPHVWkHhfRGFHzZhi6Sc=; b=o8TEhMBMjdGZ4XDuMHg/KZvSPGbrE65ZaFXk/svdaTOhXECjZl7wxj+TmXR1pnVEzHT3RcWOen0UtfHeeZjOqoCARbkKlplzI0+4T33MaUESeZrOxL+Vgq2tX/wShkOlWxi0KJgUp+BgD/orfXy7lpNqv3tSNgLll7zJzPK8tgc= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2239.GBRP123.PROD.OUTLOOK.COM (20.176.155.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Mon, 1 Apr 2019 07:03:34 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::41ac:f60c:6d07:7769]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::41ac:f60c:6d07:7769%6]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 07:03:34 +0000 From: Ian Levy To: "fosterd@bayviewphysicians.com" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Rolling out the experiment Thread-Index: AQHU6AXGp1msw+YGWU2SSBu312qmTKYm35Kg Date: Mon, 1 Apr 2019 07:03:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.141.34.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f72631d3-4543-4c48-b80e-08d6b67027f0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:LO2P123MB2239; x-ms-traffictypediagnostic: LO2P123MB2239: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39840400004)(136003)(366004)(376002)(189003)(199004)(71190400001)(8676002)(14444005)(81156014)(71200400001)(446003)(66066001)(256004)(6116002)(9686003)(476003)(790700001)(6246003)(102836004)(3846002)(2906002)(76176011)(33656002)(44832011)(11346002)(6436002)(26005)(229853002)(478600001)(486006)(2501003)(7696005)(6306002)(236005)(25786009)(99286004)(55236004)(53546011)(6506007)(55016002)(53936002)(86362001)(74482002)(54896002)(105586002)(5660300002)(52536014)(68736007)(966005)(97736004)(110136005)(106356001)(75922002)(74316002)(7736002)(316002)(14454004)(8936002)(81166006)(66574012)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2239; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hUQeuz9Fl8EbE1KWyyaWkb1POg6GuT4kcMpVFJyw05olF5D6ZF6EZTe7uRNJJsPKx347Q89WjOomv/Gb5JOwYa1hR1WCi1DaUMoWO6pGCreI3TSNuU5C4WsiP4iAMxhzTLXKnBj4lYPfcPnJxuItAOw4YfxR7XYduzHY7tOM5asxn6xySZdrSQNDQsw4JbLqBntgMoU/BiEv9EUBu4C1ji/oI3nKLzNioMrrjU+psL/IhVkSikqQYl9lRG1x6KKAdS0uAx0cBu5Dn1F6XozyhukhHu4Z4+atSLyBStB/azQVNikdy7Wg0ZQK+E2PAszmO7g2kuTie0TK+0nYCjIT0q1nhqx1BCq/w8/4uDmjiiZ8/pIHbVPisOTgvKMcrDfqbP3fozVK4yvwfjQZry3iaHdoaA4YlODWrZvnUCB6SQg= Content-Type: multipart/alternative; boundary="_000_LO2P123MB228545562601B6B06D230B8CC9550LO2P123MB2285GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: f72631d3-4543-4c48-b80e-08d6b67027f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 07:03:34.0862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2239 Archived-At: Subject: Re: [dmarc-ietf] Rolling out the experiment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 01 Apr 2019 07:03:41 -0000 --_000_LO2P123MB228545562601B6B06D230B8CC9550LO2P123MB2285GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * SPF and ASDP polices can still be published for non-existent domains Sure, but I can't predict what non-existent subdomains criminals are going = to use next. Should I publish a set of TXT records for dougfoster.gov.uk un= iquely? Given we've no way of predicting that, we're responding to any quer= y for TXT records for any undelegated gov.uk subdomain with an SPF and DMA= RC record. Regardless of how we intend to detect non-existent subdomains (f= or some value of non-existent), we'll need to stop responding with those de= fault records on gov.uk to do something approaching real world testing of P= SD-DMARC. Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk (I work stupid hours and weird times - that doesn't mean you have to. If th= is arrives outside your normal working hours, don't feel compelled to respo= nd immediately!) From: dmarc On Behalf Of Douglas E. Foster Sent: 31 March 2019 22:07 To: dmarc@ietf.org Subject: [dmarc-ietf] Rolling out the experiment Based on my reading of your draft, the testing process for non-existent dom= ains is as follows: 1. Any DMARC policies for non-existent domains must be removed, so that = the recipient system can look upward to the PSD DMARC. 2. SPF and ASDP polices can still be published for non-existent domains,= because a domain is non-existent only when it lacks A, AAAA, and MX record= s. SPF and ADSP are TXT records, so they do not affect the evaluation. Wh= at I do not understand is how a device determines that a particular domain = has no A, AAAA, or MX records. 3. Assuming that #2 iis valid, the test can proceed with no loss of curr= ent protections. SPF and ADSP policies can be used to block a fraudulent m= essage from a non-existent domain. The behavior varies by device capabili= ty. * A non-DMARC device would stop after blocking the message because o= f SPF or ADSP policy violation. * An organization-DMARC device would look for a DMARC policy and fai= l, so no feedback would be sent. It would still block the message based on= SPF and DMARC policy violations. * A PSD-DMARC device could block the message by either of two method= s: * It detects the domain as non-existent, and looks immediately fo= r a PSD-DMARC policy. * It blocks the message based on SPF or DMARC, then looks for fee= dback instructions, following the tree upward until it finds a PSD DMARC po= licy with feedback instructions. SPF is widely deployed, so dropping SPF policies will affect recipients not= participating in the test. That is why I am alarmed.. I do not understand why that should be necessary, but I suppose that the an= swer hangs on the mechanism for detecting non-existent domains in a manner = compliant with section 2.6 Doug Foster ________________________________ From: "Ian Levy" Sent: Sunday, March 31, 2019 3:07 PM To: "fosterd@bayviewphysicians.com" , "Scott= Kitterman" , "IETF DMARC WG" , "Ian L= evy" Subject: Re: [dmarc-ietf] Working group next steps The existing defences aren't 100% even before the evil kludge we've put up = for non existent subdomains, which certainly is not working everywhere. The= PSD draft, when implemented, will help scale existing defences to make evo= lution of criminal behaviour harder and do it in a standardised way so that= it's more likely to be consistently implemented. That's worth us collecti= vely doing some work and me taking some risk to help early testing. Nothing is 100% in security. Except possibly the existence of a preponderan= ce of marketing hype :-). Ta. I. - Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk (I work stupid hours and weird times - that doesn't mean you have to. If th= is arrives outside your normal working hours, don't feel compelled to respo= nd immediately!) ________________________________ From: dmarc on behalf of Douglas E. Foster Sent: Sunday, March 31, 2019 7:31 pm To: Scott Kitterman; IETF DMARC WG; Ian Levy Subject: Re: [dmarc-ietf] Working group next steps Certainly not. You cannot drop existing defenses until the new standard is 100% deployed o= n the Internet, which means probably never. Your experimental implementa= tion will need to prioritize the new test over the SPF test, to prove that = it is working and to show that it is good at intercepting any subdomains th= at have been newly imagined by the attackers To speed up the deployment process for existing or new standards, IETF woul= d meed to embrace the idea of defining required features of a spam filter. Doug Fosterd ________________________________ From: "Ian Levy" Sent: Sunday, March 31, 2019 6:18 AM To: "Scott Kitterman" , "IETF DMARC WG" Subject: Re: [dmarc-ietf] Working group next steps >> I'll also offer gov.uk as an experimental ground (within reason!). > Excellent. I've listed it in the experimental registry at psddmarc.org... > Since you already had a live DMARC record for that domain, people can exp= eriment with this now. I guess at some point we'll have to stop generating SPF and DMARC records f= or the non-existent subdomains of gov.uk so we can test the new stuff prope= rly. When we're at that point, let me know. Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk (I work stupid hours and weird times - that doesn't mean you have to. If th= is arrives outside your normal working hours, don't feel compelled to respo= nd immediately!) This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LO2P123MB228545562601B6B06D230B8CC9550LO2P123MB2285GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
  • SPF and ASDP polices can still be published for non-existent domains

&nbs= p;

Sure, but= I can’t predict what non-existent subdomains criminals are going to = use next. Should I publish a set of TXT records for dougfoster.gov.uk uniqu= ely? Given we’ve no way of predicting that, we’re responding to any query for TXT records  for any undelega= ted gov.uk subdomain with an SPF and DMARC record. Regardless of how we int= end to detect non-existent subdomains (for some value of non-existent), we&= #8217;ll need to stop responding with those default records on gov.uk to do something approaching real world testing of PSD-DM= ARC.

&nbs= p;

Ta.<= /o:p>


I.

&nbs= p;

--

Dr Ian Levy

Technical Director

National Cyber Security Centre

ian@ncsc.gov.uk

 

Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk

 

(I work stupid hours and weird times – that do= esn’t mean you have to. If this arrives outside your normal working h= ours, don’t feel compelled to respond immediately!)

&nbs= p;

From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Douglas E. Foster
Sent: 31 March 2019 22:07
To: dmarc@ietf.org
Subject: [dmarc-ietf] Rolling out the experiment

 

Based on my reading of your draft, the testing process= for non-existent domains is as follows:

  1. An= y DMARC policies for non-existent domains must be removed, so that the reci= pient system can look upward to the PSD DMARC.
  2. SP= F and ASDP polices can still be published for non-existent domains, because= a domain is non-existent only when it lacks A, AAAA, and MX records.&= nbsp; SPF and ADSP are TXT records, so they do not affect the evaluation.  What I do not understand is how a device determines = that a particular domain has no A, AAAA, or MX records.
  3. As= suming that #2 iis valid, the test can proceed with no loss of current prot= ections.  SPF and ADSP policies can be used to block a fraudulent= message from a non-existent domain.   The behavior varies by device capability.   
    • A&= nbsp;non-DMARC device would stop after blocking the message because of SPF = or ADSP policy violation.  
    • An= organization-DMARC device would look for a DMARC policy and fail, so no fe= edback would be sent.  It would still block the message based on SPF a= nd DMARC policy violations.   
    • A = PSD-DMARC device could block the message by either of two methods:
      • It= detects the domain as non-existent, and looks immediately for a PSD-DMARC = policy.
      • It= blocks the message based on SPF or DMARC, then looks for feedback instruct= ions, following the tree upward until it finds a PSD DMARC policy with feed= back instructions.

SPF is widely deployed, so dropping SPF policies will = affect recipients not participating in the test.    That is = why I am alarmed..

 

I do not understand why that should be necessary, but = I suppose that the answer hangs on the mechanism for detecting non-exi= stent domains in a manner compliant with section 2.6 

 

Doug Foster

 

 

 

 

From: "Ian Levy" <ian.lev= y@ncsc.gov.uk>
Sent: Sunday, March 31, 2019 3:07 PM
To: "fosterd@bayviewphysicians.com" <fosterd@bayviewphy= sicians.com>, "ScottKitterman" <sklist@kitterman.com>, &= quot;IETF DMARC WG" <dmarc@ietf.org>, "Ian Levy" <i= an.levy=3D40ncsc.gov.uk@dmarc.ietf.org>
Subject: Re: [dmarc-ietf] Working group next steps

 

The existing defences aren’t 100% even before th= e evil kludge we’ve put up for non existent subdomains, which certain= ly is not working everywhere. The PSD draft, when implemented, will help scale existing defences to make evolution of criminal behaviour = harder and do it in a standardised way so that it’s more likely to be= consistently implemented.  That’s worth us collectively doing s= ome work and me taking some risk to help early testing. 

 

Nothing is 100% in security. Except possibly the exist= ence of a preponderance of marketing hype :-). 

 

Ta. 

 

I. 

 

—

Dr Ian Levy

Technical Director

National Cyber Security Centre

ian@ncsc.gov.uk

 

(I work stupid hours and weird times – that does= n’t mean you have to. If this arrives outside your normal working hou= rs, don’t feel compelled to respond immediately!)

From: dmarc <dmarc-bounces@ietf.org> on behalf of D= ouglas E. Foster <fosterd@bayviewphysicians.com>
Sent: Sunday, March 31, 2019 7:31 pm
To: Scott Kitterman; IETF DMARC WG; Ian Levy
Subject: Re: [dmarc-ietf] Working group next steps <= /span>

 

Certainly not.   

 

You cannot drop existing defenses until the new standa= rd is 100% deployed on the Internet, which means probably never.  &nbs= p; Your experimental implementation will need to prioritize the new test over the SPF test, to prove that it is working and to show th= at it is good at intercepting any subdomains that have been newly imag= ined by the attackers

 

To speed up the deployment process for existing or new= standards, IETF would meed to embrace the idea of defining required f= eatures of a spam filter.

 

Doug Fosterd

 

From: "Ian Levy" <ian.lev= y=3D40ncsc.gov.uk@dmarc.ietf.org>
Sent: Sunday, March 31, 2019 6:18 AM
To: "Scott Kitterman" <sklist@kitterman.com>, "= IETF DMARC WG" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Working group next steps

 

>> I’ll also offer gov.uk as an experiment= al ground (within reason!).

> Excellent. I've listed it in the experimental registry at psddmarc.org= ...
> Since you already had a live DMARC record for that domain, people can = experiment with this now.

I guess at some point we'll have to stop generating SPF and DMARC records f= or the non-existent subdomains of gov.uk so we can test the new stuff prope= rly. When we're at that point, let me know.

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
ian@ncsc.gov.uk

Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk

(I work stupid hours and weird times – that doesn’t mean you ha= ve to. If this arrives outside your normal working hours, don’t feel = compelled to respond immediately!)


This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 

This information is exempt under the Freedom of Inform= ation Act 2000 (FOIA) and may be exempt under other UK information legislat= ion. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LO2P123MB228545562601B6B06D230B8CC9550LO2P123MB2285GBRP_-- From nobody Tue Apr 2 17:37:05 2019 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 166F61203B8 for ; Tue, 2 Apr 2019 17:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUge5wLYTiD7 for ; Tue, 2 Apr 2019 17:37:01 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B221203C4 for ; Tue, 2 Apr 2019 17:36:55 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x330ccLA007954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Apr 2019 17:38:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554251918; bh=LlFWYSTOoU6h7Cp+Z39QZGQ2JeVpx/0/aA1plPDZeWQ=; h=Subject:References:To:Reply-To:From:Date:In-Reply-To:From; b=HJ/5keTDrfrGAJe0Wy0YxEQVDNe7atCs1/5q0PQewXSRaNInDur5ibqAiamIeyOYH TqYOTsejReIY5sPTOV/Yyw80Bdgi0CDopGwlZbUcs5Uk3IOk2z/KuZ8mHwvt3DeIau FBS1j1miVNqjfZZZ5HCYK4GR7BvrAHvWBiRe8rEE= References: <155425099487.6400.1606471852874664183.idtracker@ietfa.amsl.com> To: IETF DMARC WG Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking X-Forwarded-Message-Id: <155425099487.6400.1606471852874664183.idtracker@ietfa.amsl.com> Message-ID: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> Date: Tue, 2 Apr 2019 17:36:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155425099487.6400.1606471852874664183.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 00:37:03 -0000 Hi. Just posted this... (I'm separately sending this to the dbound list, but figure cross-posting isn't productive.) Comments eagerly sought, of course. d/ -------- Forwarded Message -------- Subject: New Version Notification for draft-dcrocker-dns-perimeter-00.txt Date: Tue, 02 Apr 2019 17:23:14 -0700 From: internet-drafts@ietf.org To: T. Adams , D. Crocker , Dave Crocker A new version of I-D, draft-dcrocker-dns-perimeter-00.txt has been successfully submitted by D. Crocker and posted to the IETF repository. Name: draft-dcrocker-dns-perimeter Revision: 00 Title: DNS Perimeter Overlay Document date: 2019-04-02 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt Status: https://datatracker.ietf.org/doc/draft-dcrocker-dns-perimeter/ Htmlized: https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-dcrocker-dns-perimeter Abstract: The Domain Name System (DNS) naming syntax provides no meta-data for indicating administrative transitions through the hierarchy. For example, it does not distinguish the higher-level portions that operate as public registries, versus those that operate as private organizations. This specification creates a basic overlay mechanism for defining a logical Perimeter between administrative entities through the naming hierarchy. The mechanism can then be applied for a variety of independent administrative indications. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 02:32:50 2019 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 9F3F41200B9 for ; Wed, 3 Apr 2019 02:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6domxxhQV1GR for ; Wed, 3 Apr 2019 02:32:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCE61200B2 for ; Wed, 3 Apr 2019 02:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1554283965; bh=j1q83oLZgazZN27kYaD005UnTkb4J5SIzC1gyK/7Y58=; l=1855; h=To:References:From:Date:In-Reply-To; b=AxIgzovxo6naWwO3RlgIIEdTB3kdLlsSyTtciL4Q4EyVGWNZaS54iG/kn/ejSIPdA hB9F8EJXoX5fnGIB9Y5ZfFeSOerX4BVESYMITnpbpxqffKDSVBFMC+GyHkjICC0uQh z1m/Z+6sa2v3wOdZTAUBMGxYS1UXw3idp3uVK7ZKJK64Uytpe7OOYOqurbICx Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 03 Apr 2019 11:32:45 +0200 id 00000000005DC00B.000000005CA47DBD.0000795C To: Ian Levy , "fosterd@bayviewphysicians.com" , "dmarc@ietf.org" References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <066854c5-2649-d852-ff21-eb65bb83fd52@tana.it> Date: Wed, 3 Apr 2019 11:32:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Rolling out the experiment X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 09:32:49 -0000 On Mon 01/Apr/2019 09:03:34 +0200 Ian Levy wrote: > * SPF and ASDP polices can still be published for non-existent domains > > Sure, but I can’t predict what non-existent subdomains criminals are going to > use next. Should I publish a set of TXT records for dougfoster.gov.uk uniquely? > Given we’ve no way of predicting that, we’re responding to any query for TXT > records  for any undelegated gov.uk subdomain with an SPF and DMARC record. > Regardless of how we intend to detect non-existent subdomains (for some value > of non-existent), we’ll need to stop responding with those default records on > gov.uk to do something approaching real world testing of PSD-DMARC. This argument is utterly confusing to me. When I read Scott's draft, I understood he was talking about _existing_ domains. Indeed, that sounded somewhat strange, since the higher level domain's owner should have a say on the policies that subdomains have to follow, but IANAL. DMARC had reject-on-nxdomain, but then reduced it to appendix A.4. ADSP (historic) left it to undefined. Yet, it's the only (deprecated) auth-method having a "nxdomain" code. If we are seeking a spec that enables parent domains to specify reject-on-nxdomain for their subdomains, it doesn't seem to be necessarily related to DMARC. (I mean DMARC as a spec, not the dmarc WG.) ale@pcale:~/tmp$ dig +short dougfoster.gov.uk txt "v=DMARC1;p=reject;rua=mailto:govuk-rua@dmarc.service.gov.uk" "v=spf1 ?all" I agree that's an evil kludge. (Why ?all?) Dave just posted a draft about DNS perimeter, which might possibly evolve so as to allow only the _dmarc label to return the above record (can it?), while dougfoster.gov.uk perhaps returns the spf1 stuff. It is still overly complicated w.r.t. such a simple task as reject-on-nxdomain. Best Ale -- From nobody Wed Apr 3 10:58:33 2019 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 8054012010C for ; Wed, 3 Apr 2019 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=6MQBOjhJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=DXbCf9Yl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5gVduw7jAhE for ; Wed, 3 Apr 2019 10:58:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32E2120153 for ; Wed, 3 Apr 2019 10:58:21 -0700 (PDT) Received: (qmail 91600 invoked from network); 3 Apr 2019 17:58:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=165cd.5ca4f43c.k1904; bh=CJ5DceGTkrg3/JuZKhQOIl8xArSYrf8l3zcWIfW1OWM=; b=6MQBOjhJBhCgMTAMcrytb4BEpaCcN3aNytxAKOAa3X2CH4VmLKs9vl5uT1rs1SW8IzZUyo0NGAc/3ecRFtUSaboMOT9F2eQTjPRmsnDc+fQ/uBV/+QsrWM99r8OadP37iJtnPfzWCiWIvBOTqSmdtOWl8a+Bp21xN/7EfeaEPObjL0jXEW1msbeUPevHjJegOFi9+ERO1DqtLNcSqgar0Fni+O+3kfg5Gkz15Wj7tAuDZRjf+o0Dwb/nIhO8Gb8f DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=165cd.5ca4f43c.k1904; bh=CJ5DceGTkrg3/JuZKhQOIl8xArSYrf8l3zcWIfW1OWM=; b=DXbCf9YlnSlRZxE3SV+YLhhNt+1xXVZ2kC3k/A1fSlhT9b9vTuvnyXqaay4K9D+nWq9Ngj+kefOehlnGmrPH81iD8Nrs4/hnzciDbCsLj/mpymplsc+xI3ElUzTNrofuGvzPXIQOiJ/7ASDCASGJqiBLLMkrEHRFp1iN6td0Yjf57JhZCS5ani1HF6FMu9mgf5UygaEes98Tgdh8RBpZyKcrq06z+S5AOap2nmjZVASo0r/2VRM0OTRD0qld92L9 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2019 17:58:20 -0000 Received: by ary.qy (Postfix, from userid 501) id 8391420115F376; Wed, 3 Apr 2019 13:58:19 -0400 (EDT) Date: 3 Apr 2019 13:58:19 -0400 Message-Id: <20190403175820.8391420115F376@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net, dbound@ietf.org In-Reply-To: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 17:58:25 -0000 In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: >Comments eagerly sought, of course. This seems sorta kinda like my dbound draft, only with _tagged TXT records rather than a new rrtype, and (unless I missed something) a hope that somehow you can use a yet to be invented cache to avoid walking up the tree, where mine used wildcards to do one lookup per boundary regardless of the tree depth. I can see that the tradeoffs are different but I don't see why they're better. R's, John >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt >has been successfully submitted by D. Crocker and posted to the >IETF repository. > >Name: draft-dcrocker-dns-perimeter >Revision: 00 >Title: DNS Perimeter Overlay >Document date: 2019-04-02 >Group: Individual Submission >Pages: 20 >URL: >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt From nobody Wed Apr 3 11:23:01 2019 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 D670C120123; Wed, 3 Apr 2019 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu1SfZN4tquC; Wed, 3 Apr 2019 11:22:58 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CBA12010C; Wed, 3 Apr 2019 11:22:58 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33IOf5L001971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 11:24:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554315882; bh=BkahvQtoi62nxdS+sC5YrM1Z3uYJVGP9lhzIYvO2PKU=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=Ml8IIRWXhhN5SPG0lTEf9kyvIzNgbLv5KZxxhyBlYGzchb5mrzZTQusZfOVJ6yVux eVeOVgJ6jusheFlqhvgF9jhORMRfKjIgfBQ6Sh3T+n9eKznDuzJXlgC/ppYWYIwroR an5bFMZTDzi4pkWGtIOLgfh0DHaaYnhpYhRPwKwg= To: John Levine , dmarc@ietf.org Cc: dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> Date: Wed, 3 Apr 2019 11:22:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190403175820.8391420115F376@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 18:23:00 -0000 On 4/3/2019 10:58 AM, John Levine wrote: > In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: >> Comments eagerly sought, of course. > > This seems sorta kinda like my dbound draft, only with _tagged TXT > records rather than a new rrtype, and (unless I missed something) a > hope that somehow you can use a yet to be invented cache to avoid > walking up the tree, where mine used wildcards to do one lookup per > boundary regardless of the tree depth. Section 7's suggestion for using Additional information does not rely on caching. Reliance on existing wildcard depends on propagation of a new RR, which continues to be problematic. There's a reason the Attrleaf table has so many entries... And while there is certainly conceptual overlap with your earlier proposal, the current one has differences I'd class as significant. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 11:45:09 2019 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 68B09120165 for ; Wed, 3 Apr 2019 11:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nVmUezbn; dkim=pass (1536-bit key) header.d=taugh.com header.b=mkR/I07n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unq2NDyOM_ec for ; Wed, 3 Apr 2019 11:45:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10512120163 for ; Wed, 3 Apr 2019 11:45:03 -0700 (PDT) Received: (qmail 4640 invoked from network); 3 Apr 2019 18:45:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=121e.5ca4ff2e.k1904; bh=RiWjXqdi02tRtFWsHlf5LML/zSn96MpMpbLP1+SIZbU=; b=nVmUezbnKNk554YMNKuTkUyX3Y67z4wPtq8jGogwjz5ZsWwg7SeKd5/8w33VlOzJBBeC6rYb0t8x6a5mDWfVBPy0WAD5UtAx+EnNk+xly5eJ0zkfEzQtO8j8nWdKcWOvcQ1OYqwd745VxPTXWHAXlco1k8yibLj3A69n5TzUC59A/hrFgbeqwGx5AZSH6HpHVKsyhgv7RQnmg3L/O3AuMJMU+N2fIGhCAELwxjNMnBV2wh03n+v7DNA009cWJ+K7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=121e.5ca4ff2e.k1904; bh=RiWjXqdi02tRtFWsHlf5LML/zSn96MpMpbLP1+SIZbU=; b=mkR/I07nmTaHAfvqTrVzSVUQCbMZUovHINjOvdYiAE/ZnhPeRyAPMrSPn6e/aoOPm1dc6PVKArc7J4OE8P5CgWEzJBJwe3UMljYqQ8yg8m0aV1YXgtp5FQ30vIxOtY4oEQta+MNtY2JYeqsvMGLNyH3dVKT4l6XX/8CiYudR/S1cEnwvSJ/DrnA4JITrzccQsXlVOHodG7wTVEnmD8rE1JOeoev9oGtmKJdkYsiz/zbGcwQubpCdGr2RKASFII4d Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Apr 2019 18:45:02 -0000 Date: 3 Apr 2019 14:45:01 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dmarc@ietf.org, dbound@ietf.org In-Reply-To: <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 18:45:06 -0000 On Wed, 3 Apr 2019, Dave Crocker wrote: > Section 7's suggestion for using Additional information does not rely on > caching. > > Reliance on existing wildcard depends on propagation of a new RR, which > continues to be problematic. There's a reason the Attrleaf table has so many entries... Now we're having a discussion about which is the frying pan and which is the fire. In my experience, these days getting a new rrtype that doesn't have extra semantics into DNS servers happens pretty quickly. It's an entry in a table or a new short stylized parse/unparse routine. DNS caches don't have to change at all. The problem is the web provisioning crudware, which is what I have tried with limited success to address with my DNS extension language work. My dbound draft has no new DNS semantics, just ordinary wildcards and an ordinary rrtype. To put anything into the additional section, you're asking the DNS servers to treat a _perim name specially if there are TXT records under the name and to go search through the zone to find the extra stuff and put it in the additional section. DNS caches have to change too, to treat the additional stuff as non-hostile and pass it through, since caches throw away unrecongnized additional sections to prevent cache poisoning (the Kashpureff bug.) You should run this by dnsop where I expect you'll get a great deal of pushback and references to the DNS Camel for anything with new semantics. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 3 11:52:00 2019 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 8307A12013F; Wed, 3 Apr 2019 11:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kj1xJBNt3wJ; Wed, 3 Apr 2019 11:51:57 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02330120163; Wed, 3 Apr 2019 11:51:56 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33Irdee004165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 11:53:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554317620; bh=oYp3+ESlg1TZsFS+AAMMYcb1cJVZ+kEfzAgEJrxLYZs=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=kzBzdafWGhM4KJHi0wY2qEMB2SresZurjKCmwvsQTa7deSeGNJQOY1iVsAB6VtRB1 NYs9HLsB+FxXuP7qpYgzO6Mik1QOPOCxTSLBm+2s+ATi614GHT+A6wGDN8JBXCfMfB 0+Oqc26tMgtwK34KFl9sJ7Di3Dm+xx0/nqLXtzyY= To: John R Levine Cc: dmarc@ietf.org, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> Date: Wed, 3 Apr 2019 11:51:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 18:51:59 -0000 On 4/3/2019 11:45 AM, John R Levine wrote: > On Wed, 3 Apr 2019, Dave Crocker wrote: > In my experience, these days getting a new rrtype that doesn't have > extra semantics into DNS servers happens pretty quickly. Now, about /end to end/ support, not just publishing... Please provide some examples comparable to your proposed use case. That is, what are new RRs that are getting well-scaled, on-going use, defined in say the last 5 years? >   My dbound draft has no new DNS > semantics, just ordinary wildcards and an ordinary rrtype. I noted that. > To put anything into the additional section, you're asking the DNS > servers to treat a _perim name specially if there are TXT records under I noted that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 11:53:15 2019 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 4ACF712016D for ; Wed, 3 Apr 2019 11:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCAewJTZaczL for ; Wed, 3 Apr 2019 11:53:02 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016A212017C for ; Wed, 3 Apr 2019 11:53:00 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id i207so10611509vsd.10 for ; Wed, 03 Apr 2019 11:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=EGg3/sVfEi4QVDsYs3oojakuwOArbJQj8diDQu8pcfWE5uJATlHUTNtk9PFwcc3Jdg IsqD26gDAUtVNysBDDCKUvZqBsZ3ECPkZ1xdcA8bQqRGPZaNHaxwPie7x+a5RuZl0+eo x6AB7h4/lWV7fRpx+ocw9SVXQM6mVUfQEnWeDbk4W1UrRYlPrmlx8o/c37Fv2SG5YSdz 8+OowI0KcN1Uh6Gdh/CrAQffjSzDcIe+PVL33ZDcRRtbaS5HjdSYkqUBXAX+T3Gfo2pA GlKLY5hfWSd1LEF/1Ka1OWvXFkE/hYAOzI9hX9q6FP7WQo/TvJxcdBsoni6w6t5ITEFH BjCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=QscFUU24FkO8pvLWgJwco6LDK9krm2yojrWSaxMJCsocz1C9c7dwS8LXZg/4ueHGOO 1P3DMlhx+PPt0cKU9nSaZRdgKJXRk5pF6WjZHsy/e1I91WYCw+rDxPPBbUsj1McNF5rs kRPLOw9PpnfDUHBetCbtOxbzyTWZXE+nbJD22ZkU/mvfPlY91dLVaBYanxe1obTO9XoV 8deLaaT95gHeTjkeeKYvPDhRxIA7eTmJRYorWiEL+P+oMIyvHV2gOummbqBOt6U3J7Ws OlL1V1uj/yy0+odB792gPuV058KGoXRkKjJYp4Ueu9B/UBOElam3e3C6T1PL8GrmPjr5 z5+g== X-Gm-Message-State: APjAAAVhKSECFzd2Gfe9Xoyhh9i1Z31+hnQejAtTg24B9wf+TXEnt6bH aYGrMnTXen9c8kJ773OjclwQg+MavyfxP4YRDgFyew== X-Google-Smtp-Source: APXvYqyQd7Vo9aU1pH11vPWKShBswFBM+sGGCwIh1q8z2jRniO0mvlb4C+Xz2cugK15Fb+gGK6v9fpmezmiIX6jFYpE= X-Received: by 2002:a67:eb41:: with SMTP id x1mr1449705vso.84.1554317579930; Wed, 03 Apr 2019 11:52:59 -0700 (PDT) MIME-Version: 1.0 References: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> <20190403175820.8391420115F376@ary.qy> In-Reply-To: <20190403175820.8391420115F376@ary.qy> From: Jothan Frakes Date: Wed, 3 Apr 2019 11:52:31 -0700 Message-ID: To: John Levine Cc: dmarc@ietf.org, Dave Crocker , dbound@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 18:53:04 -0000 I appreciate the time you invested in this Dave. I definitely like that we're thinking in terms of how to leverage DNS and its distributed model vs emulating the hosts.txt situation, and PSL is essentially a hosts.txt situation. Some assert there is a benefit to being able to contain some form of static list locally for speed. This happens at the trade-off of potentially stale data, which we experience as maintainers receiving energy from expressive TLD admins describing their grief over their domains being directed at search instead of resolving in DNS because their pc, tablet or mobile device runs a browser software that did not contain their TLD. So in those cases (and potentially others) getting things into DNS _might_ be better. I think that a TLD administrator being able to make direct updates in their own zones is vastly better because it would both alleviate the arduous process of validating authority of requests, and streamline the requesting process to near zero on their updates, and enable more direct and exacting control by the registry operators. That said, we fail the community unless the potential replacements take into consideration the many constituent / subjective uses of PSL that have evolved across the years before we tick the box next to any particular solution meeting the diverse needs. We have to tread carefully here. I have great respect for the IETF and the many wise and noble experts that have donated their experience, time and wisdom towards solutions and standards. It is a process that requires patience and I have been told by many in the developer community that it is not always one that is inclusive or able to meet the pace of some development cycles and product or service evolution. The PSL basically came into existence outside of the IETF process, borne of real practical needs, and those needs have forked and matured. There is a 'lenticular' / perspective issue in how different stakeholders are using the PSL. PSL is included in software libraries, which incorporate it without prescribing how a developer might use it. Some care only about the private section of the list, some only about the "ICANN" section. Some integrators of the PSL omit certain elements, or even maintain their own supplementary sections for their project or service needs. Think it is safe to assert variety is present - each have an entirely different need and application of some or all of the PSL's contents than a browser program, search engine, security professional, anti-spam, reporting, SSL Cert, or other use. We (maintainers) don't prescribe specifically how it gets used as volunteer community maintainers, we just try to guide community entries and validate them (and focus on ICP-3 or other I* integrity). PSL is expanding - which grows the file size each time. As potential solutions are presented from web developers or even the IETF (or both) that might help to organize or better architect solutions that could help PSL from heading towards something that emulates the transition from the SRI hosts.txt challenges, I fear that unless we can ensure that some of the dependencies are met by those proposals, the proposals will not endure, and we'll remain using the PSL in a status quo manner. -Jothan Jothan Frakes On Wed, Apr 3, 2019 at 10:58 AM John Levine wrote: > > In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: > >Comments eagerly sought, of course. > > This seems sorta kinda like my dbound draft, only with _tagged TXT > records rather than a new rrtype, and (unless I missed something) a > hope that somehow you can use a yet to be invented cache to avoid > walking up the tree, where mine used wildcards to do one lookup per > boundary regardless of the tree depth. > > I can see that the tradeoffs are different but I don't see why they're better. > > R's, > John > > >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt > >has been successfully submitted by D. Crocker and posted to the > >IETF repository. > > > >Name: draft-dcrocker-dns-perimeter > >Revision: 00 > >Title: DNS Perimeter Overlay > >Document date: 2019-04-02 > >Group: Individual Submission > >Pages: 20 > >URL: > >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound From nobody Wed Apr 3 12:03:04 2019 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 427D8120603; Wed, 3 Apr 2019 12:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1A1q1DMtzUj; Wed, 3 Apr 2019 12:02:52 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3A9120651; Wed, 3 Apr 2019 12:02:52 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33J4Z28005680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 12:04:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554318275; bh=cEholvvSqRkifT9cJkCKmgEWU6I8zWxhsjwYz67GWaY=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=QnoHdB8tTryF8z1r7WvpiL2L/r5mdK7H0O7rCT71FvF962sngfbC1bwqUqUsRxlIg OQ2LnPKvtrDSBDpanUPOc+kDE1eOLziY7t3YvBHRAjZa2/sWaMPvZShaGtae5LGSiD EQCz0z/Hsy4X3m0hKjfs3yMKR8+6Yfc9x22JX2pY= To: Jothan Frakes Cc: dmarc@ietf.org, dbound@ietf.org References: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> <20190403175820.8391420115F376@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 3 Apr 2019 12:02:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 19:02:58 -0000 On 4/3/2019 11:52 AM, Jothan Frakes wrote: > I fear that unless we can ensure > that some of the dependencies are met by those proposals, the > proposals will not endure, and we'll remain using the PSL in a status > quo manner. Jothan, Thanks for adding comments so quickly after the draft was released. As the draft notes, it attempts to cover PSL use cases but needs far more experienced eyes and minds to find where the PSL emulation needs more work. To that end, anything that documents the dependencies you cite is sure to help. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 12:06:13 2019 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 9D4B8120180 for ; Wed, 3 Apr 2019 12:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GdUa8KR1; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZHORJZHD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILVXsCsVUoXQ for ; Wed, 3 Apr 2019 12:06:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD1C12016D for ; Wed, 3 Apr 2019 12:06:04 -0700 (PDT) Received: (qmail 12597 invoked from network); 3 Apr 2019 19:06:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3131.5ca5041b.k1904; bh=9Iw+6xP6Dct64Xmu3aWDaRvlhTAO/EYBtfnqwgEGOMY=; b=GdUa8KR11U1QEDmfYIlOJmZRXvt9vr16xZQQKMRebhAEA47eT0ztJBJRpmtxclvwxLfJl7ibVdLtJMIYzcQhPCKIC2o0PKMwiGfV24amERGBCzkgd0sauDLHBZSDz/IlIODVCA2Dea7T65U2qIhoAuzdsjGoSv6NDaQ0W60LR3cenXc4/77LtvGMQYxFUnOKv6CHx2/DPJJpiov5ExHCp9poqzSZWbJWOqFWkBwHvFU8i6tJe0vPwGJxThA5iJiU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3131.5ca5041b.k1904; bh=9Iw+6xP6Dct64Xmu3aWDaRvlhTAO/EYBtfnqwgEGOMY=; b=ZHORJZHD9Dj0cMYyu92cQT6eDzdTVsfz+yMfmo4ihGMPbpu7ReKoStd1deA3AanGCz/LFpObXSA+azsxnf6VTlAXHVJ9OMHMU7Csv3Khy58B5NMOB3gY7iMoAUmaTxwMcST2cZVDM2IrFdZz3dGGWJkmatyFGFgUjsYq3DDOyI4+60ibRUlAy74scm+kudDNXOMXVkBnqd1MuXb4L28x4SaKLmLGb8imDSKijFMpReyWrnXna6TCtmeuRNEQc36M Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Apr 2019 19:06:03 -0000 Date: 3 Apr 2019 15:06:02 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dmarc@ietf.org, dbound@ietf.org In-Reply-To: <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 19:06:07 -0000 On Wed, 3 Apr 2019, Dave Crocker wrote: > Now, about /end to end/ support, not just publishing... > > Please provide some examples comparable to your proposed use case. That is, > what are new RRs that are getting well-scaled, on-going use, defined in say > the last 5 years? There aren't many other than maybe CDS and CDSKEY. TLSA was defined in 2012 and Viktor says it's getting pretty wide use now, particularly considering that it needs DNSSEC. On the other hand, there hasn't been anything with new server semantics since NSEC3 in 2008. This is really an argument for dnsop, not dmarc or dbound. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 3 12:19:53 2019 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 CBE9712017A; Wed, 3 Apr 2019 12:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqeVKHvVRD8z; Wed, 3 Apr 2019 12:19:50 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F165D120172; Wed, 3 Apr 2019 12:19:49 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id w24so2119881plp.2; Wed, 03 Apr 2019 12:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zQmHF4nLMHqRVtIre9MxcEK3ViqSxg+LKRr5uLnfndI=; b=BvmvDayD4CksoGLGNj2wBgPfSb+r0wnRTQVxcNqaqftJmzRBXQn7VWZDqGNAiitwcF BEctn8O7vt8oX56WaJp6AsY+Ygat4rvHkKIbtUBcjCPEbtKcKsnfHM7tIU7PqQ3kHSsI CwWn6BvBm0SPkmHEI39iTFkrEywdJdDXVzWeCEKOuGRXpXJcpdNHZAyVWyFLtDiFHaWI QPogA5gX+PlYBWR8ookQcKkb0++057r3Hgzf48G3kKLnb0My4Fj0VNxTHhjopCo3Bcu8 f65Pkbfp2iNI0zCNkzK3KVolkt9OPHk5mx4LPmjAxtcBWc8oD4QXjWEu60OEhDD5yI6B 9gPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zQmHF4nLMHqRVtIre9MxcEK3ViqSxg+LKRr5uLnfndI=; b=bCIXqByJHAP/wZQR6yb+CDeWAeZznOfHE0GzhM73qyHhG/qO87nVBdewTzwfa9IWwB h0hghYPTMHmvTtz0uYEIrjBnC190vVeqBHTRCrLePtqoIIFMsVSAPuHYQgkB/bWqBOcV bgOlvaXSO6sNYB456eLQaMoLEYPJGuZY/hq0cWPB0BxXrgY53k/dVayq2zdBigQipLQp xgsvyUYUYA3QGA/vChRxStv1GWKRfFYehatGGtUcxdrT4cUZiJIDvAKUnyIZD+Hcj9uS IVSEHLWfcaXQLt2WSXIeQMgZNr+uGIjcbzY3P2YokHjBAAcokkCqvYRcSaDswvpItIpR cn7A== X-Gm-Message-State: APjAAAU5wwsZW8TJYOBIJnydsD57ZjEMkXb46ZYiwl0VNMccFwfpyJ0a TugpYoW/P1jnRjslvzxy22o= X-Google-Smtp-Source: APXvYqw8L4yQPQV30Gi9ZwHdQmhIsaF/hvFpd7wiPHlfUemnnHbrfiotULATjk7UAAbBhgBjlftOhw== X-Received: by 2002:a17:902:7841:: with SMTP id e1mr1688893pln.303.1554319188729; Wed, 03 Apr 2019 12:19:48 -0700 (PDT) Received: from [172.19.248.162] ([104.153.224.169]) by smtp.gmail.com with ESMTPSA id i2sm24400685pfo.9.2019.04.03.12.19.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 12:19:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Wed, 3 Apr 2019 20:19:41 +0100 Cc: dcrocker@bbiw.net, dmarc@ietf.org, dbound@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> To: John R Levine Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 19:19:52 -0000 I was going to say CAA but that=E2=80=99s 6 years old.=20 =46rom my high tech gadget > On Apr 3, 2019, at 20:06, John R Levine wrote: >=20 >> On Wed, 3 Apr 2019, Dave Crocker wrote: >> Now, about /end to end/ support, not just publishing... >>=20 >> Please provide some examples comparable to your proposed use case. That i= s, what are new RRs that are getting well-scaled, on-going use, defined in s= ay the last 5 years? >=20 > There aren't many other than maybe CDS and CDSKEY. TLSA was defined in 20= 12 and Viktor says it's getting pretty wide use now, particularly considerin= g that it needs DNSSEC. >=20 > On the other hand, there hasn't been anything with new server semantics si= nce NSEC3 in 2008. >=20 > This is really an argument for dnsop, not dmarc or dbound. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Apr 3 12:49:31 2019 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 13A22120639; Wed, 3 Apr 2019 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1dpEDOYagev; Wed, 3 Apr 2019 12:49:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17FE120633; Wed, 3 Apr 2019 12:49:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 04C10BE58; Wed, 3 Apr 2019 20:49:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9qMws_3Qodx; Wed, 3 Apr 2019 20:49:14 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8368BBE55; Wed, 3 Apr 2019 20:49:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554320954; bh=8Ig524TwrnH/RFwIEiUmeZqI1ybBrTcu1l42CCtgm3Q=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Wsv2HtitbfdM/yvP4dibJMB180NhHjF1zQvq83aSUTDzvTV6y9O+hSu3ME7PF6qA8 4znVIapoOS0D18pHPkoUhKUmu4n6a9V58CBg4XN2p9vYWkCEaF//eH3pZ7ZVqY8OB5 awDSE1pCWe9gTjaIDAbUG8y2Rv+j6S+HuChJ34s0= To: tjw ietf , John R Levine Cc: dmarc@ietf.org, dcrocker@bbiw.net, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 3 Apr 2019 20:49:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07" Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 19:49:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07 Content-Type: multipart/mixed; boundary="kAXCG537LYwE0YL2xJzEwhklxe6ljydYL"; protected-headers="v1" From: Stephen Farrell To: tjw ietf , John R Levine Cc: dmarc@ietf.org, dcrocker@bbiw.net, dbound@ietf.org Message-ID: Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> In-Reply-To: --kAXCG537LYwE0YL2xJzEwhklxe6ljydYL Content-Type: multipart/mixed; boundary="------------5D07C1BDC25D6FEFA8A7B3A3" Content-Language: en-GB This is a multi-part message in MIME format. --------------5D07C1BDC25D6FEFA8A7B3A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Far from widely deployed, but the latest ESNI draft introduced a new RRTYPE from an experimental range, and it "just worked," which was a pleasant surprise for me. (And is partly why I am happy to try that route for RDBD.) "just worked" here meaning: no registrar web-GUI involved, but whacking the ascii hex encoding of binary RR values into a zonefile on a hidden master, having that transferred to the visible NS's and accessing it from elsewhere using dig with and without DNS/TLS (DoT- flavoured via stubby) all did really just work. Only hard thing was finding the docs to say how to refer to the new RRTYPE in zonefile and dig command line. (I added some notes on that in a readme for my ESNI code - go to [1] and search down for RRTYPE if you're curious.) I think that tends to back up John's argument that today, registrar GUIs are perhaps the main barrier for new RRTYPEs that don't change the DNS semantically. But there may also be development environment issues, e.g. I don't know if you can easily query for new RRTYPEs from e.g. PHP or python code. Lastly, on Dave's draft itself, I'd be happy if something like that were deployed, and don't think it overlaps much with or competes with RDBD. (At least I hope these aren't seen as competing ideas.) In early chats about RDBD Alex and I did think about the PSL, but we ended up deliberately not trying to aim for a DNS equivalent. Without trying to speak for Alex, personally I think emulating the PSL in DNS is too big a leap to attempt in one step and isn't likely to succeed, despite it being an outcome that'd be good to (eventually) see. That's partly how we ended up with (what I'd claim) is the more modest initial goal of RDBD. Cheers, S [1] https://github.com/sftcd/openssl/tree/master/esnistuff On 03/04/2019 20:19, tjw ietf wrote: > I was going to say CAA but that=E2=80=99s 6 years old.=20 >=20 >=20 >=20 > From my high tech gadget >=20 >> On Apr 3, 2019, at 20:06, John R Levine wrote: >> >>> On Wed, 3 Apr 2019, Dave Crocker wrote: >>> Now, about /end to end/ support, not just publishing... >>> >>> Please provide some examples comparable to your proposed use case. T= hat is, what are new RRs that are getting well-scaled, on-going use, defi= ned in say the last 5 years? >> >> There aren't many other than maybe CDS and CDSKEY. TLSA was defined i= n 2012 and Viktor says it's getting pretty wide use now, particularly con= sidering that it needs DNSSEC. >> >> On the other hand, there hasn't been anything with new server semantic= s since NSEC3 in 2008. >> >> This is really an argument for dnsop, not dmarc or dbound. >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl= =2Ely >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------5D07C1BDC25D6FEFA8A7B3A3 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5D07C1BDC25D6FEFA8A7B3A3-- --kAXCG537LYwE0YL2xJzEwhklxe6ljydYL-- --ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlylDjkACgkQWrL68XsX K+pF0RAAnfCFfUlZyZdD9t8JKY1BMpGN5E+jcZDOs7lIMnOXU4DhUCrMlzgAxjVA 5Xhc/DeHYXp2qiOmDkiQ10XpgbS2TmGaNZlbXGXOdxN4Fm2M7DswFn1kn25ltwgT p3Z6m28UQyhI1uvl346Z0pPCGDcqbwpzjpAemco56HY6hlYzZwJ4meG8TLWphuva wRQV7xo2CD5IoLHe1MsEtby63DXbAyuhn+wi0wkScLHBmTrpvbp6olXKG9qHWVVl ycLuKzgDM4sRvizOwAl8MGuVH6wQl23L5E12QQGl0FyTHUh5pI2fiIzxJ5VfAsJL +kjia8kP9ftxQsHlKLKjb4xuM1OCd7PEOmja7aHx4D7MbRGXjwBqW71dX6D2MIcL 2V0fEF0eQt+KBqbIi0ImxUIW8SCRd43eF23K/bYRsdz3CLnH69VAH4F9g4EiT2FN kLXDqwOFb/3z8yoQeb3acOMAeZnH/GKBkhDaP4ZGJOdrk46wbsfT6Fzsd9+Zdbee 5JHS+6AKOuRos6WHMziT8chDIO+Lf8NRR27f/ely51c3rdbK6SwUQ+ZlbZH4KaU8 ra5VEAf7tylp/jmBV4PVXkcoU1X0gt7H2KKGC1Kh7tKpsMHaAtPTd6iXtlNWgwqT ZORYBSS+miRez11yHnWfAHsGonVInvW4NgdrGMRnNze17q2iquw= =ihaW -----END PGP SIGNATURE----- --ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07-- From nobody Wed Apr 3 13:20:29 2019 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 4623C12011C for ; Wed, 3 Apr 2019 13:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdULQFlVorPx for ; Wed, 3 Apr 2019 13:20:20 -0700 (PDT) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FD71200E5 for ; Wed, 3 Apr 2019 13:20:19 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id i207so10767887vsd.10 for ; Wed, 03 Apr 2019 13:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CwjlInjtZCaIUsv6RvkmS4aC9HRscDK9Gw9M4bj8O5Y=; b=rnB2xR6HUcBUWrCMAYBBSw2/Z7phe13/rlN7lLLzd/exFCgV7e0CLoS9zSW45g7Pcc mbfhhsDUOOtiQX6P+hXyIfhf+0CQ8iR85eB9OD6mej5ZAx8ggG2lj7TB3z1C7OCImY03 EeEXQrYxHZ5x7u6u48Hmr5NK5xwg0HooO+nFjyz/75fSD1NBc5KOozvV9ArWk6BO0b2L dZnhYNg3PNm+lCpxnja8cenGt8B18tEUMm/j+pnfz1hnWR67HNKotHPypB4kMG25SIX4 QTzb6phDi3SDnZwS0U7JI/cx4cuupRyIpr+875tzCyTqD+zc1hAd8WllW52oTB/BUNc4 fkIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CwjlInjtZCaIUsv6RvkmS4aC9HRscDK9Gw9M4bj8O5Y=; b=f3exrDgdvF4hhVrBqA6EzN8kxMDPmahdcPxVuMbB0xqnFuaY+k8Tg35tGpLO0QduvS fRprH4IUpEa7nJj5X78OG9zkKezyaJ3EQnBl84/5riNrSlW+gGa/zkz9LDY+tGtowu6j nlTWmcl7mFvzveh0vx+pVWo+fU7iTEifHgt6cVRcYKv8Gg8eviNnmmNJUXRbE3FgGKdX xWP228pMF7sS4YlroWf0C/SsmseKu4/aZpk9t3GzmyeQHOeSMQcoIRqblKsJNOuLpnlf cCHHc43rV54/UnPcw78DGpC5uxbUdbQr05Fp0Lt+E1i+ccttJrctORJ/QdRSWErr7HQu BILg== X-Gm-Message-State: APjAAAWFmnmxsGUswAm0wzgnjRV7+C2ir6r81T7pb3QNnebbxBPSAj6u 6gIUE/OndkCwT3u91EPxiQgzAE5fpeLo+5cxolTQ1A== X-Google-Smtp-Source: APXvYqxMBE7+UXfqMmur3VH3TFi3RgD9nKf6LeT47kyrfFDQVSbXPrBjW1j+XQ+GaD4b1QucWZLWaeE24JAgRx2Y6fA= X-Received: by 2002:a67:76d7:: with SMTP id r206mr1656907vsc.25.1554322819015; Wed, 03 Apr 2019 13:20:19 -0700 (PDT) MIME-Version: 1.0 References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> In-Reply-To: From: Jothan Frakes Date: Wed, 3 Apr 2019 13:19:47 -0700 Message-ID: To: Stephen Farrell Cc: tjw ietf , John R Levine , dmarc@ietf.org, Dave Crocker , dbound@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 20:20:22 -0000 > ... registrar > GUIs are perhaps the main barrier for new RRTYPEs ... s/registrar/DNS Management/ these are often not one in the same - and the only reason I make that pedantic distinction is that the frequent situation where DNS Management != registrar heavily impedes DNSSEC end-to-end configuration, because it needs config harmony within the registration path (registrar) and the resolution path (DNS) Hope that made sense. Just want to ensure these are not conflated to avoid drag on efforts From nobody Wed Apr 3 13:30:59 2019 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 325681201F1; Wed, 3 Apr 2019 13:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7NBQjoHRQ_c; Wed, 3 Apr 2019 13:30:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A72912011C; Wed, 3 Apr 2019 13:30:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1DFB0BE55; Wed, 3 Apr 2019 21:30:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAD8F_NUi60w; Wed, 3 Apr 2019 21:30:43 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2124CBE2F; Wed, 3 Apr 2019 21:30:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554323443; bh=PWc1izpf7Yx0h1jTJSo7dMN3OzWXPdFypWXzFCjzXSc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bTBy9zzusoMNvx17KonvrgCNb1ZnFvbG0fleeU83bgoxWWgbpllNv/uCYa2dkglAh 3MV0O+v8HKcJduVHMKk90oMWg+Y6BN8O4WauB12MoKVTf78mb3GrqPXyqJgx+Asd61 DFQy7GvwqWNkzI3XETclksgkyKpWYyTj5FifBwZA= To: Jothan Frakes Cc: tjw ietf , dmarc@ietf.org, John R Levine , Dave Crocker , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <7e3b2eb8-3ab8-5dda-1523-c15589486a4b@cs.tcd.ie> Date: Wed, 3 Apr 2019 21:30:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE" Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 20:30:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE Content-Type: multipart/mixed; boundary="oDLHWUm1wtKH92DiK8xnXrUbWJyWsrHog"; protected-headers="v1" From: Stephen Farrell To: Jothan Frakes Cc: tjw ietf , dmarc@ietf.org, John R Levine , Dave Crocker , dbound@ietf.org Message-ID: <7e3b2eb8-3ab8-5dda-1523-c15589486a4b@cs.tcd.ie> Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> In-Reply-To: --oDLHWUm1wtKH92DiK8xnXrUbWJyWsrHog Content-Type: multipart/mixed; boundary="------------7E01A62664094D51509BFA37" Content-Language: en-GB This is a multi-part message in MIME format. --------------7E01A62664094D51509BFA37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/04/2019 21:19, Jothan Frakes wrote: >> ... registrar >> GUIs are perhaps the main barrier for new RRTYPEs ... >=20 > s/registrar/DNS Management/ >=20 > these are often not one in the same - and the only reason I make that > pedantic distinction is that the frequent situation where > DNS Management !=3D registrar > heavily impedes DNSSEC end-to-end configuration, because it needs > config harmony within the registration path (registrar) and the > resolution path (DNS) >=20 > Hope that made sense. Just want to ensure these are not conflated to > avoid drag on efforts Fair point. Ta, S. >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------7E01A62664094D51509BFA37 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7E01A62664094D51509BFA37-- --oDLHWUm1wtKH92DiK8xnXrUbWJyWsrHog-- --6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlylF/IACgkQWrL68XsX K+qdkQ//TqiWEKR/R9eemXJQnb3VaJM1x+VJCc88Pn2KGlm2ITXb3rvSdDwfFj01 d+Z7QJMbW2OrFFl4LlDVkPL0wjoZr3dpQEXmeQn9x+BvH4tblyE/sxbI6oGvdZPX tVaUJzOi2Hkl+S2C4/Iupw/G4uf62RrIYq4PWCEWQeBqHuTVr82TO9aBPNR5cgV1 gC8BcmMMRiBIxcQiGWCPW1UVewcyCPeXQ4t3ZGx95XnPJSaB5DtLlKe66qkD8Qg0 FBG+4194WakHXHXyF6PkpQBWUXf2trveM4y7tbxOTEmyq8HEdomR3RTDnQjc+QzF N0Q6h4qvMfCaj0xy4+sJjNxwL/WvehInybPxoIKu7GVJjYEE3A4knnfY/YoPQi1Y aoVbtufq538C4Qrri84X3ReiGBPIfgwvd6WJMwMDCbnYGRYbzT6GCL31XP0l7R8D 6MShqxNqpMOcL6Nb3EFlVTimtQOtFVA13yA8hCGO2yQ2SjNQH59YNpaJpznKN3qV HIcXALi/V6xN35eElNa2R0Y2aP1pJjWU/3WIlQOIDoQ4NSQH4kv07zJwv2POpQXR FkxPL9HKypu9j0sjZSQh8Rd+8VWGtCDlviMjHjz4LAeotrqX/GHVig7zKLW7xlXd rmzwiTRv17CSgyQKF863YX6vBpxY28x38ceuUiZ6IdmZsU+x96U= =W/U0 -----END PGP SIGNATURE----- --6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE-- From nobody Wed Apr 3 14:07:31 2019 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 1176F120281; Wed, 3 Apr 2019 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1htL9QiX0Ik; Wed, 3 Apr 2019 14:07:21 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41F712027F; Wed, 3 Apr 2019 14:07:21 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33L93A3017670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 14:09:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554325744; bh=B0Bjay4xvc/1GJ7cS/roMAIoU0vrInnY/YOaPsBbWVk=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=HvcnpbXeNtvMcAnArg6I0bG+D3Frgan/Axnr7r/LUlMuUEuaNQUI9WMbmJokaAI86 S2eKtPnSG4kERMbT7yJEfzV/w1g8HWZRjoh9CQj4TeQ4Va4Y4M4CrQoM+GmanqUwxI dVf9oR99FvcucoJnVTbUmEUEHRXBxhKz3ilTxI4M= To: tjw ietf Cc: dmarc@ietf.org, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> Date: Wed, 3 Apr 2019 14:07:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 21:07:23 -0000 On 4/3/2019 12:19 PM, tjw ietf wrote: > I was going to say CAA but that’s 6 years old. 5 was a random number. I was merely meaning 'recent'. But suggesting CAA in response to my query means that you think RFC 6844 has received widespread -- ie, at scale -- end to end adoption and use. Yes? Please forgive my skepticism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 14:09:14 2019 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 3795A120285; Wed, 3 Apr 2019 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlu2sW1KxEnL; Wed, 3 Apr 2019 14:09:11 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1593512027F; Wed, 3 Apr 2019 14:09:11 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33LAs7t017791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 14:10:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554325854; bh=kx391p1EJdWjU2MGzsyPqFs1kpGfK0+aymhzU4uUis0=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=aSeKxHsDbczJfgo2SD5jOLv5GSyXBzT5a2eAIyd3CEPaKuymVHr3BB/9nWtkaDFGa d9627PdmgYhs0sg22G6X2nL5jgafjf7mkx1ufvJIKP69e1bIbB+3sCg44THCuXYeg+ 6ShpUk+7aFCorfg3aBYipr/1F6I2AuatetxTMsNs= To: dmarc@ietf.org, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <07a9df2c-1a2c-9dc4-c6ca-a93f5bffd1e0@dcrocker.net> Date: Wed, 3 Apr 2019 14:09:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] cross-posting (was Re: [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 21:09:12 -0000 May we quickly settle on a single mailing list for discussing this draft? I assume dbound is the right choice but don't really care, as long as it is only one. Absent objection, I propose that this note be the last one cross-posted. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 4 07:05:56 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDFD120632; Thu, 4 Apr 2019 07:05:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155438674964.30951.886977582578601777.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 07:05:49 -0700 Archived-At: Subject: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-eaiauth-04=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 04 Apr 2019 14:05:50 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dmarc-eaiauth-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Does -04 fix all issues / comments from the Internationalization directorate (which was about -03) ? Nits: section 8 in security consideration, unsure whether the use of "as far as the author knows" is useful or required. From nobody Thu Apr 4 11:25:32 2019 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 6A035120046; Thu, 4 Apr 2019 11:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=WSZ9Wi0N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fAnb9pMr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeLFX7EWToh6; Thu, 4 Apr 2019 11:25:21 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270CC120125; Thu, 4 Apr 2019 11:25:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 328B821F5C; Thu, 4 Apr 2019 14:25:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 04 Apr 2019 14:25:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=j YT/Pmau4ZTnqXtlZP8LldqMTI1Bgs6AiYRfDF0uL3A=; b=WSZ9Wi0NdHZTkRXOL ofQF7yYUPWixO5oLE+RrVgQCKwtsqvlT8+MrhyiwhQ+1JX1EBsyb6OGLlJkXmUXd 8sIHgppaIR4vuGbI3JNnX/LmyacqUQUxfKynBuqL9K0DGHFDILWa/+Btass1S9t+ WHC6/k+JjjU6TQdlY37Finq10HgyzdQVQe+dRlYsVvVtlQDavwgjyp2im999khNp v0aJUmQaa64OGkNGPKa/4C3LSJR4NPpKnoWjuZ9ZiFz2R7tpW9j58g3FSLhAwAKR T2hZ0oi4pR2TCxXVyrqbzfODHaMHt+DLQQ9IPzBJeXYhnMp+jWYBMWYl0EOfXSvV Yqllg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=jYT/Pmau4ZTnqXtlZP8LldqMTI1Bgs6AiYRfDF0uL 3A=; b=fAnb9pMrtkbwnvFqngzAnnQeJl5GrUNDCjI4vMr0llb7XeuymJaiK6Bwj ybAH2eJccOvGUS+ZPry2T2Ik2w2NmbL1TbBFtJOSXoiiDFl6HvigrrWXC6btut5D 24/TyUiljEz7OzuDP+LCO++ZeEu8epQxfQN9ioKtNkRQLE1Tq0W61CH0f7mS0I5o 031X0UG06SwSsiePXhS4CAS4pxjKGuX9WtHmtdKBcLPGMV9zOHP0wXxb31vkMwqq w/fjbHvLDB+5qPPXwcCX1Wwm+ewZT5P+fn+Wmxl5gD4bxnE6P/zvNLgE23fry/Kj dJDf9D3Fmrf884gg/924kXi1Ibh8w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdduvdefucdltddurdeguddtrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurheptggguffhofgjfffgkfhfvfesthhqmhdthhdt jeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovh esfhgrshhtmhgrihhlrdhfmheqnecukfhppedukeehrdeiledrudeghedrudenucfrrghr rghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.219.217.123] (unknown [185.69.145.1]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E9841030F; Thu, 4 Apr 2019 14:25:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (15G77) In-Reply-To: <155438674964.30951.886977582578601777.idtracker@ietfa.amsl.com> Date: Thu, 4 Apr 2019 19:25:10 +0100 Cc: The IESG , dmarc@ietf.org, kurta@drkurt.com, draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155438674964.30951.886977582578601777.idtracker@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-dmarc-eaiauth-04=3A_=28with_COMMENT=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 04 Apr 2019 18:25:24 -0000 Hi Eric, > On 4 Apr 2019, at 15:05, =C3=89ric Vyncke via Datatracker wrote: >=20 > Does -04 fix all issues / comments from the Internationalization directora= te > (which was about -03) ? I believe so. Best Regards, Alexey From nobody Fri Apr 5 10:26:06 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986C81200B9; Fri, 5 Apr 2019 10:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2019 10:25:57 -0700 Archived-At: Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 17:25:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-eaiauth-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document; it's good to improve the clarity and precision of how various pieces of the ecosystem interact. That said, I do have a couple of potential issues that need to be addressed prior to publication: I'm not sure I fully understand the security consequences of causing the SPF macros %{s} and %{l} to never match when the local-part contains non-ASCII characters, but they seem potentially quite bad. That is, if the policy is intending to limit allowed senders to a specific list (or block specific senders), would an attacker be able to avoid the restriction by using a non-ASCII local-part? I'd also like to discuss whether we need greater specificity in the nature of the updates applied to the Updates:'d documents. For example, Section 6 (of this document) says that Xection X [of RFC7489] is updated "to say that all U-labels in domains are converted to A-labels before further processing", but most of those referenced sections contain step-by-step listings of a procedure to follow. It doesn't seem like much of a burden for us to say "between steps X and X+1, insert the following step: "[convert domain from U-label to A-label]", and that has a potentially significant gain in clarity to the reader (and thus, interoperability). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2 That's not the actual boilerplate text from RFC8174; please just copy/paste the appropriate snippet. Section 3 In headers in EAI mail messages, domain names that were restricted to ASCII can now be U-labels, and mailbox local parts can be UTF-8. nit: "can now" implies some previous baseline state, but that reference for comparison is not especially clear just from context. Section 5 I'm having a hard time following this paragraph: Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags of a DKIM-Signature header MUST be encoded as A-labels. This rule is relaxed only for internationalized messages headers [RFC6532] so IDNs SHOULD be represented as U-labels but MAY be A-labels. This provides improved consistency with other headers. The set of allowable characters in the local-part of an i= tag is extended as described in [RFC6532]. When computing or verifying the hash in a DKIM signature as described in section 3.7, the hash MUST use the domain name in the format it occurs in the header. Is "this rule is relaxed" a new policy as of this document? RFC 6532 does not mention an "i=" tag anywhere, so I feel like we may need greater detail on what behavior from 6532 we're pulling in. (Are we just intending to add the UTF8-non-ascii block as valid ABNF for the RHS of the "i=" tag?) Is there any risk that an intermediary will reencode the domain name and cause the signature validation to fail? Section 6 DMARC [RFC7489] defines a policy language that domain owners can specify for the domain of the address in a RFC5322.From header. nit: the formatting looks weird Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the RFC5322.From address domain are to be handled. [...] (ditto) Also, a bare "Section 6.6.1" normally refers to the current document, so repeating RFC 7489 is probably in order. (Same for the other Section references in this section.) A-labels before further processing. Sections 6.7 and 7.1 are similarly updated to say that all U-labels in domains being handled are converted to A-labels before further processing. I don't really see a procedural listing described in Section 6.7 of RFC 7489; can you point me to where this conversion to A-labels is supposed to happen? Section 8 (Depending on how the first DISCUSS point is resolved, we may be adding some new threats that need to be covered.) From nobody Fri Apr 5 10:50:24 2019 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 6CF2212012F for ; Fri, 5 Apr 2019 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lKGwpLmt; dkim=pass (1536-bit key) header.d=taugh.com header.b=R+ECEL72 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqo88iRVa7Fp for ; Fri, 5 Apr 2019 10:50:19 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B4E12008B for ; Fri, 5 Apr 2019 10:50:18 -0700 (PDT) Received: (qmail 64796 invoked from network); 5 Apr 2019 17:50:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fd19.5ca79558.k1904; bh=yBMYXvU7L9BKmQtjOrB1C127FCqksOFcRYXDnrWRPfs=; b=lKGwpLmtfEbiRw/oEZ4esH6zmj0ZbFDAohFraWlMffbkzetmzNnK5mWMu7NtB4OnAm2rTPbj/AvB0ZZUZAESt8sZ36eskTD6KFjRbhLtKBglR04gke8Vy0oNzRlcbO7fe3M4rZp/9Ng44xr48iCFzmtoYbrub4QGZFLLEAgFyQaolsrfVahJpvbnWnWQyknlQCpKNFEFYbz/3Om9oI43YniByejhzcY4QA1mMzFhmk4PuT+dq2kIMj0d24C3Q+gA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fd19.5ca79558.k1904; bh=yBMYXvU7L9BKmQtjOrB1C127FCqksOFcRYXDnrWRPfs=; b=R+ECEL72xikFULO6n25+FvOtJnQV4LVsFIWSOK4YfaUv2Kdtf95xFhucmqIyAPTNt6d7150MREUAl1tNk5NKYK262m8vZFr9tVuSHnPEsWqBtBp8NIoo0MkvQ2H6n943O0/C4BD3Kd5bFC4s0FAJLjIemlIRMbEP/HmMeYdvCMEtZzDVBFTtyu06KvEhp8aaD/gSopQnbPWntsgLTuLYG88boKpjRoqJ755KWhdYP8PFwvC7YP9K9km2E1c24WJU Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Apr 2019 17:50:15 -0000 Date: 5 Apr 2019 13:50:15 -0400 Message-ID: From: "John R Levine" To: "Benjamin Kaduk" Cc: "The IESG" , dmarc-chairs@ietf.org, "Kurt Andersen" , dmarc@ietf.org In-Reply-To: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 17:50:23 -0000 On Fri, 5 Apr 2019, Benjamin Kaduk via Datatracker wrote: > I'm not sure I fully understand the security consequences of causing > the SPF macros %{s} and %{l} to never match when the local-part contains > non-ASCII characters, but they seem potentially quite bad. That is, if > the policy is intending to limit allowed senders to a specific list (or > block specific senders), would an attacker be able to avoid the > restriction by using a non-ASCII local-part? Approximately nobody uses those macros even for ASCII addresses. SPF lists a set of things to allow, not to forbid, so that the most that will happen is that an address won't authenticate. > I'd also like to discuss whether we need greater specificity in the > nature of the updates applied to the Updates:'d documents. For example, > Section 6 (of this document) says that Xection X [of RFC7489] is updated > "to say that all U-labels in domains are converted to A-labels before > further processing", but most of those referenced sections contain > step-by-step listings of a procedure to follow. It doesn't seem like > much of a burden for us to say "between steps X and X+1, insert the > following step: "[convert domain from U-label to A-label]", and that has > a potentially significant gain in clarity to the reader (and thus, > interoperability). There are a fair number of people in the WG who implement this stuff and nobody has said it's hard to follow. I'm not inclined to add verbiage just for the sake of doing so. > Section 5 > > I'm having a hard time following this paragraph: > > Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags > of a DKIM-Signature header MUST be encoded as A-labels. This rule is > relaxed only for internationalized messages headers [RFC6532] so IDNs > SHOULD be represented as U-labels but MAY be A-labels. This provides > improved consistency with other headers. The set of allowable > characters in the local-part of an i= tag is extended as described in > [RFC6532]. When computing or verifying the hash in a DKIM signature > as described in section 3.7, the hash MUST use the domain name in the > format it occurs in the header. > > Is "this rule is relaxed" a new policy as of this document? Yes. > RFC 6532 does not mention an "i=" tag anywhere, ... I suppose I could say "as in the description of local parts of e-mail addresses as in RFC 6532" > Is there any risk that an intermediary will reencode the domain name and > cause the signature validation to fail? No more than there has been all along. Intermediaries can do all sorts of bad stuff to mail messages althrough for the most part they don't. > A-labels before further processing. Sections 6.7 and 7.1 are > similarly updated to say that all U-labels in domains being handled > are converted to A-labels before further processing. > > I don't really see a procedural listing described in Section 6.7 of RFC > 7489; can you point me to where this conversion to A-labels is supposed > to happen? Good catch, the ref to 6.7 is left over from an earlier version where this draft also updated the Authentication-Results spec. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 5 11:09:56 2019 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 46D06120091; Fri, 5 Apr 2019 11:09:54 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQNN6VeB4OrI; Fri, 5 Apr 2019 11:09:52 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3C812000F; Fri, 5 Apr 2019 11:09:52 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x35I9jVD002724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Apr 2019 14:09:49 -0400 Date: Fri, 5 Apr 2019 13:09:45 -0500 From: Benjamin Kaduk To: John R Levine Cc: The IESG , dmarc-chairs@ietf.org, Kurt Andersen , dmarc@ietf.org Message-ID: <20190405180945.GF70202@kduck.mit.edu> References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 18:09:55 -0000 Hi John, On Fri, Apr 05, 2019 at 01:50:15PM -0400, John R Levine wrote: > On Fri, 5 Apr 2019, Benjamin Kaduk via Datatracker wrote: > > I'm not sure I fully understand the security consequences of causing > > the SPF macros %{s} and %{l} to never match when the local-part contains > > non-ASCII characters, but they seem potentially quite bad. That is, if > > the policy is intending to limit allowed senders to a specific list (or > > block specific senders), would an attacker be able to avoid the > > restriction by using a non-ASCII local-part? > > Approximately nobody uses those macros even for ASCII addresses. SPF I gathered that. But if they're still in the spec, we need to properly document their behavior (and any security consequences of the choices we made). I would probably be okay with a generic recommendation to not use these and an acknowledgment in the security considerations that there are extra considerations if they are used. But I don't think you can hand-wave away the potential risk just by saying "no one really uses these so we'll ignore them". > lists a set of things to allow, not to forbid, so that the most that will > happen is that an address won't authenticate. > > > I'd also like to discuss whether we need greater specificity in the > > nature of the updates applied to the Updates:'d documents. For example, > > Section 6 (of this document) says that Xection X [of RFC7489] is updated > > "to say that all U-labels in domains are converted to A-labels before > > further processing", but most of those referenced sections contain > > step-by-step listings of a procedure to follow. It doesn't seem like > > much of a burden for us to say "between steps X and X+1, insert the > > following step: "[convert domain from U-label to A-label]", and that has > > a potentially significant gain in clarity to the reader (and thus, > > interoperability). > > There are a fair number of people in the WG who implement this stuff and > nobody has said it's hard to follow. I'm not inclined to add verbiage > just for the sake of doing so. With all due respect, if the only people we cared about were people in the WG, why would we need to publish this as an RFC? The whole premise of rigorous specifications is that anyone can jump in to the ecosystem and implement something that interoperates, and in my opinion the current presentation is not very accomodating to such a participant. I'm happy to continue having a discussion, including with my fellow IESG members, about what standards of clarity we expect for IETF-stream documents. > > Section 5 > > > > I'm having a hard time following this paragraph: > > > > Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags > > of a DKIM-Signature header MUST be encoded as A-labels. This rule is > > relaxed only for internationalized messages headers [RFC6532] so IDNs > > SHOULD be represented as U-labels but MAY be A-labels. This provides > > improved consistency with other headers. The set of allowable > > characters in the local-part of an i= tag is extended as described in > > [RFC6532]. When computing or verifying the hash in a DKIM signature > > as described in section 3.7, the hash MUST use the domain name in the > > format it occurs in the header. > > > > Is "this rule is relaxed" a new policy as of this document? > > Yes. Maybe "hereby relaxed" or "this document relaxes this rule" or similar would help me be confident in that as the correct interpretation. > > RFC 6532 does not mention an "i=" tag anywhere, ... > > I suppose I could say "as in the description of local parts of e-mail > addresses as in RFC 6532" > > > Is there any risk that an intermediary will reencode the domain name and > > cause the signature validation to fail? > > No more than there has been all along. Intermediaries can do all sorts of > bad stuff to mail messages althrough for the most part they don't. Right. But we don't, say, know of any current implementations that try to canonicalize the representation of the domain name, for example? > > A-labels before further processing. Sections 6.7 and 7.1 are > > similarly updated to say that all U-labels in domains being handled > > are converted to A-labels before further processing. > > > > I don't really see a procedural listing described in Section 6.7 of RFC > > 7489; can you point me to where this conversion to A-labels is supposed > > to happen? > > Good catch, the ref to 6.7 is left over from an earlier version where this > draft also updated the Authentication-Results spec. Ah, that makes sense. Thanks, Ben From nobody Fri Apr 5 11:20:30 2019 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 034EE1205D2 for ; Fri, 5 Apr 2019 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=VoXW3dFN; dkim=pass (2048-bit key) header.d=kitterman.com header.b=HeU6unev Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uO7uhvUdAi7 for ; Fri, 5 Apr 2019 11:20:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373DA1203F6 for ; Fri, 5 Apr 2019 11:20:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id A337FF8081F for ; Fri, 5 Apr 2019 14:20:24 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554488424; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=m5HQbweKzFXZaW5cYtat3Mj+f56GqHr9KhpVRyQNiao=; b=VoXW3dFN+KHFNLr9lBAc23tt4VPjbqYMT7lkluYhtHCWVQ0h52ZjwaLV toyimvBxDWsTZCzU98Kc+DMVfChZAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554488424; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=m5HQbweKzFXZaW5cYtat3Mj+f56GqHr9KhpVRyQNiao=; b=HeU6unevDALuITekbX6qYKRnjLs3vpS+RcaptnmlDZ8o650VXEwzcR2I LXsupJeUgllgwkWX7O/IcREmPU7hgl6J8BrHBRngliC8A0pjYj/ZjTXbm8 B8vF0wYx+KaBE2Cc3NhJxkS95PQAXWVFrnJ83gtHfR2PKinoOdYrQ+DKpd TP60df7l7iQu95yPh826b+94xc/FwH5+oXYzONWicmvnbzLZYR+monQJ17 Rr8pm1wu8R+vNBq31vYp4hRinDxF3O1966y86vOZpS60cNIsDRiTycvWDT ePDAgoDhBQN6V36+K0xWySHFuY/N/3TUPRxZd27GE1x7Xp0XFnt75w== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 73459F80053 for ; Fri, 5 Apr 2019 14:20:24 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 05 Apr 2019 14:20:23 -0400 Message-ID: <14007257.XvzNgCV7GG@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 18:20:28 -0000 On Friday, April 05, 2019 10:25:57 AM Benjamin Kaduk via Datatracker wrote: > I'm not sure I fully understand the security consequences of causing > the SPF macros %{s} and %{l} to never match when the local-part contains > non-ASCII characters, but they seem potentially quite bad. That is, if > the policy is intending to limit allowed senders to a specific list (or > block specific senders), would an attacker be able to avoid the > restriction by using a non-ASCII local-part? For the working group's consideration: I think this part of the discuss is a result of the draft appearing to specify a change in behavior for SPF, when all it's really doing is documenting the consequences of how EAI, SPF, and DNS interact. There's no change in security considerations because there's no change in the protocol. We're merely more clearly documenting the interaction. I'll leave it to the chairs/author/shepherd to decide how to respond to the discuss, but I think "we're just documenting how it implicitly works" is a more likely road to success than "meh, no one really uses that". Scott K From nobody Fri Apr 5 11:52:24 2019 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 E3BCF1205D8 for ; Fri, 5 Apr 2019 11:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FLtq9bD7; dkim=pass (1536-bit key) header.d=taugh.com header.b=pc7OZK9i Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GIxufIpsIDS for ; Fri, 5 Apr 2019 11:52:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94BE712008D for ; Fri, 5 Apr 2019 11:52:16 -0700 (PDT) Received: (qmail 79756 invoked from network); 5 Apr 2019 18:45:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13789.5ca7a24e.k1904; bh=gC3K9krae5rfw6iY+EoTW7fuLvidF7sd1Y2uXrwlJM4=; b=FLtq9bD7hm5VNEUaJsJ88NRWE/7f7kXslG5TvT10DkrC2fvQmxpaYEp+2gWg6S0PpXBlv9xrzRqFrtKTOmr9LY2QQvEvEeatcq1KUMZIBGRJLToTDRTu6+khubdyerQXL6dB9qs2xEN7M4i99/b1p1F6X3ZcHSvkXIsoj1mhveH7XL51kzyJiwcOlGtqXSIlu0SAPTa3cICqmdF5p/NztO7rd9nCGtltM2FT8S5gRiLkIwLv63OUZ/psGS4/dlJW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13789.5ca7a24e.k1904; bh=gC3K9krae5rfw6iY+EoTW7fuLvidF7sd1Y2uXrwlJM4=; b=pc7OZK9iSweF334rjke++Xzsq4yZo9mLGVYIhx7z5SuzxixZIb1GIewedVq4AOkBSS9daMj2PdQP1Ak6KnawdKQWWwUxjKLlz6lfMYR16PAh2DOtt1sH37QaLLgSxVS6ifwKqy35tf2xbGIg3P2BLSMjWNFEk0sTHPFF8kk5xB7TXpSwXogWakPKvYh/qPa31StouWY9+ucvN/ly+x88PcrngMUNV8GToq6AlKXDuNI+lzBUalupAHxpYMeGGgzW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Apr 2019 18:45:34 -0000 Date: 5 Apr 2019 14:45:33 -0400 Message-ID: From: "John R Levine" To: "Benjamin Kaduk" Cc: "The IESG" , dmarc-chairs@ietf.org, "Kurt Andersen" , dmarc@ietf.org In-Reply-To: <20190405180945.GF70202@kduck.mit.edu> References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> <20190405180945.GF70202@kduck.mit.edu> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 18:52:20 -0000 On Fri, 5 Apr 2019, Benjamin Kaduk wrote: > The whole premise of rigorous specifications is that anyone can jump in to > the ecosystem and implement something that interoperates, and in my opinion > the current presentation is not very accomodating to such a participant. We seem to have a fairly basic disagreement of who "anyone" would be. I'm assuming, and I think the WG is assuming, that the audience for this document is people who are already somewhat familiar with SPF or DKIM or DMARC. It appears that you believe it is possible to add enough mechanical detail that even someone who knows nothing about them could make these changes. That seems awfully optimistic. I don't fault you for not being an SPF or DKIM expert but I really don't think it is useful to add a lot of stuff that any plausible reader already knows. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 5 12:54:43 2019 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 DFBDE120602; Fri, 5 Apr 2019 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XIsvYKCVlaj; Fri, 5 Apr 2019 12:54:40 -0700 (PDT) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217B31205FB; Fri, 5 Apr 2019 12:54:40 -0700 (PDT) Received: by mail-it1-f181.google.com with SMTP id y204so11411473itf.3; Fri, 05 Apr 2019 12:54:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pPIVBrNiRhwH2X3X1fI01sCjoBCDlhsGfr4ubEQrRY4=; b=GMLg3dbbdHqCNeAjoDO6RvcR/WzHFlbxt0FaoZTkl/47ATj80HT638QPkTIFyuTcxW MaaGndti/QeuYZtY7Zmya8yanSeqEqj/tRA2r4zPxbZIS6dqub1v5gwYNi2iQkBKbMgi oRGzf+RF9oeTZBRG8r/nd87w2KgW0cJiAyUXbHfRavrN5lsDSkv1NVKiZlX81rW4IS9t 7bix+Z448bBMV/v1x588++iMBpwLlfbiU8zmgHiLWWMvJvT+zQwXMs6j5GJyZ6d9kk9l oHfokBWRecQIlgYjVysxf9AnfkjvkHlx7jS9d7mKqnEMf+W/S3FSQq30OksWEPiysI5X XErA== X-Gm-Message-State: APjAAAUl0cApeHAqP1m9uZMDBzzVZCxdWkMlO8DCa1ypxadPzNsFuinS pd7fyROgOdKSLJcf4PYN01in7+4JaVuZxBCF3JQ= X-Google-Smtp-Source: APXvYqwu+ihMQy7wHXsa+0NTuID0tgGP6XISL7UDJIail/9FBXWZYuPhO9RtPTyoBNi7eWeSwgvBRF6MmIC2DNcTLtM= X-Received: by 2002:a02:1384:: with SMTP id 126mr11702495jaz.72.1554494079069; Fri, 05 Apr 2019 12:54:39 -0700 (PDT) MIME-Version: 1.0 References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> <20190405180945.GF70202@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Fri, 5 Apr 2019 15:54:28 -0400 Message-ID: To: John R Levine Cc: Benjamin Kaduk , dmarc@ietf.org, Kurt Andersen , The IESG , dmarc-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 19:54:42 -0000 I had this discussion many times in my previous time as AD. The bottom line is that we can't explicitly specify everything, and need to strike a reasonable balance between making things clear to *anyone* and making things clear only to experts, or those who were around when the document was written. The balance is usually to aim the text to someone reasonably well versed in the area we're talking about -- short of an expert, but farther along than a beginner. Ben, I really do think the text you're talking about is fine, given that balance. One can't implement this without implementing the other related technology first: SPF, DKIM, DMARC, SMTP.... If this text is beyond one, one would never have gotten this far anyway, because one would have been stumped by knottier questions one doesn't have the background to deal with. So, yeah, we can insist on tweaking that text to make a few things more explicit, but it would not actually improve the document in a meaningful way. (One thing I'll pick at that I missed before, John: The phrasing "SHOULD do X but MAY do Y" doesn't really work: taken strictly, the MAY weakens the SHOULD. I would take the second key word out, and say "SHOULD do X but Y is permitted .") Barry On Fri, Apr 5, 2019 at 2:45 PM John R Levine wrote: > > On Fri, 5 Apr 2019, Benjamin Kaduk wrote: > > The whole premise of rigorous specifications is that anyone can jump in to > > the ecosystem and implement something that interoperates, and in my opinion > > the current presentation is not very accomodating to such a participant. > > We seem to have a fairly basic disagreement of who "anyone" would be. > I'm assuming, and I think the WG is assuming, that the audience for this > document is people who are already somewhat familiar with SPF or DKIM or > DMARC. It appears that you believe it is possible to add enough > mechanical detail that even someone who knows nothing about them could > make these changes. That seems awfully optimistic. > > I don't fault you for not being an SPF or DKIM expert but I really don't > think it is useful to add a lot of stuff that any plausible reader already > knows. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > From nobody Fri Apr 5 15:04:22 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C420120628; Fri, 5 Apr 2019 15:04:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155450186048.9987.11247255934150917477@ietfa.amsl.com> Date: Fri, 05 Apr 2019 15:04:20 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-eaiauth-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 22:04:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : E-mail Authentication for Internationalized Mail Author : John Levine Filename : draft-ietf-dmarc-eaiauth-05.txt Pages : 7 Date : 2019-04-05 Abstract: SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-eaiauth-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-eaiauth-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 5 15:05:52 2019 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 3C85612064F for ; Fri, 5 Apr 2019 15:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=KMKoybzN; dkim=pass (1536-bit key) header.d=taugh.com header.b=JNS+1zWT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uYCUo0JByAS for ; Fri, 5 Apr 2019 15:05:38 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A180120637 for ; Fri, 5 Apr 2019 15:05:38 -0700 (PDT) Received: (qmail 44751 invoked from network); 5 Apr 2019 22:05:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=aecd.5ca7d130.k1904; bh=tn6Z+VDKhwX6CFmnalJoEj8k9Uu43WdT3U9I2LsHUcA=; b=KMKoybzNCHlSxm96Mjlv+pilv2snaIVYp2cCmtkemGhF6b3pPg5AG3LYaRsNg5w8sZeUGcGL/Od54s2eBK0+ZdFKcFHg19hmCiCivFkdGMSRTy3VUCWGOWEFIKftVffp/5EbcsousM46JHPDmUswRWVWB+0Tfe0xDMH2TybRGtWQHOMfb00Kq+O5qmg+D7AX6zY1amgzvcGzv4DHhgMNLoFKv4km9nyh11n8MCBbPVzhIH0EP3HpIokrUKZSSkdm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=aecd.5ca7d130.k1904; bh=tn6Z+VDKhwX6CFmnalJoEj8k9Uu43WdT3U9I2LsHUcA=; b=JNS+1zWT/L63PZdDStDdRwC5lLVfVwlILUrlNwtJc5+CaaeIC5FlZesJUrB/fKzWZyAQx2Od//YH3PZZVjALZCJF/dUQOUDEDz6SOg4U8j1KqSG1NiR73S/nUUp5C3wZRRl0YnUk3s69hOwIso74M8GGMWrqe2hAVjtGPB9fL8CEZCEIM198Bi+4HJYzJMxCt4dQ0+OlOoWMt0K9edKCqqR7eEjZ48NPCiMeKF+mPo1yUEFN/6hAVJjlQTPeT0Nx Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Apr 2019 22:05:36 -0000 Date: 5 Apr 2019 18:05:36 -0400 Message-ID: From: "John R Levine" To: "Barry Leiba" Cc: "Benjamin Kaduk" , dmarc@ietf.org, "The IESG" In-Reply-To: References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> <20190405180945.GF70202@kduck.mit.edu> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 22:05:51 -0000 > (One thing I'll pick at that I missed before, John: The phrasing > "SHOULD do X but MAY do Y" doesn't really work: taken strictly, the > MAY weakens the SHOULD. I would take the second key word out, and say > "SHOULD do X but Y is permitted circumstances>.") OK, fixed that and Ben's catch of a dangling section ref in -05. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 5 17:21:56 2019 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 96E8712016F for ; Fri, 5 Apr 2019 17:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ciMLnBGi; dkim=pass (1536-bit key) header.d=taugh.com header.b=E/oV3b0e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iFNRHUV3zej for ; Fri, 5 Apr 2019 17:21:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C289F120043 for ; Fri, 5 Apr 2019 17:21:53 -0700 (PDT) Received: (qmail 81793 invoked from network); 6 Apr 2019 00:21:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13f7e.5ca7f120.k1904; bh=hpXlgozCrMziVtclIxG0gg6kmktq8+b6IPwwDqyuihA=; b=ciMLnBGioUEeUQkmTN4ItJ7cCJ9uHtBcgNl8dcO124GWI0hBfeOwbnXZKycrDa8DhjojtzEq5AddDArbsay+HIobaoQYCsvIJemEBPWJ6dW155DWvq5fHyeV5YKJMPwNpNU0t23KUaUucTZIjmhr1Mt9XrQT400UiB/lj2lB6zIUOKXbEBTM2NkognkhodeGL52PGbR4d8vy4j4Ay9mIjGbRTqefNqTJ8exzFJxQqOuxFLtWH63RpjyDtXuG699u DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13f7e.5ca7f120.k1904; bh=hpXlgozCrMziVtclIxG0gg6kmktq8+b6IPwwDqyuihA=; b=E/oV3b0ep5sRULYTXATtYVGtuV45RMLPr7XLga/iOJVEKd+OZwVu+6MpDJazmeIOF8lxSjY60zpSo5q9gVgne6/orAO4PL0Q7EMXcfYDn4sVl10JXk7RoWNtyzs4U/tTdrdTnvdr4YIIYqhfOBrE8AsdCUZTXi2/CXUC6N0ZeQ0W4GfnsI8lcOwignXQhJlJZubDsxpsPSSI7FA0RH7RvbhywtfP80C9WlfKHgm5Ny1YX+TxdXNAEHjK3+/aplNY Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Apr 2019 00:21:51 -0000 Received: by ary.qy (Postfix, from userid 501) id 9C07820119E9DC; Fri, 5 Apr 2019 20:21:50 -0400 (EDT) Date: 5 Apr 2019 20:21:50 -0400 Message-Id: <20190406002151.9C07820119E9DC@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <14007257.XvzNgCV7GG@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Apr 2019 00:21:56 -0000 In article <14007257.XvzNgCV7GG@kitterma-e6430> you write: >There's no change in security considerations because there's no change in the >protocol. We're merely more clearly documenting the interaction. I'll leave >it to the chairs/author/shepherd to decide how to respond to the discuss, but >I think "we're just documenting how it implicitly works" is a more likely road >to success than "meh, no one really uses that". Oh, of course. What I was trying to say was that's why we didn't try to invent a way to make it work with EAI mailboxes. From btv1==0019ccb4d59==fosterd@bayviewphysicians.com Sun Apr 7 17:02:47 2019 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 4DC0B12021C for ; Sun, 7 Apr 2019 17:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PXlt2zWiWzL for ; Sun, 7 Apr 2019 17:02:44 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D8612004C for ; Sun, 7 Apr 2019 17:02:43 -0700 (PDT) X-ASG-Debug-ID: 1554681761-0990573e6338690001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id rsiGnh1QyvoiaUCm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 07 Apr 2019 20:02:41 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=9t+uqiNnXGUGrHLRNDIrl8sXsN92TCLTLi95nRJW7f4=; b=W+Hr85GUmW1Xvd0HGI4sbfqAd04s88GisgFE2YHhmhxrF8zEf5fVrZH9M8VQoimYS 6k/zg/Fjlm0z6xkYNGPAMZThOwN30q8qeP8lAtKbF91SrpUxfOEIDP/Sn+LQuUN8z +H/6BYjHRBm5OwtuypPtJ4gv1GfzBeoMVXmpS1fHQ= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 7 Apr 2019 20:02:33 -0400 From: "Douglas E. Foster" To: Date: Sun, 7 Apr 2019 20:02:33 -0400 X-ASG-Orig-Subj: Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=9dc9cb119e5e494fb9c094f624cfefb4 X-Originating-IP: [192.168.1.239] X-Exim-Id: c588c5eeec224162bffd080693c703e1 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554681761 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 12262 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 00:18:26 -0000 This is a multipart message in MIME format. --9dc9cb119e5e494fb9c094f624cfefb4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I understand how much work it takes to create consensus toward an IETF standard, but I suggest that the problem needs to be re-examined because DMARC for PSDs seems to be neither the sufficient solution nor the necessary one. The problem: Spammers use non-existent domains to achieve identity spoofing, such as tax.example.gov.uk This is primarily a reception problem, because many recipient mail filters are not equipped to block this type of fraud. However, domain owners are also concerned about protecting their reputation from fraudulent material sent using their identity. These two sender-receiver combinations are already protected from the problem: Recipients with DMARC enforcement enabled if the message comes from a parent domain with DMARC-enforcing policy. Recipients who filter for non-existent domains, regardless of parent domain or receiver DMARC capability. These three sender-receiver combinations currently have no protection: Any recipient when the sender does not request DMARC enforcement (and non-existent domain filtering is also off.) Any recipient who lacks both DMARC enforcement capability and non-existent domain filtering.. Any recipient when the parent domain is a PSD (and non-existent domain filtering is also off.) The DMARC for PSD standard will only protect the last category of unprotected recipients. What can we assume about legitimate usage of non-existent subdomains? Non-existent subdomains support application-generated messages, not personal ones. Some messages will be transactional, where the recipient expects the message and will whitelist as necessary to ensure delivery. Some message will be marketing related, as a tool to support data collection related to specific marketing campaigns. The recipient probably does not expect the traffic, and is not likely to whitelist the traffic. The sender relies on the probability that most recipients do not filter on non-existent domains, so their non-standard business practice has minimal consequences for the sender. Possibly, some government cyber-warfare or cyber-intelligence operations use this feature. Whether this is legitimate or not depends on the government involved. It is unlikely that the recipient will consider the usage appropriate. Is there justification for IETF to tolerate or tacitly permit messages from non-existent domains? No. Before SPF, there was no method for a sender to announce a transmit-only domain, but that problem was solved a long time ago. Based on existing IETF standards, it is reasonable to conclude that: If a domain has not published either an MX record or a SPF record, then it is not a legitimate source of email. Obviously, domains with no NS record are also included Given all of the above, I hope the real solution is clear: We need to encourage recipients to block messages from non-existent domains (any domain that has no MX or SPF record published.) Whitellisting should be used for exceptions. Domain registration is not difficult and involves minimal cost, so there is no real justification for legitimate senders to maintain sloppy business practices. Implementation methods: Obtain a quorum of major mail-receiving organizations to announce that they will no longer accept messages from domains that are non-existent or not mail-enabled via an MX or SPF record (effective no later than mm/dd/yyyy). Exceptions require application on their registered-sender site, with justification. I expect that Google GMail and Microsoft LiveMail would be sufficient to be considered a quorum, and I assume they are represented on this distribution list. .The government domains could decide whether the best political strategy is to join the initial announcement or to mimic it shortly thereafter. Encourage mail filter vendors to provide non-existent domain filtering capability in their products, with the ability to confirm whitelisting as requested by the system administrator. .The major cloud-based email filtering services can add this protection to their clients, if it is not already present in their products. This brings another large group of recipients under protection To ensure that every recipient can implement non-existent domain filtering, it would be beneficial if non-existent domain checking becomes implemented as a Reputation Block List: When an email filter requests an RBL check on the domain name, the RBL checks for existence of at least one MX or SPF record. If none is found a reject address is returned. Since every email filtering product that I have encountered has support for RBL checking, this provides potential coverage for all recipients everywhere, and quickly. If IETF wants to provide a standards-based mechanism for mail-enabling a non-existent subdomain, this could be done as follow-up, using TXT records in the parent domain. Once promulgated, it would only be useful for senders who know that their recipients have email filters which apply the new standard. Outside a limited distribution group, this is not something that the sender can ever know. Consequently, I do not see this as a particularly useful undertaking, but I have no objection to it. Those who do not want to depend on recipient whitelisting should register their domains and publish an SPF record. It seems like this approach should be able to solve the whole problem in less than 6 months. Have I misunderstood the problem, or misunderstood your solution to it? Doug Foster --9dc9cb119e5e494fb9c094f624cfefb4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
I understand how much work it takes to create consensus toward an IETF= standard, but I suggest that the problem needs to be re-examined because D= MARC for PSDs seems to be neither the sufficient solution nor the nece= ssary one.
 
The problem:
  • Spammers use non-existent domains to achieve identity spoofing, such a= s tax.example.gov.uk
This is primarily a reception problem, because many recipient mail fil= ters are not equipped to block this type of fraud.  However, domain ow= ners are also concerned about protecting their reputation from fraudul= ent material sent using their identity.
 
These two sender-receiver combinations are already protected from= the problem:
  • Recipients with DMARC enforcement enabled if the message comes fr= om a parent domain with DMARC-enforcing policy.
  • Recipients who filter for non-existent domains, regardless of parent d= omain or receiver DMARC capability.
These three sender-receiver combinations currently have no protec= tion:
  • Any recipient when the sender does not request DMARC enforcement (and = non-existent domain filtering is also off.)
  • Any recipient who lacks both DMARC enforcement capability and non= -existent domain filtering..
  • Any recipient when the parent domain is a PSD (and non-existent domain= filtering is also off.)
The DMARC for PSD standard will only protect the last category of= unprotected recipients.
 
What can we assume about legitimate usage of non-existent subdomains?<= /div>
  • Non-existent subdomains support application-generated messages, n= ot personal ones.
  • Some messages will be transactional, where the recipient expects the m= essage and will whitelist as necessary to ensure delivery.
  • Some message will be marketing related, as a tool to support data coll= ection related to specific marketing campaigns.  The recipient probabl= y does not expect the traffic, and is not likely to whitelist the traf= fic.   The sender relies on the probability that most recipients = do not filter on non-existent domains, so their non-standard business = practice has minimal consequences for the sender.
  • Possibly, some government cyber-warfare or cyber-intelligence operatio= ns use this feature.   Whether this is legitimate or not depends = on the government involved.   It is unlikely that the recipient w= ill consider the usage appropriate.
Is there justification for IETF to tolerate or tacitly permit mes= sages from non-existent domains?
  • No.   Before SPF, there was no method for a sender to announ= ce a transmit-only domain, but that problem was solved a long time ago.&nbs= p;  Based on existing IETF standards, it is reasonable to conclude tha= t:
    • If a domain has not published either an MX record or a SPF recor= d, then it is not a legitimate source of email.   Obviously, doma= ins with no NS record are also included
Given all of the above, I hope the real solution is clear:
  • We need to encourage recipients to block messages from non-existent do= mains (any domain that has no MX or SPF record published.)  Whitellist= ing should be used for exceptions.  Domain registration is not difficu= lt and involves minimal cost, so there is no real justification for legitim= ate senders to maintain sloppy business practices.
Implementation methods:
  • Obtain a quorum of major mail-receiving organizations to announce that= they will no longer accept messages from domains that are non-existent or = not mail-enabled via an MX or SPF record  (effective no later than mm/= dd/yyyy).  Exceptions require application on  their registered-se= nder site, with justification.   I expect that Google GMail and M= icrosoft LiveMail would be sufficient to be considered a quorum, and I assu= me they are represented on this distribution list. .The governmen= t domains could decide whether the best political strategy is to join the i= nitial announcement or to mimic it shortly thereafter.
     
  • Encourage mail filter vendors to provide non-existent domain filtering= capability in their products, with the ability to confirm whitelistin= g as requested by the system administrator.   .The major cloud-ba= sed email filtering services can add this protection to their clients, if i= t is not already present in their products.   This brings another= large group of recipients under protection 
     
  • To ensure that every recipient can implement non-existent domain filte= ring, it would be beneficial if non-existent domain checking becomes implem= ented as a Reputation Block List:   When an email filter requests= an RBL check on the domain name, the RBL checks for existence of at least = one MX or SPF record.  If none is found a reject address is returned.&= nbsp; Since every email filtering product that I have encountered has suppo= rt for RBL checking, this provides potential coverage for all recipien= ts everywhere, and quickly.
     
  • If IETF wants to provide a standards-based mechanism for mail-ena= bling a non-existent subdomain, this could be done as follow-up, using = ;TXT records in the parent domain.  Once promulgated, it would only be= useful for senders who know that their recipients have email filters which= apply the new standard.   Outside a limited distribution group, = this is not something that the sender can ever know.   Consequent= ly, I do not see this as a particularly useful undertaking, but I have no o= bjection to it.   Those who do not want to depend on recipient wh= itelisting should register their domains and publish an SPF record. &n= bsp;
It seems like this approach should be able to solve the whole problem = in less than 6 months.
 
Have I misunderstood the problem, or misunderstood your solution to it= ?
 
Doug Foster
 
--9dc9cb119e5e494fb9c094f624cfefb4-- From nobody Sun Apr 7 17:50:51 2019 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 E428A12011A for ; Sun, 7 Apr 2019 17:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UCgxCwIj; dkim=pass (1536-bit key) header.d=taugh.com header.b=VGV9MGRQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_aFJ95PXGPz for ; Sun, 7 Apr 2019 17:50:48 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64CE120256 for ; Sun, 7 Apr 2019 17:50:47 -0700 (PDT) Received: (qmail 46159 invoked from network); 8 Apr 2019 00:50:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b44d.5caa9ae6.k1904; bh=+yJkXc6hHWPYdsGqDIyPpfWac4WkTtGJ+RMqfVU17mk=; b=UCgxCwIjWmntrkLWzcr9D7lsIKhrl22IkeeCvXaP/hR7OOjjKwJtV9XFl64otfnF+3dWtV4C0StOhjBUs00U2qVA3PQ1ezPK4TAc4Qo9g4WmUsdU9Nl0/DFYUOeLkPm2qmyD+lCck90osSfZkC3Tn+pXDwGYn7QiK0H2SQ6AtNEONh/wzLIIGBmCvuAeblhiqM7Bl46DqQgffbJiIhl01rOkQA96qj7FvmsAvts0vwjQShOK5+gAER1Z2l8UGBs4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b44d.5caa9ae6.k1904; bh=+yJkXc6hHWPYdsGqDIyPpfWac4WkTtGJ+RMqfVU17mk=; b=VGV9MGRQj/iWlGTIMdIUubBNFk1TRNiDprDvrPwgk0XKSEzfuvjwE1J6rN4+QiLG4fGUnKSxhv+y79RcQHPOuqUjWUbpChPiRhhTjKJbauqnYdYnHfB4Pyl5negzORykTFbxvejIjcPYxn10Jyin08C2rqWFBVCg1kH7kaAKeMs5twfBBm9bRWe4Vd1ltaBrPbVYgthnTdo9NobahMGVkfoH46xE701hGZEJ/YUwf//CUdieqTkzM45wDLCQ2FEr Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Apr 2019 00:50:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 5EC462011B2BFE; Sun, 7 Apr 2019 20:50:44 -0400 (EDT) Date: 7 Apr 2019 20:50:44 -0400 Message-Id: <20190408005045.5EC462011B2BFE@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 00:50:50 -0000 In article you write: > The problem: > Spammers use non-existent domains to achieve identity spoofing, such as >tax.example.gov.uk > This is primarily a reception problem, because many recipient mail filters >are not equipped to block this type of fraud. .. Right, and we can stop right there. A decent spam filter will treat a nonexistent From: domain or envelope bounce address as extremely suspicious and send the message into spam folder purgatory. If someone's filters aren't doing that, it is unlikely that they're paying much if any attention to DMARC, and no amount of fiddling with DMARC will make any difference. My mail server rejects anything with a non-existent bounce address at SMTP time and I don't think it's ever rejected anything my users would want. The solution to this problem is for mail systems to fix their filters, not to invent yet another mail-breaking hack that they won't use anyway. R's, John From nobody Sun Apr 7 18:59:45 2019 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 C2B0512039A for ; Sun, 7 Apr 2019 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ThvfQRRT; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mdtuABMV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB3q5oi2x55v for ; Sun, 7 Apr 2019 18:59:36 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B512120636 for ; Sun, 7 Apr 2019 18:59:36 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 09E11F807DE for ; Sun, 7 Apr 2019 21:59:35 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554688774; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=vsKZJkeDAX4tvbgENb6Nhy8gh2Cg5700mJf6HzNHOTk=; b=ThvfQRRT+XWv2gE05U3Gk1/XLqZhn/MbwdJ2w7oF6yiNbHavsyvItr6Y qFD6qIE5MVYxrUJHIqP1OuXCf10eAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554688774; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=vsKZJkeDAX4tvbgENb6Nhy8gh2Cg5700mJf6HzNHOTk=; b=mdtuABMVDxNucw1XTM3/AcitVoMyNLQyNBndyEFzz0ngj4Z5fMUH+QkZ PJNmD7tUCAUj0UaoJOvFRfoux3p9DRWAFTbfdqRfoPDFxca+ASC98d1Bz4 Ooy/T5feNBElrTdiguDMIEk//0Ysr5RpCvr1aHqUyZMqJBEaW34I+MJqIL FisOj2tonb1A/tPHGmyHnY0XchVJeGV4p/ZfaBYnoYk76oYs7VNt4Kk81q zpwwjjGNAsXFyi3HeAw7XzOVRA4SHhmX9GFxU2hxLoOre+sH1/j1DEEJOQ aL+Veguu88QZoipVTSDYuKUfxZU2jhmrV73VUSM7kQNkhRZ4gy/nWA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id CB27CF807D4 for ; Sun, 7 Apr 2019 21:59:34 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 07 Apr 2019 21:59:33 -0400 Message-ID: <2380056.rpXNijDuEj@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20190408005045.5EC462011B2BFE@ary.qy> References: <20190408005045.5EC462011B2BFE@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 01:59:44 -0000 On Sunday, April 07, 2019 08:50:44 PM John Levine wrote: > In article you write: > > The problem: > > Spammers use non-existent domains to achieve identity spoofing, such as > > > >tax.example.gov.uk > > > > This is primarily a reception problem, because many recipient mail filters > > > >are not equipped to block this type of fraud. .. > > Right, and we can stop right there. > > A decent spam filter will treat a nonexistent From: domain or envelope > bounce address as extremely suspicious and send the message into spam > folder purgatory. If someone's filters aren't doing that, it is > unlikely that they're paying much if any attention to DMARC, and no > amount of fiddling with DMARC will make any difference. > > My mail server rejects anything with a non-existent bounce address at > SMTP time and I don't think it's ever rejected anything my users would > want. > > The solution to this problem is for mail systems to fix their filters, > not to invent yet another mail-breaking hack that they won't use > anyway. Which mail breaking hack is that? Since PSD DMARC almost entirely applies to domains that don't send mail, I don't think it breaks anything. It is in part a tool to make hard rejects easier for receivers that don't typically reject solely due to non-existence and in part a tool to provide feedback to PSD operators so they can understand patters of abuse in their namespace. As I understand it, rejecting mail from non-existent domains is a long standing, well-known tool for receivers. I hear you saying it works for you in your circumstances, but that doesn't mean it scales. Given that rejecting non-existent domains is a well established option, but not everyone does it, what basis for optimism do you have that 'fix their filters' will change anything? If fixing filters was enough, would anyone bothered to have published: $ dig txt _dmarc.gov.uk +short "v=DMARC1\;p=reject\;sp=none\;adkim=s\;aspf=s\;fo=1\;rua=mailto:dmarc- rua@dmarc.service.gov.uk\;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk" All PSD DMARC would do is make that record apply to domains lower in the tree without their own DMARC record. It's not that complicated. Fielding of DMARC did a huge amount of damage to the e-mail ecosystem that I'm not convinced it will ever fully recover from, but PSD DMARC doesn't add to it. Scott K From nobody Sun Apr 7 20:42:50 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789912002E; Sun, 7 Apr 2019 20:42:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155469496909.18303.13613983804266247826.idtracker@ietfa.amsl.com> Date: Sun, 07 Apr 2019 20:42:49 -0700 Archived-At: Subject: [dmarc-ietf] Barry Leiba's No Objection on draft-ietf-dmarc-eaiauth-05: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 03:42:49 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dmarc-eaiauth-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 4 — An IDN in MAIL FROM can be either U-labels or A-labels. There’s a number agreement error here. Make it “...can use...,” (or “can include”) and I think that fixes it. From nobody Mon Apr 8 04:02:42 2019 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 24E951200D7 for ; Mon, 8 Apr 2019 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RP6N2fQNMKm for ; Mon, 8 Apr 2019 04:02:37 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F46F12006D for ; Mon, 8 Apr 2019 04:02:37 -0700 (PDT) X-ASG-Debug-ID: 1554721355-0990573e633e780001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id ooieDBf8DYjDEotm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 07:02:35 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=gdxLJzaMc/QDG539l2WTeyk5cBHQI1hpykjWW1pH5hc=; b=UmnJW1NDCdqEMprjynkFcPjUVN2SuoY/Xz7qwQsDmxmPlzqS/Jwc8Ncr2Hq7Qu/rI Cw37x6+QHB3hxt4CfcnBVRYppC/QUnFU34DHvyte+YWU6IkEaiQp+2h5stpwXlgxa gXbvRLFWOFGJM4rv0lkkVD30PEi3j3sjF07B7+4dA= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 07:02:26 -0400 From: "Douglas E. Foster" To: , "John Levine" Date: Mon, 8 Apr 2019 07:02:26 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=0c98ee675aff48e8a15f888fc383b12c X-Originating-IP: [192.168.1.239] In-Reply-To: <20190408005045.5EC462011B2BFE@ary.qy> References: <20190408005045.5EC462011B2BFE@ary.qy> X-Exim-Id: 034c10b67aaf41a7809430c3c3b64c84 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554721355 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 7407 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 11:02:40 -0000 This is a multipart message in MIME format. --0c98ee675aff48e8a15f888fc383b12c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mr Levine brings up the valid point that there are a lot of mail filters with inadequate capabilities. I determined that my two products have inexcusable weaknesses, so I went shopping. I had only these rudimentary requirements: IP filtering Reverse DNS filtering Multi-factor whitelisting or some other safe mechanism for handling SPF policy mistakes. DMARC policy enforcement A secure-email method for outbound messages with sensitive content No domain spoofing by the product that is supposed to protect from domain spoofing. I was blown away when I discovered: Products that could not do IP filtering. Products that could do DMARC enforcement but not Reverse DNS filtering, and the reverse. Vendors who had no idea what multi-factor whitelisting meant. High-end vendors who did domain spoofing in their secure-email solution. (They have been notified.) Along the way, I was referred to three industry-analyst reports, and was equally disappointed that the reports showed no evidence of a theoretical framework on which to judge vendor differences. At least one analyst declared the industry "mature", which struck me as odd given the damage done by WannaCry and the obvious problems in the products I have been examining. I currently have exactly ONE vendor that is probably adequate, but I curtailed the discussion when I realized his costs were way higher than what I can interest management in spending. Overall, it appears product vendors have no idea what is actually needed and why. Since bad email filters are the problem, why is there no IETF working group to define the expected behavior of email filters? More importantly, can we start one NOW? I have been preparing to submit an email filter evaluation RFC as an individual, since this group seemed uninterested after an earlier post. But it would be better as a working group document, and it might become standards-worthy. Doug Foster ---------------------------------------- From: "John Levine" Sent: Sunday, April 7, 2019 8:51 PM To: dmarc@ietf.org Cc: fosterd@bayviewphysicians.com Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs In article you write: > The problem: > Spammers use non-existent domains to achieve identity spoofing, such as >tax.example.gov.uk > This is primarily a reception problem, because many recipient mail filters >are not equipped to block this type of fraud. .. Right, and we can stop right there. A decent spam filter will treat a nonexistent From: domain or envelope bounce address as extremely suspicious and send the message into spam folder purgatory. If someone's filters aren't doing that, it is unlikely that they're paying much if any attention to DMARC, and no amount of fiddling with DMARC will make any difference. My mail server rejects anything with a non-existent bounce address at SMTP time and I don't think it's ever rejected anything my users would want. The solution to this problem is for mail systems to fix their filters, not to invent yet another mail-breaking hack that they won't use anyway. R's, John --0c98ee675aff48e8a15f888fc383b12c Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Mr Levine brings up the valid point that there are a lot of mail filte= rs with inadequate capabilities.   I determined that my two = products have inexcusable weaknesses, so I went shopping.   
I had only these rudimentary requirements:
  • IP filtering
  • Reverse DNS filtering
  • Multi-factor whitelisting or some other safe mechanism for handling SP= F policy mistakes.
  • DMARC policy enforcement
  • A secure-email method for outbound messages with sensitive conten= t
  • No domain spoofing by the product that is supposed to protect from dom= ain spoofing.
I was blown away when I discovered:
  • Products that could not do IP filtering.
  • Products that could do DMARC enforcement but not Reverse DNS filtering= , and the reverse.
  • Vendors who had no idea what multi-factor whitelisting meant.
  • High-end vendors who did domain spoofing in their secure-email solutio= n.  (They have been notified.)   
Along the way, I was referred to three industry-analyst reports, and w= as equally disappointed that the reports showed no evidence of a theor= etical framework on which to judge vendor differences.  At least = one analyst declared the industry "mature", which struck me as od= d given the damage done by WannaCry and the obvious problems in the product= s I have been examining.
 
I currently have exactly ONE vendor that is probably adequate, bu= t I curtailed the discussion when I realized his costs were way higher than= what I can interest management in spending.   Overall, it appear= s product vendors have no idea what is actually needed and why.
 
Since bad email filters are the problem, why is there no IETF working = group to define the expected behavior of email filters?    More i= mportantly, can we start one NOW?
 
I have been preparing to submit an email filter evaluation RFC as an i= ndividual, since this group seemed uninterested after an earlier post. = ;  But it would be better as a working group document, and it might be= come standards-worthy.
 
Doug Foster
 
From: "John Levine" <johnl@taugh.com>
Sent: Sunday, April 7, 2019 8:51 PM
To: dmarc@ietf.org
Cc: fosterd@bayviewphysicians.com
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
 
In article <c588c5eeec224162bffd080693c703e1@bayviewphysicians.com> y= ou write:
> The problem:
> Spammers use non-existent domains to achieve identity spoofing, such a= s
>tax.example.gov.uk
> This is primarily a reception problem, because many recipient mail fil= ters
>are not equipped to block this type of fraud. ..

Right, and we can stop right there.

A decent spam filter will treat a nonexistent From: domain or envelope
bounce address as extremely suspicious and send the message into spam
folder purgatory. If someone's filters aren't doing that, it is
unlikely that they're paying much if any attention to DMARC, and no
amount of fiddling with DMARC will make any difference.

My mail server rejects anything with a non-existent bounce address at
SMTP time and I don't think it's ever rejected anything my users would
want.

The solution to this problem is for mail systems to fix their filters,
not to invent yet another mail-breaking hack that they won't use
anyway.

R's,
John


 
--0c98ee675aff48e8a15f888fc383b12c-- From nobody Mon Apr 8 04:11:08 2019 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 D0F721202E7 for ; Mon, 8 Apr 2019 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVYLJYeZnSQ7 for ; Mon, 8 Apr 2019 04:10:59 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F391203D6 for ; Mon, 8 Apr 2019 04:10:59 -0700 (PDT) X-ASG-Debug-ID: 1554721857-0990573e633ea60001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id P2GzLMYvydN6WNmY (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 07:10:57 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=8ORfGKnPzCAJpgKX2JxdR7segzloXUGiyKlQkjJH/04=; b=ZppLa66wvkuGACc73eekUh6dfW6PPdfZhH2U6hVu3VwJU0UDCvLVDVkeZjxwhsWSE NGCaFThDlA1I0ZylxKWrxZskdAY/JBsFaWV+jsMmpTd0GEwU2r2OqR6vVP3QP7GG8 Pr6FW1TVmT1v4XdEI8zxfj9VxtlHKWklMSvayKjDM= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 07:10:49 -0400 From: "Douglas E. Foster" To: , "Scott Kitterman" Date: Mon, 8 Apr 2019 07:10:49 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: <4d1471de0a9c482e9a51a1a1deb2d71c@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=afe27a23aea84dbe8feb2cbc0a766b1a X-Originating-IP: [192.168.1.239] In-Reply-To: <2380056.rpXNijDuEj@kitterma-e6430> References: <20190408005045.5EC462011B2BFE@ary.qy> <2380056.rpXNijDuEj@kitterma-e6430> X-Exim-Id: 4d1471de0a9c482e9a51a1a1deb2d71c X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554721857 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 7676 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 11:11:07 -0000 This is a multipart message in MIME format. --afe27a23aea84dbe8feb2cbc0a766b1a Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Have the national CIRT groups made an issue about needing to block non-existent domains? Because a spammer can create a non-existent government agency like "irs.audit.gov", this email weakness becomes a national security issue and should be handled as a CVE. This should get the vendors moving. Has it been done? If not, perhaps Mr Levy would be willing to start the process on behalf of uk.gov. Doug Foster ---------------------------------------- From: "Scott Kitterman" Sent: Sunday, April 7, 2019 10:00 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs On Sunday, April 07, 2019 08:50:44 PM John Levine wrote: > In article you write: > > The problem: > > Spammers use non-existent domains to achieve identity spoofing, such as > > > >tax.example.gov.uk > > > > This is primarily a reception problem, because many recipient mail filters > > > >are not equipped to block this type of fraud. .. > > Right, and we can stop right there. > > A decent spam filter will treat a nonexistent From: domain or envelope > bounce address as extremely suspicious and send the message into spam > folder purgatory. If someone's filters aren't doing that, it is > unlikely that they're paying much if any attention to DMARC, and no > amount of fiddling with DMARC will make any difference. > > My mail server rejects anything with a non-existent bounce address at > SMTP time and I don't think it's ever rejected anything my users would > want. > > The solution to this problem is for mail systems to fix their filters, > not to invent yet another mail-breaking hack that they won't use > anyway. Which mail breaking hack is that? Since PSD DMARC almost entirely applies to domains that don't send mail, I don't think it breaks anything. It is in part a tool to make hard rejects easier for receivers that don't typically reject solely due to non-existence and in part a tool to provide feedback to PSD operators so they can understand patters of abuse in their namespace. As I understand it, rejecting mail from non-existent domains is a long standing, well-known tool for receivers. I hear you saying it works for you in your circumstances, but that doesn't mean it scales. Given that rejecting non-existent domains is a well established option, but not everyone does it, what basis for optimism do you have that 'fix their filters' will change anything? If fixing filters was enough, would anyone bothered to have published: $ dig txt _dmarc.gov.uk +short "v=DMARC1\;p=reject\;sp=none\;adkim=s\;aspf=s\;fo=1\;rua=mailto:dmarc- rua@dmarc.service.gov.uk\;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk" All PSD DMARC would do is make that record apply to domains lower in the tree without their own DMARC record. It's not that complicated. Fielding of DMARC did a huge amount of damage to the e-mail ecosystem that I'm not convinced it will ever fully recover from, but PSD DMARC doesn't add to it. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --afe27a23aea84dbe8feb2cbc0a766b1a Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Have the national CIRT groups made an issue about needing to block non= -existent domains?
 
Because a spammer can create a non-existent government agency lik= e "irs.audit.gov", this email weakness becomes a national se= curity issue and should be handled as a CVE.    This should get t= he vendors moving.  Has it been done?
 
If not, perhaps Mr Levy would be willing to start the process on = behalf of uk.gov.
 
Doug Foster
 
 
 
 
From: "Scott Kitterman" <sklist@kitterman.com>
Sent: Sunday, April 7, 2019 10:00 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
 
On Sunday, April 07, 2019 08:50:44 PM John Levine wrote:
> In article <c588c5eeec224162bffd080693c703e1@bayviewphysicians.com&= gt; you
write:
> > The problem:
> > Spammers use non-existent domains to achieve identity spoofing, s= uch as
> >
> >tax.example.gov.uk
> >
> > This is primarily a reception problem, because many recipient mai= l filters
> >
> >are not equipped to block this type of fraud. ..
>
> Right, and we can stop right there.
>
> A decent spam filter will treat a nonexistent From: domain or envelope=
> bounce address as extremely suspicious and send the message into spam<= br /> > folder purgatory. If someone's filters aren't doing that, it is
> unlikely that they're paying much if any attention to DMARC, and no > amount of fiddling with DMARC will make any difference.
>
> My mail server rejects anything with a non-existent bounce address at<= br /> > SMTP time and I don't think it's ever rejected anything my users would=
> want.
>
> The solution to this problem is for mail systems to fix their filters,=
> not to invent yet another mail-breaking hack that they won't use
> anyway.

Which mail breaking hack is that? Since PSD DMARC almost entirely applies t= o
domains that don't send mail, I don't think it breaks anything. It is in pa= rt
a tool to make hard rejects easier for receivers that don't typically rejec= t
solely due to non-existence and in part a tool to provide feedback to PSD operators so they can understand patters of abuse in their namespace.

As I understand it, rejecting mail from non-existent domains is a long
standing, well-known tool for receivers. I hear you saying it works for you=
in your circumstances, but that doesn't mean it scales. Given that rejectin= g
non-existent domains is a well established option, but not everyone does it= ,
what basis for optimism do you have that 'fix their filters' will change anything?

If fixing filters was enough, would anyone bothered to have published:

$ dig txt _dmarc.gov.uk +short
"v=3DDMARC1\;p=3Dreject\;sp=3Dnone\;adkim=3Ds\;aspf=3Ds\;fo=3D1\;rua= =3Dmailto:dmarc-
rua@dmarc.service.gov.uk\;ruf=3Dmailto:dmarc-ruf@dmarc.service.gov.uk"=

All PSD DMARC would do is make that record apply to domains lower in the tr= ee
without their own DMARC record. It's not that complicated.

Fielding of DMARC did a huge amount of damage to the e-mail ecosystem that = I'm
not convinced it will ever fully recover from, but PSD DMARC doesn't add to=
it.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 
 --afe27a23aea84dbe8feb2cbc0a766b1a-- From nobody Mon Apr 8 04:21:24 2019 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 1774F1202CD for ; Mon, 8 Apr 2019 04:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKhkUtDN-T94 for ; Mon, 8 Apr 2019 04:21:20 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A80312006D for ; Mon, 8 Apr 2019 04:21:20 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1554722480; b=NEH7zLg6PnxTN+LlcZvPIgyD/KZL8CAocnvsyrbkw9Df4dcF+Y8O8OpTm1yyDN5H9jZOJ8Vobm ORBzUtWOWjaethVuUlApw2+pLg5LD6QXmQ2WjwUrdElnJgYSmquvc6Nv5uTAoz0ojzRl2bsB79 1mF58scwgT1uzuFyryNTWhw=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1554722480; bh=6X2/rIgqzdjuJ3jZbOdEY/194l9uMtg0gJLV8P/KwGE=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=W/An9gfmnBAC8gTgm++DhnL8IrowSZUSqaz1JZlI1gDr+Tm+icsO2loqbl3CPfQ80cVob2Ibtm b9xsjf4pjPuzBuH+RXX+dpzAx1anEQXcIaVw2sqj+E0SdZ/3GqH8EGY2xG/tOmVA8ZPBHcQWGk 31YyWC1MBtk5WPxKjrFBCi0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=Dte0k7Dw+Kz1+QYzcmdFoIVC+FPJY6ESoBz/5KjpNXY=; b=B AUu/Gb/SfsWdNPljVeZUYxCl82vee24m3pymFGG3C29U6i7A5ShmvvjMq3Lr4N+TWgdVxaZ1Wi9V0 4wGmaG6sgbWUt45JiNBaCwoQojghGfMI5dWkIoFMOinbw4oS3b9NLW/rFyU0RyKaKIvx+WdoNNlVK P3PcrYXDNn4UEvww=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) by wizmail.org (Exim 4.92.106) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1hDSL0-0005Ur-Fj for dmarc@ietf.org (return-path ); Mon, 08 Apr 2019 11:21:18 +0000 To: dmarc@ietf.org References: <20190408005045.5EC462011B2BFE@ary.qy> <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <1d3e6511-b109-8540-af0f-e08d30649d45@wizmail.org> Date: Mon, 8 Apr 2019 12:21:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 11:21:22 -0000 On 08/04/2019 12:02, Douglas E. Foster wrote: > I had only these rudimentary requirements: > [...] A secure-email method for outbound messages with sensitive > content Rudimentary? How secure; what's your threat model? Those two things often don't go together. (I should declare an interest: Exim developer.) -- Jeremy From nobody Mon Apr 8 05:46:36 2019 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 2D6091202E6 for ; Mon, 8 Apr 2019 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lueEdhYY3glF for ; Mon, 8 Apr 2019 05:46:32 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29FD120086 for ; Mon, 8 Apr 2019 05:46:32 -0700 (PDT) X-ASG-Debug-ID: 1554727585-0990573e6341b90001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id poDVxD2qMRQpgiSz (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 08:46:25 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=ACEEM8ni3U62HGaA6GRgi40frJGWQKUsH5Mnu1y46uI=; b=fzbIGUlal7K6+aoBuLEQZvpBQljNC1H9kuyZ2+Q3NCl05CN2Mu71c+X/0qSzUb1t2 eCvUtog++lfTOVhxgkaH8OmE4vk0LDbjNf8+oDUuexPUk0mQpLunnTr7QawZUTp3b lSmDhlWEJfa/Mi/OM13Bi15ZdVnirh8rsZjSktIGg= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 08:46:15 -0400 From: "Douglas E. Foster" To: , "Jeremy Harris" Date: Mon, 8 Apr 2019 08:46:15 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=980a5be64a08435a871caae28c83e9ef X-Originating-IP: [192.168.73.35] In-Reply-To: <1d3e6511-b109-8540-af0f-e08d30649d45@wizmail.org> References: <20190408005045.5EC462011B2BFE@ary.qy> <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> <1d3e6511-b109-8540-af0f-e08d30649d45@wizmail.org> X-Exim-Id: caf60746797d46078aca66d28e65406f X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554727585 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 15259 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 12:46:35 -0000 This is a multipart message in MIME format. --980a5be64a08435a871caae28c83e9ef Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Your question confirms my core argument: We do not have consensus around email filter requirements because IETF has focused on sender behavior rather than recipient behavior. To the specifics: By "secure email relay", I am referring to Zixmail-type functioinality. It is complex code, generally involving a cloud server (although I would prefer keeping it on an appliance under my control). It is the least bad option for demonstrating regulatory compliance when transmitting sensitive information to an ad-hoc recipient. Most organizations need it. Further discussion on this point probably belongs in the MEDUP discussion. Use Cases I receive hositle mail from "server7.badexample.com". I want to block the IP address because I know it is a bad source. But I also want to blacklist the other servers at this organization, so I want hostname filtering to block *.badexample.com. I actually want to block anything from this organization, so I really want to block this entity anytime it appears in a HELO/EHLO name, a reply-to name, a list header name, a URL field, or a message-id field. But for simplicity in a low-end product that meets my budget, I will settle for IP and ReverseDNS filtering. DMARC has three components: detecting and enforcing sender DMARC policy, collecting feedback information and transmitting it to the sender, and interpreting feedback received for the sender domain. In a low-end product, I am only expecting policy enforcement, not the other two components. From a coding standpoint, it seems only slightly more complex than SPF enforcement or DKIM signature checking. From a regulatory standpoint, it is mandatory. If PayPal and Gmail have gone to the trouble to request DMARC enforcement, and I am devastated by malware because I did not check DMARC information,, then I am guilty of reckless negligence. So yes, DMARC enforcement is essential. Multi-factor whitelisting is needed because whitelisting (give this message high trust because the sender is trustworthy) is only safe if the sender is authenticated (the message really came from the trusted sender). Sender authenticator requires multiple attributes. Example: CompanyA.com uses HostingSevice.com. I want to ensure that messages from CompanyA.com are not blocked based on spam scoring heuristics. Siingle-factor whitelisting says that I can whitelist the sender (and expose myself to atacks from anyone spoofing their domain) or I can whitelist the source server (and expose myself to attacks from any other client domain at HostingService.com). When ReverseDNS is not an option, i have no feasible way to whitelist HostingService.com, because I have no way to know all of their servers and keep the list maintained over time. A related problem is that I should be able to do granular whitelisting, for example to ignore only spam scoring while retaining other tests. Many of the examined products provide all-or-nothing whitelist mechanisms. SPF corrections are a related issue, and multi-factor whitelisting would be a tolerable but inferior tool for handling the problem. What is really needed is a local override mechanism that can be expressed in SPF terms. SPF omissions can include (a) primary domain omitted a server from its list, (b) included domain omitted a server from its list, or (c) an entire domain is omitted from the list. Email filters should provide constructs to handle all three; None of the corrections require whitelisting. I do not necessarily want to guarantee delivery, I just want the SPF sender authentication function to be peerformed on accurate source data. On EXIM in particular: My secondary spam filter is based on EXIM, with a vendor-supplied wrapper and user interface. Because it is secondary, I am protected from some of the products weaknesses. Other system administrators routinely complain that when the message From-Address is there own domain, the message is not blocked. The product does not fitler on message From -Address, and my research into Exim capabilities indicated that the Exim filtering process could not even extract the message From-Address to reference in filtering. The product based on Exim cannot do ReverseDNS filtering. It looked like I might be able to simulate the capability with Exim filter syntax, but I gave up because I could not decipher how the vendor implemented its wrapper. The logging is a summary of all of the chatter between sending and receiving systems. The logs entries need to be assembled to present a single data record about what happened to this message. The vendor's GUI provides a crude approximation of this process,, but the GUI information cannot be exported. I finally wrote a bunch of complex code to turn the log detail into a message data record. The product based on Exim has only two SPF options: Off or Block. When it is off, it does not check or log SPF results. When it is on, it blocks the message so there is no data on which to evaluate false positives. If a false positive is detected despite the difficulties, the product only supports single-factor whitelisting, although it does provide granularity by feature. Since email filtering is a heuristic process,, the message review features are as important as the message filtering features. It should be possible to enable any filtering rule in two modes: without enforcement (learn mode) so that effectiveness and false positives can be evaluated and corrected prospectively, before the policy is enforced. with enforcement (policy mode) with sufficient data collected so that false positives can be detected and corrected retrospectively, after the policy is enforced. Consequently, I stand by the assertion that my feature list is the bare minimum for anything that claims to be a spam filter. It is not a complete list. For example RBL checking is also mandatory, but I have not seen that as an omitted feature, so it was omitted. Nothing in this list requires proprietary databases that only the richest vendors can offer. Doug Foster ---------------------------------------- From: "Jeremy Harris" Sent: Monday, April 8, 2019 7:21 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs On 08/04/2019 12:02, Douglas E. Foster wrote: > I had only these rudimentary requirements: > [...] A secure-email method for outbound messages with sensitive > content Rudimentary? How secure; what's your threat model? Those two things often don't go together. (I should declare an interest: Exim developer.) -- Jeremy _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --980a5be64a08435a871caae28c83e9ef Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Your question confirms my core argument:   We do not have co= nsensus around email filter requirements because IETF has focused on sender= behavior rather than recipient behavior.
 
To the specifics:
  • By "secure email relay", I am referring to Zixmail-type func= tioinality.  It is complex code, generally involving a cloud serv= er (although I would prefer keeping it on an appliance under my control).&n= bsp;  It is the least bad option for demonstrating regulatory complian= ce when transmitting sensitive information to an ad-hoc recipient.  Mo= st organizations need it.   Further discussion on this point prob= ably belongs in the MEDUP discussion.
Use Cases
  1. I receive hositle mail from "server7.badexample.com".  =  I want to block the IP address because I know it is a bad source.&nbs= p;  But I also want to blacklist the other servers at this organizatio= n, so I want hostname filtering to block *.badexample.com.  I actually= want to block anything from this organization, so I really want to bl= ock this entity anytime it appears in a HELO/EHLO name, a reply-to name, a = list header name, a URL field, or a message-id field.   But for s= implicity in a low-end product that meets my budget, I will settle for IP a= nd ReverseDNS filtering.
     
  2. DMARC has three components:  detecting and enforcing sender DMARC= policy, collecting feedback information and transmitting it to the sender,= and interpreting feedback received for the sender domain.   In a= low-end product, I am only expecting policy enforcement, not the other two= components.   From a coding standpoint, it seems only slightly m= ore complex than SPF enforcement or DKIM signature checking.   Fr= om a regulatory standpoint, it is mandatory.  If PayPal and Gmail have= gone to the trouble to request DMARC enforcement, and I am devastated by m= alware because I did not check DMARC information,, then I am guilty of reck= less negligence.   So yes, DMARC enforcement is essential.
     
  3. Multi-factor whitelisting is needed because whitelisting (give this me= ssage high trust because the sender is trustworthy) is only safe if the sen= der is authenticated (the message really came from the trusted sender).&nbs= p; Sender authenticator requires multiple attributes.

    Example:  CompanyA.com uses HostingSevice.com.   I want to = ensure that messages from CompanyA.com are not blocked based on spam scorin= g heuristics.   Siingle-factor whitelisting says that I can white= list the sender (and expose myself to atacks from anyone spoofing their dom= ain) or I can whitelist the source server (and expose myself to attacks fro= m any other client domain at HostingService.com).    When Re= verseDNS is not an option, i have no feasible way to whitelist HostingServi= ce.com, because I have no way to know all of their servers and keep the lis= t maintained over time.   A related problem is that I should be a= ble to do granular whitelisting, for example to ignore only spam scoring wh= ile retaining other tests.   Many of the examined products provid= e all-or-nothing whitelist mechanisms.
     
  4. SPF corrections are a related issue, and multi-factor whitelisting wou= ld be a tolerable but inferior tool for handling the problem.  What is= really needed is a local override mechanism that can be expressed in SPF t= erms.   SPF omissions can include (a) primary domain omitted a se= rver from its list, (b) included domain omitted a server from its list, or = (c) an entire domain is omitted from the list.   Email filters sh= ould provide constructs to handle all three;  None of the corrections = require whitelisting.   I do not necessarily want to guarantee de= livery, I just want the SPF sender authentication function to be peerformed= on accurate source data. 
On EXIM in particular:
 
My secondary spam filter is based on EXIM, with a vendor-supplied wrap= per and user interface.   Because it is secondary, I am protected= from some of the products weaknesses.
  • Other system administrators routinely complain that when the message F= rom-Address is there own domain, the message is not blocked.   Th= e product does not fitler on message From -Address, and my research into Ex= im capabilities indicated that the Exim filtering process could not even ex= tract the message From-Address to reference in filtering.
     
  • The product based on Exim cannot do ReverseDNS filtering.   = It looked like I might be able to simulate the capability with Exim filter = syntax, but I gave up because I could not decipher how the vendor implement= ed its wrapper.
     
  • The logging is a summary of all of the chatter between sending an= d receiving systems.   The logs entries need to be assembled to p= resent a single data record about what happened to this message.  &nbs= p;The vendor's GUI provides a crude approximation of this process,, bu= t the GUI information cannot be exported.  I finally wrote a bunch of = complex code to turn the log detail into a message data record.
     
  • The product based on Exim has only two SPF options:   Off or= Block.   When it is off, it does not check or log SPF results.&n= bsp; When it is on, it blocks the message so there is no data on which to e= valuate false positives.   If a false positive is detected despit= e the difficulties, the product only supports single-factor whitelisting, a= lthough it does provide granularity by feature.
     
  • Since email filtering is a heuristic process,, the message review feat= ures are as important as the message filtering features.  It should be= possible to enable any filtering rule in two modes:
    • without enforcement (learn mode) so that effectiveness and false posi= tives can be evaluated and corrected prospectively, before the policy is en= forced.
    • with enforcement (policy mode) with sufficient data collected so that= false positives can be detected and corrected retrospectively, after = the policy is enforced.
Consequently, I stand by the assertion that my feature list is th= e bare minimum for anything that claims to be a spam filter.  It = is not a complete list.  For example RBL checking is also mandatory, b= ut I have not seen that as an omitted feature, so it was omitted.  &nb= sp;Nothing in this list requires proprietary databases that only the riches= t vendors can offer.
 
Doug Foster
 
 
 
 
From: "Jeremy Harris" <jgh@wizmail.org>
Sent: Monday, April 8, 2019 7:21 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
 
On 08/04/2019 12:02, Douglas E. Foster wrote:
> I had only these rudimentary requirements:
> [...] A secure-email method for outbound messages with sensitive
> content
Rudimentary? How secure; what's your threat model?
Those two things often don't go together.

(I should declare an interest: Exim developer.)

--
Jeremy

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 
 --980a5be64a08435a871caae28c83e9ef-- From nobody Mon Apr 8 06:41:50 2019 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 C7BD012030F for ; Mon, 8 Apr 2019 06:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Hh1elsf/; dkim=pass (1536-bit key) header.d=taugh.com header.b=v9eewJSy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3NFUj_QWx2I for ; Mon, 8 Apr 2019 06:41:47 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EB61201BD for ; Mon, 8 Apr 2019 06:41:46 -0700 (PDT) Received: (qmail 27008 invoked from network); 8 Apr 2019 13:41:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=697d.5cab4f99.k1904; bh=++CHb4tUFbx9s6/516cwAa/k5q67sbtSas1jI3ef/3k=; b=Hh1elsf/vt0LiYz6UOSFQOk4uIsjdnjEXaMZo9LPK68h73f9SMx4Y/L+QdASl4a5BDEqiVdVYaenrTY9zhBRfEw/WGhURiHCMkufuO2v+PJLAgE1b2iKF7PtBkSCMLrfW26vBK4Z1rkHAkP8fyb+VI2kEr8YfbapGpNv6jY+FnkmgTLtwBQPtWMHucxnmWpumUvSVnFUCJrsdnK5h+I3e2oB9HPjH5P3s7Js5lmiM/SDBoWazBtqm9qLZ+efTSwG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=697d.5cab4f99.k1904; bh=++CHb4tUFbx9s6/516cwAa/k5q67sbtSas1jI3ef/3k=; b=v9eewJSyCMNcLox4fksvDsztHtUKuHsmsFgMHyMpsqtdM2hErMxjdW4uOrJZi0wSQQ5pXWx2PvPgcC4VP/RZUQ5ovZp8zYjfcLlKXCc4G8x5tW8tfKTCjHNx5XFGU5HB7IIAYuSupIkqlfore/VUngLU6NWmJRqgimFOg64dCR3meoZZveIN2LpBblu9CkAcRxRZfrDTaY7n/Vg1qKQ78IVl08GO0UQCKW2upGHnKuWQMXzV6+FQUVoftMYP5uEZ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Apr 2019 13:41:45 -0000 Date: 8 Apr 2019 09:41:44 -0400 Message-ID: From: "John R Levine" To: "Douglas E. Foster" Cc: dmarc@ietf.org In-Reply-To: <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> References: <20190408005045.5EC462011B2BFE@ary.qy> <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 13:41:49 -0000 > Since bad email filters are the problem, why is there no IETF working > group to define the expected behavior of email filters? More > importantly, can we start one NOW? It's kind of outside the IETF's expertise -- there are people in the IETF (not in this WG) who believe that DNSBLs were a failed experiment in the 1990s and nobody uses them any more. There's also the perverse incentive that if you define the way filters work, you're giving bad guys a road map to avoid them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Apr 8 06:50:23 2019 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 9EC6D120312 for ; Mon, 8 Apr 2019 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1old5TAomd6i for ; Mon, 8 Apr 2019 06:50:19 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BB712030F for ; Mon, 8 Apr 2019 06:50:19 -0700 (PDT) X-ASG-Debug-ID: 1554731416-0990573e6344a20001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 9uo7JcBaU3d0JXox (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 09:50:17 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=wW6DlRcZWlmVNX6kiXZCESTk4vhMGTfzaFdJzY+FKBI=; b=qE0zo3yfObAdbwqKGjejlkWkHnEXlDngdR0ZK64bzdouK/kIUJHiCG95VkDWPSyRn ptyJXnRW4HcGIyt9Nn3zJTy5oTN24ZK280hEpWuq9/mXUfzpqOOBEdcRc/gxhQHA2 aunTHyeNoWb+wlszS6UlFxQ2+WqAPP14rUqs+lykY= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 09:50:08 -0400 From: "Douglas E. Foster" To: "John R Levine" CC: Date: Mon, 8 Apr 2019 09:50:08 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=271c455e40294ad1bdc29618c5876ea0 X-Originating-IP: [192.168.73.35] In-Reply-To: References: <20190408005045.5EC462011B2BFE@ary.qy> <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> X-Exim-Id: e4eeecd07b4a482096e5f0eeb2cc5d45 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554731417 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4235 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 13:50:22 -0000 This is a multipart message in MIME format. --271c455e40294ad1bdc29618c5876ea0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RBLs are alive and well. I understand the risk of helping the bad guys, but I think the evidence is that silence is hurting the good guys more than the bad guys. My focus is on defining a framework for discussing product capabilities, while leaving room for vendors to add value above the minimum configuration. Demonstrating email legitimacy is essentially a protocol between sender and receiver. IETF has only defined one half of the protocol, so why should we be surprised that the conversation is broken. Expertise can be assembled; the task is desperately needed. In the interim, I am open to recommendations for good spam filters. I have been trying to avoid disparaging the bad ones by name in a public forum. Doug Foster ---------------------------------------- From: "John R Levine" Sent: Monday, April 8, 2019 9:41 AM To: "Douglas E. Foster" Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs > Since bad email filters are the problem, why is there no IETF working > group to define the expected behavior of email filters? More > importantly, can we start one NOW? It's kind of outside the IETF's expertise -- there are people in the IETF (not in this WG) who believe that DNSBLs were a failed experiment in the 1990s and nobody uses them any more. There's also the perverse incentive that if you define the way filters work, you're giving bad guys a road map to avoid them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --271c455e40294ad1bdc29618c5876ea0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
RBLs are alive and well.
 
I understand the risk of helping the bad guys, but I think the evidenc= e is that silence is hurting the good guys more than the bad guys= . 
 
My focus is on defining a framework for discussing product capabi= lities, while leaving room for vendors to add value above the minimum confi= guration.
 
Demonstrating email legitimacy is essentially a protocol between sende= r and receiver.   IETF has only defined one half of the protocol,= so why should we be surprised that the conversation is broken.   = ;Expertise can be assembled; the task is desperately needed.
 
In the interim, I am open to recommendations for good spam filter= s.   I have been trying to avoid disparaging the bad ones by= name in a public forum.
 
Doug Foster
 
 
From: "John R Levine" <johnl@taugh.com>
Sent: Monday, April 8, 2019 9:41 AM
To: "Douglas E. Foster" <fosterd@bayviewphysicians.com&= gt;
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
 
> Since bad email filters are the problem, why is there no IETF working<= br /> > group to define the expected behavior of email filters? More
> importantly, can we start one NOW?

It's kind of outside the IETF's expertise -- there are people in the IETF (not in this WG) who believe that DNSBLs were a failed experiment in the 1990s and nobody uses them any more.

There's also the perverse incentive that if you define the way filters
work, you're giving bad guys a road map to avoid them.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly  
 --271c455e40294ad1bdc29618c5876ea0-- From nobody Mon Apr 8 07:28:10 2019 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 2415A120416 for ; Mon, 8 Apr 2019 07:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wemonitoremail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUKyvFuHAhZP for ; Mon, 8 Apr 2019 07:27:59 -0700 (PDT) Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4577E120415 for ; Mon, 8 Apr 2019 07:27:59 -0700 (PDT) Received: from localhost [127.0.0.1] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1554733677; bh=5Btz/7/hagYSz5fjjj3Jrso9ULoKGYzwwsHeOF3L1Nk=; h=Subject:From:To:Date:In-Reply-To:References; b=tKEAMz5dV5olYDgTZ3Wi7OdTHK7CjZzrk6nF9BKFK1cXMOVZwhosE1qshArCEUe+e dGGEIqs0tVTzxXK12bu0GCkNLYgMiL6jb5TLWHp14tE/Fc+pcHzB39dvN7zkqwfKzH VHtLcQz2fNtxodSKzoVUC/9S3jG+JBgae41WdsCE= Message-ID: <3a4aad7d6d707f880b1e3d9a3fdabbc62e55bf32.camel@wemonitoremail.com> From: Ken O'Driscoll To: dmarc@ietf.org Date: Mon, 08 Apr 2019 15:27:55 +0100 In-Reply-To: References: <20190408005045.5EC462011B2BFE@ary.qy> <034c10b67aaf41a7809430c3c3b64c84@bayviewphysicians.com> Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.101.2 at email.wemonitoremail.com X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 14:28:08 -0000 On Mon, 2019-04-08 at 09:50 -0400, Douglas E. Foster wrote: [...snip...] > My focus is on defining a framework for discussing product capabilities, > while leaving room for vendors to add value above the minimum > configuration. That sounds more like what organisations such as Gartner are there for as opposed to the IEFT. And they do a fairly good job in framing vendor selection processes. > Demonstrating email legitimacy is essentially a protocol between sender > and receiver. IETF has only defined one half of the protocol, so why > should we be surprised that the conversation is broken. Expertise can > be assembled; the task is desperately needed. That's not exactly true. The protocols do explain how a receiver should implement them from a technical perspective. That ensures that there is no divergence between how say a SPF record is interpreted on a product by product basis. What they don't do, and what you appear to be alluding to, is proscribe how receivers should filter spam, and more specifically forged sender addresses from non-existent domains. The IETF don't make such proscriptions because a) it's off-mission and b) there is no one size fits all spam filter configuration. What works for a small office would be unsuitable for a large corporation, what works for a large corporation would be unsuitable for a hospital with a similar number of users and in turn, dealing with millions of users requires a completely different approach all together. > In the interim, I am open to recommendations for good spam filters. I > have been trying to avoid disparaging the bad ones by name in a public > forum. This list isn't the appropriate place for that discussion as it does not pertain to DMARC, despite the fact DMARC might be baked into some spam filtering solutions. Your starting point should be proper functional requirements specific to your organisation. Ken. From nobody Mon Apr 8 15:55:45 2019 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 C18F9120123 for ; Mon, 8 Apr 2019 15:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n3zg9a0qy-E for ; Mon, 8 Apr 2019 15:55:42 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB59120118 for ; Mon, 8 Apr 2019 15:55:41 -0700 (PDT) X-ASG-Debug-ID: 1554764140-0990573e635f790001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id oWdjMAn0FSCePQ0z (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 08 Apr 2019 18:55:40 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=xorY7xfGhBwgO3Qg6ZdpWxj6vEn5sj17gxlMnheXnDw=; b=kNvlwCtq8AT731FfA9bSVSDvepLZ7JmRY0rOIX/AnBzCbqCvGMl0U8CQFLnNbn35J kw92rYYyfbNpyxBpFuVC1j1nwZWox9M9KkQn/DIjaLlZKw6aarITMePD6+Ftn8PnH VkQsQt9kFsR275iwykVzK+92od5pYUe5KSYV5fff0= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 18:55:31 -0400 From: "Douglas E. Foster" To: Date: Mon, 8 Apr 2019 18:55:31 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: <08252783d22443e79b707537df97c872@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ef4592c37f07445c9073c05ac60d8985 X-Originating-IP: [192.168.1.239] X-Exim-Id: 08252783d22443e79b707537df97c872 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554764140 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 1212 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 22:55:44 -0000 This is a multipart message in MIME format. --ef4592c37f07445c9073c05ac60d8985 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't know how to express my shock at today's conversations. One of the shocks comes from this: We have consensus that the better email filters do not need the DMARC for PSDs standard, because they are already blocking non-existent domains. The inferior email filters are not expected to implement this feature, because they are inferior products. Therefore the new standard has no expected benefit, but we need to finish it anyway. Please explain. --ef4592c37f07445c9073c05ac60d8985 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
I don't know how to express my shock at today's conversations.  &= nbsp;One of the shocks comes from this:
 
We have consensus that the better email filters do not need the D= MARC for PSDs standard, because they are already blocking non-existent doma= ins.   The inferior email filters are not expected to implement t= his feature, because they are inferior products.   Therefore the = new standard has no expected benefit, but we need to finish it anyway.
 
Please explain.
 
--ef4592c37f07445c9073c05ac60d8985-- From nobody Mon Apr 8 15:59:37 2019 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 0E4CF120123 for ; Mon, 8 Apr 2019 15:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQuKb3zDY1TP for ; Mon, 8 Apr 2019 15:59:33 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19CF120121 for ; Mon, 8 Apr 2019 15:59:32 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id p10so18368946wrq.1 for ; Mon, 08 Apr 2019 15:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hOhksE/rnoJ8WzZONdFNHJdkQBxInOGGAlR7u6/amqo=; b=pFTYvC8fJni4l9TU65P9YoMLi8FKwO5i1O27uECmNykLAYYhFhLSW+KoQOAs6yIvPx 57aP9yrzNG3hJaRCUxkE4qeiB1V4YmcfiSwzHOG/tC1XDGGGTecarF6k0NLR5mMxW1yl 3muwHqhR0PGOP9WeU30SygLsq0pgw/owOkLfbK/EY7u2Y3naIv/FbWPNNmvLTOL7QpnO BM+DuJ7SoqqsAcb07eveqdFPKpWnqstp2j+Xq+NhRkMsZFGzqIQ3bkM7pd0PtRb4ElXG ni/Z+xmOxV8yJVd5P7x0acFJvAUl7/n4tupGmbIqCi0SNwdbvuI8NTP1ZyHxBkpB0JKN 4Yfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hOhksE/rnoJ8WzZONdFNHJdkQBxInOGGAlR7u6/amqo=; b=CJFx221VZv2oj7tf+JLE4DIG0D8VHd537pJvWn/CvUOKmSYv2tL3Knbi3dagnHLn2T tZcVnSN+npt1gn2osUgl2GBaY4Pe8trW+6AhJYZj+SGx1XnjGJnaQAOUoJJ2m0pBrG7k ckMunCdQpI1++WiCZ+iRcBBG9KdImzSRoMLo4vH/PGl0DL64bLuQVJQ3NxUYFGWGfsuX N4syHYfYOBNh3asJBzLrbOxbNiBOu0lNDwqS0h/s5ndfOGKnUV92YE9Ymh9czzz9Xynm mQiTR2tRTu0OC+kheGwm3b7te492+AzQybfPb35sxPhbR9IYmKRIrAww416ko3snCWVY 39Vg== X-Gm-Message-State: APjAAAUMPCEvk4Tmp4B7+7NCF89Bs7TlOFFKXrMzA2dU4RjIBn8esbgJ lozWIhcHz4BwBxuplAiK2pXaAcal2UAVuxigY9J6Ig== X-Google-Smtp-Source: APXvYqxAurvpC6fMfe1S9YIVBs/BtNcMSMRHZAYRoD4frKBo3up7rfAXDpkOoVe+v0e7ZxCPAUupOxtFTh1bzc/kaRk= X-Received: by 2002:adf:ea0b:: with SMTP id q11mr2251929wrm.233.1554764371268; Mon, 08 Apr 2019 15:59:31 -0700 (PDT) MIME-Version: 1.0 References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> In-Reply-To: <08252783d22443e79b707537df97c872@bayviewphysicians.com> From: Dotzero Date: Mon, 8 Apr 2019 18:59:20 -0400 Message-ID: To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000f192a05860cca4a" Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 22:59:35 -0000 --0000000000000f192a05860cca4a Content-Type: text/plain; charset="UTF-8" What part of that do you need an explanation for? It seems pretty clear to me. If you disagree with the statement then you should explain the rationale for your disagreement. Michael Hammer On Mon, Apr 8, 2019 at 6:55 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > I don't know how to express my shock at today's conversations. One of > the shocks comes from this: > > We have consensus that the better email filters do not need the DMARC for > PSDs standard, because they are already blocking non-existent domains. > The inferior email filters are not expected to implement this feature, > because they are inferior products. Therefore the new standard has no > expected benefit, but we need to finish it anyway. > > Please explain. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000000f192a05860cca4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What part of that do you need an explanation for? It seems= pretty clear to me. If you disagree with the statement then you should exp= lain the rationale for your disagreement.

Michael Hammer=

On Mon, Apr 8, 2019 at 6:55 PM Douglas E. Foster <fosterd@bayviewphysicians.com> wrot= e:
I don't= know how to express my shock at today's conversations.=C2=A0 =C2=A0One= of the shocks comes from this:
=C2=A0
We have consensus that the better email filters do not need the=C2=A0D= MARC for PSDs standard, because they are already blocking non-existent doma= ins.=C2=A0 =C2=A0The inferior email filters are not expected to implement t= his feature, because they are inferior products.=C2=A0 =C2=A0Therefore the = new standard has no expected benefit, but we need to finish it anyway.
=C2=A0
Please explain.
=C2=A0
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000000f192a05860cca4a-- From nobody Mon Apr 8 16:09:05 2019 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 A906E12011E for ; Mon, 8 Apr 2019 16:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAI3eCKNpWSc for ; Mon, 8 Apr 2019 16:08:57 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7922C120125 for ; Mon, 8 Apr 2019 16:08:57 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id q14so1960733itk.0 for ; Mon, 08 Apr 2019 16:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W2h34AVYzJ8WKZZGXNZuIVBAuf2C3ozaZsCVkmWCfzY=; b=eTYrpGGGqg0+DqOA6Oxx+tqV293ieMgrmgi/X5C9XJ/3oW7eGErSepQImAQOOxdGG4 i1Bz9WzEq3VOGTiGd9np4pjTuMbH+KDinRHL/96ZuNDELHFaOt5QPKxbfRxhS9DJ4wXm Bo2yO5jur9yTOFToa2qs3DEteyonPIoIPalfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W2h34AVYzJ8WKZZGXNZuIVBAuf2C3ozaZsCVkmWCfzY=; b=BtygJSC2gGyHtoHHDdlZTdKLR6vrQfYgqB3UMjOg2tle4MXGC43EyuY0gH8rPVmglb OwhXWW/KKdgZLM417XINFdIJ1Qdfo5HdjAXAnZE3eQmwObrA4sI1x+DopigEa0gYPesu KZmSPZW4JByKsqY75x3zTzSMZA0exBz9gz20K2lmvC/bNF50IBYhOVQoKaU8URwQhppd ELQcmCZQpLM3Li4Gx01LDHwhulXSl4sRdYJd8r1TmDX5Z8ubQvLjzjOFcSqg/94lWh5Y Sv0dKprKJQipRRZnBRKKaAr64QqpwrcQ19NI6qyZxTadcjf3F9kl43RMgtKEEwWqIhGe EOkQ== X-Gm-Message-State: APjAAAXr1nxk1mllMkC0ObnsL2yTJUB1L9zxk60J9cIWsoZaEhJyaniD c5T0pgpIEG0xgWrWGucN+64EP9PJkIrsEBU+IlaNzmimtdc= X-Google-Smtp-Source: APXvYqyoKs7QaXlJRXE8/eRPcMPTpjhvcu5u81/MN7IG+XaxVgOeT/+HQI4csCf1YP1+5MfrhwAv62iwiIm5deVL+z4= X-Received: by 2002:a02:8243:: with SMTP id q3mr24387898jag.37.1554764936635; Mon, 08 Apr 2019 16:08:56 -0700 (PDT) MIME-Version: 1.0 References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> In-Reply-To: <08252783d22443e79b707537df97c872@bayviewphysicians.com> From: "Kurt Andersen (b)" Date: Mon, 8 Apr 2019 16:08:30 -0700 Message-ID: To: fosterd@bayviewphysicians.com Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c2026505860ceb19" Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 23:09:04 -0000 --000000000000c2026505860ceb19 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > I don't know how to express my shock at today's conversations. One of > the shocks comes from this: > > We have consensus that the better email filters do not need the DMARC for > PSDs standard, because they are already blocking non-existent domains. > This neglects the benefit to the domain operators of receiving the reports about abuse of their domain space. For the end recipient of the bogus traffic, there is no difference. > The inferior email filters are not expected to implement this feature, > because they are inferior products. > Somewhat tautological, but most likely true. > Therefore the new standard has no expected benefit, but we need to finish > it anyway. > Incorrect - see my first point. --Kurt > --000000000000c2026505860ceb19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2019 at 3:55 PM Douglas E.= Foster <fosterd@bayvie= wphysicians.com> wrote:
I don't know how to express m= y shock at today's conversations.=C2=A0 =C2=A0One of the shocks comes f= rom this:
=C2=A0
We have consensus that the better email filters do not need the=C2=A0D= MARC for PSDs standard, because they are already blocking non-existent doma= ins.=C2=A0 =C2=A0

This neglect= s the benefit to the domain operators of receiving the reports about abuse = of their domain space. For the end recipient of the bogus traffic, there is= no difference.
=C2=A0
The inferior email filters are not expected to implement this = feature, because they are inferior products.=C2=A0 =C2=A0

Somewhat tautological, but most likely true.
=C2=A0
There= fore the new standard has no expected benefit, but we need to finish it any= way.

Incorrect - see my first = point.

--Kurt
--000000000000c2026505860ceb19-- From nobody Mon Apr 8 16:12:53 2019 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 B6599120123 for ; Mon, 8 Apr 2019 16:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=FBgDFAKE; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CvXvk0In Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUXFAZQvasiM for ; Mon, 8 Apr 2019 16:12:50 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA52A12011E for ; Mon, 8 Apr 2019 16:12:50 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id A9254F80920; Mon, 8 Apr 2019 19:12:48 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554765168; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=ph1xxQNYWcQuFjqaKATzt3VcOCNEkU7hbfY3nMoI7vk=; b=FBgDFAKEIlVebhL0y5om6HMNZAXaaxUIrxQQIyKomUaW7mRG9EzIGP/m X+7lAnlsXUjKBfbaBmJyltp6uLyhBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554765168; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=ph1xxQNYWcQuFjqaKATzt3VcOCNEkU7hbfY3nMoI7vk=; b=CvXvk0InnxZX5ehkDNG9NIdBvRJBg8mFzUJMXE5+LYP/ugfy/9EYxH7H 1crhGMg/bSH18tQkZxiknY4mSav7ZUek5AwH4lYfywZwjqDM/XWTKbqpRx 8jYMy0Dw9jDtiQaJZlapdKMN9vg0YcTGumkTi3o8k4lf8UF6naBo2Nslj/ nPTaekh8LDLS4f9PxtIx6HuRMWV0iBpiwZtNfobA4wX4gOtpOQH1OYgkfy u65jAn9uQ2tq7dLVLv1pHCPU5UuFwfrygwG2mtcSwMAMRsczlsibqZIHyy nw8Ar7ol1akdKxGov9sPmdC/iaMywGtF/9na4feVgqkrE300nEyg7g== Received: from [10.82.211.29] (mobile-166-170-31-60.mycingular.net [166.170.31.60]) by interserver.kitterman.com (Postfix) with ESMTPSA id 41C27F807D4; Mon, 8 Apr 2019 19:12:48 -0400 (EDT) Date: Mon, 08 Apr 2019 23:12:46 +0000 In-Reply-To: References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 23:12:53 -0000 On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" = wrote: >On Mon, Apr 8, 2019 at 3:55 PM Douglas E=2E Foster < >fosterd@bayviewphysicians=2Ecom> wrote: > >> I don't know how to express my shock at today's conversations=2E One >of >> the shocks comes from this: >> >> We have consensus that the better email filters do not need the DMARC >for >> PSDs standard, because they are already blocking non-existent >domains=2E >> > >This neglects the benefit to the domain operators of receiving the >reports >about abuse of their domain space=2E For the end recipient of the bogus >traffic, there is no difference=2E > > >> The inferior email filters are not expected to implement this >feature, >> because they are inferior products=2E >> > >Somewhat tautological, but most likely true=2E > > >> Therefore the new standard has no expected benefit, but we need to >finish >> it anyway=2E >> > >Incorrect - see my first point=2E The entire thing is further premised on the false premise that because two= small mail operators find one filtering technique appropriate for their si= tuation and scale, anyone that has a different design is inferior=2E Scott K From nobody Mon Apr 8 16:49:37 2019 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 C3CB01200C7 for ; Mon, 8 Apr 2019 16:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=5Jc/qt+l; dkim=pass (1536-bit key) header.d=taugh.com header.b=SCu4eMvD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1Dimz_alSO2 for ; Mon, 8 Apr 2019 16:49:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493441200B2 for ; Mon, 8 Apr 2019 16:49:34 -0700 (PDT) Received: (qmail 109 invoked from network); 8 Apr 2019 23:49:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6b.5cabde0c.k1904; bh=ndmZmzSjV3hK6+6qTlz2AGIttaLDEaCiIWBpACPHrR4=; b=5Jc/qt+l/ssFwxN6WmuUcCG1m9v1Ww3yu/U9d4+dtmQpurK9U+pD9KMVHBuox0I04WK0ZVL59lq9hFP3/XilUtciFi7V6DQuXRolk80xf4y4ZInzW6ieU24/5LMJF8NKu4Hr4t7h6Glh5C7FOFzxLa5/1L59pfmBWntsMqF+VvSWw1QYVu8MlvTbO8HzWv+3eT1tO9s6yZr8xfLaWHZ+cwZDdEVf1O4tkebGi+Y0ul9lYsQG5gFd4QluqW/EdVSw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6b.5cabde0c.k1904; bh=ndmZmzSjV3hK6+6qTlz2AGIttaLDEaCiIWBpACPHrR4=; b=SCu4eMvDWmMruJQLXqvX6zHRTsG7VY88OsFtYVu+v64BWup3xqmKcj7gCqZKDp3aa8zDrBO9mM4mWBWjMbuTtgYsT2RojhdvyCD2JYjtjUr+sc5nbPEkaVDAFoC16au8LjN7GMgVnJt5nFNxl/Z99HKmeVvH6jnlrO6OAIavQS+O8gP2eBn2vGitozHjfrHppPjVEMK44IxRm+EN/+iyaitSfn1920JXrhk+zSdymYFxBiVagt2mrhAt49VQmlNK Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Apr 2019 23:49:32 -0000 Received: by ary.qy (Postfix, from userid 501) id 2B3402011C0471; Mon, 8 Apr 2019 19:49:30 -0400 (EDT) Date: 8 Apr 2019 19:49:30 -0400 Message-Id: <20190408234932.2B3402011C0471@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 23:49:36 -0000 In article you write: >This neglects the benefit to the domain operators of receiving the reports >about abuse of their domain space. For the end recipient of the bogus >traffic, there is no difference. I agree that the reports are useful, regardless of the policy. I just wish we could figure out how to do this without reinventing the PSL. From btv1==0029a2ea2a4==fosterd@bayviewphysicians.com Mon Apr 8 17:07:51 2019 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 5619D1200E5 for ; Mon, 8 Apr 2019 17:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owGtCRz-gwFd for ; Mon, 8 Apr 2019 17:07:49 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAE31200C7 for ; Mon, 8 Apr 2019 17:07:49 -0700 (PDT) X-ASG-Debug-ID: 1554768467-0990573e63604e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id mWr0sjv7TL29mlgZ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 20:07:47 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=qf5A5CD7jed6QvDg+WZNZUgDmT99tyhsfooo7K6Mc9Y=; b=N3WbM2sdsJgCIIQv1nL895CLvUBcQ2MSxFQCGsjxxv0B2W0pOLfAhXUn+ujS0KAff I5JSpyoQ+FnMzLJVrzvhtPoowFqcCYzhvRA1+UKwcxu6y+C2wSZvOqbxVxUQsDtbB MfAEz6R0GXmSpvgW9uRgV2uPPgfmVXs32IZ/n+hjo= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 20:07:40 -0400 From: "Douglas E. Foster" To: "Kurt Andersen (b)" CC: "dmarc@ietf.org" Date: Mon, 8 Apr 2019 20:07:40 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: <2d4a44dd9a8c43f6871027bf82c27b57@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=8255ebf684b3417ba5e0b73a203d946e X-Originating-IP: [192.168.1.239] In-Reply-To: References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> X-Exim-Id: 2d4a44dd9a8c43f6871027bf82c27b57 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554768467 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 6846 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 00:08:55 -0000 This is a multipart message in MIME format. --8255ebf684b3417ba5e0b73a203d946e Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let's pursue the use cases for this information. Existing DMARC feedback has three uses, after interpretation: Compromised accounts: "Account appears to be comprised and sending spam. Please shut it down." Configuration errors: "We may have blocked legitimate mail, indicating that your SPF policy is incorrect or a sending entity is not applying DKIM signatures properly" Criminal activity: "Server is trying to send email using your identity, but failed to trick us." For non-existent domains, the first two use cases are not applicable. The last use case is an opportunity for law enforcement, so it may be particularly interesting to government PSDs. Keep in mind, however, that for ordinary folks like me, an unsuccessful attempt at electronic crime is not interesting to law enforcement, and will not trigger a response because there are always bigger problems to chase. On the technical side, the feedback to PSOs will only occur f the new feature (DMARC for PSDs) is given higher precedence than previous defenses (such as blocking non-existent domains or blacklisting bad IP addresses.) So precedence rules need to make it into the specification. ---------------------------------------- From: "Kurt Andersen (b)" Sent: Monday, April 8, 2019 7:09 PM To: fosterd@bayviewphysicians.com Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster wrote: I don't know how to express my shock at today's conversations. One of the shocks comes from this: We have consensus that the better email filters do not need the DMARC for PSDs standard, because they are already blocking non-existent domains. This neglects the benefit to the domain operators of receiving the reports about abuse of their domain space. For the end recipient of the bogus traffic, there is no difference. The inferior email filters are not expected to implement this feature, because they are inferior products. Somewhat tautological, but most likely true. Therefore the new standard has no expected benefit, but we need to finish it anyway. Incorrect - see my first point. --Kurt --8255ebf684b3417ba5e0b73a203d946e Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Let's pursue the use cases for this information.   Existing = DMARC feedback has three uses, after interpretation:
  • Compromised accounts:   "Account <username> = appears to be comprised and sending spam.   Please shut it down.&= quot;
  • Configuration errors: "We may have blocked legitimate mail, indic= ating that your SPF policy is incorrect or a sending entity is not applying= DKIM signatures properly"
  • Criminal activity: "Server <ipaddress> is trying to send em= ail using your identity, but failed to trick us."
For non-existent domains, the first two use cases are not applicable.&= nbsp;  The last use case is an opportunity for law enforcement, so it = may be particularly interesting to government PSDs.   Keep in min= d, however, that for ordinary folks like me, an unsuccessful attempt at ele= ctronic crime is not interesting to law enforcement, and will not trigger a= response because there are always bigger problems to chase.
 
On the technical side, the feedback to PSOs will only occur f the new = feature (DMARC for PSDs) is given higher precedence than previous defenses = (such as blocking non-existent domains or blacklisting bad IP addresses.)&n= bsp;   So precedence rules need to make it into the specification.
 
 
 
 
 
 
From: "Kurt Andersen (b)" <kboth@drkurt.com>
Sent: Monday, April 8, 2019 7:09 PM
To: fosterd@bayviewphysicians.com
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
 
On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:
= I don't know how to express my shock at today's conversations.   = One of the shocks comes from this:
=  
= We have consensus that the better email filters do not need the DMARC = for PSDs standard, because they are already blocking non-existent domains.&= nbsp;  
 
This neglects the benefit to the domain operators of receiving the rep= orts about abuse of their domain space. For the end recipient of the bogus = traffic, there is no difference.
 
= The inferior email filters are not expected to implement this feature, beca= use they are inferior products.   
 
Somewhat tautological, but most likely true.
 
= Therefore the new standard has no expected benefit, but we need to finish i= t anyway.
 
Incorrect - see my first point.
 
--Kurt
 
--8255ebf684b3417ba5e0b73a203d946e-- From nobody Mon Apr 8 17:27:19 2019 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 54BCD1200C7 for ; Mon, 8 Apr 2019 17:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCs3OqstEr9p for ; Mon, 8 Apr 2019 17:27:15 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2071200B2 for ; Mon, 8 Apr 2019 17:27:15 -0700 (PDT) X-ASG-Debug-ID: 1554769633-0990573e6360850001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id NHNXGqYbPz42CBDn (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 20:27:14 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=9L1ekYxDnMx8JLRPafoLwe3xaINn88f4RzoI58666Qk=; b=LAqcto5YhnjWKCNd6xipWdOl20NkrvESi3coyJ8fm75iF1cPeumEi4S4q1WRT3eaE W4riMxn6k3YYTbRinxOpFfBZTG0+w+YEWIUYCGPuECYRBEp90TGY9Pgds4M2Rt2AH tlWTwYPSX7OT7NaKMfm26wpCHtDg3k/Zb0hpO9UTs= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 8 Apr 2019 20:27:06 -0400 From: "Douglas E. Foster" To: , "Scott Kitterman" Date: Mon, 8 Apr 2019 20:27:06 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs Reply-To: fosterd@bayviewphysicians.com Message-ID: <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=497f17404f554734b20b27435daf6fa2 X-Originating-IP: [192.168.1.239] In-Reply-To: <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> X-Exim-Id: 3e3a5997f71544f1a29fca8845fcbf60 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1554769634 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 9214 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 00:27:17 -0000 This is a multipart message in MIME format. --497f17404f554734b20b27435daf6fa2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Scott, you misunderstand what this type of standard would look like. It would defines Use Cases that the device should address, with some acknowledgement to the tradeoffs between perceived risk and perceived difficulty of implementation. Implementation suggestions may be part of the use case. It would be hard to implement SPF-like capability without using SPF data, but there are many ways that SPF data could be utilized. There are also fundamental security principles that everyone should be following. "Trusted communication (whitelist) should not occur until and unless the identity of the correspondent is confirmed." Escalation of privilege (in this context, bypassing integrity tests) should be limited to the minimum necessary set of privileges to achieve the business requirement. Mr. O'Driscoll's comments seemed to make the same mistake. The configuration of email defenses will be different between a residential ISP, a large bank, and the US Army. However, the principles and use cases will be similar because any threat actor could take aim at any target. What differs is the perceived risk and the perceived complications from mitigating the risk, matched to each organizatoin's tolerance for risk. Nothing in this standard could be an absolute mandate, because only government has the legal authority to say "This product cannot be sold for purpose X because it does not have feature Y," It could say, "You must implement this feature to claim compliance with RFC xxxx" This type of standard can and would pressure vendors to move in the right direction. It would also help purchases know how to be more intelligent shoppers. There is plenty of difficulty in reaching a consensus statement on something like this, not least because each vendor wants to look acceptable, no matter how inferior his current product may be. Just because a topic is difficult does not mean there is no reason to discuss it. Working Groups exist because these issues take time and effort to flesh out. It is hard to argue that spam-getting-through is not an important topic, but I suppose some people may try to do so. ---------------------------------------- From: "Scott Kitterman" Sent: Monday, April 8, 2019 7:13 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" wrote: >On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster < >fosterd@bayviewphysicians.com> wrote: > >> I don't know how to express my shock at today's conversations. One >of >> the shocks comes from this: >> >> We have consensus that the better email filters do not need the DMARC >for >> PSDs standard, because they are already blocking non-existent >domains. >> > >This neglects the benefit to the domain operators of receiving the >reports >about abuse of their domain space. For the end recipient of the bogus >traffic, there is no difference. > > >> The inferior email filters are not expected to implement this >feature, >> because they are inferior products. >> > >Somewhat tautological, but most likely true. > > >> Therefore the new standard has no expected benefit, but we need to >finish >> it anyway. >> > >Incorrect - see my first point. The entire thing is further premised on the false premise that because two small mail operators find one filtering technique appropriate for their situation and scale, anyone that has a different design is inferior. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --497f17404f554734b20b27435daf6fa2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Scott, you misunderstand what this type of standard would lo= ok like.   It would defines Use Cases that the device should addr= ess, with some acknowledgement to the tradeoffs between perceived risk and = perceived difficulty of implementation. 
 
Implementation suggestions may be pa= rt of the use case.  It would be hard to implement SPF-like capab= ility without using SPF data, but there are many ways that SPF data could b= e utilized.   
 
There are also fundamental security = principles that everyone should be following.   
  • "Trusted communication (whitelist) should not occur until and unl= ess the identity of the correspondent is confirmed."
     
  • Escalation of privilege (in this context, bypassing integrity tests) s= hould be limited to the minimum necessary set of privileges to achieve the = business requirement.
Mr. O'Driscoll's comments seemed to = make the same mistake.   The configuration of email defenses will= be different between a residential ISP, a large bank, and the US Army.&nbs= p;  However, the principles and use cases will be similar because any = threat actor could take aim at any target.   What differs is the = perceived risk and the perceived complications from mitigating the risk, ma= tched to each organizatoin's tolerance for risk.
 
Nothing in this standard could be an= absolute mandate, because only government has the legal authorit= y to say "This product cannot be sold for purpose X because it do= es not have feature Y,"   It could say, "You must imple= ment this feature to claim compliance with RFC xxxx"   This = type of standard can and would pressure vendors to move in the right direct= ion.  It would also help purchases know how to be more intelligen= t shoppers. 
 
There is plenty of difficulty in rea= ching a consensus statement on something like this, not least because each = vendor wants to look acceptable, no matter how inferior his current product= may be.   Just because a topic is difficult does not mean there = is no reason to discuss it.   Working Groups exist because these = issues take time and effort to flesh out.   It is hard to argue t= hat spam-getting-through is not an important topic, but I suppose some= people may try to do so.
 
 
 
From: "Scott Kitterman" <sklist@kitterman.com>
Sent: Monday, April 8, 2019 7:13 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
 


On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" <kboth@d= rkurt.com> wrote:
>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <
>fosterd@bayviewphysicians.com> wrote:
>
>> I don't know how to express my shock at today's conversations. One=
>of
>> the shocks comes from this:
>>
>> We have consensus that the better email filters do not need the DM= ARC
>for
>> PSDs standard, because they are already blocking non-existent
>domains.
>>
>
>This neglects the benefit to the domain operators of receiving the
>reports
>about abuse of their domain space. For the end recipient of the bogus >traffic, there is no difference.
>
>
>> The inferior email filters are not expected to implement this
>feature,
>> because they are inferior products.
>>
>
>Somewhat tautological, but most likely true.
>
>
>> Therefore the new standard has no expected benefit, but we need to=
>finish
>> it anyway.
>>
>
>Incorrect - see my first point.

The entire thing is further premised on the false premise that because two = small mail operators find one filtering technique appropriate for their sit= uation and scale, anyone that has a different design is inferior.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 
 --497f17404f554734b20b27435daf6fa2-- From nobody Mon Apr 8 17:37:57 2019 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 4F356120162 for ; Mon, 8 Apr 2019 17:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=GlYETMyE; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Q5Hse2P4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK0oeESk0ahp for ; Mon, 8 Apr 2019 17:37:54 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1603B12014D for ; Mon, 8 Apr 2019 17:37:54 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 27C9BF80920; Mon, 8 Apr 2019 20:37:53 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=GlYETMyEgn+mqXdrHhoEcrf3DPDTv8avRXeFRRzv7tbUbikZkyEt8mGQ 94AmC/k8bE+GEr5WKQJPbDiXNJXFCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=Q5Hse2P4xgSvAN3eYIuY2h/UKhfG77H1v4I9HY+10BmIJ2046b7Pe5eM gXKS3gLLC1RYNNXvcXz4VS1HghIEHThOJVIOb+uwrgImUUjpfg5km8aEcr 8DktpVV206BAoz+h3Z7aHPXf/q/Nwc5VhZJwSajEKbslZhwSXgpsB8fOUk FgiCo0NNOe+O2sOHzCyRBgZ+8NrepnFl5jcL+TI+kVoq582qGyWS30Oi8u dRGYAlEBsQ9PLzIDuTlKvBbgOBfZoho/Lxo8TEMQJttfumBRuHZ/7epRg3 aK9cZPCsyWvbNmWCb267TsdH2N0Ab75bqZjjw4Q3tpqjEOhFvwrpOQ== Received: from [10.82.211.29] (mobile-166-170-31-60.mycingular.net [166.170.31.60]) by interserver.kitterman.com (Postfix) with ESMTPSA id 99F36F807D4; Mon, 8 Apr 2019 20:37:52 -0400 (EDT) Date: Tue, 09 Apr 2019 00:37:51 +0000 In-Reply-To: <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com> References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <7EFE60BD-0EBB-431D-AC6B-C63383ECDFD0@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 00:37:56 -0000 No, I think you seriously misunderstand what the IETF does=2E It doesn't d= o product specifications, it does interoperability specifications=2E This is seriously off-topic for the DMARC working group list anyway=2E Scott K P=2ES=2E There are open source components to accomplish all the requiremen= ts you listed, some assembly required=2E Discussion though should happen s= omewhere else=2E On April 9, 2019 12:27:06 AM UTC, "Douglas E=2E Foster" wrote: >Scott, you misunderstand what this type of standard would look like=2E = =20 >It=20 >would defines Use Cases that the device should address, with some=20 >acknowledgement to the tradeoffs between perceived risk and perceived=20 >difficulty of implementation=2E=20 > =20 >Implementation suggestions may be part of the use case=2E It would be >hard=20 >to implement SPF-like capability without using SPF data, but there are >many=20 >ways that SPF data could be utilized=2E =20 > =20 >There are also fundamental security principles that everyone should be=20 >following=2E =20 > "Trusted communication (whitelist) should not occur until and unless >the=20 >identity of the correspondent is confirmed=2E" > Escalation of privilege (in this context, bypassing integrity >tests)=20 >should be limited to the minimum necessary set of privileges to achieve >the=20 >business requirement=2E=20 > Mr=2E O'Driscoll's comments seemed to make the same mistake=2E The=20 >configuration of email defenses will be different between a residential > >ISP, a large bank, and the US Army=2E However, the principles and use >cases=20 >will be similar because any threat actor could take aim at any target=2E= =20 >=20 >What differs is the perceived risk and the perceived complications from > >mitigating the risk, matched to each organizatoin's tolerance for risk=2E > =20 > Nothing in this standard could be an absolute mandate, because only=20 >government has the legal authority to say "This product cannot be sold >for=20 >purpose X because it does not have feature Y," It could say, "You >must=20 >implement this feature to claim compliance with RFC xxxx" This type >of=20 >standard can and would pressure vendors to move in the right direction=2E > It=20 >would also help purchases know how to be more intelligent shoppers=2E=20 > =20 > There is plenty of difficulty in reaching a consensus statement on=20 >something like this, not least because each vendor wants to look=20 >acceptable, no matter how inferior his current product may be=2E Just= =20 >because a topic is difficult does not mean there is no reason to >discuss=20 >it=2E Working Groups exist because these issues take time and effort to > >flesh out=2E It is hard to argue that spam-getting-through is not an=20 >important topic, but I suppose some people may try to do so=2E > =20 > > =20 > =20 > >---------------------------------------- > From: "Scott Kitterman" >Sent: Monday, April 8, 2019 7:13 PM >To: dmarc@ietf=2Eorg >Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs =20 > >On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" >=20 >wrote: >>On Mon, Apr 8, 2019 at 3:55 PM Douglas E=2E Foster < >>fosterd@bayviewphysicians=2Ecom> wrote: >> >>> I don't know how to express my shock at today's conversations=2E One >>of >>> the shocks comes from this: >>> >>> We have consensus that the better email filters do not need the >DMARC >>for >>> PSDs standard, because they are already blocking non-existent >>domains=2E >>> >> >>This neglects the benefit to the domain operators of receiving the >>reports >>about abuse of their domain space=2E For the end recipient of the bogus >>traffic, there is no difference=2E >> >> >>> The inferior email filters are not expected to implement this >>feature, >>> because they are inferior products=2E >>> >> >>Somewhat tautological, but most likely true=2E >> >> >>> Therefore the new standard has no expected benefit, but we need to >>finish >>> it anyway=2E >>> >> >>Incorrect - see my first point=2E > >The entire thing is further premised on the false premise that because >two=20 >small mail operators find one filtering technique appropriate for their > >situation and scale, anyone that has a different design is inferior=2E > >Scott K > >_______________________________________________ >dmarc mailing list >dmarc@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dmarc >=20 From nobody Mon Apr 8 19:27:16 2019 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 A4B3E12013C for ; Mon, 8 Apr 2019 19:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adN8nKuQm6GL for ; Mon, 8 Apr 2019 19:27:13 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9528E120077 for ; Mon, 8 Apr 2019 19:27:12 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id y6so13005278ljd.12 for ; Mon, 08 Apr 2019 19:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+bTZNcZJImkgygSCTcye0VcQzpX1q06LtrDR3bjsBwo=; b=iq4iHvOfDSyNLvkZFs2cBe2l66M/25x+T2W4vKnZbnqUwS583U6RxUraYv54+b7UBj Dnh72jbr5K5yBZPeDILUyhox9oOFeNSg4yAd83eA0rwtPi4MuI2cvKbsnn2lATXluY4I dM2jBZZ1qkHAFvdhaN5OQGhffwByrM+NqwrEJ9VQYJdoXusvWsT/2XKUAOd/E25mRzYD PlfgRFiaB9SB1EVXdy9iQBOvcyBkzXhUUHSLHZ0Zr5rXOCf/qa/CVF2HzXCyVfsa7RM4 lzCiQIxGWPG0Y+faygtDa+1buhAK+LTTMRHbaooF8giH9JR+8bExPbPEEJBmxrUTVB7Y jKBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+bTZNcZJImkgygSCTcye0VcQzpX1q06LtrDR3bjsBwo=; b=ltrK1fXlu2X/a4lvY1sqq6v9lZh4HWOvYmR0+F2OiqZ6L0e5ygehvKx277QtWh5LZt yfQdAL/58HWUkEUjvZ0wEdfSlx223XV2OPdc6k3hO9O39QNilZh9bepmEmHKgZpyxA/l dSUlEEd5M7Xs0B8MtPy6hR28tgPQiA2thds446aM2ZE8tyC3jWKjLpuvEBohGdlFPMUw KN+YoN5PTRoYCCzMLevtTSBHjI0q53/q1yLFEeIlOGHsjmHhqvk86bjk59hSYxO369F+ CUDuc+jmNtnSD7mcZsI75GwGpb03KfcSHXv4dBryo+QntCjHMCGZY1zOYtGJprhOWBrb j7fw== X-Gm-Message-State: APjAAAVTgRZQ/z/w8jp6g5eR+UzGs3WaFAlRgjayyRu9uUvX9nxIqtYU RowR1F1hIwPgMeh0fKKyGbEg8Pbwn2DRBaqHUAJpvw== X-Google-Smtp-Source: APXvYqz/VgOq6Y/IN3zKFxZcsStrVmgXp1WVm3xeKkZH/kIidILROgwkTAFr7HJ7ULd49CE828/ImjkQa3wPmL2w3y4= X-Received: by 2002:a2e:8e96:: with SMTP id z22mr17673084ljk.123.1554776830670; Mon, 08 Apr 2019 19:27:10 -0700 (PDT) MIME-Version: 1.0 References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com> In-Reply-To: <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Mon, 8 Apr 2019 19:26:56 -0700 Message-ID: To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000b27b8005860fb0fa" Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 02:27:15 -0000 --000000000000b27b8005860fb0fa Content-Type: text/plain; charset="UTF-8" On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > Scott, you misunderstand what this type of standard would look like. It > would defines Use Cases that the device should address, with some > acknowledgement to the tradeoffs between perceived risk and perceived > difficulty of implementation. > If what you're looking to do is drum up interest for working on this and, if there's critical mass to do the work, getting something published, I suggest any of the following: ietf-822@ietf.org (message format discussions) ietf-smtp@ietf.org (SMTP discussions) art@ietf.org (ART area general discussions) dispatch@ietf.org (once you have an actual proposal for work that needs a home) ...possibly others, but those spring immediately to mind. However, I believe Scott is correct that this work is not currently within our charter, and thus it's off-topic for this list. I don't believe there's any working group currently chartered to produce something like what's being proposed here; EXTRA probably comes closest, and I think it's off-topic there too. Some years ago Dave Crocker and I assembled RFC 6647 about greylisting, which was an applicability statement over email in general that talked about how to implement greylisting. You could follow that model if you like, which merits standards track publication, though that means you'll need to convince an AD to sponsor it or form a working group to develop it. If my co-chair concurs, then it's appropriate that this conversation be moved elsewhere. -MSK --000000000000b27b8005860fb0fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<chair hat on>

On Mon, Apr 8, 2019 at 5:27 P= M Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:
Scott, you misunderstand what = this type of=C2=A0standard=C2=A0would look like.=C2=A0 =C2=A0It would defin= es Use Cases that the device should address, with some acknowledgement to t= he tradeoffs between perceived risk and perceived difficulty of implementat= ion.=C2=A0

If what you're = looking to do is drum up interest for working on this and, if there's c= ritical mass to do the work, getting something published, I suggest any of = the following:

ietf-822@ietf.org (message format discussions)
ietf-smtp@ietf.o= rg (SMTP discussions)
art@ietf.org (ART area general discussions)
dispatch@ietf.org (once you have an = actual proposal for work that needs a home)

..= .possibly others, but those spring immediately to mind.=C2=A0 However, I be= lieve Scott is correct that this work is not currently within our charter, = and thus it's off-topic for this list.=C2=A0 I don't believe there&= #39;s any working group currently chartered to produce something like what&= #39;s being proposed here; EXTRA probably comes closest, and I think it'= ;s off-topic there too.

Some years ago Dave Crocke= r and I assembled RFC 6647 about greylisting, which was an applicability st= atement over email in general that talked about how to implement greylistin= g.=C2=A0 You could follow that model if you like, which merits standards tr= ack publication, though that means you'll need to convince an AD to spo= nsor it or form a working group to develop it.

If = my co-chair concurs, then it's appropriate that this conversation be mo= ved elsewhere.

-MSK
--000000000000b27b8005860fb0fa-- From nobody Mon Apr 8 19:46:41 2019 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 11EAD12010C for ; Mon, 8 Apr 2019 19:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuD0LoWyOQWS for ; Mon, 8 Apr 2019 19:46:38 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4CF1200CC for ; Mon, 8 Apr 2019 19:46:38 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id j132so12300681oib.2 for ; Mon, 08 Apr 2019 19:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vt+2Lg95Fr7v7mxHuPqTpd8hDQGP3v913iWUadWwLOw=; b=p8b7BHlTDedQEnqItAxuw2mTEbenSCKUE5paYwdQZlu+9Z2s6KfSWEOCqCt7/jXtMG GY6icms+SgBIoOb7NopUtJmkh3EygXi0jR8ZnpAecT/3O0Q4noQiBUpfD0S2RuSbPfnZ Wn1QFZuK/8h4OYzkhoRIFlp+rq6mM7zMuwKB6cDC3L2o1OTFrQ/IOOX6Ah3TC5AX8V9D 2YHRHGoNTwVsbvDhY6juNf9g7Ww8wS6Ng28KNY461hjmy1SQEFRAvbCiBdxfgIO07scf 6ud8neylxGyicEVla9dru3+ilOGIAD4oZxUvDMszZnWYaPxI970wkfBAZ1N7ku/0vxi7 8krA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vt+2Lg95Fr7v7mxHuPqTpd8hDQGP3v913iWUadWwLOw=; b=lRr/rB6eK7ZwbdPNRhqdZC5Xmz4fitSz8IRo1bq7lLYvpYwir3REN8hD8UCCRSP1BW DoR7aFjdGEh76A1ufxE0/1l8OA4oXWAjVTnkptB/F5JuKbujr4A5wOGTAozE0oT/KBAq vp/kzyOWjayf5oW5KVkGNlritQ5uSDS3pcpWruhJHNOFUDT6QrDyhqADtcx44CsCcA1R eHCQGPSuxED59mGF/qiTsLuJjEbzRrpnlHFfATHijE72uUbt93wJ49bIE5zWYjWs6zNi Bs3cAALWj2IT2F2CR9MyXSB+73N/eE1xWXX1eVfNaePGz3b3cDy+jnT+geUhPSNOyHxw csog== X-Gm-Message-State: APjAAAVpo49B6XLwnw5s0gYHpIU0t1ecwTO2fnVBXWHal+TGok84yx82 Etx5VJGYxV/svbimIrtf0vGM7HEM3l8bPRfUPz8= X-Google-Smtp-Source: APXvYqzeLDPr9CCXp1PyChIQK1D0FEUZsmwAzqrsr23W1eNY8cdXJNSmdSn6Zn5sQTK8npz7V1vR3sxYhW9zt2CaEGg= X-Received: by 2002:aca:be07:: with SMTP id o7mr6198097oif.118.1554777997439; Mon, 08 Apr 2019 19:46:37 -0700 (PDT) MIME-Version: 1.0 References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com> In-Reply-To: From: Tim Wicinski Date: Mon, 8 Apr 2019 22:46:25 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: fosterd@bayviewphysicians.com, IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="0000000000003df7d105860ff6ac" Archived-At: Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 02:46:40 -0000 --0000000000003df7d105860ff6ac Content-Type: text/plain; charset="UTF-8" +1 on moving the discussion elsewhere Tim On Mon, Apr 8, 2019 at 10:27 PM Murray S. Kucherawy wrote: > > > On Mon, Apr 8, 2019 at 5:27 PM Douglas E. Foster < > fosterd@bayviewphysicians.com> wrote: > >> Scott, you misunderstand what this type of standard would look like. It >> would defines Use Cases that the device should address, with some >> acknowledgement to the tradeoffs between perceived risk and perceived >> difficulty of implementation. >> > > If what you're looking to do is drum up interest for working on this and, > if there's critical mass to do the work, getting something published, I > suggest any of the following: > > ietf-822@ietf.org (message format discussions) > ietf-smtp@ietf.org (SMTP discussions) > art@ietf.org (ART area general discussions) > dispatch@ietf.org (once you have an actual proposal for work that needs a > home) > > ....possibly others, but those spring immediately to mind. However, I > believe Scott is correct that this work is not currently within our > charter, and thus it's off-topic for this list. I don't believe there's > any working group currently chartered to produce something like what's > being proposed here; EXTRA probably comes closest, and I think it's > off-topic there too. > > Some years ago Dave Crocker and I assembled RFC 6647 about greylisting, > which was an applicability statement over email in general that talked > about how to implement greylisting. You could follow that model if you > like, which merits standards track publication, though that means you'll > need to convince an AD to sponsor it or form a working group to develop it. > > If my co-chair concurs, then it's appropriate that this conversation be > moved elsewhere. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000003df7d105860ff6ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on moving the discussion elsewhere

Tim

On Mon, Apr 8, 2019 at 10:27 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
<chair hat on>

<= div class=3D"gmail_quote">
On Mon, Apr= 8, 2019 at 5:27 PM Douglas E. Foster <fosterd@bayviewphysicians.com> wro= te:
Scott, you misunderstand what this type of=C2= =A0standard=C2=A0would look like.=C2=A0 =C2=A0It would defines Use Cases th= at the device should address, with some acknowledgement to the tradeoffs be= tween perceived risk and perceived difficulty of implementation.=C2=A0

If what you're looking to do i= s drum up interest for working on this and, if there's critical mass to= do the work, getting something published, I suggest any of the following:<= br>
ie= tf-822@ietf.org (message format discussions)
ietf-smtp@ietf.org (SMTP di= scussions)
= art@ietf.org (ART area general discussions)
dispatch@ietf.org (once you have = an actual proposal for work that needs a home)

....possibly others, but those spring immediately to mind.=C2=A0 However, = I believe Scott is correct that this work is not currently within our chart= er, and thus it's off-topic for this list.=C2=A0 I don't believe th= ere's any working group currently chartered to produce something like w= hat's being proposed here; EXTRA probably comes closest, and I think it= 's off-topic there too.

Some years ago Dave Cr= ocker and I assembled RFC 6647 about greylisting, which was an applicabilit= y statement over email in general that talked about how to implement greyli= sting.=C2=A0 You could follow that model if you like, which merits standard= s track publication, though that means you'll need to convince an AD to= sponsor it or form a working group to develop it.

If my co-chair concurs, then it's appropriate that this conversation b= e moved elsewhere.

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000003df7d105860ff6ac-- From nobody Tue Apr 9 10:26:39 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE45120047; Tue, 9 Apr 2019 10:26:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155483079217.19501.1750110168379625362.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2019 10:26:32 -0700 Archived-At: Subject: [dmarc-ietf] Roman Danyliw's No Objection on draft-ietf-dmarc-eaiauth-05: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 17:26:32 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-dmarc-eaiauth-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clarifications this draft provides to deployed technologies. A few comments: (1) Support Ben’s first DISCUSS asking questions about macro expansion (2) A process question – are there any issues with a IETF stream proposed standard draft (this draft) updating an ISE stream published document (RFC7489)? (3) Section 3, Please expand “EAI” on first use. It isn’t in the RFC Editor Abbreviations List -- https://www.rfc-editor.org/materials/abbrev.expansion.txt (4) Section 4 says, “Since the EHLO command precedes the server response that tells whether the server supports the SMTPUTF8 extension , an IDN argument MUST be represented as an A-label.” Is the “IDN argument” in question the hostname used in the EHLO? If this is the only argument, I would recommend explicitly saying s/an IDN argument/an IDN hostname used in EHLO/). (5) Section 6, Recommend making the reference clearer by s/described in section 7/described in section 7.1 of [RFC7208]/ (6) Section 5, Recommend making the reference clearer by s/When computing or verifying the hash in a DKIM signature as described in section 3.7/ When computing or verifying the hash in a DKIM signature as described in section 3.7 [RFC6376]/ (7) Section 6, Recommend making the reference clearer by s/Section 6.6.1 specifies/Section 6.6.1 of [RFC7489]/ s/Sections 6.7 and 7.1/Sections 6.7 and 7.1 of [RFC7489]/ (8) Section 6 says “Section 6.6.1 specifies, somewhat imprecisely”. What does the “somewhat” mean? I recommend more precision in describing the ambiguity left by RFC7489 or dropping that word. (9) Section 8. Recommend making more specific statements about the Security Considerations: s/This document attempts to slightly mitigate some of them but does not, as far as the author knows, add any new ones. / This document provides clarifications to existing protocols to improve their handling of internationalized email./ Recommend adding something as follows as the last sentence: “It introduces no additional security considerations beyond those already identified in the base specifications of [RFC7208], [RFC6376] and [RFC7489].” – pending resolution of Ben’s first DISCUSS. From nobody Tue Apr 9 15:05:30 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86595120013; Tue, 9 Apr 2019 15:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155484752849.19715.13998301912703613498@ietfa.amsl.com> Date: Tue, 09 Apr 2019 15:05:28 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 22:05:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-02.txt Pages : 10 Date : 2019-04-09 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 9 15:09:35 2019 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 57879120089 for ; Tue, 9 Apr 2019 15:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=/5Si2oXY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=WEOV0rRX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM2eDesg_tU0 for ; Tue, 9 Apr 2019 15:09:32 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3510120013 for ; Tue, 9 Apr 2019 15:09:32 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 9251CF8070C for ; Tue, 9 Apr 2019 18:09:31 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554847771; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=A8GMjTYxxMcwE1TOOXdXdgJOaJR7cMSKmiuaTy/7cMQ=; b=/5Si2oXYR04ghABRHhtfsJ8LVeSV2/oUjxmWl8l2e0DrHc+lw9Z1Z43v Uv5N5In77XZWslRUVkam/1HPqlFsDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554847771; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=A8GMjTYxxMcwE1TOOXdXdgJOaJR7cMSKmiuaTy/7cMQ=; b=WEOV0rRXqAMmwpq+An0Pl1ubZ3UjUT4doRJEy/f1RteGHeFPWrQq2MPD k64Mj0x1gA50GVMo+hYrNXO8LyU+BaMkNvGONKYS7/x+dSB576rmEEbTHz 8MuSqUzC1jH9DpcxIyG65JLwJz3G3qWqcsmA+tzcA8RgAscsXHGhg+RJrR XRVfFHSMTKyyzTP6nS5ESwQBC53GHOCcUWyL/7FF+V1KHRGlwmV3UIk0+L 79VhoWiiBy8sD0vkItT/JaZIXkoPkvrxzjWbvmoZaSdsQU1+OmZwvwK4Nm HHURdSSfpc4LekUQ4xSKU5848Nz2g+mtMzisxBwVrvDHpXHzdVj8QQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 55DF9F8070A for ; Tue, 9 Apr 2019 18:09:31 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 09 Apr 2019 18:09:30 -0400 Message-ID: <2706940.jsilLbKzHY@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <155484752849.19715.13998301912703613498@ietfa.amsl.com> References: <155484752849.19715.13998301912703613498@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 22:09:34 -0000 On Tuesday, April 09, 2019 03:05:28 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain-based Message > Authentication, Reporting & Conformance WG of the IETF. > > Title : DMARC (Domain-based Message Authentication, > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > Author : Scott Kitterman > Filename : draft-ietf-dmarc-psd-02.txt > Pages : 10 > Date : 2019-04-09 I've attempted to do a few things with this draft update: 1. Moved to experimental as that seemed to be the direction it's going (easy enough to put back if I got ahead of myself. 2. Added an appendix to describe with the experiment is. 3. Added an appendix to describe the registry approach to mitigating the data leakage privacy issue. 4. Enhanced the description of the privacy issue. 5. Taken an initial whack at Acknowledgements. Please contact me off list if you feel like I left you out and shouldn't have. I'm sure it's not perfect. Scott K From nobody Tue Apr 9 20:24:52 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0474120077; Tue, 9 Apr 2019 20:24:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155486669171.19715.14014281020759221500.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2019 20:24:51 -0700 Archived-At: Subject: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-eaiauth-05: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 03:24:52 -0000 Adam Roach has entered the following ballot position for draft-ietf-dmarc-eaiauth-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. --------------------------------------------------------------------------- The i18ndir review included a number of minor issues that appear to remain unaddressed. (To be clear, I don't assert that all of them require document changes, but I would expect to see responses to the reviewer on these points). I reiterate one of the more important minor comments below. --------------------------------------------------------------------------- I agree with Benjamin's DISCUSS comment: this document needs to better explain the consequences of the inability to match %{s} and %{l}. He talks about it from a security perspective, but I think there's also a discussion to be had here about whether this disadvantages users who elect to have non-ASCII characters in their mailbox names. I did see the response to the i18ndir review regarding the low usage of these macros. If that is relevant to the decision to ignore the proper functioning of these macros, then such rationale should be included in this document. Further, if this document is breaking these macros under certain circumstances due to low deployment, I would urge the working group to consider whether this document should formally deprecate their use rather than relegating certain users to second-class status. --------------------------------------------------------------------------- §1: > the From: header of e-mail messages. Nit: "...header field..." --------------------------------------------------------------------------- §5: > Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its > definition is modified in messages with internationalized headers so > that non-ASCII UTF-8 characters need not be quoted. The ABNF for > dkim-safe-char in those messages is replaced by the following, adding > non-ASCII UTF-8 characters from [RFC3629]: Nit (twice): replace "UTF-8 characters" with either "UTF-8 byte sequences" or "UTF-8 encoded Unicode characters". --------------------------------------------------------------------------- §3: > Header names and other text intended primarily to be interpreted by Nit: "Header field names..." --------------------------------------------------------------------------- §5: > DKIM [RFC6376] specifies a message header that contains a Nit: "...header field..." > of a DKIM-Signature header MUST be encoded as A-labels. This rule is Nit: "...header field..." > consistency with other headers. (A-labels remain valid to allow a Nit: "...header fields..." > in section 3.7, the hash MUST use the domain name in the format it > occurs in the header. Nit: "...header field." From nobody Wed Apr 10 09:55:59 2019 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 01CFD1203DB for ; Wed, 10 Apr 2019 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VZyTJmsuoju for ; Wed, 10 Apr 2019 09:55:57 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F383120106 for ; Wed, 10 Apr 2019 09:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1554915355; bh=pulpbgoMGtDWQfoij2JtVZNpNcuPIIHJ7JYe9AhVaM4=; l=1342; h=To:References:From:Date:In-Reply-To; b=BM/mIjMCdDdF9bsJm3xjL7IUBh4EvBKY5TYxZAE58ZjqBkbgat4D0F23oRnmvADKd M7AdFUFcABvNZLH0NfzgnOdV1TD5zkssPLENbTYvmnpdUynTGlltoYfcNQP4vbnGjM 5jpYOQWau3oPdAqhlwXJpzPJywljVtYGFaEUBYa0xyh5KkPxBhxoKRuC7bI9I Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 10 Apr 2019 18:55:55 +0200 id 00000000005DC013.000000005CAE201B.0000220C To: dmarc@ietf.org References: <20190408005045.5EC462011B2BFE@ary.qy> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 10 Apr 2019 18:55:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190408005045.5EC462011B2BFE@ary.qy> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] More rethinking on DMARC for PSDs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 16:55:59 -0000 I changed the subject to make it clear that this is not about mail filtering in general. It is about Scott's draft. On Mon 08/Apr/2019 02:50:44 +0200 John Levine wrote: > > A decent spam filter will treat a nonexistent From: domain or envelope > bounce address as extremely suspicious and send the message into spam > folder purgatory. If someone's filters aren't doing that, it is > unlikely that they're paying much if any attention to DMARC, and no > amount of fiddling with DMARC will make any difference. > > My mail server rejects anything with a non-existent bounce address at > SMTP time and I don't think it's ever rejected anything my users would > want. Me too. However, I don't reject nxdomain in From:. I have the option, but I disabled it because some mailing lists have (had?) authors with addresses like johndoe@NOSPAMexample.com. That said, rethinking boils down to consider if it would suffice to look up the PSD's _dmarc record only in case of non-existing domains. Existing domains can be forced to publish adequate DMARC records by forging a suitable PSD's policy. That way, old-fashioned mailing lists can continue to use picturesque From:'s as long as they are based on traditional TLDs (assuming .com won't publish a strict DMARC policy.) And no central repository. jm2c Ale -- From nobody Wed Apr 10 12:36:51 2019 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 7211D12062B for ; Wed, 10 Apr 2019 12:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnZMj2zcZK81 for ; Wed, 10 Apr 2019 12:36:40 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343831205DF for ; Wed, 10 Apr 2019 12:36:40 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id v84so2834957oif.4 for ; Wed, 10 Apr 2019 12:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=uUVj4ecjCz7d4undUkQdxcuNUuLpktQ8w30oWp6Ix54=; b=D9ulzfHKmHi4/WARyhRr8pKryOVUPH5u/81Tjdfj7gXH1QIlfTWg/yUXShptWvZV4R 1WXHvAMFUlelV7EFDch+Snv6tvA0zNX9E2ctD1IhZvoaE4rufQyW0rCunvU6rHE7WVyH VjcFhTRYOhqzMA02Z+aLZq21A8abxrSk07jTVjI5lvPLcrbgwUV4TXeoZGGVlnQ2Tp5Z 3MzhTL1JPAUJvHKaTXBWw84Ul706HFAcEC8iggBDzkbkhdKaJmuw3BnHXNS+JhTgbO4m 3aHmGQkTCMlRnzd9zpbZEFnT5Ej6Rj/kafPzoLjRenbhTtFE+CbBsVJ1puQtMcxmGRBr uSIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=uUVj4ecjCz7d4undUkQdxcuNUuLpktQ8w30oWp6Ix54=; b=YY+4XOn3u4XvzNTdRBLJvJ/C/v8SlFM8TIFHAYiqb206An0lw5JG3XF0CU2U3nlRMI Ocnfhj5eEoZKNZWpaFuAepLi3i/foNYTp7wEUCxg7jZGoUWQXs+3U9MvK06mIpp/Rzp2 Ixmjuh9Hw3okZfWsouVs+fYVIXH2pwKykl0ut227CNAnn8s9YZqI1H1Rf0TaGdse004F f1KG8zrRVEwnLzftmZ/S7/zDPWiJsDAaxfll1A508rdFRiqCaob1Bmb9rvR2lLGZUVQK FzkjTaVJpZnb4iutERfVoQ63J8M78KHvG9N+ihnYzNgUmWNyy5xD0nlQARLRkm7pRR0t aWWA== X-Gm-Message-State: APjAAAXfYS33zAaARqhR9CSy0jLiVEPDS8VOGezQuYRi9o6EPMrp5Sgm p18AoHt0g0YP776BJESWzbMdsx0L X-Google-Smtp-Source: APXvYqyUK+9ogkBTcnTx6wqgFYNWMHE/oKIDWpsQI5d/lj9IIrv0bVjhxxbfKRCE+eg8zDDVoYIysA== X-Received: by 2002:aca:cf92:: with SMTP id f140mr3745639oig.48.1554924998993; Wed, 10 Apr 2019 12:36:38 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:a513:542:b741:80cf? ([2600:1700:a3a0:4c80:a513:542:b741:80cf]) by smtp.gmail.com with ESMTPSA id v201sm11419461oia.39.2019.04.10.12.36.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 12:36:38 -0700 (PDT) From: Dave Crocker To: IETF DMARC WG Message-ID: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> Date: Wed, 10 Apr 2019 12:36:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 19:36:50 -0000 Folks, Howdy. I'm trying to get a bit of education about reality. Always dangerous, but I've no choice... For the software you know about, how are queries to the DNS performed, to obtain the TXT records associated with DKIM and/or DMARC? I'm trying to understand the breadth and limitations of returned information that is filtered or passed by the code that is actually in use. Which libraries and which calls from those libraries. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 10 15:26:59 2019 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 2617312008B for ; Wed, 10 Apr 2019 15:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=AciAlyuB; dkim=pass (1536-bit key) header.d=taugh.com header.b=k1F9R0Lz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGdm2qHvgfn7 for ; Wed, 10 Apr 2019 15:26:57 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556F8120049 for ; Wed, 10 Apr 2019 15:26:57 -0700 (PDT) Received: (qmail 61875 invoked from network); 10 Apr 2019 22:26:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f1b0.5cae6daf.k1904; bh=3Kn3n+xMRqPl/IYSNrmUuRscbjSGTngfZKtaKoS0+0s=; b=AciAlyuBDiE45yZm7qjxx1zYryws07HJLmw9oYShSyCydzaaiKskZew/N5DSkiOOj32LJyBdDESFL3orA7Hg150SlyR73K7Xlq3VEpkMUALBe9vplnZJu4uF23Ri2Fe8a0J8p3Ei/Y3lAL/b3Fi2iY+SN9vO48xwQa0MgEcBc3qpgaxX9zXSA5huC7eIsHlwGWkjQNsCobQ4EVJKOGKNYFhns0ab6Fk+Zpq6sj28gt5W3LUE5Oq7hCg7s54yoWY/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f1b0.5cae6daf.k1904; bh=3Kn3n+xMRqPl/IYSNrmUuRscbjSGTngfZKtaKoS0+0s=; b=k1F9R0LzMa6iP6k8aQ/nL7JsQl0ewM7aqsouruzllvgJXvnFzdF/p3BofHhnGLLuZPQ3ohK1h/PSlKutUv9mL5Fsm0h5iLHM3+T3EvQq5eDRyj6NTwqtGVMYeXmABlCQbTycSc/OtxktnOA5EarsEwckgyG0ZCKITRax7LrB3DpaJl4Kvn/y8RkUnQJk8kC7i4pGjbD8WgebdFauXe9hxs2WVHe64SO9nD3upkc3s0oBU1Db/NkydX5OYS2sv0RL Received: from ary.intern ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Apr 2019 22:26:54 -0000 Received: by ary.intern (Postfix, from userid 501) id 671832011D4FED; Thu, 11 Apr 2019 00:26:54 +0200 (CEST) Date: 11 Apr 2019 00:26:54 +0200 Message-Id: <20190410222654.671832011D4FED@ary.intern> From: "John Levine" To: dmarc@ietf.org Cc: adam@nostrum.com In-Reply-To: <155486669171.19715.14014281020759221500.idtracker@ietfa.amsl.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-eaiauth-05: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 22:26:59 -0000 In article <155486669171.19715.14014281020759221500.idtracker@ietfa.amsl.com> you write: >I agree with Benjamin's DISCUSS comment: this document needs to better >explain the consequences of the inability to match %{s} and %{l}. It has no consequences at all. As Scott noted, it documents what the code does now. He talks about >it from a security perspective, but I think there's also a discussion to be had >here about whether this disadvantages users who elect to have non-ASCII >characters in their mailbox names. I have to object here -- this is asking us to put a tutorial about SPF into this minor update document. Anyone who is familiar with SPF knows that local part macros are useless and it makes no difference. Even if they weren't useless and we we wanted to encode UTF-8 local parts in the DNS, that doesn't work because the semantics of local parts and of domain names and the way they are interpreted are very different. The obvious problem is case folding which has in the past kind of mostly worked because the ASCII DNS case folding rule and ASCII mail case folding conventions happen to be similar, but it goes straight downhill from there with characters other than ASCII letters and digits. This has been argued to death many times, and again this is not the place for a tutorial. R's, John From nobody Wed Apr 10 20:38:07 2019 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 B32341201EE for ; Wed, 10 Apr 2019 20:38:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=nh6SFw0K; dkim=pass (2048-bit key) header.d=kitterman.com header.b=cP/cEXBH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHxtzoa94CcY for ; Wed, 10 Apr 2019 20:38:03 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561841201E8 for ; Wed, 10 Apr 2019 20:38:03 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 6C3A5F80486 for ; Wed, 10 Apr 2019 23:38:01 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554953881; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=9lpu1aD9oG0PBxqTj0aI6ZXDCSsqCsOWWnuTZri51lU=; b=nh6SFw0Khnv27drtwOEr/PIseD19JXWMkr/CWTpLehXGYkZtBNffL/wm scTb2dbFfQeA/hnFjIpsxW2K+LvcBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554953881; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=9lpu1aD9oG0PBxqTj0aI6ZXDCSsqCsOWWnuTZri51lU=; b=cP/cEXBHdA2cwRog46RIMuYTfYb+wyF9cpwuGy8dGEi262AD5QaDK7EU ILvLtFXRpUhfw/uqR8ZiNJNOVoo2x9mBGlkYbDfnjN2//j315FHkCv+8DD LvDlX68niwLbDmZBIZpKxh2uIuPMV9lDvK4kILKoENabF3CqWCg1cC7hag ilupj5u+rqzFjR8oiqSl3UVdSJI9UkMFclu36RSoJCgtSQZG+VMN5Iibia 2fvYumg7E9f0rX2DJm7bMlteLcpE3Gu0nm+adtAt9tKhM+OTLWkJ3iwt4N 6Kzp7QE+OF4OAmRyJccKvOGidcT/5z7Q+eDuCKpcUWgnER1GHW8/wA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 40FA1F8038A for ; Wed, 10 Apr 2019 23:38:01 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 10 Apr 2019 23:38 -0400 Message-ID: <8787907.T9Vn2QKn0N@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 03:38:06 -0000 On Wednesday, April 10, 2019 12:36:34 PM Dave Crocker wrote: > Folks, > > Howdy. > > I'm trying to get a bit of education about reality. Always dangerous, > but I've no choice... > > > For the software you know about, how are queries to the DNS performed, > to obtain the TXT records associated with DKIM and/or DMARC? > > I'm trying to understand the breadth and limitations of returned > information that is filtered or passed by the code that is actually in > use. Which libraries and which calls from those libraries. I'm most familiar with how it's done with dkimpy (Python DKIM library) [1]. It uses an internal abstraction layer (we call dnsplug) to that the module itself works with either pydns/py3dns [2] or dnspython. I'm not sure exactly what you're after here, but the code's simple enough, so here it is: def get_txt_dnspython(name): """Return a TXT record associated with a DNS name.""" try: a = dns.resolver.query(name, dns.rdatatype.TXT,raise_on_no_answer=False) for r in a.response.answer: if r.rdtype == dns.rdatatype.TXT: return b"".join(r.items[0].strings) except dns.resolver.NXDOMAIN: pass return None def get_txt_pydns(name): """Return a TXT record associated with a DNS name.""" # Older pydns releases don't like a trailing dot. if name.endswith('.'): name = name[:-1] response = DNS.DnsRequest(name, qtype='txt').req() if not response.answers: return None return b''.join(response.answers[0]['data']) There is a detection process that will decide what to use and then define dnsplug.get_txt as the appropriate variant. Not being sure how far you want to take this, here's an example of a TXT query using pydns or py3dns (I picked this one because it has multiple TXT records): Code: >>> import DNS >>> response = DNS.DnsRequest('google.com', qtype='txt').req() >>> print(response.answers) Result (whitespace added for clarity): [ {'classstr': 'IN', 'ttl': 299, 'rdlength': 46, 'class': 1, 'typename': 'TXT', 'data': [b'docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e'], 'name': 'google.com', 'type': 16}, {'classstr': 'IN', 'ttl': 3599, 'rdlength': 36, 'class': 1, 'typename': 'TXT', 'data': [b'v=spf1 include:_spf.google.com ~all'], 'name': 'google.com', 'type': 16}, {'classstr': 'IN', 'ttl': 3599, 'rdlength': 60, 'class': 1, 'typename': 'TXT', 'data': [b'facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95'], 'name': 'google.com', 'type': 16}, {'classstr': 'IN', 'ttl': 3599, 'rdlength': 65, 'class': 1, 'typename': 'TXT', 'data': [b'globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8='], 'name': 'google.com', 'type': 16} ] For completeness, here's the balance of what you can pull out of the response object for this request: >>> print(response.header) {'ra': 1, 'qdcount': 1, 'opcode': 0, 'id': 46730, 'tc': 0, 'nscount': 0, 'arcount': 0, 'z': 0, 'ancount': 4, 'aa': 0, 'status': 'NOERROR', 'qr': 1, 'rd': 1, 'opcodestr': 'QUERY', 'rcode': 0} >>> print(response.questions) [{'qname': 'google.com', 'qtypestr': 'TXT', 'qclassstr': 'IN', 'qclass': 1, 'qtype': 16}] >>> print(response.authority) [] >>> print(response.additional) [] >>> print(response.args) {'qtype': 'txt', 'port': 53, 'protocol': 'udp', 'elapsed': 95.10970115661621, 'opcode': 0, 'server_rotate': 0, 'rd': 1, 'timeout': 30, 'timing': 1, 'name': 'google.com', 'server': '127.0.1.1'} What gets returned to the application from dnsplug is a list of the TXT data. In this case: [b'docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e', b'v=spf1 include:_spf.google.com ~all', b'facebook-domain- verification=22rm551cu4k0ab0bxsw536tlds4h95', b'globalsign-smime- dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8='] Is that the kind of thing you're after? Scott K [1] https://git.launchpad.net/dkimpy/tree/dkim/dnsplug.py [2] For pydns/py3dns there are separate code bases for python2 and python3, but the calls are the same. From nobody Wed Apr 10 21:08:52 2019 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 C88AF12009C for ; Wed, 10 Apr 2019 21:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhcnGgX75zDO for ; Wed, 10 Apr 2019 21:08:48 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F2A1200B3 for ; Wed, 10 Apr 2019 21:08:47 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id r25so3489987lfn.13 for ; Wed, 10 Apr 2019 21:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rFIZiyaJ7W1AGAnUcJeyShKmS4nybuyrGdfvsvKyvhw=; b=F7ztS/WLGGe2OYpuCokpa3NUrroBxq+HaO3+BR5Oe69cyPwVnRHcjegzyWpmOP3QRs mlcoq6rsWTi4e9hhWgdwDrVo2OvsqmRpYgf2lYOTzfiyeUDlNx2Nr3mcyFv01gmfdoVq Bt/YE16M5zmzvyX2GGYY5LQ3bCgWXm3GIDtR8EPhF2r++vWpn8xqDML6/1TC2hEjVYuV 7nlfmCzyfn5QbUnQ/oj8yXyb0Y/Xf5B450NIfuMXSUTKDSX8Rq39gzkdHFTSnczqkUMi JEOWMwfFIwZUCjQu5CBYrKiKXsD0se55Rjrt1sDGaWVbevTGjCbAjwIG+H2arf0JrpZj G1LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rFIZiyaJ7W1AGAnUcJeyShKmS4nybuyrGdfvsvKyvhw=; b=NcLPJezXVps9KboFkadyaTjMVrRhav0qcruXA1FSo1nkGWuBVd/U75j0cBbOBQFWeA YAwqyAmGf9kOuto+wP4bng8XZ8V5Hr8VsUw7vUaYM4lUl2dpVIJTQOm/G2YHVYfC3gfo iBSggmdo6UUO9kiAyE+kFDDcYy+UxwMvKb4FanedAQhG+n71r1TH7uiPtJVoPzKXRDte VYARtbcOjROw1yw9EDX0L9Agfrv+KCIFC2HNf44NQAZOhHEJtAeLCDD9hRR5v7oSRWsV cfbojNtAGWo4jOSyz7HwQrdEAsUMuD167HV3rvFqS4HUl8I+fe8IicdQqfM7K8tWQDpz NirQ== X-Gm-Message-State: APjAAAXVmg1UDz5qU6n4xHxq4sTq3CC6BZcjqDkkzFvA5nGU8725TUt/ bJmTEVmDmRs3Pz5yUngwk0fiCdNBJVaYrwo7MziqxA== X-Google-Smtp-Source: APXvYqy6QNiIdzwGTHsfR9SJrg8yvnPUxg2X2afv17BEh3tHTjzj9hs1t7PjI90We0lNvx848p1dGfYiRSb5cPHcKtk= X-Received: by 2002:ac2:52a6:: with SMTP id r6mr24723708lfm.27.1554955725906; Wed, 10 Apr 2019 21:08:45 -0700 (PDT) MIME-Version: 1.0 References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> In-Reply-To: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> From: "Murray S. Kucherawy" Date: Wed, 10 Apr 2019 21:08:31 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000af271c0586395762" Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 04:08:50 -0000 --000000000000af271c0586395762 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 10, 2019 at 12:37 PM Dave Crocker wrote: > For the software you know about, how are queries to the DNS performed, > to obtain the TXT records associated with DKIM and/or DMARC? > By default, libopendkim and libopendmarc use the standard C library functions (i.e., res_*()) to do these queries and await replies. The specific functions are res_query() and res_nquery() depending on which version of the library is available. I believe both can be configured to use libunbound instead (certainly libopendkim can). -MSK --000000000000af271c0586395762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 10, 2019 at 12:37 PM Dave Cro= cker <dcrocker@gmail.com> w= rote:
For the software you know about, how are queries to the DN= S performed,
to obtain the TXT records associated with DKIM and/or DMARC?

By default, libopendkim and libopendmarc use the stan= dard C library functions (i.e., res_*()) to do these queries and await repl= ies.=C2=A0 The specific functions are res_query() and res_nquery() dependin= g on which version of the library is available.

I = believe both can be configured to use libunbound instead (certainly libopen= dkim can).

-MSK

--000000000000af271c0586395762-- From nobody Wed Apr 10 21:17:03 2019 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 F2F961200B3 for ; Wed, 10 Apr 2019 21:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjJQwzoYscDo for ; Wed, 10 Apr 2019 21:17:00 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749B2120077 for ; Wed, 10 Apr 2019 21:17:00 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id u15so4004678otq.10 for ; Wed, 10 Apr 2019 21:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1V4VPbFDD9QWPgvn0nkNqLAtkz9T/MCHND+nZ+IZyj0=; b=FpCrKTfpaiA3uCQOhD11pUTWv0v3AbFugM8kT7g3bYI6b7/nctqCvBagHCGuURhcYe upIZ5v+bN9ndx3jFI3QQaBeOZkLvpBXWNAVLdjUy1GoGvbSbkmuyi2y8qr7brORPVQBY lGlnP56ugPpLbR/F2tutKn3+fb1682740ZlFKMz9boAnoSl0w1/yBwtuQ6Quv71jgIc0 8jvjm/RtFXCZV3oy1OHFb+LXbUInD+Dar9kyE5glQVbEWAeNypSmILqBFBGyWfTUEg52 h2yWJJdaK+YxsO7iS7BXVTRA9tbWRG43LF2RDqdxuh2LAEKbOZqjvMO3NjgsKG4HRq9M fegA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1V4VPbFDD9QWPgvn0nkNqLAtkz9T/MCHND+nZ+IZyj0=; b=fKw6gEsQoWeFCHxC9WnkJjYlklAZa5M2ZKwODeLbMQB2KxIzzcNf/ImeDHr2JgOIQ2 cRIbBKOzum7w0oorCHNfgC/4qDIwWP8aAZK9aVpxc+VmgcGScIBmqEc8cVfhnKcgdhWV /nt5qJ9cjOpTHk5iSKbFKQ6xyjYm62kEJ9VDeIieMBczrsJtgOTCI8FL5xc42sw3b8Bk vWx3vCUqvwqomH7dwt3vS13bCdJbt5rw023hqtk4IdT/cdKb2DPv5JXz9xLs6aCDTCYk IfAf3kvgW86XUlsZJNJe1Nbx7tB82pEtzgtyAFMQjSc69Etem19/WbR21HQA5q7cTUZ3 /qEw== X-Gm-Message-State: APjAAAUc4eZ6lzrVyOqgxdObiDTznK9O7bIdoELqwjtuNm+bvFM9OfyJ pi1jMigKdZTqls0bV88+mJRJldSj X-Google-Smtp-Source: APXvYqycBYxQ5b5G2DQpwH+dvcWyjWx+drdnGNDz7s7ahpXP5pvcV4rCTAIma3jr6maXo9K62q5WSA== X-Received: by 2002:a9d:6191:: with SMTP id g17mr966636otk.291.1554956219316; Wed, 10 Apr 2019 21:16:59 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:f9:ff7b:88ef:bf94? ([2600:1700:a3a0:4c80:f9:ff7b:88ef:bf94]) by smtp.gmail.com with ESMTPSA id c145sm15210291oig.0.2019.04.10.21.16.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 21:16:58 -0700 (PDT) To: Scott Kitterman , dmarc@ietf.org References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> <8787907.T9Vn2QKn0N@kitterma-e6430> From: Dave Crocker Message-ID: Date: Wed, 10 Apr 2019 21:16:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8787907.T9Vn2QKn0N@kitterma-e6430> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 04:17:02 -0000 On 4/10/2019 8:37 PM, Scott Kitterman wrote: >>>> print(response.additional) > [] > Turns out that's what I was especially hoping to see. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 10 21:29:33 2019 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 E2817120168 for ; Wed, 10 Apr 2019 21:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=txlQOgQO; dkim=pass (2048-bit key) header.d=kitterman.com header.b=dyZ4e1nq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUeNQ_hJuPOO for ; Wed, 10 Apr 2019 21:29:30 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C831D1200CC for ; Wed, 10 Apr 2019 21:29:30 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CB090F80486 for ; Thu, 11 Apr 2019 00:29:29 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554956969; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=u9OA0WCKTkDCkIymm5tpSv2P+Q+Q2r92JTvSLdvSk1g=; b=txlQOgQOLCzz5cBi2AXjRWxd0d1GAJXaO6JWzgrIeM4Qcl1DubHQa5qr 0zmukLxiAJPYS7zUcJ5hYqs6fS6sBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554956969; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=u9OA0WCKTkDCkIymm5tpSv2P+Q+Q2r92JTvSLdvSk1g=; b=dyZ4e1nqG1+d+L7w2hIXNH9meLNIguxM7dvs3tKxiCayTzMQjO7CX/Jd in0+a4mUYDDwRqD84Jw7dlrAEMl1iPkZPpy9ELHNszNdV6YYQDJmgD5nrd lNyF51MmA/aM+59bSaPe6dpyf9TS9OCaJqavx953w11k4NXR0lKgEaypfd soGaZeRLYmt7o/GWKXtAtpITSkQdo1nwES1OCozjUXWnTsUSvpZOYxFz3d VwFlqKzZnnQx2TSHSXE6nu+Uv99R3BZ5pjnF7McY+8k9ufEZXkZGUuc3d3 3guqDMLZX7C2Etckzb5eVViedLwSF8OMdIKRIJe50p7Aj7Vprhxd0Q== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8E493F8038A for ; Thu, 11 Apr 2019 00:29:29 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 11 Apr 2019 00:29:28 -0400 Message-ID: <4298318.26pBuaHoxp@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> <8787907.T9Vn2QKn0N@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 04:29:32 -0000 On Wednesday, April 10, 2019 09:16:56 PM Dave Crocker wrote: > On 4/10/2019 8:37 PM, Scott Kitterman wrote: > >>>> print(response.additional) > > > > [] > > Turns out that's what I was especially hoping to see. > Great. I checked and dnspython can do that too: >>> import dns.resolver >>> a = dns.resolver.query('google.com', dns.rdatatype.TXT) >>> print(a.response.additional) [] Scott K From nobody Wed Apr 10 21:42:57 2019 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 D081412023C for ; Wed, 10 Apr 2019 21:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=J6u32ufY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=V5W39qNr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLCC26E6JGGa for ; Wed, 10 Apr 2019 21:42:53 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064E91201A8 for ; Wed, 10 Apr 2019 21:42:52 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id F0160F80486 for ; Thu, 11 Apr 2019 00:42:51 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554957771; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=dBtRl+KqYBmBL5B1zdSX28tnGDkNOIMfq3sYIbsSF/c=; b=J6u32ufYDgw3pjugHoCHI5kh1svbsyNU/DLKCPvKDGeMxhjUWO8oKIWN E0z4bvJ60OR6FKY4tqNPQw0M9NtbCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554957771; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=dBtRl+KqYBmBL5B1zdSX28tnGDkNOIMfq3sYIbsSF/c=; b=V5W39qNrkAPs2YPHqoSekygsSvJK0ucSKjUwP252pulxBeO3oLn6bjEy t4SUDYPDKdYq2V1evFekOKSwaDqL1K4lFc0WB4Vbxp5EcLaWZVDeDs5lmQ iP75zQNH1ACy7Rl0mAXJ0Icmd7nymSnIpYyQ0JEcA1Lmr8NEGLecaXa06e /RhVpWU6TMjWF+FHgDFtKerIoLlfVm2jsMdxF1ovb4t7O6mQnJYkU1PscR kmxk2mUM7YlpE4Ek+utMVWInuagotRhrQnojIg0mwkcHYtMY8gj/XUIl18 ydn0+N+R6YxXhQS7ZFGYhpGrNfTbObHVsKM50K7hHBlWDa2DkKSZDA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id C0362F8038A for ; Thu, 11 Apr 2019 00:42:51 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 11 Apr 2019 00:42:50 -0400 Message-ID: <25082821.JLSd9BuZku@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <4298318.26pBuaHoxp@kitterma-e6430> References: <571ce243-a8b0-094d-0d59-06f1432bd741@gmail.com> <4298318.26pBuaHoxp@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 04:42:55 -0000 On Thursday, April 11, 2019 12:29:28 AM Scott Kitterman wrote: > On Wednesday, April 10, 2019 09:16:56 PM Dave Crocker wrote: > > On 4/10/2019 8:37 PM, Scott Kitterman wrote: > > >>>> print(response.additional) > > > > > > [] > > > > Turns out that's what I was especially hoping to see. > > Great. I checked and dnspython can do that too: > >>> import dns.resolver > >>> a = dns.resolver.query('google.com', dns.rdatatype.TXT) > >>> print(a.response.additional) > > [] And just for fun python-getdns [1] has an even more interesting result to that same query: {'additional': [{'do': 1, 'extended_rcode': 0, 'rdata': {}, 'type': 41, 'udp_payload_size': 65535, 'version': 0, 'z': 0}] As far as I know, the unbound python bindings don't do TXT, so that's all the Python libs I know about. Scott K [1] https://github.com/getdnsapi/getdns-python-bindings From nobody Thu Apr 11 10:52:25 2019 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 C376D1205FB; Thu, 11 Apr 2019 10:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2fX4TFyRm06; Thu, 11 Apr 2019 10:52:15 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4A01205B5; Thu, 11 Apr 2019 10:52:14 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3BHq7ip008143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 13:52:10 -0400 Date: Thu, 11 Apr 2019 12:52:07 -0500 From: Benjamin Kaduk To: John R Levine Cc: The IESG , dmarc-chairs@ietf.org, Kurt Andersen , dmarc@ietf.org Message-ID: <20190411175206.GK18549@kduck.mit.edu> References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> <20190405180945.GF70202@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 17:52:18 -0000 [consolidating the postscript back in] On Fri, Apr 05, 2019 at 02:45:33PM -0400, John R Levine wrote: > On Fri, 5 Apr 2019, Benjamin Kaduk wrote: > > The whole premise of rigorous specifications is that anyone can jump in to > > the ecosystem and implement something that interoperates, and in my opinion > > the current presentation is not very accomodating to such a participant. > > We seem to have a fairly basic disagreement of who "anyone" would be. > I'm assuming, and I think the WG is assuming, that the audience for this > document is people who are already somewhat familiar with SPF or DKIM or > DMARC. It appears that you believe it is possible to add enough > mechanical detail that even someone who knows nothing about them could > make these changes. That seems awfully optimistic. Well, that wasn't really my intent in making the comment. Rather, that it feels sloppy to be so informal. It may not cause problems here, but on the other hand, even people who know things can have off days; sloppiness can also become a habit and creep into places where it does have a real impact. I've seen plenty of those even in just one year on the IESG, and try to exert some general backpressure, though I hope that I limit the blocking backpressure to cases where it does actually matter. In this particular case, I said "I would like to discuss" the topic, and we have had a discussion. Your and Barry's arguments have convinced me that no change is needed here, so I will reballot and remove that point, since the discussion has occurred. > I don't fault you for not being an SPF or DKIM expert but I really don't > think it is useful to add a lot of stuff that any plausible reader already > knows. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly On Fri, Apr 05, 2019 at 02:57:55PM -0400, John R. Levine wrote: > PS: > > >>> Is there any risk that an intermediary will reencode the domain name and > >>> cause the signature validation to fail? > >> > >> No more than there has been all along. Intermediaries can do all sorts of > >> bad stuff to mail messages althrough for the most part they don't. > > > > Right. But we don't, say, know of any current implementations that try to > > canonicalize the representation of the domain name, for example? > > Sure we do, some still replace CNAMEs with the target as described in RFC > 1123. But what does that have to do with internationalized mail? It > sounds like you're thinking that an intermediary will turn U-labels into > A-labels or the like, which would require an extremely perverse misreading > of the EAI RFCs. > > Again, I don't fault you for not being an EAI expert, but again, this is > stuff that anyone working in the area would know. Well, that's why I am asking questions instead of telling you how to write the document. And when you keep making that sort of response to my questions, it starts to come across like you're asking me to abdicate my responsibility as an AD to apply faithful review to the documents in front of the IESG, and instead just trust the experts in the WG to have done the right thing. I intend to continue to do my job, and I hope that the community will support me in that, including by filling the gaps in my knowledge as relevant. -Ben From nobody Thu Apr 11 10:56:28 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8045D120106; Thu, 11 Apr 2019 10:56:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155500537851.14222.14675803011447947339.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 10:56:18 -0700 Archived-At: Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-05: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 17:56:19 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-eaiauth-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document; it's good to improve the clarity and precision of how various pieces of the ecosystem interact. That said, I do have an issue that needs to be addressed prior to publication: We need to properly document the consequences of causing the %{s} and %{l} macros to never match when the local-part contains non-ASCII characters. I understand that they are quite rare in practice, and this rarity justifies not going to great lengths to provide a technical solution, but that doesn't mean that we can silently ignore the issues. [discussion of specificity of Updates removed, as the discussion happened] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 In headers in EAI mail messages, domain names that were restricted to ASCII can now be U-labels, and mailbox local parts can be UTF-8. nit: "can now" implies some previous baseline state, but that reference for comparison is not especially clear just from context. Section 5 I'm having a hard time following this paragraph: Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags of a DKIM-Signature header MUST be encoded as A-labels. This rule is relaxed only for internationalized messages headers [RFC6532] so IDNs SHOULD be represented as U-labels but MAY be A-labels. This provides improved consistency with other headers. The set of allowable characters in the local-part of an i= tag is extended as described in [RFC6532]. When computing or verifying the hash in a DKIM signature as described in section 3.7, the hash MUST use the domain name in the format it occurs in the header. Is "this rule is relaxed" a new policy as of this document? RFC 6532 does not mention an "i=" tag anywhere, so I feel like we may need greater detail on what behavior from 6532 we're pulling in. (Are we just intending to add the UTF8-non-ascii block as valid ABNF for the RHS of the "i=" tag?) Is there any risk that an intermediary will reencode the domain name and cause the signature validation to fail? Section 6 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the RFC5322.From address domain are to be handled. [...] A bare "Section 6.6.1" normally refers to the current document, so repeating RFC 7489 is probably in order. (Same for the other Section references in this section.) Section 8 (Depending on how the first DISCUSS point is resolved, we may be adding some new threats that need to be covered.) From nobody Thu Apr 11 14:09:02 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76861120220; Thu, 11 Apr 2019 14:08:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155501693937.14087.3085605038966955028@ietfa.amsl.com> Date: Thu, 11 Apr 2019 14:08:59 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-eaiauth-06.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 21:09:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : E-mail Authentication for Internationalized Mail Author : John Levine Filename : draft-ietf-dmarc-eaiauth-06.txt Pages : 7 Date : 2019-04-11 Abstract: SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-06 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-eaiauth-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-eaiauth-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 15:34:05 2019 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 CDC49120405 for ; Thu, 11 Apr 2019 15:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW335iYnQTBy for ; Thu, 11 Apr 2019 15:34:03 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4651203EB for ; Thu, 11 Apr 2019 15:34:02 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id y10so12362961itc.1 for ; Thu, 11 Apr 2019 15:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=UtysxvEwtwLuLdlDizlQ0JuLUvsBz0YmFUmJbM8ldsA=; b=XFQTdZjVYV95AzTfx7LlpRTI+i7LWjtZ8nMqo6ldZF+znkEEKH16cIlFnP3QY9Pfm/ HEJ6QixvLpL4u34dFpHiqZi+VdsVlb5qykEydp3z5O5Ern5dda078/NKQ8Q34g0RMKxL 4ukjp+eRqB/5RsNQDozI3r5t6taHXZpd1fy+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UtysxvEwtwLuLdlDizlQ0JuLUvsBz0YmFUmJbM8ldsA=; b=GSQFNyXl6GsLzUSDyyd9byxDi0hON/ynkOuhFIOpk++dd20xti4H1tBveLOdlhZIlL a0b1I14o75RXXFbHT5I2vaTx6lYL/Ictl12xaLjZEbI2CbJyxLpR0p1G1e1f1NJ4W0Xw 59A2W1Ktsz97U5vD1MCgzlGQC+opsU+9wRyiLEP3y698ErP74nS/4V6xtLdGfv3sKdv1 E/Mcpt/5XQ3qJ8UCNT7O40w/h0tZKX46TBIvtKOipJU43syRlgx3EHZANrIUTehwF5Jn yot8gvl9gRVvZJoMFr+suPeEB0I/991l7uk12mL960/rIoCT/squxmvAR/3VTqm0jf2z 7iKw== X-Gm-Message-State: APjAAAW5jjNmCVR83AAEwyOIIBxQNv1yiTPS9x5ogPMPHs03eENYeJ/r xYrAOvK7jXc6GkgCL8t90SiYTDsEQabr6gUK24J1VK1K/3v/Og== X-Google-Smtp-Source: APXvYqwhcSROZ8UcsyAHZaNyLQBs0XipxnYBDYZpXbaYoQeJwCvQkKDuimbIy7V/ffUAWXvtqta/rClWlXGEyIb7Jbc= X-Received: by 2002:a24:2244:: with SMTP id o65mr10198743ito.126.1555022041581; Thu, 11 Apr 2019 15:34:01 -0700 (PDT) MIME-Version: 1.0 From: Kurt Andersen Date: Thu, 11 Apr 2019 15:33:34 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000068239e058648c84a" Archived-At: Subject: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 22:34:05 -0000 --00000000000068239e058648c84a Content-Type: text/plain; charset="UTF-8" Firstly, just a nit, but section 4.1 introduces a new abbreviation in the last bullet point: "PSDo". I suspect that this should be PSO for consistency. More substantively, in Appendix A, the case is being advanced for "concerns associated with Multi-organization PSDs that do not mandate DMARC usage". I'm not sure why "multi-organization" is an appropriate qualifier, nor as to what mandated DMARC usage has to do with any of the privacy concerns. Neglected DMARC usage is what leads to the spillage up to the PSD level. Even within a single organization there may be serious privacy walls which need to be respected between different sub-portions of the org - which may or may not be represented in a DNS hierarchy. I've read through the breakdown in section 4.1, but I think that it is incomplete - largely on the terms mentioned above. Also, the claim that reports on cousin domains would be sent to the [right] PSO ignores the risk of the PSD itself being the cousin attack point. After all if a domain doesn't exist, one may as well start from the top :-) I think it would be more effective to add an anti-RUF requirement to the implementation of this spec - such that no RUF reports would be sent, regardless of the record which is published by the PSD. Since very few providers even support RUF at all, this does not seem to be a big ask, although it does require some additional logic. The privacy risk is primarily related to RUF, not RUA reports so blocking RUF could (IMO) effectively mitigate the perceived risk of the PSD records while still allowing the DMARC validation protection. --Kurt --00000000000068239e058648c84a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Firstly, just a nit, but section 4.1 intr= oduces a new abbreviation in the last bullet point: "PSDo". I sus= pect that this should be PSO for consistency.

More subst= antively, in Appendix A, the case is being advanced for "concerns asso= ciated with Multi-organization PSDs that do not mandate DMARC usage". = I'm not sure why "multi-organization" is an appropriate quali= fier, nor as to what mandated DMARC usage has to do with any of the privacy= concerns. Neglected DMARC usage is what leads to the spillage up to the PS= D level. Even within a single organization there may be serious privacy wal= ls which need to be respected between different sub-portions of the org - w= hich may or may not be represented in a DNS hierarchy.

=
I've read through the breakdown in section 4.1, but I think that i= t is incomplete - largely on the terms mentioned above. Also, the claim tha= t reports on cousin domains would be sent to the [right] PSO ignores the ri= sk of the PSD itself being the cousin attack point. After all if a domain d= oesn't exist, one may as well start from the top :-)

I think it would be more effective to add an anti-RUF requirement to= the implementation of this spec - such that no RUF reports would be sent, = regardless of the record which is published by the PSD. Since very few prov= iders even support RUF at all, this does not seem to be a big ask, although= it does require some additional logic. The privacy risk is primarily relat= ed to RUF, not RUA reports so blocking RUF could (IMO) effectively mitigate= the perceived risk of the PSD records while still allowing the DMARC valid= ation protection.

--Kurt
--00000000000068239e058648c84a-- From nobody Thu Apr 11 19:57:40 2019 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 2ED001204D6 for ; Thu, 11 Apr 2019 19:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=76MnHeJc; dkim=pass (2048-bit key) header.d=kitterman.com header.b=YnhtONef Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRfa0ZLShHwn for ; Thu, 11 Apr 2019 19:57:37 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB691204AD for ; Thu, 11 Apr 2019 19:57:37 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 153ABF807D9 for ; Thu, 11 Apr 2019 22:57:36 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555037855; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5U5Lj4bBLp9yv26Z6ViR944EJeOdKaICn/jW1w79kPA=; b=76MnHeJcoYBqI3AJzvQDj05BfSQd4ta7S+9EFS7KRraP/FnS2OFtuVlL l+J61sNUQLi8WlXdmXP+EkdlAgDuDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555037855; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5U5Lj4bBLp9yv26Z6ViR944EJeOdKaICn/jW1w79kPA=; b=YnhtONefCKb6rd65y6hYnexgIh/niI3nhBDS5ukbrXxd+TL2RC6A4Lrh 8dLErq6buMlFKTKHbjS0+fP+qDn+KDGyNrkkDQ0PdnhD2uAfgdsoGCVZNc DfDaxDeL4yNoPXWIXYE8sCZAPz+8BgU1JqtnrNpLEM3LUrAVE+CLe/SLiP YaYri0dyfOhYuP6O8peWBPZusmwL4niuIZRTJ/KTRBb66q+tCVUYIHkzNK HLRGclwNWSIf6v11gPjWeNZB9WlANbzoBmdXXQwQYTyZ2zuZRrXotdCihW luuIbqnjsi0E+Z1toMBU7k0z1KVaarkF9BHAhIjanclRzNQAM07feg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id B9DDEF8038A for ; Thu, 11 Apr 2019 22:57:35 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 11 Apr 2019 22:57:34 -0400 Message-ID: <2560485.41NbCdns5Z@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 02:57:39 -0000 On Thursday, April 11, 2019 03:33:34 PM Kurt Andersen wrote: > Firstly, just a nit, but section 4.1 introduces a new abbreviation in the > last bullet point: "PSDo". I suspect that this should be PSO for > consistency. Agreed. Thinko on my part. Fixed for the next revision. > More substantively, in Appendix A, the case is being advanced for "concerns > associated with Multi-organization PSDs that do not mandate DMARC usage". > I'm not sure why "multi-organization" is an appropriate qualifier, nor as > to what mandated DMARC usage has to do with any of the privacy concerns. > Neglected DMARC usage is what leads to the spillage up to the PSD level. > Even within a single organization there may be serious privacy walls which > need to be respected between different sub-portions of the org - which may > or may not be represented in a DNS hierarchy. When you say "Neglected DMARC usage", it gives the impression that you think not participating in DMARC is somehow negligent. It's not. It's not even an IETF RFC of any kind. DMARC is opt-in. PSD DMARC is opt-in for PSOs, but not for lower level organizations. When an organization is involuntarily subject to having details of it's email activity mailed to an entity which it has not authorized to get it, that's the very definition of a privacy breach. For single entity PSDs, the decision to participate in PSD DMARC and receive feedback is approximately identical to the decision for non-PSO organizations to participate in DMARC with their organizational domains. Yes, their can be sensitivities within an organization, but they have a common management to determine how to address those issue. The Internet doesn't have to do it for them. For multi-entity PSDs, there is no common management among the organizational domains, so it is a different situation. Where DMARC is already required within a PSD, compliant organizations have already opted-out of PSD DMARC, so the privacy breach potential is, I argue, effectively mitigated. Where DMARC is not required (approximately everywhere today), that's not the case and I feel pretty strongly there's an issue we have to address. > I've read through the breakdown in section 4.1, but I think that it is > incomplete - largely on the terms mentioned above. Also, the claim that > reports on cousin domains would be sent to the [right] PSO ignores the risk > of the PSD itself being the cousin attack point. After all if a domain > doesn't exist, one may as well start from the top :-) OK. If this discussion helps you understand where I'm coming from, I'd appreciate suggestions on text to make it clearer in the document. > I think it would be more effective to add an anti-RUF requirement to the > implementation of this spec - such that no RUF reports would be sent, > regardless of the record which is published by the PSD. Since very few > providers even support RUF at all, this does not seem to be a big ask, > although it does require some additional logic. The privacy risk is > primarily related to RUF, not RUA reports so blocking RUF could (IMO) > effectively mitigate the perceived risk of the PSD records while still > allowing the DMARC validation protection. I think adding a MUST NOT regarding RUF is a good idea. I added this to the draft for the next revision in the section about RFC 7489 Section 7: [RFC7489] Section 7.3 Failure Reports MUST NOT be sent for PSD DMARC. I don't think eliminating RUF reports is nearly sufficient. While the content of the RUA reports is certainly much less sensitive than the content of the RUF reports, they are still privacy sensitive. As an exercise, I've reviewed my own domain's RUA reports and explored what conclusions I could draw from them. I concluded it was enough that they are still privacy sensitive, much more so for small domains than large ones since patterns of individual users will be more obvious. Consider, as a scenario, the ccTLD operator of an oppressive nation state reviewing RUA reports and then passing on information to the national police when they see indications someone in a domain has been communicating with human rights activists. The 'law' enforcement agency can then require details from the domain owner to determine who the individual in question is. Yes, there are other ways this could be done, but I don't think we should make things like this easier. This is well within the scope of attacks described by RFC 7258. It's a BCP to mitigate such attacks. I don't think leaving them unmitigated is acceptable. Scott K From nobody Fri Apr 12 00:00:51 2019 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 021451200BA for ; Fri, 12 Apr 2019 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxdSF-UZdr0H for ; Fri, 12 Apr 2019 00:00:46 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F83120092 for ; Fri, 12 Apr 2019 00:00:45 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id q1so10528470wrp.0 for ; Fri, 12 Apr 2019 00:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PTWLCCRHJJ38VrUGL6w/mlGw+3a2UlGNmEbumnnoOYQ=; b=Mqo3CRbhCprl3lcEhcnSlSqsMzMSIk2v3TzytGXaaGTwL0GcVmmr+4i8UYntGTstgj r/prnh9LbSbAlYwMFG0vxuNKPGkP0X67S2tovLHw6xSMlk1R1Zwji49x6rR/ZIQerXea EpsC/ZyV3DrqQS61K2v6DPw9ahJM7VgBdfPLXFEfG5P2O0tJSK31Xm7hc0qbrPdSbKiR Q0i//HgYGfuv0IuvYstdUprPJO4faQhKjeGoC0QuG7Qnwy7LAnxeTWzX6225jtSIMk6a Yi+cCxl2jl7PvWHNH576JCQBe2sleTRcylFLTIHQWroBLItRcgfgwmfefDjxpgQYyrQc yXfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PTWLCCRHJJ38VrUGL6w/mlGw+3a2UlGNmEbumnnoOYQ=; b=m4NldIt4wxkcre9UH1fRmAV/6fZr44L84Q2CRG+bHeeL38WvBd2GlGamXNVBqxi1iX eunqyKhwT69qsBnEQTyl31l8vJHHvwAqQzvzd7CxZA+wvr4BK3hOwHtoVzu45U3AseDr aZ1/2cBq4DyUzKbgiD4D2LclhfSja+/D8q9YfnLN1Bo7aWqJ+kMHGwbNgFX/befNvAuA r880++J7pK7h+s2EtuB7yGpPzKqijzMz8OemDNej6X5uMKC0oMXWGMaJhoWOcYcY5cmg PU877XOlmUHFJLrmiAgVrIE2222KtFRvj9HMCVYuTjuyOCwWK5xUHc4ZmV6a2DadF8LS gMIw== X-Gm-Message-State: APjAAAU46HKhgDHg+jwnwvWp8ICn6j+IQ3VY4MZzLh6k14kH0kTGqXkn 0CpyYoC/eucaepxMNm0PCs0iDezuxX+vbqTf+TI8ESrxx+s= X-Google-Smtp-Source: APXvYqx3HhgOYSTbd0eEyM6+ZOx5Zf6TTHdmsrGWM9CBW2TcVqw6jHStsAHY8T24R4MV+ZGhnf215cy/q4W3iia64Tk= X-Received: by 2002:adf:e790:: with SMTP id n16mr23450756wrm.292.1555052444163; Fri, 12 Apr 2019 00:00:44 -0700 (PDT) MIME-Version: 1.0 References: <2560485.41NbCdns5Z@kitterma-e6430> In-Reply-To: <2560485.41NbCdns5Z@kitterma-e6430> From: Seth Blank Date: Fri, 12 Apr 2019 09:00:33 +0200 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008ab20405864fdc62" Archived-At: Subject: Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 07:00:50 -0000 --0000000000008ab20405864fdc62 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 12, 2019 at 4:57 AM Scott Kitterman wrote: > I think adding a MUST NOT regarding RUF is a good idea. > I think this is a bad idea for two very important reasons: 1) Any gTLD being used as a brand domain (i.e. .google, .microsoft, etc.) may wish to use failure reports on these domains just as they would on their .com's. 2) We wanted this spec to be the *minimum* delta from DMARC possible. That's why we added the third lookup but removed all other items. A MUST NOT for RUF no longer feels like a minimum delta. It also adds extra overhead to any implementation changes needed to test the experiment. We should (and I believe do) make the case in privacy consideration that failure reports for a third lookup is a bad idea. I don't think we need more of this right now. If during the experiment it becomes clear that this guidance is needed, then it can be folded into DMARC 2.0 when everything comes together. --0000000000008ab20405864fdc62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 12, 2019 at 4:57 AM Scott Kit= terman <sklist@kitterman.com= > wrote:
I think adding a MUST NOT regarding RUF is a good id= ea.=C2=A0

I think this is a bad i= dea for two very important reasons:

1) Any gTLD be= ing used as a brand domain (i.e. .google, .microsoft, etc.) may wish to use= failure reports on these domains just as they would on their .com's.

2) We wanted this spec to be the *minimum* delta fr= om DMARC possible. That's why we added the third lookup but removed all= other items. A MUST NOT for RUF no longer feels like a minimum delta. It a= lso adds extra overhead to any implementation changes needed to test the ex= periment.

We should (and I believe do) make the ca= se in privacy consideration that failure reports for a third lookup is a ba= d idea. I don't think we need more of this right now. If during the exp= eriment it becomes clear that this guidance is needed, then it can be folde= d into DMARC 2.0 when everything comes together.
--0000000000008ab20405864fdc62-- From nobody Fri Apr 12 04:38:42 2019 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 E9CBB12028F for ; Fri, 12 Apr 2019 04:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=P3eAIfvc; dkim=pass (2048-bit key) header.d=kitterman.com header.b=pBhQU4Q3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMhiZ3PKnIdG for ; Fri, 12 Apr 2019 04:38:39 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BE9120003 for ; Fri, 12 Apr 2019 04:38:38 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 03AE2F807C6 for ; Fri, 12 Apr 2019 07:38:37 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555069116; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=nHzBs3Hp4Y/Lzl9f1PpDKDlP+QZc/BZ97a6qm8FBeQM=; b=P3eAIfvcu+LhjTa1R/FFReAcQQptFWHFN5L/UvTKdpnamp6eu1H5Kbrl hhryxozdWoLx5P3xcNNXwASjjulKCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555069116; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=nHzBs3Hp4Y/Lzl9f1PpDKDlP+QZc/BZ97a6qm8FBeQM=; b=pBhQU4Q3oCNhSerbLq1jfJVyBKJyC3Zlx6DKqsC976YbEtltSpfxyU/e 7n+0oIReVglDUexQBavGrA05BmXAoYamHzKckm94KbCf6JqBrWrDMmgb6X ITqjPUkcYV9Lji4xJIDA6l7k+Dq5jHG4FpwwqUTg2KgTnRO2Z/RcRlSIcs ABpG66jHgZAU1PfCEuLkqcIKtTPV5ywh13pdjN05rs1HYw6/buZkwV9aG9 zhNM7c5vVcykr162m99VxcehlhxUNT7Eb68KJDDMwto9xu49E8uPv6C4ok TrncL15XfX40cldEi6qq67GGNJe4jIAIRsWO+oMVS/6lt3YMIEi99g== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id AEBC3F80029 for ; Fri, 12 Apr 2019 07:38:36 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Apr 2019 07:38:35 -0400 Message-ID: <4617305.8bk7ACbl42@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2560485.41NbCdns5Z@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 11:38:41 -0000 On Friday, April 12, 2019 09:00:33 AM Seth Blank wrote: > On Fri, Apr 12, 2019 at 4:57 AM Scott Kitterman > > wrote: > > I think adding a MUST NOT regarding RUF is a good idea. > > I think this is a bad idea for two very important reasons: > > 1) Any gTLD being used as a brand domain (i.e. .google, .microsoft, etc.) > may wish to use failure reports on these domains just as they would on > their .com's. > > 2) We wanted this spec to be the *minimum* delta from DMARC possible. > That's why we added the third lookup but removed all other items. A MUST > NOT for RUF no longer feels like a minimum delta. It also adds extra > overhead to any implementation changes needed to test the experiment. > > We should (and I believe do) make the case in privacy consideration that > failure reports for a third lookup is a bad idea. I don't think we need > more of this right now. If during the experiment it becomes clear that this > guidance is needed, then it can be folded into DMARC 2.0 when everything > comes together. I think your first point is a reasonable one. For the second one, I think minimum may be in the eye of the beholder. From an implementation perspective, I think the difference is trivial (if X then don't do Y) and I think part of minimum is a design that makes sense from a privacy perspective. As a practical matter, since so few entities send RUF reports, it's not a major issue either way. Let's see what others think. I'm glad to take it back out if that's the way the group leans. Scott K From nobody Fri Apr 12 06:04:36 2019 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 5CB6B1204D5 for ; Fri, 12 Apr 2019 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=fH1l5D4v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q8ZtCAbm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkzJjRe6CW-Z for ; Fri, 12 Apr 2019 06:04:32 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DF31204C2 for ; Fri, 12 Apr 2019 06:04:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id D488D4CF; Fri, 12 Apr 2019 09:04:31 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 12 Apr 2019 09:04:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:cc:subject:content-type; s= fm2; bh=xbQVQ4go1VLqaKxSr7Y5M6AP5iri56QnGxQYFjpRdsU=; b=fH1l5D4v NNLvSsZlx1woWpDr6yPObcX/axUMNNFZ+PdcTbbCp0/vHap3imHqGNCJiv9yXThP WNHiwRiudryHWo791w+deVMGSktKrFkizzieC1HQNPs0SrEZ0+F5z0QBjuYHQlPG fqDfHCAbKbWz5IPQGQSMf5waSGlmUycP4Nrv4tGd0B7O2+MNGMzwVFrY9KPQjfKG pip4YrbQlqeIn5uiv1XOmmmovhYtRpDxrhukCBktiuH7HDLsSBFxOcEg+YXUGWLB UR05f2yS6XYE3Rm61bfW95PzbvayUIZSCto/KfLOehqxlN1VL45VzTWEBmRyzxss o2JZn1LPudpePg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xbQVQ4go1VLqaKxSr7Y5M6AP5iri5 6QnGxQYFjpRdsU=; b=q8ZtCAbmgGKINEjX10zqFspL7Kj5nWCt+kegbBza9x9Dm Bbw99vA+LGS7F36QQ+6emr8je9R9YF/aMKDvxFqu5yQe+P9hzRXXQ4R8I148ZgaF ylM5RbGk0z6dGuZP0be6P1UXtpkt2+q9hPVM6z9Clsj4IsiVtD9JXkJ2K9KF0t0N T5fJqz3G3XNNao7805C5WxGq4i183Ekq9Nmswj7noHJHTVshQ9W15OgtJVy1zxup lbqed6L6gag1Pwkc2eI6gYJ72ZPm+AWJ7kJu1Qhv7SwhD5DfE3UDSKp3yjl8eopP IjDda76NcURXnpvn80ifO1K24PaK/tEKi84u6pWLw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvddugdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgigvgih ucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqe enucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghi lhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E33F8D4235; Fri, 12 Apr 2019 09:04:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-332-g22ddc6a-fmstable-20190412v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: Date: Fri, 12 Apr 2019 09:04:31 -0400 From: "Alexey Melnikov" To: dmarc@ietf.org Cc: "Seth Blank" Content-Type: text/plain Archived-At: Subject: [dmarc-ietf] Seth Blank as the new DMARC WG secretary X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 13:04:35 -0000 Hi all, I am pleased to announce that Seth Blank agreed to become the DMARC WG secretary to help Murray and Tim with organizing work and helping to get it done. Best Regards, Alexey, as AD From nobody Fri Apr 12 08:23:32 2019 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 41A181202DE for ; Fri, 12 Apr 2019 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxgvxpbiKoNu for ; Fri, 12 Apr 2019 08:23:29 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382C71202CE for ; Fri, 12 Apr 2019 08:23:29 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id y134so16291119itc.5 for ; Fri, 12 Apr 2019 08:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72PgCWN6M+bKndcwELmgjkfVgSEpyU/bgmsLUEw0cEU=; b=JJ4Qh1EBlzPif3Utfy7EhTWtlMhoiNEM2N+Is6QIhroyipAgeLOUmMpi8d4g00aP9f UPej2zFnXZb0vqRRdlkhSu9USbUxg++fLklnaDlE2nbXfS4R3jkrol2GYEaV+eLqqGfv xWBBx559LInG8kTQj5oFNm5L8Bb8W4D80Wxxk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=72PgCWN6M+bKndcwELmgjkfVgSEpyU/bgmsLUEw0cEU=; b=hOe36/njWR7+Q0AsyYMvW+b3IUHu7snyn2yVNj6UlSKCaCyaoQwlFml+Wq8fKDvBBn 6RcT15q5b5ESClsbsTz2DrPabkmfdY94y6cX1/Jlo9uuQh5IP7Rdfup/p764iHS++EG6 xyBmED60osNCLoPtfl3IBUYCFyafBAg/WE06LGOo8VfT48QbJ571cgAiU74FMbQ1o2XR jLqhVLEkybYhuNPoe14r52F7mDR08H9unctIeAuNlTQUBu7Mw3n4Czt1G2iagw/6eVwh s9luDPBQ4+t8L+qsCY8sr0z7MWoK2GBGt8Feft22nhRmeiNJKd5MPW9y2OmbeN0p1fsK dbqg== X-Gm-Message-State: APjAAAXmi/9EJLJrB0YJwKARUwW5JNG2G55BjfrwPus4TFUplocl1CBP /XWVHXrvFy+R4aNbIMIxaKt1gvZ4EdOLp0/L0WyyBA== X-Google-Smtp-Source: APXvYqy9QH8dGp9C4tlwS01PqvTF5IQ79XRcqxhiQvXpGjfjPUFsSUa8BLSD5u04kfI2+4wqNaVk/0Bp1MoctPOdyfo= X-Received: by 2002:a24:9cc2:: with SMTP id b185mr14484740ite.141.1555082608445; Fri, 12 Apr 2019 08:23:28 -0700 (PDT) MIME-Version: 1.0 References: <2560485.41NbCdns5Z@kitterma-e6430> In-Reply-To: <2560485.41NbCdns5Z@kitterma-e6430> From: "Kurt Andersen (b)" Date: Fri, 12 Apr 2019 08:23:01 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000792271058656e20a" Archived-At: Subject: Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 15:23:31 -0000 --000000000000792271058656e20a Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 7:57 PM Scott Kitterman wrote: > On Thursday, April 11, 2019 03:33:34 PM Kurt Andersen wrote: > > More substantively, in Appendix A, the case is being advanced for > "concerns > > associated with Multi-organization PSDs that do not mandate DMARC usage". > > I'm not sure why "multi-organization" is an appropriate qualifier, nor as > > to what mandated DMARC usage has to do with any of the privacy concerns. > > Neglected DMARC usage is what leads to the spillage up to the PSD level. > > When you say "Neglected DMARC usage", it gives the impression that you > think > not participating in DMARC is somehow negligent. It's not. > I'm using that term in the context of what you are deeming "mandated usage". Hence, not doing it is neglecting that mandate. --Kurt --000000000000792271058656e20a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2019 at 7:57 PM Scott Kit= terman <sklist@kitterman.com= > wrote:
On Thursday, April 11, 2019 03:33:34 PM Kurt Anderse= n wrote:
> More substantively, in Appendix A, the case is being advanced for &quo= t;concerns
> associated with Multi-organization PSDs that do not mandate DMARC usag= e".
> I'm not sure why "multi-organization" is an appropriate = qualifier, nor as
> to what mandated DMARC usage has to do with any of the privacy concern= s.
> Neglected DMARC usage is what leads to the spillage up to the PSD leve= l.

When you say "Neglected DMARC usage", it gives the impression tha= t you think
not participating in DMARC is somehow negligent.=C2=A0 It's not.=C2=A0= =C2=A0

I'm using that term in the c= ontext of what you are deeming "mandated usage". Hence, not doing= it is neglecting that mandate.=C2=A0

--Kurt=C2=A0=

=C2=A0
--000000000000792271058656e20a-- From nobody Fri Apr 12 09:14:04 2019 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 4A4C5120887 for ; Fri, 12 Apr 2019 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=xXZaZ1sK; dkim=pass (2048-bit key) header.d=kitterman.com header.b=XKMkKi1d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUt-cGFjMghc for ; Fri, 12 Apr 2019 09:13:56 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A32A12085C for ; Fri, 12 Apr 2019 09:13:56 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 02811F807C6 for ; Fri, 12 Apr 2019 12:13:55 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555085634; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=hVnledz5uT+xLmBb4lxzteBXSEhZ/0ivhBAAtHo8eJU=; b=xXZaZ1sKu0EfxxRjC9gzhyQrkeNxyF3p4l3ifeUxiE4LFAaN4IOAntRZ hdRRWWr4YkOpnRfmUeU+jtRU6TQWBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555085634; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=hVnledz5uT+xLmBb4lxzteBXSEhZ/0ivhBAAtHo8eJU=; b=XKMkKi1dwNZtUXgT3j3+h5uJWr4IjNyHCCz4AUj2N3ERVmuJjDXGGVtW bDpE5I3NYJB391bH0avYnFf4q0YGDm5dbUxcqt/9BJksASnV6m0LjvnTDZ gEcIE0VcHdvvbTZG6sF7JSsr3t7pmlaQWDsL9yjNe+eP8jNh9N0IWE324n m2KuotTe3+6NZSdjI0EvK0dhhKRZJBZL6I/tD164zJHYCJYzQCfSpYv5fG YKF/0TzlVqdYDANQW8CE+DEM3U8RlXJQ+OtuglauwMoJ85dVN+oexH3gpy v7SezzhPsbNWfpBpTt4edCyoclOkmwfZtAXxlubk35BIeO0+KsCtbA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id C03F5F80706 for ; Fri, 12 Apr 2019 12:13:54 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Apr 2019 12:13:54 -0400 Message-ID: <1944287.uG7mQ2khBI@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2560485.41NbCdns5Z@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2019 16:14:03 -0000 On Friday, April 12, 2019 08:23:01 AM Kurt Andersen wrote: > On Thu, Apr 11, 2019 at 7:57 PM Scott Kitterman > > wrote: > > On Thursday, April 11, 2019 03:33:34 PM Kurt Andersen wrote: > > > More substantively, in Appendix A, the case is being advanced for > > > "concerns > > > associated with Multi-organization PSDs that do not mandate DMARC > > > usage". > > > I'm not sure why "multi-organization" is an appropriate qualifier, nor > > > as > > > to what mandated DMARC usage has to do with any of the privacy concerns. > > > Neglected DMARC usage is what leads to the spillage up to the PSD level. > > > > When you say "Neglected DMARC usage", it gives the impression that you > > think > > not participating in DMARC is somehow negligent. It's not. > > I'm using that term in the context of what you are deeming "mandated > usage". Hence, not doing it is neglecting that mandate. OK. I didn't get that. Agreed that for an organizational domain in a PSD that mandates DMARC, not having an organizational DMARC record is neglectful. In that context, I think it's perfectly reasonably to say that if you don't follow the rules, you get the consequences (in our case the PSO gets your reports). Somewhat similarly, for a .bigcompany PSD, it's really an internal matter if they want reports to the PSO or various subdomains. So there are two criteria for is there a privacy risk in my view: 1. Is DMARC a requirement for organizations within the PSD? 2. Are multiple organizations represented with the PSD? Hopefully this ASCII art truth table will come out OK (leading '/' represent negation (i.e. not required and not OK): |One | Multi | |org | org | ------+-----+-------+ DMARC | | | Req | OK | OK | | | | ------+-----+-------+ DMARC | | | /Req | OK | /OK | | | | ------+-----+-------+ In the lower right corner of the table where I see the problem, there's no mandated DMARC usage, so the opt-in/opt-out problem exists. I hope that makes it clearer why I used multi-organizational as a qualifier. Scott K From nobody Sat Apr 13 05:47:40 2019 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 8CEDF1200CD; Wed, 10 Apr 2019 09:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=FE1ZRHw6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uCeZgEv/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f64pRP1qaaQg; Wed, 10 Apr 2019 09:01:19 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C19D1202FA; Wed, 10 Apr 2019 09:01:19 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id BE754D825; Wed, 10 Apr 2019 12:01:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 12:01:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Q TQB+iFAoD8qzy5TnA9QII/4znlaCuf5D/uWFkxOCmY=; b=FE1ZRHw6+aTt2tUSJ M+kVF9Jl1tQEJDM35DU6ejqKgNNv2oAw2JwU2dpK8MKe2GzP8GtyUf8mM2MYMeAB LsH5uQZOVx3FcxyASeqD6gbuDnh5R0fAqtR5FNLZu5WAPssczKJFWT/M1eJjP/Mb seaFLmYwNggkAgIh4zoZQVt7qp7xdWPKMs4Tzvv6hV8hVe9PHhWK0j0oyzAWB2zS glzmKKJ/PnkBHwn2tJQraIkBkJE4QGed8YvQjDSG8b0LpyYh+EXQjJusXqwSXiWZ y83FZK2qOimgq7ew8Gw3IZ85Ld73+kdzBwBe5Xhg7itlqmcnilQQgijwvoC6IZDW jEWNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QTQB+iFAoD8qzy5TnA9QII/4znlaCuf5D/uWFkxOC mY=; b=uCeZgEv/g8+/yFUj9vHxBvHOXhh5usuAiAfw/HKUMWVeEO/Mu8j9rpQGH Pwy+AxvwI8VP05nTYPzRNlDcrvptSk9ST5fP/UqtcumIDMoax/k5W8X47AdyDPxr q8HpFe5sHNQT1helIEi2t+Y7zTo6QPPJNC8XChSzC/CSIlBtEhE5VfnZ34FrlqAV 7Kqiji5hgWf4SBxAilXbYiXZBveMZWx49zRWYdMWrK8XgMFTVGKU42h1Y64gEz39 bS9wyAytGSkGzohF0Glleh/wVQm9Cf6jlNaNSuQrflofkdgi9f754y9IHf5NaVcl 6sVfTTBrOjuu/bTbqR1Bch9vaLI3A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghdpthgruhhghhdrtghomhenucfkphepudejfedrfeekrdduudej rdekjeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrd hinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id CE4AFE41C3; Wed, 10 Apr 2019 12:01:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Wed, 10 Apr 2019 12:01:11 -0400 Cc: Tim Wicinski , Ben Campbell , Adam Roach , "ietf@ietf.org" , Alexey Melnikov , Tim Evens via Datatracker , "gen-art@ietf.org" , "dmarc@ietf.org" , Murray Kucherawy , Barry Leiba , Kurt Andersen Content-Transfer-Encoding: quoted-printable Message-Id: References: <155234487991.23094.14124317288389045798@ietfa.amsl.com> <53F5AD4A-BCE9-4E00-A982-4365BBD9ACA8@cisco.com> To: "John R. Levine" , "Tim Evens (tievens)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-Mailman-Approved-At: Sat, 13 Apr 2019 05:47:37 -0700 Subject: Re: [dmarc-ietf] [Gen-art] [taugh.com-standards] Re: Genart last call review of draft-ietf-dmarc-eaiauth-03 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 16:01:22 -0000 Tim, thanks for your review. John, thanks for your response. I can see = how the section references could be a little confusing, but given the = context of the surrounding text, I think leaving them as-is is ok. I = entered a No Objection ballot. Alissa > On Mar 11, 2019, at 8:31 PM, John R. Levine wrote: >=20 > On Mon, 11 Mar 2019, Tim Evens (tievens) wrote: >=20 >> I should have been more clear. This is NOT specific to HTML/HREF = rendering. Section references to an RFC without the RFC mentioned is = misleading. For example: >> " DMARC [RFC7489] defines a policy language that domain owners can >> specify for the domain of the address in a RFC5322.=46rom header. >>=20 >> Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the >> RFC5322.=46rom address domain are to be handled. That section is >> updated to say that all U-labels in the domain are converted to >> A-labels before further processing. Sections 6.7 and 7.1 are >> similarly updated to say that all U-labels in domains being handled >> are converted to A-labels before further processing." >=20 >> The above references Section 6.6.1 (and Sections 6.7 and 7.1), but = from which RFC(s)? Are these from RFC5322, RFC7489, this draft? This = would be somewhat more clear if this had mentioned the intended = referenced RFC (7489) in the same paragraph that the reference is made. = For example, In RFC7849, Section=E2=80=A6 >=20 > All of sectioh 6 is about DMARC and the only RFC mentioned in section = 6 is 7489 so I assumed it was clear enough that's what the references = are for. I suppose I could add "of RFC 7489" after each section = reference but it seems awfully pedantic. >=20 >> "In RFC7489, Section 6.6.1 =E2=80=A6 " is equivalent to "Section = 6.6.1 [RFC7489]." IMO, authors (in general) should put effort into = checking that the various renderings meet expectations. If there are = incorrect hyperlinks, fix them or remove them. The rendering issue is = not just HTML, it also effects the PDF rendering. >=20 > That really seems like something for the tools team or the RFC editor. = The xref links in the XML are all there, and the stuff you're worried = about is all mechanically created by xml2rfc. >=20 > R's, > John_______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Sat Apr 13 14:12:29 2019 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 90B6212030F for ; Sat, 13 Apr 2019 14:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=vZqm+jDI; dkim=pass (2048-bit key) header.d=kitterman.com header.b=PmikKL1r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8_WOUmEJa2z for ; Sat, 13 Apr 2019 14:12:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C40A12026B for ; Sat, 13 Apr 2019 14:12:25 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 0CAC9F807E8 for ; Sat, 13 Apr 2019 17:12:24 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555189943; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=xm17an4AqrcNOHQ4e/+kaSY4QXr7WrxR8eVNK+zErbg=; b=vZqm+jDIWlLfdIrymwxoR3cTeSfhqmPO1X7fWTNoT2Fn8+6aUSvANrEU EARTMVFiPjz++uEW1bCkPmZx+770AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555189943; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=xm17an4AqrcNOHQ4e/+kaSY4QXr7WrxR8eVNK+zErbg=; b=PmikKL1rK55ECth1pcOUE1rgE5DTm9KVCe8ClCC7hyETNS5v9R7APHvI 6aQSSDWEhIiFyZEDLVvSNA7AA2KooQAzUmKM60VkknvXKm7mIbZl+Ds9YG JzgSm8cvjmgigcfrbw7/1LFQP0Orgm6q2RBROIqM8sBMalPpff1rfLrHNh F4d3l2M7mQDzg9hDuNcwYRYaIbOBzh2OFLpIEAFnaO4FO1D4PAKJ7bmphf +7Mcj50DJ+XxNJCuhMn0j65DpOCQDclExuajANjot4tEsfR/ObTIUD6SWl nSv9xuHel8tNEpgocv3xgStpXdRzVjD322Bq88/Vc5Q1elCNhqXHSw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id CDDFAF807E3 for ; Sat, 13 Apr 2019 17:12:23 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Apr 2019 17:12:20 -0400 Message-ID: <8060835.KeXT7UZBJi@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] DMARC Coverage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 13 Apr 2019 21:12:27 -0000 A couple of days ago I sent a single message to a reasonably large mailing list (spf-help, email oriented - so likely not representative, but it's a data point). Since I am a list owner, I know how many subscribers there are and from my DMARC feedback, I know how many times that single message got reported. 43% of them showed up in my DMARC feedback, so that's at least one data point on breadth of coverage for DMARC feedback. To do this (at least the way I did it), you need to send a single message in a reporting period to an email list that does not re-write from and for which you know how many subscribers there are. I'm curious what kind of numbers other might be able to come up with. Scott K From nobody Sat Apr 13 20:20:56 2019 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 46C7B120351 for ; Sat, 13 Apr 2019 20:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EeYqes7j; dkim=pass (1536-bit key) header.d=taugh.com header.b=DTVeOLKy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdsciepNsmqf for ; Sat, 13 Apr 2019 20:20:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7312312034D for ; Sat, 13 Apr 2019 20:20:52 -0700 (PDT) Received: (qmail 23506 invoked from network); 14 Apr 2019 03:20:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5bce.5cb2a711.k1904; bh=VSOnkeVJmUL+Vw0oTINr00/rkJDJ7UUM17sJ8mvea+I=; b=EeYqes7j8KSbtxeOUhh7nT6HlotfF3biILvmqfOAmgXJv25WeqqnZEixRPPq6nuxDVv7KBb9wMsPdw4HBbnk4qv0SCpGmuk9fiRJuB9c0cStGmiBulny8hCIlxEehmcN4dzW/vv0Z2sT68X5A+n1cdtK8y9OrEBBncfQIzsTwkWSqQymnXu3J+yZDQIXp45WtKTbWQIwM0kqn+bG+cjgMR+cBdKp0WYkNh1il8Cceu1TZy/8zgtvd1CJoWoQC8xN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5bce.5cb2a711.k1904; bh=VSOnkeVJmUL+Vw0oTINr00/rkJDJ7UUM17sJ8mvea+I=; b=DTVeOLKyrSfPHK9gfnL6THwaLggTH3qfNhUbnp/OXGvvOqd7P62u/f7Xvjbh3T9BS0Rf6lydIM/3OFEP27qWesKWNbKme15SUnbTCc5VnwPhXy7ZGdYaZU72Kh8fssiI3fBt3EMWktM/Kn+xRIuRmKcEN052MNujrvnyi3eBAlp0BIHW8eY9BenE++iXXSpAVDMD7E9OujJU8VyjYFKk1R7dXyEUZfvSEarhCRg+mvVe9jX2Lls5TUdXDCw27lqt Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 14 Apr 2019 03:20:49 -0000 Received: by ary.qy (Postfix, from userid 501) id 113592011EB715; Sat, 13 Apr 2019 23:20:48 -0400 (EDT) Date: 13 Apr 2019 23:20:48 -0400 Message-Id: <20190414032049.113592011EB715@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Apr 2019 03:20:54 -0000 In article you write: >On 4/10/2019 8:37 PM, Scott Kitterman wrote: >>>>> print(response.additional) >> [] >Turns out that's what I was especially hoping to see. As I understand it, your design depends on putting NXDOMAIN signals in the additional section to show that there aren't any boundaries between the names it returns. How do you plan to do that? R's, John From nobody Sat Apr 13 20:40:47 2019 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 61EC4120355 for ; Sat, 13 Apr 2019 20:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osPaltud26jp for ; Sat, 13 Apr 2019 20:40:45 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D826312034D for ; Sat, 13 Apr 2019 20:40:44 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id e5so11677497otk.12 for ; Sat, 13 Apr 2019 20:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XHV7eSFAw81Y7lN701BYx9eMHSngppTMWPAB472tnLM=; b=FgKQNcmM+w4pZ4SHvjGKRYcoSjIB+5DwjyUcHeccSw0qVGrxuHulmqmdtuNet427pt 8swP9Py7bGZIMzlArLsCYo67V6ZFE3DGWnJ34xoNGusU30fjXpmNojxX6VipldVaSkGO 4+gnsb4b10rVFlHcSwaoUjoW4hteW2j/3zkerv387RedHmtZjLzO+l80FdyBP0WwMaDl RlSIL1ajOG1OQiO93wQQONHSZeySp5TcCSuIGiOo+0ny6VUk11PzdRauWhnn4RKTEJct 5pyeg2O0YAkWv+Xy97L4HJ6WTuXqGHIKCUQ+zx6ZhsU+uk7AvLoWG0k05UMaHftxhXBT 516g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XHV7eSFAw81Y7lN701BYx9eMHSngppTMWPAB472tnLM=; b=N1relCZaFEoChU1Jy9P5dXRlw4kV/ZAkH7J5jw7gAQ6jMYbQa07Qo7JpNm4PuELPcO w1v2Dh5lAr4F5iJKd3V6uBMDgQ9VMvyk6hqj+vV2c4k5VUWYEXYMa7FcXWiurmtZysJN f2LHir8EG7vNa4HPA4rbQ/+i7rkhCLvlo/XwFd/6YPn5EnNKN7qL0zVhL/FvtaY53JdR nO9ltwHYw1hVr5B4GlEAEMS8PkqY1aTzJewe9zO7Mos1YJA558Nr6WJANlNxDat+T/QR rrp8Kqlc3fFTPKcpzkBa47aML/MpUuO3FufSoj8KWqJij+2oPuSKvj3bXzxSj3O0p7bF XfFA== X-Gm-Message-State: APjAAAX6VxuE5tSc9D2qDJM5ut9PPGtzeT+bXFpG/ZX7BP6eTFLZ+NvD 9uXnK4NuDXqpgPwfjPC15Ndf2U0x X-Google-Smtp-Source: APXvYqz4YKTSO0oLbKtQFSxB1xx3XpY3j3lwAUtGLb/itFgafHkVDVYE7Hp26KxXSu2B2rZHSSJesg== X-Received: by 2002:a05:6830:1390:: with SMTP id d16mr44054011otq.30.1555213243787; Sat, 13 Apr 2019 20:40:43 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:48e7:4131:7580:907a? ([2600:1700:a3a0:4c80:48e7:4131:7580:907a]) by smtp.gmail.com with ESMTPSA id q205sm11666225oih.17.2019.04.13.20.40.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Apr 2019 20:40:42 -0700 (PDT) To: John Levine , dmarc@ietf.org References: <20190414032049.113592011EB715@ary.qy> From: Dave Crocker Message-ID: Date: Sat, 13 Apr 2019 20:40:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190414032049.113592011EB715@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Apr 2019 03:40:46 -0000 On 4/13/2019 8:20 PM, John Levine wrote: > In article you write: >> On 4/10/2019 8:37 PM, Scott Kitterman wrote: >>>>>> print(response.additional) >>> [] >> Turns out that's what I was especially hoping to see. > > As I understand it, your design depends on putting NXDOMAIN signals > in the additional section to show that there aren't any boundaries > between the names it returns. How do you plan to do that? John, I don't understand your note. I don't know what you mean by "NXDomain signals" and I've no idea what you mean by "show that there aren't any boundaries between the names it returns." The latter sound strange enough to make me suspect you read some draft other than mine. And just to add a bit of constraint, my this sub-topic within the draft concerns a possible means of getting some efficiency in a search. It's offered as a discussion session in the larger spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 13 20:51:22 2019 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 7701B120139 for ; Sat, 13 Apr 2019 20:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=n7gQr/BO; dkim=pass (1536-bit key) header.d=taugh.com header.b=C0s5ejz+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj2rNsUlZzj6 for ; Sat, 13 Apr 2019 20:51:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CB31200DE for ; Sat, 13 Apr 2019 20:51:18 -0700 (PDT) Received: (qmail 29132 invoked from network); 14 Apr 2019 03:51:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=71c8.5cb2ae35.k1904; bh=eblLgJBZ87wLXn+ZnswIp8KyP/r4XEoS1VmHebE54xc=; b=n7gQr/BO9eWSVr3EODfpmJ1qLSgUAZm4/2a7xLwV9GDem163W5YSoRvX0J+WDYrFbYYV1bBUx/lMAiqCNa8/ECN/g64lRxI36bx7M5Iy9a8Q6ZSm2arFMaTT135VTqm/+Lau4O5O1v/RLYruRvOMgtJcUEpKowudj5EdaJLd5Qb5P7mFOwxV1xgch9i6eE+iRKkmJCPfnAfxr6dO/mpG5BkyWe/bOjPyfi2nLolNsUertSjDHIAohVqTTGsFLsXD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=71c8.5cb2ae35.k1904; bh=eblLgJBZ87wLXn+ZnswIp8KyP/r4XEoS1VmHebE54xc=; b=C0s5ejz+w41lPxdL6gxkMPmUd8KixhuT78LqPWP5axELR9rYf8n3lLzkQF2UatIZ2y6aLPFmCX6PMAwx/URJYw52vUvuDYRcPVeKiJ9Hwaq2iCuDIXXI06c7JXqFHnPYJGyZiovKGuiV/x87DvcCK9F8V6N3KGSk6P95Bg2Vf2KyNjTG/RaBr4on6W3RPKpnwqBtQ6k/ZMJRl3i4ew/jIBXFkpsZEa0TPaDzPIvjpprAuLC8GZYB1N5tvCiI5aU3 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Apr 2019 03:51:16 -0000 Date: 13 Apr 2019 23:51:16 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: References: <20190414032049.113592011EB715@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Apr 2019 03:51:21 -0000 >> As I understand it, your design depends on putting NXDOMAIN signals >> in the additional section to show that there aren't any boundaries >> between the names it returns. How do you plan to do that? > > John, I don't understand your note. In draft-dcrocker-dns-perimeter-00, it says this: Another approach is use of the DNS Additional section in the server response. When there is a query for a Perimeter node, the server would include the associated Perimeter BEGIN record from earlier in the hierarchy, if the queried node is within that hierarchy -- that is, is above the actual or virtual END record. If you asked for _perim.a.b.c.example.com, and the perimeter is actually at "c", there, you hope that modified DNS servers will return NXDOMAIN and in the additional section add _perim.c.example.com. But since the additional section info is just advisory, that doesn't tell you anything about _perim.b.c.example.com, which might exist or might not. To avoid doing a tree walk, you'd need a signal that _perim.b.c.example.com does not exist, and there's no way to do that in an additional section. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Apr 14 06:38:57 2019 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 975BC120098 for ; Sun, 14 Apr 2019 06:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKMFlY4-xwyW for ; Sun, 14 Apr 2019 06:38:53 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7152712007A for ; Sun, 14 Apr 2019 06:38:53 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id p10so18243304wrq.1 for ; Sun, 14 Apr 2019 06:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a13B9Z9SGHGQ+Xuihcb2R3BTHpcP9YcSFiHTUE0+8G8=; b=ZdOzI07TJmBhtEhOAHUsOzCC7cJhQq9nEx0uU+M4ybqpumzeEWMpKgbmCPB4/sHHrg Hxibb0GzEPU/8eqTIPBe0RrMCs0VQigzRGwaxLxX+uHW8onF4yRTElDcpV9zrqaavrgw 66sXNwLEq8Fp6s747vJ4hWptILTITrL7pnvqZUERBcz/a4H7oKB9XRt3XbsvbyepTRaG jcGaqMzh5zyKKRQXksPoojMQKN+slS72lI/as1LyEJCQIQAkiukhHv2VmdEw5fMOjEDK lrksgbT4PUJHwUfdomS7/C94LYiPS5imwY14MpGKO+QxDhmBRPuML5qH0/STrRHPkYzG S89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a13B9Z9SGHGQ+Xuihcb2R3BTHpcP9YcSFiHTUE0+8G8=; b=bspTy1HGxip0TiHwFTBdVaCmr7D43bki9/CHX3I5/oU1D8eFACRFkmnGbM2ijKPXsN 0ZlowMWyr4yQZhZPLl9wFj+k4Yu2tyySrgpyZ1t3ce7DxfOs9G8fcDBn+UB5xfC2UHbJ eh9y1DuG1EPa3oG1oCTM9lcn5WFGzQ6I2RENxSq9uDOwj/P6kOKv9MFxAUhEFjtytBP1 rUMtOMKL01y1Ztm3gT/EYvBaBEix3EmieEYS/Ohjg956TYWw8UwyLNwnYQ97wb9GUCad DVUI98uzcEsetna0joeaWjvvsdrdZTGqzL3p+I9ebprSfVAkdSHrmCV6g2fsFKNCBTL5 pA2g== X-Gm-Message-State: APjAAAUheVMpVLPMSw3u2fVfoDaUHL4eFHqdXC9ihxyASCkoI6znWUQB eLvekjjJH9egY+9ipovu8O6CvmlZoTosbCapP5yCFPC9 X-Google-Smtp-Source: APXvYqxOjPTZOgD39KP4TlT9RbQfi1AxkgSuhDazjbBwrEF7/pgYgIiOREGDNZqFCS/UGvF6gkFq742F5lqKgAqCxYw= X-Received: by 2002:adf:ea0b:: with SMTP id q11mr24918761wrm.233.1555249131867; Sun, 14 Apr 2019 06:38:51 -0700 (PDT) MIME-Version: 1.0 References: <8060835.KeXT7UZBJi@kitterma-e6430> In-Reply-To: <8060835.KeXT7UZBJi@kitterma-e6430> From: Dotzero Date: Sun, 14 Apr 2019 09:38:42 -0400 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000ad49505867da83b" Archived-At: Subject: Re: [dmarc-ietf] DMARC Coverage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Apr 2019 13:38:56 -0000 --0000000000000ad49505867da83b Content-Type: text/plain; charset="UTF-8" Scott, it's almost certainly an undercount as there are domains which validate for DMARC but do not send reports. Michael Hammer On Sat, Apr 13, 2019 at 5:12 PM Scott Kitterman wrote: > A couple of days ago I sent a single message to a reasonably large mailing > list (spf-help, email oriented - so likely not representative, but it's a > data > point). Since I am a list owner, I know how many subscribers there are > and > from my DMARC feedback, I know how many times that single message got > reported. > > 43% of them showed up in my DMARC feedback, so that's at least one data > point > on breadth of coverage for DMARC feedback. > > To do this (at least the way I did it), you need to send a single message > in a > reporting period to an email list that does not re-write from and for > which > you know how many subscribers there are. > > I'm curious what kind of numbers other might be able to come up with. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000000ad49505867da83b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott, it's almost certainly an undercount as the= re are domains which validate for DMARC but do not send reports.
=
Michael Hammer

On Sat, Apr 13, 2019 at 5:12 PM Scott Ki= tterman <sklist@kitterman.com> wrote:
A couple of days ago I sent a single= message to a reasonably large mailing
list (spf-help, email oriented - so likely not representative, but it's= a data
point).=C2=A0 Since I am a list owner, I know how many subscribers there ar= e and
from my DMARC feedback, I know how many times that single message got
reported.

43% of them showed up in my DMARC feedback, so that's at least one data= point
on breadth of coverage for DMARC feedback.

To do this (at least the way I did it), you need to send a single message i= n a
reporting period to an email list that does not re-write from and for which=
you know how many subscribers there are.

I'm curious what kind of numbers other might be able to come up with.
Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000000ad49505867da83b-- From nobody Sun Apr 14 07:05:21 2019 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 8E7AA12004D for ; Sun, 14 Apr 2019 07:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAjBqEoEiO2j for ; Sun, 14 Apr 2019 07:05:17 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930FC120003 for ; Sun, 14 Apr 2019 07:05:17 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id i21so11658738oib.11 for ; Sun, 14 Apr 2019 07:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q6Fg+aPpPj6Y4iA79wdc/+4vVKDHP2hVfs43hQLCNyo=; b=DXekpUwJSOHp0ZQ8dXgPNPBIC/lUch9/tQXXf0+R/jglWoMCV9VpGKvAo8AABnlPiF 9X7LohbxrZYm0ipdA+XHJw7Wmn9dXOvhGp+Sh7T1hM5LxWXZuuxHaAALeFi1dB/l9vfI FLQGHAcv4/sOGRZoiJHBy7Ct40umhDnELylCuVPjPii7K6SmauNMFrQljonlN0TC309C D64TaHqmSRWgN+OD6+TaOkUnWUOnue6r6kck9u59kiopskswSM0sZ5RXHdu0+z/Zpl3T u4OWCJo8i6RGSaGT1bWeTMMygIiCcCiaU/4TAYIlw4IvnSB6JdWrwRfsFNRIj/47LS12 tvWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q6Fg+aPpPj6Y4iA79wdc/+4vVKDHP2hVfs43hQLCNyo=; b=p5+mQeXTNwu0tooIRonYisMcqfF1wlM8UtSgMrJiDEskYtUZALDYW35VscMbhLr+ar VWOf4IgVF1yVScQMY0oQlAOwSWUKjJBuvBu4PnVTjWXPeWpmYM7LMGmQab2NsEeZxTW7 +65Z4y3mjY/buJ3FaP1gO8dSPVT7SETmIwcZjCE6KVp5+hOd9jzSs8OVhhZo3dmde2lC 7/67E9cpTr1c62ihVbzJd4Psg4CgBpz5EDvOUhxp6g9eBEgYx0elmK7gX1iW8pA4Sejk TY00ydg5aWcSieXE41GruLT/Li9ZLUYmmos94XlTWqNWODrVFmPaQdcBFnA1QiW3Vu8V BjoA== X-Gm-Message-State: APjAAAV2YRSRf1rM7DxI7RF56W7Xg8p0siuKmu2QoR0uqmhmCE0Bx8L9 4c3GQTAWt2MXFUn6ltS4yKu8xG9e X-Google-Smtp-Source: APXvYqxXvS/5ZzGF4IgMBSzJmAbcAibcn9F4xUdaHuCr4OtHBgw/omEJuidA0a7LSsnaT2VrQTSFUQ== X-Received: by 2002:aca:3905:: with SMTP id g5mr16889684oia.49.1555250716034; Sun, 14 Apr 2019 07:05:16 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:8981:f659:72f2:350f? ([2600:1700:a3a0:4c80:8981:f659:72f2:350f]) by smtp.gmail.com with ESMTPSA id m22sm12425437otq.47.2019.04.14.07.05.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2019 07:05:14 -0700 (PDT) To: John R Levine Cc: dmarc@ietf.org References: <20190414032049.113592011EB715@ary.qy> From: Dave Crocker Message-ID: <7741d1b8-852e-37ba-ad7b-6b0103b4518d@gmail.com> Date: Sun, 14 Apr 2019 07:05:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Apr 2019 14:05:20 -0000 On 4/13/2019 8:51 PM, John R Levine wrote: >>>  As I understand it, your design depends on putting NXDOMAIN signals >>>  in the additional section to show that there aren't any boundaries >>>  between the names it returns.  How do you plan to do that? >> >> John, I don't understand your note. > > In draft-dcrocker-dns-perimeter-00, it says this: > >    Another approach is use of the DNS Additional section in the server >    response.  When there is a query for a Perimeter node, the server >    would include the associated Perimeter BEGIN record from earlier in >    the hierarchy, if the queried node is within that hierarchy -- that >    is, is above the actual or virtual END record. > > If you asked for _perim.a.b.c.example.com, and the perimeter is actually > at "c", there, you hope that modified DNS servers will return NXDOMAIN > and in the additional section add _perim.c.example.com. Good. That language seems about right. > But since the > additional section info is just advisory, that doesn't tell you anything > about _perim.b.c.example.com, which might exist or might not.  To avoid > doing a tree walk, you'd need a signal that _perim.b.c.example.com does > not exist, and there's no way to do that in an additional section. The rest of your paragraph, again, is confusing and probably misleading. First, by definition, the fact that NXDomain is returned means that _perim.b.c.example.com does not exist. There is no need or suggestion that the Additional section also indicate that that name doesn't exist. Rather, a query to such a non-existent domain will provide information that it doesn't exist by using the usual NXdomain response, except that response will /also/ have an Additional section, containing information about the node up the branch that contains the Perimeter 'begin'. My draft doesn't yet offer a detailed specification for this. It's phrased to explore an approach. So the details of exactly what would go into the Additional section for an NXDomain response are tbd. Let's wait to criticize or improve those details until after they've been written. As for the concern about 'advisory', that merely means that the client would need to confirm the information from the Additional section. That's one more direct query to the referenced _perim.c.example.com. Doing exactly one more query is already demonstrated to be acceptable, at least for some applications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Apr 15 08:44:49 2019 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 691F3120441 for ; Mon, 15 Apr 2019 08:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=RxlKgokb; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=c6x51FXV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkPjoJAFAXml for ; Mon, 15 Apr 2019 08:44:38 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1C120436 for ; Mon, 15 Apr 2019 08:44:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=199; t=1555343076; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=uXKTVpHzx7pvekKAPc2uRUpMDZM=; b=RxlKgokb/2FLeWHz9lQV5TPoZXtIHBXsefrnzPUoGadT+exuvNZA3sTat0tTxq AGbrDupBy81A0sATQ+zFm5ebpaZ/Tyd//vaJdqUy/4JFe6yjqpD0fJEPdyljJzPH xD1p0NCkagPHdT2AOGuqm1xTbyA34WtOze9534PUDax9E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 15 Apr 2019 11:44:36 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 430539889.5.2112; Mon, 15 Apr 2019 11:44:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=199; t=1555342994; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TCq9Lzv /VYs6hg3Dvbc1DDcfWLAXBPwYjUBz+CzXeCM=; b=c6x51FXV0FmhmabcbXI7xw6 bq/6ukAOP4cuSs/KIDQBs4H9iNfOC+iLgn01hlcARr6yNDQTkxRiPMDQgF3qIPim sJNhaHE7O9VMw/A+RqkUgFq8Fov9pPYTQ+1j3nHhl5GcBWl5cRGjI1x42vhCyzud QNEVGuT4tGVUVmsMZc4k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 15 Apr 2019 11:43:14 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2002816691.9.80508; Mon, 15 Apr 2019 11:43:13 -0400 Message-ID: <5CB4A6E1.6050902@isdg.net> Date: Mon, 15 Apr 2019 11:44:33 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <8060835.KeXT7UZBJi@kitterma-e6430> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC Coverage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 15:44:44 -0000 On 4/14/2019 9:38 AM, Dotzero wrote: > Scott, it's almost certainly an undercount as there are domains which > validate for DMARC but do not send reports. +1, without a doubt. -- HLS From nobody Mon Apr 15 09:52:27 2019 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 347D512000F for ; Mon, 15 Apr 2019 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt9ifR6ZnHdb for ; Mon, 15 Apr 2019 09:52:24 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5151200F5 for ; Mon, 15 Apr 2019 09:52:17 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id s3so13403950itk.1 for ; Mon, 15 Apr 2019 09:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9gHBUJE7zSnRlcdzYLVqummaWITfsy1hu5jJ5QfcZq4=; b=PSs7m2ildhty3WTvSRkKYgOmpSA1Hvk0kospN7KYKDevabdFu3x0s5o4xyNz8riAQw H1E+SCyvYkVb0kPKSgkSXhQIBCRBPj6TiPSAU4gy0QDYPpRv9s9OtNcE9PBCDC5T8gtc pmimeYNyJw8odyc4zPrayJBCs7Eb6Wgsva8jc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9gHBUJE7zSnRlcdzYLVqummaWITfsy1hu5jJ5QfcZq4=; b=L0nHovphsyOUmOA0fTQtT0Gt7uCl07wfgt9wOUOam9EbDKNh0MvGWrrGScQQ+IcUWX tj8SPqi58aYfOqqfXqBTQ5nqhY6ifrQOJcPKFk/TBtSVClaXrcH/HePZ6gYlbQ5Zum40 bBtOMFlaYiSRfSKS7cHKgEE/1OTIAoaf+xHa7iPd6cSX2BrUwL13yh2zr6chz8qDOiAB nsAfW1CDPLt8S0wRLkQFZbZJenvFRh+uv0aRanHI2VzQGof7p/wX4vs7IwBVN6b/ViCP EBgtVHv/yelXToRtESwIDkhJZ52UjkwXWHp2HTBnQmRDjpomiMGqX5a4eD8pQjuM9QM9 wPnQ== X-Gm-Message-State: APjAAAXcD4y/BicHa2oNzd2QT8l/2OGlIk2umYznlsYGoKd7qpF22k46 Qe5u6BtI10d4QmZhJPpqrheIvcASqgVjBSDYpGY3CQ== X-Google-Smtp-Source: APXvYqyn9+6U5Tept3ttZnOIFoanU6VE7DIZVFE5fQWdfeqX2lUXCkYgCc+uPWh1zPZC+2oTppwBKbZGefPjNhwx8K8= X-Received: by 2002:a24:2244:: with SMTP id o65mr24907189ito.126.1555347136952; Mon, 15 Apr 2019 09:52:16 -0700 (PDT) MIME-Version: 1.0 References: <8060835.KeXT7UZBJi@kitterma-e6430> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 15 Apr 2019 09:51:49 -0700 Message-ID: To: Dotzero Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000099e5d20586947984" Archived-At: Subject: Re: [dmarc-ietf] DMARC Coverage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 16:52:26 -0000 --00000000000099e5d20586947984 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 14, 2019 at 6:39 AM Dotzero wrote: > Scott, it's almost certainly an undercount as there are domains which > validate for DMARC but do not send reports. > Not sure why you would say that since he was looking at "coverage for DMARC feedback". Not necessarily for validation. --Kurt --00000000000099e5d20586947984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Apr 14, 2019 at 6:39 AM Dotzero &= lt;dotzero@gmail.com> wrote:
Scott, it's almost certainly an underc= ount as there are domains which validate for DMARC but do not send reports.=

Not sure why you would say tha= t since he was looking at "coverage for DMARC feedback". Not nece= ssarily for validation.

--Kurt=C2=A0
--00000000000099e5d20586947984-- From nobody Wed Apr 17 06:21:29 2019 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 A58BE12034A for ; Wed, 17 Apr 2019 06:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=rByVhDy1; dkim=pass (2048-bit key) header.d=kitterman.com header.b=OqshDUGj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrgfEfdKYYus for ; Wed, 17 Apr 2019 06:21:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B4F12008D for ; Wed, 17 Apr 2019 06:21:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 9E0A9F807EE for ; Wed, 17 Apr 2019 09:21:25 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555507285; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Fb1Q7ZpwVqKSbUMOuU25I1rxtU62YrGZXOGhNnsqkqU=; b=rByVhDy13KQ887CY9CkfDH8J+QWXU3wTKxVGTMWtDWMnWD+2gDppNrB2 KZ46kjorb6gZjtKz89K6FdZdglVDDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555507285; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Fb1Q7ZpwVqKSbUMOuU25I1rxtU62YrGZXOGhNnsqkqU=; b=OqshDUGjLDUrYXJ82YiCH8tWQErBuZkwaCYEhiMLZtWAXlVBqLTtJx6Z XPFRb3CTc+hDoBR/owgKWJ+9V8j+NYDj0KVQTNhrgPMs0/GddNWmW0YrCz 9fQalmh9qOFzVHDfbRz6GUYBdFDFP7F19ZUZiB2k+nqbaFkiH2CqRY/Du4 SBQSA4AWTBY1/aErR8+k8pPBdJgWRu3wmH0fUKz+QL3M6nVS0H9lw5hyv1 Jjj7Lpade+4lYPpKG8MxVxU+rNCG0orgbsPG3Tqclth3+A38gIY00v25JQ tce05m5cxENujWPxtTmMHWsis5991Q0fW2Z+1/7Rt3wwx0eT2IY/Pg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 6F282F8008C for ; Wed, 17 Apr 2019 09:21:25 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Apr 2019 09:21:23 -0400 Message-ID: <9099331.8T8SFv4asT@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-168-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <2706940.jsilLbKzHY@kitterma-e6430> References: <155484752849.19715.13998301912703613498@ietfa.amsl.com> <2706940.jsilLbKzHY@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Apr 2019 13:21:28 -0000 On Tuesday, April 09, 2019 06:09:30 PM Scott Kitterman wrote: > On Tuesday, April 09, 2019 03:05:28 PM internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Domain-based Message > > Authentication, Reporting & Conformance WG of the IETF. > > > > Title : DMARC (Domain-based Message Authentication, > > > > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > > Author : Scott Kitterman > > > > Filename : draft-ietf-dmarc-psd-02.txt > > Pages : 10 > > Date : 2019-04-09 > > I've attempted to do a few things with this draft update: ... > 3. Added an appendix to describe the registry approach to mitigating the > data leakage privacy issue. ... I've gone ahead and implemented addition of both PSD DMARC at checking the registry described in Appendix B to see if it's an appropriate PSD. It's less than 20 lines of code in Python for both. This confirms (for me anyway), my thought that this is not a complex DMARC extension to implement. Scott K From nobody Wed Apr 17 10:47:26 2019 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 BB976120127 for ; Wed, 17 Apr 2019 10:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df9cHRBIN5wj for ; Wed, 17 Apr 2019 10:47:21 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100121.outbound.protection.outlook.com [40.107.10.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7821D12002E for ; Wed, 17 Apr 2019 10:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zP/vEBIo72Mr+flA6WjltwDfrv4KsN00APtkJdhZg7U=; b=LveznCw9C6VpJ5LACxqeeMHowvBWTs5ZchwpQlfNjsz0phoZakbnywPrl9A00ARDYcCvAv2K8e3d/+9XlzMC7SYqlxC/jDnT3uSffsf2LUqUlKWG9DeROiwlJ8vHiURHBo53PJgIw9JuIGRqH8LHI4pxtr/EImABezHCW2NnWvg= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB1920.GBRP123.PROD.OUTLOOK.COM (20.176.155.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Wed, 17 Apr 2019 17:47:19 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::3d7d:bcac:a450:6621]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::3d7d:bcac:a450:6621%7]) with mapi id 15.20.1792.021; Wed, 17 Apr 2019 17:47:18 +0000 From: Ian Levy To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] DMARC Coverage Thread-Index: AQHU8j2h6McpQd34NEeQ+7zWHDT0U6ZAojYw Date: Wed, 17 Apr 2019 17:47:18 +0000 Message-ID: References: <8060835.KeXT7UZBJi@kitterma-e6430> In-Reply-To: <8060835.KeXT7UZBJi@kitterma-e6430> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 774b80d3-c466-48c2-74e9-08d6c35cbcb6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LO2P123MB1920; x-ms-traffictypediagnostic: LO2P123MB1920: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39850400004)(396003)(366004)(376002)(136003)(189003)(199004)(13464003)(7736002)(2906002)(45080400002)(74316002)(966005)(478600001)(305945005)(256004)(14444005)(44832011)(81166006)(68736007)(105586002)(81156014)(14454004)(110136005)(33656002)(25786009)(2501003)(106356001)(6116002)(102836004)(8676002)(7696005)(99286004)(66066001)(76176011)(186003)(26005)(53546011)(55236004)(6506007)(3846002)(97736004)(71190400001)(11346002)(476003)(486006)(446003)(55016002)(316002)(71200400001)(9686003)(6436002)(229853002)(6306002)(8936002)(52536014)(5660300002)(6246003)(74482002)(86362001)(75922002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB1920; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: goADyMfN0AUtdyg8GznIUnfE0X8mkeQBFeOBlsFJCCcgKvobp2Pbp4m7Ep3O0ZQ0bsYUth3yEwWjbujePGUIEHqrOJIanoVjgcLqZahpZRTtMkzAkljziahzjZgmOzHbelGNGjL30MEroarhcDZgrbzsBmFTAeORePPTcoHby49VehbNZXMY4NfjMXBXfFKQ3uyF70i6Kq4oQuxviIBsmEt25MKk9nB6JOVwYgzhJd7zSbX22zk5q71HM+lSbSGYqtK2F7duoJQTRGOM7y/fyT7Fdqvl1MyByKbPs0b3P+1jaPcdoDgss7PIIEkusYrhpJ45OL2sGPbtaBmwM9x5dbRK7ViCUprpfeg4G4qLsVOF/2d0a0Ogr02qhLibKR/reqcygUeIet6PmQ3vhw9gdZdqYjgBAkilxEL5J36j4vg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 774b80d3-c466-48c2-74e9-08d6c35cbcb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 17:47:18.8644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1920 Archived-At: Subject: Re: [dmarc-ietf] DMARC Coverage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Apr 2019 17:47:25 -0000 We've done something slightly different (because it's data we have to hand)= but I think it's still comparable. We looked at the all messages sent from ncsc.gov.uk in March 2019. In total= , we sent 67,962 emails and received DMARC reports for 8,657 emails, about= 12.5%. Now, I think our main correspondents are likely to be in gov.uk and= we know there's a lot of Office 365 and older on-prem solutions that don't= report, so it's going to be artificially low. Possibly more interesting is the data from the Gov.UK Notify service, which= sends mail from the notifications.service.gov.uk domain. Notify is the pla= tform for government to send notifications to people and it publishes its p= erformance data, for example for March 2019 at https://www.gov.uk/performan= ce/govuk-notify/notifications-by-type#from=3D2019-03-01T00:00:00Z&to=3D2019= -03-01T00:00:00Z This shows that Notify sent 36,301,537 emails in March and we received repo= rting of 13,671,108 emails, about 37.9%. Notify sends messages to a much broader set of receivers so is likely to be= more representative and therefore useful statistically. I'd be really interested in what happens to these numbers if Microsoft star= t sending DMARC reports, for both O365 and their consumer platforms. Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk (I work stupid hours and weird times - that doesn't mean you have to. If th= is arrives outside your normal working hours, don't feel compelled to respo= nd immediately!) -----Original Message----- From: dmarc On Behalf Of Scott Kitterman Sent: 13 April 2019 22:12 To: dmarc@ietf.org Subject: [dmarc-ietf] DMARC Coverage A couple of days ago I sent a single message to a reasonably large mailing = list (spf-help, email oriented - so likely not representative, but it's a d= ata point). Since I am a list owner, I know how many subscribers there are= and from my DMARC feedback, I know how many times that single message got = reported. 43% of them showed up in my DMARC feedback, so that's at least one data poi= nt on breadth of coverage for DMARC feedback. To do this (at least the way I did it), you need to send a single message i= n a reporting period to an email list that does not re-write from and for w= hich you know how many subscribers there are. I'm curious what kind of numbers other might be able to come up with. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Cian.levy%40ncsc.gov= .uk%7C14b11e326d154e893be508d6c054c2b9%7C14aa5744ece1474ea2d734f46dda64a1%7= C0%7C0%7C636907867621729087&sdata=3Dcpa%2BmnPs5ClQ1ruPwExr6qwOfqzpb1WWk= JUwm4%2B5p7M%3D&reserved=3D0 This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk From nobody Wed Apr 17 21:42:22 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 936D112011C; Wed, 17 Apr 2019 21:42:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155556253959.21180.3147427329043418444.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2019 21:42:19 -0700 Archived-At: Subject: [dmarc-ietf] Benjamin Kaduk's No Objection on draft-ietf-dmarc-eaiauth-06: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 18 Apr 2019 04:42:20 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-eaiauth-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my Discuss point! From nobody Thu Apr 18 12:46:16 2019 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 AC1651203E2 for ; Thu, 18 Apr 2019 12:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLSnJnMMr_Ca for ; Thu, 18 Apr 2019 12:46:12 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931301203E7 for ; Thu, 18 Apr 2019 12:46:12 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id y134so5134287itc.5 for ; Thu, 18 Apr 2019 12:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=MRVEGX3MhvWRBBcSeygbFJhW0wDj6DolgDmKKimbrIQ=; b=ZmQ95hmm/Ukvi6tjwhgOKMWFUhQCjRT2t06XeO0udvncuiep2NzFgeJPrU9nD3vHLm 1LdYz3NswYtmwtwOqWemolR7itjAzk2Qw+hJp8olLNZExtD/RW+QlyoXsmxQedwbaMdD PHezgzsdYVkZyvCsxeG1t4iEC5LvzflpqzlmQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MRVEGX3MhvWRBBcSeygbFJhW0wDj6DolgDmKKimbrIQ=; b=WRAOn69kw5JhFpi+4kB4X7UCjUrFSeBL0U+xciF8i6QHHSg/vu2jyJQZ7TbHwGt9QI 7Lyz9WjZJpht193XSL5S+eosN62s3/21d3QlTNHZCCB7JE0TEQDRYC3qwevRgOTU6f2W a59u1spUrXpNhn84R96NN+8Tc/paX7iVMI8N/akmNTpmoYuyk6bUTrTq6kJPcE3faxTt 54sJMYyeni9u18UDj4Q2ljLyioXtXzxXZ+9EcILZ6CJkjlAxbeUD+QxQOSnN82W5nklb RTWF6p/n28UJAsc35RATujuUOcKBr6qfRlpDO8YIWNyO7fP5AS3kdUMzGJpCGkr0gvoI vQUA== X-Gm-Message-State: APjAAAXA+JFjuLJC2nKjw7+ysoMVI5cfK9t5dXJ+ROi95lCMluwlbaDl kurkdLuPZZkYLqfRoVvim9a3JU2lQfckQNsY9QjmkAUV3cORLg== X-Google-Smtp-Source: APXvYqxDI62ygxcsiIWVzjBO+T6LVcSXCywDN41rrvyL/GjFDI+GJtvPn+zLILT2A5hDwI6a2Xux/PfbcAy5gtfXq/Y= X-Received: by 2002:a24:e004:: with SMTP id c4mr5351339ith.78.1555616771153; Thu, 18 Apr 2019 12:46:11 -0700 (PDT) MIME-Version: 1.0 From: Kurt Andersen Date: Thu, 18 Apr 2019 12:45:42 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000d36180586d3417a" Archived-At: Subject: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 18 Apr 2019 19:46:15 -0000 --0000000000000d36180586d3417a Content-Type: text/plain; charset="UTF-8" If we have a boundary that is 6 names deep in the DNS hierarchy (so the org domain would be 7 names long), then what is a DMARC validator supposed to do with an email that claims to come from the domain that is only 5 names long? What happens to the second lookup (org-level)? Example: priv-org.psd-a.b.c.d.e.example: If an email comes from sub1.priv-org.psd-a.b.c.d.e.examplepriv-org.psd-a.b.c.d.e.example, then lookup 1 is for _dmarc.sub1..., lookup 2 is _dmarc.priv-org... and the proposed lookup 3 (for PSD protection) would be _dmarc.psd-a... If the email comes from b.c.d.e.example, then lookup 1 is _dmarc.b... but what would lookups 2 and 3 be? skipped? --Kurt --0000000000000d36180586d3417a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we have a boundary that is 6 names deep in the DNS hier= archy (so the org domain would be 7 names long), then what is a DMARC valid= ator supposed to do with an email that claims to come from the domain that = is only 5 names long? What happens to the second lookup (org-level)?
Example:

priv-org.psd-a.b.c.d.e.examp= le: If an email comes from sub1.priv-org.psd-a.b.c.d.e.examplepriv-org.psd-= a.b.c.d.e.example, then lookup 1 is for _dmarc.sub1..., lookup 2 is _dmarc.= priv-org... and the proposed lookup 3 (for PSD protection) would be _dmarc.= psd-a...

If the email comes from b.c.d.e.example, = then lookup 1 is _dmarc.b... but what would lookups 2 and 3 be? skipped?

--Kurt
--0000000000000d36180586d3417a-- From nobody Fri Apr 19 08:44:05 2019 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 C76CF120321 for ; Fri, 19 Apr 2019 08:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=aOD4JItk; dkim=pass (2048-bit key) header.d=kitterman.com header.b=A0sr5z9t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNeniXJZpn57 for ; Fri, 19 Apr 2019 08:43:59 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11FE120334 for ; Fri, 19 Apr 2019 08:43:58 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id AEEC3F8073D for ; Fri, 19 Apr 2019 11:43:56 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555688636; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aeVBIhXpaowHR+E8VwknC/3UbsH3z3x4FPuBadpHxIM=; b=aOD4JItkcWPslz+w7rPHcQ9QEsWN688CzKI2RuzFQcd0ORBV93z4xlI4 jIyebgEzQXOI/BVayJ5PWoopfx8oDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555688636; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aeVBIhXpaowHR+E8VwknC/3UbsH3z3x4FPuBadpHxIM=; b=A0sr5z9tKYel8WwJRQczBuiXiynfQT8biYmyx/zZl5m6OreJur4hq7u4 EEvzXTk8gaQ7xLVQY3rw6E4olUBld+9c9sDKzjzfvMejQnJiJbzc+/aYv5 HvQjz9kIvg+tdVVFH+4ukDn+cGCBRbGDE42fn5Tgjl5GcBoxU6hohFBmNl rdZjukux+f/BVBKZsZyx2/sXuWKtgwKlyFE2jFuN/N4bzhVb7kSIdag077 3bWrYNNiueSOh+9faYSQalXSdYbzRxFkGpalw9+pe6oSvgYFb/z1bAI3kX Lq9VdINMK9F4UvzFD30PmWAYYcfD1RvK1t0qQuJISHD/KsJuDx8rxQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 73D8AF801E7 for ; Fri, 19 Apr 2019 11:43:56 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 19 Apr 2019 11:43:51 -0400 Message-ID: <1897481.12dR8pik7S@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-168-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 19 Apr 2019 15:44:05 -0000 On Thursday, April 18, 2019 12:45:42 PM Kurt Andersen wrote: > If we have a boundary that is 6 names deep in the DNS hierarchy (so the org > domain would be 7 names long), then what is a DMARC validator supposed to > do with an email that claims to come from the domain that is only 5 names > long? What happens to the second lookup (org-level)? > > Example: > > priv-org.psd-a.b.c.d.e.example: If an email comes from > sub1.priv-org.psd-a.b.c.d.e.examplepriv-org.psd-a.b.c.d.e.example, then > lookup 1 is for _dmarc.sub1..., lookup 2 is _dmarc.priv-org... and the > proposed lookup 3 (for PSD protection) would be _dmarc.psd-a... > > If the email comes from b.c.d.e.example, then lookup 1 is _dmarc.b... but > what would lookups 2 and 3 be? skipped? > > --Kurt It's an interesting question, since I think may be a hole in DMARC generally, but we can fill it, if needed. I took a look at the non-comment content of the public portion of the PSL to get an idea of the scope of this problem. Here's the distribution of lengths of public suffixes: one: 3077 two: 3821 three: 1986 four: 3 None longer than that, unless I screwed up my script. Since more than 20% of the currently documented public suffixes are longer than two dots, I think this is a use case worth covering, but I don't think changes are needed. In every case I checked, if c.d.e.example is in the PSL, then d.e.example, e.example, and example are also listed, so the proposed PSD DMARC lookups should succeed just fine in these cases. The privacy implications of these types of public suffixes are no different than the longest public suffix, since we don't know that they are not also used for registering non-public organizational domains. It might be useful to state this as a condition required for PSD DMARC to work correctly, so it's documented rather than just a happy coincidence of the current PSL implementation. Scott K From nobody Fri Apr 19 09:12:19 2019 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 268061202E7 for ; Fri, 19 Apr 2019 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az1ASx_WXRL7 for ; Fri, 19 Apr 2019 09:12:16 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627B0120172 for ; Fri, 19 Apr 2019 09:12:16 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id r18so3904098ioh.2 for ; Fri, 19 Apr 2019 09:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vvfdb3BvTJcIuluogwXnvPAZQIvRKf2UBgcv85ER0Jk=; b=HibGR9WdgnACebcnGvtCpEZPILKzaqCys1cx/cy91BBONvVEssbKsFcD2P7kzTgYFk oX49xxNbwNjy/dRLLrcRwwGpb1LjzOEKiLNTunAp9/4+5NBkEmZAOm1z5FlerFQBL8+N X9DBmhiE/Wq6iAbJjgN7wk9Fi8w6vTxLVVcPY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vvfdb3BvTJcIuluogwXnvPAZQIvRKf2UBgcv85ER0Jk=; b=XuQZQtBoy2S4eePkBKFiz0DZTG2ClO/ZVBxr12S9Th8KeqaNwMI9TfdzdWDAI8ikwR ez4/1A/nJg9rQhl5TKgojg2LUizjyFk/HOLbNVkD1NmSkTAh5EqGayAXpDzlstmv8AuD TQiREEQgh4wruew86EBoTc34S1QN4VMa3t8vrYt3GO+oAYYpo50jQJXyahI2oAwapj42 Tjk+BWMXyAAb1CAux75LHzZc8aiJ9vG5ujnAWuhgwDXiREjW0CvPRfCuynEYGtHLsZ9i 7IKRaAjdRlW2slDhfj4QGuT1IJe5hy+lifQJz8xCK6vDDARknDjy02DKXwTV3pm/G+9Y gzuw== X-Gm-Message-State: APjAAAWspZhx3cLNgnw1KfzXrpaZcov9QX5rj10++KA3+tq5DbU5oq/p 4GqCqplyjq2N6CV4QayfQv+uQcZ9cL9I812feOCHqg== X-Google-Smtp-Source: APXvYqxRlWdrGv5XDhhE69vkvUf3zKgRvlsIilEXnM3XL+HxsKui8UOKDBZVhYPbd3d3ZlWTSnQL72Fo1p/KbVtOXCY= X-Received: by 2002:a5e:8517:: with SMTP id i23mr3033886ioj.228.1555690335355; Fri, 19 Apr 2019 09:12:15 -0700 (PDT) MIME-Version: 1.0 References: <1897481.12dR8pik7S@kitterma-e6430> In-Reply-To: <1897481.12dR8pik7S@kitterma-e6430> From: "Kurt Andersen (b)" Date: Fri, 19 Apr 2019 09:11:45 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d1e0860586e46113" Archived-At: Subject: Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 19 Apr 2019 16:12:18 -0000 --000000000000d1e0860586e46113 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 19, 2019 at 8:44 AM Scott Kitterman wrote: > > I took a look at the non-comment content of the public portion of the PSL > to > get an idea of the scope of this problem. Here's the distribution of > lengths > of public suffixes: > > one: 3077 > two: 3821 > three: 1986 > four: 3 > > None longer than that, unless I screwed up my script. > While it may have changed since the days of DBOUND, I recall that there was at least one hierarchy which had a public --> private --> public --> private double transition which could make for longer names. --Kurt --000000000000d1e0860586e46113 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 19, 2019 at 8:44 AM Scott Kit= terman <sklist@kitterman.com= > wrote:

I took a look at the non-comment content of the public portion of the PSL t= o
get an idea of the scope of this problem.=C2=A0 Here's the distribution= of lengths
of public suffixes:

one: 3077
two: 3821
three: 1986
four: 3

None longer than that, unless I screwed up my script.
=
While it may have changed since the days of DBOUND, I recall= that there was at least one hierarchy which had a public --> private --= > public --> private double transition which could make for longer na= mes.

--Kurt=C2=A0
--000000000000d1e0860586e46113-- From nobody Fri Apr 19 09:15:57 2019 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 3287712035B for ; Fri, 19 Apr 2019 09:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=kZdAmFP3; dkim=pass (2048-bit key) header.d=kitterman.com header.b=h0u3Gqu0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI-QSejCntxc for ; Fri, 19 Apr 2019 09:15:48 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AE0120331 for ; Fri, 19 Apr 2019 09:15:48 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id BD4F8F8073D for ; Fri, 19 Apr 2019 12:15:47 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555690547; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=kHnGPnWbNn0/4E/giPx0gL1Mu8nV9NXgaJsn7kkbJqo=; b=kZdAmFP3xtaA4xJ+VJ+aeJZ+Cn3WXtb1blx5qxcJCXdb6AZ97HrbD8Yl 1ErNSw3udO8Z0NE90PQS1aStIyFlAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555690547; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=kHnGPnWbNn0/4E/giPx0gL1Mu8nV9NXgaJsn7kkbJqo=; b=h0u3Gqu0ybrgjYn2Ox92GH5/eUIMfKk1V6QY7T8ejb9V/Mp6r7OH+9Xv lc5ytyRTIW2GWXSgfEnoaPOs6QolmBjVIHjmSv1+H2KBZgp1KCriJfr0Bt 8DbnGiaKIVFGDwD4MFR/Cbbpk85yT/6t+GmluVKIqh0wOc/nJBUSdtxPxJ G1vPsmvw2/lJddYoij3ia17rFOd7eqziSLDLnMHhzsRmhl0+6ze+r+p6c3 q6N2pUAe3LLVw7QReic3zYf/pKTtEjg5kwQdV+WZBxNmSN+4xEH/ytFnco 594YoVOCUCOXd6fOiDEHKDxSuocWACrWooJS2nEOCulmZa1ucZ/biQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 91024F801E7 for ; Fri, 19 Apr 2019 12:15:47 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 19 Apr 2019 12:15:42 -0400 Message-ID: <7073931.FQBSMkfpyc@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-168-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <1897481.12dR8pik7S@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 19 Apr 2019 16:15:56 -0000 On Friday, April 19, 2019 09:11:45 AM Kurt Andersen wrote: > On Fri, Apr 19, 2019 at 8:44 AM Scott Kitterman > > wrote: > > I took a look at the non-comment content of the public portion of the PSL > > to > > get an idea of the scope of this problem. Here's the distribution of > > lengths > > of public suffixes: > > > > one: 3077 > > two: 3821 > > three: 1986 > > four: 3 > > > > None longer than that, unless I screwed up my script. > > While it may have changed since the days of DBOUND, I recall that there was > at least one hierarchy which had a public --> private --> public --> > private double transition which could make for longer names. OK. I don't think that changes the analysis as long as all the public components are listed. Scott K From nobody Fri Apr 19 14:24:44 2019 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 89BFD120156 for ; Fri, 19 Apr 2019 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=A4AT7tAe; dkim=pass (1536-bit key) header.d=taugh.com header.b=KhFits+7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjqgs0Ii3ItB for ; Fri, 19 Apr 2019 14:24:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862C7120131 for ; Fri, 19 Apr 2019 14:24:40 -0700 (PDT) Received: (qmail 47753 invoked from network); 19 Apr 2019 21:24:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ba7c.5cba3c96.k1904; bh=kt77yDCsRSNwHDmZYo1P7+SoVZ8299aUOkYglCo6i6I=; b=A4AT7tAebs76gdatZmnjHtYmNnGDrqVsVlUfO364pWX7BJVEMYTXTJ24Jsr6/+W9vUwPN8DOA09D6ube4iMHp+mf2zxX5Lwax23rYDO5TvnmUBmrgAho7xAgPn71MGPAgaPv0/xyVnOJyuYZ7kzJ6iXPfYzv96jmmzgBbLj/agOANzIXqUQFZRaIMyhtddePAA+3zFx/x0p+Gx/8J9CXWpSO3j07a9phSL+gAC/khLqpFTm6wFxrwI5sbG+Ubh8n DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ba7c.5cba3c96.k1904; bh=kt77yDCsRSNwHDmZYo1P7+SoVZ8299aUOkYglCo6i6I=; b=KhFits+7w6CmbIh/4oHZ5yqemhDkauiV1mHRaLduzkhAdnuESyzs49ez/flsYSkzwRxDDoxvtHSHr2WsAsZOqTot9HkaBjmF+3Xhj37beKbeFGRiEbzVHQfBtR08mvoJCp+Pw2N4OnDuoSmYrKSWBIg4BFXmKlNg9VeYrqTSZtYRcOBIeSmRT6vNKx/9vgkNRzVPgleqg66Z+ZLXFQSeIY4sflmLwmi/5JzKV5T2ekqHGFQw46h/ll5BOYs9/enz Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 Apr 2019 21:24:37 -0000 Received: by ary.qy (Postfix, from userid 501) id B66E72012B0300; Fri, 19 Apr 2019 17:24:37 -0400 (EDT) Date: 19 Apr 2019 17:24:37 -0400 Message-Id: <20190419212437.B66E72012B0300@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <1897481.12dR8pik7S@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 19 Apr 2019 21:24:43 -0000 >I took a look at the non-comment content of the public portion of the PSL to >get an idea of the scope of this problem. Here's the distribution of lengths >of public suffixes: > >one: 3077 >two: 3821 >three: 1986 >four: 3 I only see 1527 with no dot. Since there's only 1532 TLDs it's hard to see where another 1500 could come from. The other numbers look right. R's, John From nobody Fri Apr 19 19:35:33 2019 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 344A012019A for ; Fri, 19 Apr 2019 19:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=0gmlKxT7; dkim=pass (2048-bit key) header.d=kitterman.com header.b=bLSXCM4N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N40pPiQQhXrJ for ; Fri, 19 Apr 2019 19:35:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68AE12004F for ; Fri, 19 Apr 2019 19:35:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 963C4F80319 for ; Fri, 19 Apr 2019 22:35:27 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1555727727; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=yeQvsJx8+U+h/Y1RqCRHm/425PgGa8pi7uegWn16VEE=; b=0gmlKxT7FU9ZwfcHnqU0rXFeeB8Oh2dK+Q/vhyTZxOEPEJV2mdIrQ5pQ ARjUCJYPDw+WayGRea3kmtjFeQDwAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1555727727; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=yeQvsJx8+U+h/Y1RqCRHm/425PgGa8pi7uegWn16VEE=; b=bLSXCM4NWzgSiQJ5uUdhbBFsGFcLUjAnznrdiH+LkcO6XWEj+70UDphL s5TTsQiPvee83swQEiNGErr60uiJQG9xUXfx8fvVyFzmivdg7JqQhRYBSE VGYuYrIlEaCtMUuzGN4kwP+msBrozC1+xoQyPFRmdWO3OIsE8l2mDBaAeF oWUx1SRGUy+cnDxlBrBui1O9/nTPPCu0Arwl/7ecFQTRhTkduQjp3tGYCG 1ExRSkV0Y+9Uig24GB5QiF7VIw2MAlfP6edii0J4R0UA4JHHak0lgbRGJv i46SqHhixSNZWR1sW7VYQFC+NSPEOITCohvHTscet+roYwe7PcdE2w== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 6173DF8027D for ; Fri, 19 Apr 2019 22:35:27 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 19 Apr 2019 22:35:26 -0400 Message-ID: <2133744.rL2vL2M1mL@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-168-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20190419212437.B66E72012B0300@ary.qy> References: <20190419212437.B66E72012B0300@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] What happens for org and PSD lookups when you are already above the PSL boundary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 20 Apr 2019 02:35:31 -0000 On Friday, April 19, 2019 05:24:37 PM John Levine wrote: > >I took a look at the non-comment content of the public portion of the PSL > >to get an idea of the scope of this problem. Here's the distribution of > >lengths of public suffixes: > > > >one: 3077 > >two: 3821 > >three: 1986 > >four: 3 > > I only see 1527 with no dot. Since there's only 1532 TLDs it's hard to > see where another 1500 could come from. > > The other numbers look right. Thanks. My script was counting blank lines (sigh). Now I get the same result you do. That raises the three or more percentage over 27%. Scott K From nobody Tue Apr 23 00:41:27 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB55120401; Tue, 23 Apr 2019 00:41:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155600526735.32557.16416240098461136843@ietfa.amsl.com> Date: Tue, 23 Apr 2019 00:41:07 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-07.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Apr 2019 07:41:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Recommended Usage of the Authenticated Received Chain (ARC) Authors : Steven M Jones Kurt Andersen Filename : draft-ietf-dmarc-arc-usage-07.txt Pages : 19 Date : 2019-04-23 Abstract: The Authentication Received Chain (ARC) provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. But the specification does not indicate how the entities handling these messages should interpret or utilize ARC results in making decisions about message disposition. This document will provide guidance in these areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-07 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 23 19:02:56 2019 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 B35EF120276 for ; Tue, 23 Apr 2019 19:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=hrjuWv1j; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=tnXqdLb6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTRn9Gzr2SLI for ; Tue, 23 Apr 2019 19:02:52 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id A393D120105 for ; Tue, 23 Apr 2019 19:02:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=219; t=1556071367; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=MxJHf7sQKvahmjM6WbrbLSCWAdE=; b=hrjuWv1j8MHsnUbk+mhb0DsH6WX5ld5xrER4X5Koxa+k09L9fGGO66NlkOE+Hu qs6Ou7LQ2n3fIW+7KZF3R0En97+73DaLJr2XUFLYqjtwbAIC3qhD1vjkCQ0Efysq syvoHuXNXiyBM7JU0hljRu2ObIYjGc4fD1wQP2LfcKEhY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Tue, 23 Apr 2019 22:02:47 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1158821712.2033.1816; Tue, 23 Apr 2019 22:02:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=219; t=1556071268; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CAVdP7c ztbqGImRKDiBOvhi1ErYfitzH5/z0wacTh7g=; b=tnXqdLb6kbobhbdlz4w2k0u 2rG5RhB04wpMUpfkyXBPDAB8swS5p4Ow0SGuxeFVgWXzz4QveE6miqSp+RdEfzdt 1+N7WB6J0j5Tv2p5RxuVy4JYJOOf9mCaMo48/C5+iRgmL83HspNsnmkV4an1gATy nLsCedchpGaauXaB4mQ4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Tue, 23 Apr 2019 22:01:08 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2731090972.9.305080; Tue, 23 Apr 2019 22:01:07 -0400 Message-ID: <5CBFC3C6.2000107@isdg.net> Date: Tue, 23 Apr 2019 22:02:46 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 24 Apr 2019 02:02:55 -0000 Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc encryption?... Using OpenSSL API in v1.1 format? Thanks PS: Not sure where to post this, but it equally applies to OpenSSL at GitHub. -- HLS From nobody Wed Apr 24 04:34:38 2019 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 2EE0512003F for ; Wed, 24 Apr 2019 04:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5riBpyf9SDx4 for ; Wed, 24 Apr 2019 04:34:35 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175C312000E for ; Wed, 24 Apr 2019 04:34:34 -0700 (PDT) Authentication-Results: mail.aegee.org/x3OBYTNV025358; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1556105671; i=dkim+MSA-tls@aegee.org; r=y; bh=Dvowa/3uNGnMhDQF0yy85aXskM9YpSxFhnhYilW0kwk=; h=Subject:From:To:Date:In-Reply-To:References; b=R2L4Dyf4O8jc7MrPfXpbrifMQUIGmKNs5cQdjGFPEiNgrftQutu1IS9buPRuUcMX8 /j3/VQ0twO6lGK7PfC4LA6slcOepxWXqe6g3WLRqOX3s/YkhqsnHKyx7MOE187pIo0 QlLR0ae1RPtQ6iuZVnszCuT4rHllE78vHVcM+/GJkkshLS7WmAKNGEBqIOMmws+Cqd EVdptmvL6nSf9PCBVXzZo0dUOJJJ+0bh1nhOH+07jABQbVEyuBcV2NYTXK59t+a19g vT+P9DnZvuxpDio30mlk+rsybYFOBThctqTI7SIc7cVlfDdmQw2e34vwvUCPNfOa3T JwgYiQd1LV9+M3LRYzEqxjtETNRW5N7gletzV6jpGYxlKbVF84G8MjcviuzjRdpSel BOYZ1zLNilK8uaO6rQ2PgwWnZU+l+MHBZySfP+zOaS9ggUO2kLl9AhVhWJUAklPPWT pkRjPu9z+DJ6cd7wKcvfq3cziWwjO853QHYuGtpl5G9r+R55h18VqZirDA17KSlkW6 /PTYPHwSfwIoxwKM1cdzMiAziFtqC0jowzLH21g6KF2mk8rifaJ5HDMLnwMOicuXZg tnY5+4MRCxnA2r+jOp8LF4r/eRtC7LLoRkV+3yQGdhsTY/9I1WBIRYzvr3cOzaUMYO IHanezDcQ1B2mFmSRRYO5s2c= Authentication-Results: mail.aegee.org/x3OBYTNV025358; dkim=none Received: from Tylan (eduroam-PAT.sit.fraunhofer.de [141.12.129.132]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x3OBYTNV025358 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 24 Apr 2019 11:34:30 GMT Message-ID: <1171c16a35e2285d95f00c0dd01d31c99c273d1b.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: hsantos@isdg.net, dmarc@ietf.org Date: Wed, 24 Apr 2019 11:34:29 +0000 In-Reply-To: <5CBFC3C6.2000107@isdg.net> References: <5CBFC3C6.2000107@isdg.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 24 Apr 2019 11:34:37 -0000 Hello Hector, you can check https://github.com/Exim/exim/commit/286b9d5fa4344de72fe6575fa089237 (Exim+GnuTLS) or https://github.com/trusteddomainproject/OpenDKIM/commit/35bf6c901a2 (OpenDKIM+OpenSSL) and the last discussion at https://mailarchive.ietf.org/arch/browse/dcrup/ (dcrup@ietf.org) . Regards Дилян On Tue, 2019-04-23 at 22:02 -0400, Hector Santos wrote: > Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc > encryption?... Using OpenSSL API in v1.1 format? > > Thanks > > PS: Not sure where to post this, but it equally applies to OpenSSL at > GitHub. > From nobody Wed Apr 24 05:03:07 2019 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 2672D12006B for ; Wed, 24 Apr 2019 05:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=halon.se header.b=Ebl96Rrs; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=halon.se header.b=xKaUpKMI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXkLu3ts3FjD for ; Wed, 24 Apr 2019 05:03:04 -0700 (PDT) Received: from se1-gles-flk1.inumbo.com (se1-gles-flk1.inumbo.com [IPv6:2a02:750:1::161:babe]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF422120145 for ; Wed, 24 Apr 2019 05:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=halon.se; s=spaceship2; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=Cd3/sMpqUH8vcaz4sUA5hgWA19JmUENS+V7ZNZBkfi4=; b=Ebl96Rrsiwl2S51NyukktmmIyzsx59ucoXCpeO0T2Lva2+LLXO4175kjXsk5phLg5AKQk6z4hMi5H 65oIf4M/aBsZdT0fevnqE9SIbcFKKifisVET5Wy8CJu1V8OaLqz3Pi0lk3bIDEo6Cx8HG6/W5S8mkF wGYnPRAXFye/J3sxPJ6mKPz1zvUN84PHAh8+WwjWJtqXDMBrIngP8uprZ57y9R/AiWzb11IHrnmsAi S4YkjVbEuXCLvHkn1u71drQjnk4R8pTB7XdfBjCC08TnpKKjLbIxKitQmm0vT9yjPVq3luKEB2yeNQ 6Ug0+/QHsz43Qi+agEayYI4XzA9s4Fw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=halon.se; s=rocketship1; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=Cd3/sMpqUH8vcaz4sUA5hgWA19JmUENS+V7ZNZBkfi4=; b=xKaUpKMIpJ5H6/igvaKvWF55tBb0GkkcsiWN5vlY7FqALk5JyiCMWGEKLmuk2rVtoY0O+YQsaC5lJ qqpULnzBA== X-Inumbo-Out-ID: e771ee73-6688-11e9-a99d-bdd877a52a68 X-Inumbo-Cookie: f98a7681a392d6505ab172aab160ce7195d1a355 ARC-Seal: i=1; a=rsa-sha256; t=1556107380; cv=none; d=halon.se; s=spaceship2; b=g4XgBqb2vCKjFbeT27a/47ZKmHV3c/rACfOTscZiqGIlFuSQgfXkk02JDROEuf1zBziCqt2rzD6cI EYMYPhAmgCuHhbP4UgcKQs0qHMqECjFA1yCepRlhbPogk5faEWJBs7mPEM+EfUfAdM66af3SbYtifm jnINHgJS1qpfplVI5ZBge8MKmaUHOCMTTmBdQNZhcaiHZYad+Yr7iN1VBrc+9YsmWX7Yetf9TQtEAi pMQJd3ZYxkuYMMsczsbwqXQUavmNlfzghwJSNNGMrNIRbqlx6rdaGwiaEj4TtiViP2fAnxCSYIxAW4 XU9/joo7TMLT+R05LMfM/H1g4biE2iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=halon.se; s=spaceship2; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=Cd3/sMpqUH8vcaz4sUA5hgWA19JmUENS+V7ZNZBkfi4=; b=lgnHvenZK9Ae0BzULXuNuQQ+8JvsYeWSjT/eDVpRtLqv9xQeLAXNF8qfdQeSE5DluwzQU0UWmr7nY DrWRFFqzx8pJZCfwCh4B43e2zbAuQec7DXETxfr+h0qFjuBeiyg5GSVk0Np/9BtypbeNALNKhfjQMU fhMMJUK0kI0y/FQzLpFaUy8W1B8PqQow0xb9E/SVM+1y88uEDsK/qF5X92D84AmJLh1yuOk3i5LWpt 5TYbQji1K7LNIfUtc1+ZC5wmlXkQY0Jbw/zjm5CLfq0CgwIvqJlfhUvLbVoCWHEDHQ1rsboXUeqRXs hO1UQPRT72SahG/ArGxQhebeQKje9vw== ARC-Authentication-Results: i=1; se1-gles-flk1.inumbo.com; auth=pass; Received: from mail.halon.se (unknown [212.85.68.184]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPSA id e771ee73-6688-11e9-a99d-bdd877a52a68; Wed, 24 Apr 2019 14:02:59 +0200 (CEST) Received: from Eriks-MacBook-Pro.local (unknown [10.2.50.15]) (Authenticated sender: erik) by mail.halon.se (Postfix) with ESMTPSA id 830214E04E for ; Wed, 24 Apr 2019 14:02:59 +0200 (CEST) To: dmarc@ietf.org References: <5CBFC3C6.2000107@isdg.net> <1171c16a35e2285d95f00c0dd01d31c99c273d1b.camel@aegee.org> From: Erik Lax Message-ID: Date: Wed, 24 Apr 2019 14:02:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1171c16a35e2285d95f00c0dd01d31c99c273d1b.camel@aegee.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 24 Apr 2019 12:03:06 -0000 And this using libsodium https://github.com/halon/libdkimpp/commit/7e73f5b6a115b2cfdf8122824575b321d1c114f2 Regards Erik On 2019-04-24 13:34, Дилян Палаузов wrote: > Hello Hector, > > you can check > > https://github.com/Exim/exim/commit/286b9d5fa4344de72fe6575fa089237 (Exim+GnuTLS) > > or > > https://github.com/trusteddomainproject/OpenDKIM/commit/35bf6c901a2 (OpenDKIM+OpenSSL) > > and the last discussion at https://mailarchive.ietf.org/arch/browse/dcrup/ (dcrup@ietf.org) . > > Regards > Дилян > > > On Tue, 2019-04-23 at 22:02 -0400, Hector Santos wrote: >> Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc >> encryption?... Using OpenSSL API in v1.1 format? >> >> Thanks >> >> PS: Not sure where to post this, but it equally applies to OpenSSL at >> GitHub. >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Apr 24 05:11:36 2019 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 C1E1C12021F for ; Wed, 24 Apr 2019 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rspamd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcHGWsZILnhD for ; Wed, 24 Apr 2019 05:11:32 -0700 (PDT) Received: from mail.highsecure.ru (mail.highsecure.ru [88.99.142.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFC5120047 for ; Wed, 24 Apr 2019 05:11:31 -0700 (PDT) Received: from [192.168.1.185] (cpc92314-cmbg19-2-0-cust390.5-4.cable.virginm.net [82.11.185.135]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 9CED43000C8; Wed, 24 Apr 2019 14:11:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rspamd.com; s=dkim; t=1556107887; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mr5umcSaR2BkgkZyUnlov0ulLyyRmSic023Jby3TzQo=; b=bZgA59VeIW+2UXcGVjHwJ/rHo5oPJ/i81H+KiW5jH/xi7hRBWqbwXV/69dmbv41+81JlSy Jpy/HRSoCpRuQOu4V7s/1CRcWIk0UmMiUgfBP/LSghgrln06HafZ4fqJLL6vYkrQoMHlhM e3PRzzy0M7iBuldgyHCv7PWYem4PW+8= To: hsantos@isdg.net, dmarc@ietf.org References: <5CBFC3C6.2000107@isdg.net> From: Vsevolod Stakhov Openpgp: preference=signencrypt Message-ID: <5f3c2a68-c562-044b-fa05-4818ecbe2a25@rspamd.com> Date: Wed, 24 Apr 2019 13:11:17 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <5CBFC3C6.2000107@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: mail.highsecure.ru; auth=pass smtp.auth=vsevolod@highsecure.ru smtp.mailfrom=vsevolod@rspamd.com Archived-At: Subject: Re: [dmarc-ietf] DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 24 Apr 2019 12:11:35 -0000 On 24/04/2019 03:02, Hector Santos wrote: > Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc > encryption?... Using OpenSSL API in v1.1 format? > > Thanks > > PS: Not sure where to post this, but it equally applies to OpenSSL at > GitHub. > Here is my pretty minimalistic (~3k LoC in total) implementation of DKIM in Rspamd: https://github.com/rspamd/rspamd/blob/master/src/libserver/dkim.c#L2832 It uses OpenSSL supporting both 1.1+ and previous versions. This implementation supports both signing, verification, ARC and ed25519 sigs (via own library but can easily be adopted for libsodium). From nobody Wed Apr 24 05:28:19 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C978612006E; Wed, 24 Apr 2019 05:28:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dmarc@ietf.org, draft-ietf-dmarc-eaiauth@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org, kurta@drkurt.com, dmarc-chairs@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155610889781.32015.11019425461201758420.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2019 05:28:17 -0700 Archived-At: Subject: [dmarc-ietf] Protocol Action: 'E-mail Authentication for Internationalized Mail' to Proposed Standard (draft-ietf-dmarc-eaiauth-06.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 24 Apr 2019 12:28:18 -0000 The IESG has approved the following document: - 'E-mail Authentication for Internationalized Mail' (draft-ietf-dmarc-eaiauth-06.txt) as Proposed Standard This document is the product of the Domain-based Message Authentication, Reporting & Conformance Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ Technical Summary: E-Mail Authentication for Internationalized Mail updates the pre-EAI authentication mechanisms: SPF, DKIM, and DMARC by clarifying which form of the internationalized domain names (IDNs) to use in those protocols and when recording results in the Authentication-Results header. Working Group Summary: The working group process has not had any controversy regarding this specification as it is viewed primarily as clarifying existing practice. Two other documents from the working group are referencing this document for their treatment of IDNs in the context of the ARC and 7601bis update to the Authentication-Results header syntax. Document Quality: This document covers the implications for all three of the referenced specifications. It includes a normative reference to an informative specification (RFC7489) because of the mixture between standards track and informative among the updated specs. Personnel: Document Shepherd: Kurt Andersen Area Director: Alexey Melnikov From nobody Sat Apr 27 12:20:03 2019 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 788BE12015A for ; Sat, 27 Apr 2019 12:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=0hDeRn8T; dkim=pass (1536-bit key) header.d=taugh.com header.b=OXGnGrGZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02aBNlduFF3o for ; Sat, 27 Apr 2019 12:19:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510AE120019 for ; Sat, 27 Apr 2019 12:19:59 -0700 (PDT) Received: (qmail 74923 invoked from network); 27 Apr 2019 19:19:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=124a6.5cc4ab5d.k1904; i=johnl-iecc.com@submit.iecc.com; bh=ENRuAzKxtAvMKPCcIck4XUIG+jyG5a8sFI2vIJNU1so=; b=0hDeRn8TA+ig6Zht2efT3dkfYtjtDOUNOxdBZmampSCqjPWs00QOQd5CSKzKeqId2ofSfthR2P8hSo2hpVQZI3rZq1d2Y9AL5J3ltj0hdm5yaE7+2yLEXy5/EDNcBI/0vx5P+egh3BjQumUk/QA//VGGnGtTZD5QyxioYb09FwN+Wwdfsvg/4RkEejjA2GXwORZaeFsiNYv5kCYUP74ds9scNMsL1M2q1ZIqw3QXQh8R1sssOQM65brNDSdh8uRp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=124a6.5cc4ab5d.k1904; olt=johnl-iecc.com@submit.iecc.com; bh=ENRuAzKxtAvMKPCcIck4XUIG+jyG5a8sFI2vIJNU1so=; b=OXGnGrGZ5Sf/kMIiMkagVUgbauL2fj6XmKtWjtfsiu7J7hz6huJXgAw1zWbjeCzUz+NFI0WSPw+oiVer4a9zfKAhST1pUHmEVfKn7UMF9DtQ9JnQXW8m5M6pKJ4Rh4cZlP/jEQL+Vj8CEJHAFG+/pssOmRBk2YALOM1rb5A+xy0Tpm/woCkn12T0ic0OvpmiJiFlPzJyCE/Y+1sO4fSmARE7ipXno7zs7+C7P+R6DrRAqbm6sz6X1JFv6UJqnicK Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 Apr 2019 19:19:57 -0000 Date: 27 Apr 2019 15:19:57 -0400 Message-ID: From: "John R Levine" To: dbound@ietf.org, dmarc@ietf.org In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dmarc-ietf] New Version of draft-levine-dbound-dns-03 with code X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 27 Apr 2019 19:20:02 -0000 You may recall that we've been discussing ways to publish DNS authority boundaries, like the Mozilla PSL but in the DNS itself, not a text file. I've been claiming that with careful use of wildcards one make the number of lookups depend on the number of boundaries, not the number of labels in the name being checked, so it's reliably reasonably fast. I figured I should put my bits where my mouth is so I wrote a script to translate the Mozilla PSL into DNS rules. It turned out to be harder than I thought because the PSL has wildcard rules with exceptions, e.g.: *.ck !www.ck That turned out to be straightforward to handle with a tweak to the spec I just made in the -03 version. The code to make the DNS records, and another script to take a domain name and look it up in those records are here: https://github.com/jrlevine/bound I think the lookup code is OK but there may be some glitches in the PSL translator for some of the more arcane combination of wildcard and non-wildcard boundaries. Take a look if interested. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS to Scott: I think it would be pretty easy to add a tag for PSD TLDs.