From nobody Tue Apr 3 15:23:57 2018 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 E9E05126C2F for ; Tue, 3 Apr 2018 15:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 GlecPAqpIfZ5 for ; Tue, 3 Apr 2018 15:23:54 -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 A07E312D886 for ; Tue, 3 Apr 2018 15:23:49 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; b=h/85hV6n9atJdwcktt3JV1x4sgVDkUyIn4Y3lMeMxB2Qs/dzBrDvLxsMuAENgmBlruDvc32IYj hGChWeHWTgGKd5OJxYlRxVCV0gl8+Pl1+NlsZ5sMj2EHJITpMp9hKgJejZ7VNRp3ODYWBorgEq Y6eXH/CYvwX1Hhg8sDwHHWg=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; bh=/V6MIMV0iT37je1jA9QHrvKaVAZI7pjjs6B+4bCUTY4=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject; b=ivrwLOUHGh0+RzTA2ELxk8m77P1UkVEo/80NRMI44zNjB1LMPfUi+dzLdWQzEf9q4aAXUV6aQj dEuGamd3OFTlmu3YXsOpoOgLOxA44FHBBxCXtV1bmhiT6qCJkZ2I/787atirdn9zeuykv073nV KMkGVsgILviPJwUyVTNdYRg=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.117) id 1f3ULD-0004qZ-Pc for dmarc@ietf.org (return-path ); Tue, 03 Apr 2018 22:23:47 +0000 To: dmarc@ietf.org References: <152164445995.7425.14367704532798414761.idtracker@ietfa.amsl.com> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAHNJkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+wsB7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGzsBNBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAHCwF8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: Date: Tue, 3 Apr 2018 23:23:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2018 22:23:56 -0000 On 21/03/18 15:18, Murray S. Kucherawy wrote: > On Wed, Mar 21, 2018 at 3:00 PM, wrote: > >> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt >> has been successfully submitted by Kurt Andersen and posted to the >> IETF repository. I see that Google are still listed as implementing Version 6 - and indeed, if you don't supply a t= tag in the AS (which is not required, as far as I can find in Version 13) then gmail.com says: "arc=fail (missing mandatory fields);" in it's A-R. Which should I implement? De-jure, or de-facto (and too-big-to-fail)? -- Cheers, Jeremy From nobody Tue Apr 3 16:05:55 2018 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 38CDD126E01 for ; Tue, 3 Apr 2018 16:05:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 O75eVp4zOmj6 for ; Tue, 3 Apr 2018 16:05:51 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 246F3124235 for ; Tue, 3 Apr 2018 16:05:51 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id v207-v6so22563536lfa.10 for ; Tue, 03 Apr 2018 16:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=f+WZNxowLDVIb1+JRh4k9O1rkT+T6/2WDxM6IjNbbkM=; b=NQw82EQdzPrTU0cKE1q0ePk1M8hgqBLcsFbp1mPCqqFfKZL4xfP51X3JYnzrgimxOa xBHcjSkMw/+i1R9TQ8l9M0h5UPeB/5z1LgSBJa1Xow2UVFIo3u4XXyYGx/ocZwpPWWv0 BKP/wRmhbkTYG45lU+bvEpsXv+LJH9HViXVkg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=f+WZNxowLDVIb1+JRh4k9O1rkT+T6/2WDxM6IjNbbkM=; b=GBJ1Rg+6s04lRD8GzMQ89CUwY74is4oyUb3pSi2krsLxVc1xcqAGTZY4UD8AD9Nvz6 3PWgcMWgv3qsc13sDWL7fKPHxac+W5DC3eApAZNm2889z2WHvPU49TwVHGUU0M6KcZXf 97UDqARkrgp8CARqgAqwdl6ySlIh2DAal7HvEHpXZ8WfOMe60KyqnvQeBoj/Fjc9ifjP tOK/z4jJXhGix6hbSr9yeas1eXsuvAWobxw8HxEhJIXlwfDmbrzC4nJrYztZsi5FZTFa iSuL48i0dd9LxUbN1hspITEoo9jis1PLceqLDrXuyZUu7lfhUB3cCEUURyGdKdHRqzcr GCUA== X-Gm-Message-State: AElRT7Grl35/Q+Wcpb64esMApWJ5hJaPqRAxKvJ251cogOqJrV7LekOy G3eRYDbyhnOS43DQe0F1ZYeCUMOxjSzw7EqfTXJCCRRJ X-Google-Smtp-Source: AIpwx4/cGUPxxmR0Ip4Ti3z3W6IF7PwssEIqDJFhrS1i0CYSIQr6zD25Cj9FH6DYsC5CYWC/E8ppo/oI3PHFyVpPhFg= X-Received: by 2002:a19:911a:: with SMTP id t26-v6mr9307632lfd.101.1522796749285; Tue, 03 Apr 2018 16:05:49 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:e504:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 16:05:48 -0700 (PDT) In-Reply-To: References: <152164445995.7425.14367704532798414761.idtracker@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Tue, 3 Apr 2018 16:05:48 -0700 X-Google-Sender-Auth: 6IQakmLZiEpOkqT5OJWaUqkzrr4 Message-ID: To: Jeremy Harris Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004e82be0568f9bf71" Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2018 23:05:54 -0000 --0000000000004e82be0568f9bf71 Content-Type: text/plain; charset="UTF-8" Please implement -13, but there are almost no protocol changes between -6 and -13. It's mostly editorial. We may have made some tags optional but if Google wants 'em, it's probably best to include them, but that doesn't mean you aren't implementing -13. --Kurt On Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris wrote: > On 21/03/18 15:18, Murray S. Kucherawy wrote: > > On Wed, Mar 21, 2018 at 3:00 PM, wrote: > > > >> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt > >> has been successfully submitted by Kurt Andersen and posted to the > >> IETF repository. > > I see that Google are still listed as implementing Version 6 - > and indeed, if you don't supply a t= tag in the AS (which is not > required, as far as I can find in Version 13) then gmail.com says: > > "arc=fail (missing mandatory fields);" > > in it's A-R. > > Which should I implement? > De-jure, or de-facto (and too-big-to-fail)? > > -- > Cheers, > Jeremy > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000004e82be0568f9bf71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please implement -13, but there are almost no protocol cha= nges between -6 and -13. It's mostly editorial. We may have made some t= ags optional but if Google wants 'em, it's probably best to include= them, but that doesn't mean you aren't implementing -13.

<= /div>
--Kurt

On Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris = <jgh@wizmail.org> wrote:
On 2= 1/03/18 15:18, Murray S. Kucherawy wrote:
> On Wed, Mar 21, 2018 at 3:00 PM, <internet-drafts@ietf.org> wrote:
>
>> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt >> has been successfully submitted by Kurt Andersen and posted to the=
>> IETF repository.

I see that Google are still listed as implementing Version 6 -
and indeed, if you don't supply a t=3D tag in the AS (which is not
required, as far as I can find in Version 13) then gmail.com says:

=C2=A0 "arc=3Dfail (missing mandatory fields);"

in it's A-R.

Which should I implement?
De-jure, or de-facto (and too-big-to-fail)?

--
Cheers,
=C2=A0 Jeremy

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

--0000000000004e82be0568f9bf71-- From tomki.camp@gmail.com Tue Apr 3 12:03:18 2018 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 5647E12D874 for ; Tue, 3 Apr 2018 12:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6OUmddPna_vW for ; Tue, 3 Apr 2018 12:03:15 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 35E911242F7 for ; Tue, 3 Apr 2018 12:03:15 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id e98-v6so24188517itd.4 for ; Tue, 03 Apr 2018 12:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=R+jWNqTFcIoer4Jo5jv1Bp8QtkLtVifnq8tG6vNutWU=; b=P86HxfFXUF3L9P2NqWHpNUC/TMI+gScc8wp3lM5mMwDKdSLJdB+LvCE48iBHXqUH5O OXda1VTW8owFxI5FwPZmg/vLK3DzJ8dxQPK2cyS7Dqu/K+uJFXp3NEiDvEyr3v2HpH/v ZOTx2CbQjd2RYGuNLagfJD6o2yob8T8omONdacwktugGfhbiF7Gb74Bu2kPl7pz2DDgN WrfGd6fBN4GJMf9tep29IXBKqWmtGIs+tPF46w0Ja7Vpx41Tsf8dNJmuNftAOJqfGkPv gXWoZ6luPUBG5LGh+mSk553Hvvqq8bX906GeXxan/ENXsP49K9vIbZpuLhVFte10L6SQ 8cBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=R+jWNqTFcIoer4Jo5jv1Bp8QtkLtVifnq8tG6vNutWU=; b=WpfMdzdYgavOT2ql6gHtc1uMyNuNnRGFWm16jDURmR3A3WLcIifPX459mbpnS7zwWd EuVYeEJaUsYKvFzkFLX3PKRkD6fv3FeeSQQJGls7mFAksjUWVCUfZMlGI2SPDeyAJhk3 Lcq3s3jxqwkVSCxZza6iUAq0fduAk3Vv2nWFBOZ/UuIkpJMwrmoYyprIn1LMTB+sPqie p2pFmg/Ognz+jz40whPA1cls/UQ6ZVyOjsEGWY5mJQwkTkGJth6yW23ZcF1UBPXKwRgr M7tJjKsQ90TKnyLegWzhcsDgrUv/g9A5vVwUj31WTSDFbupREy1FjPSfWJnBG7xUVW3z upMg== X-Gm-Message-State: AElRT7G0K89yUlTd/vJjqE1gUUnA2a/vcIrAb4G9EzqYpUKnzwatq3aY dixUrkApT6Iov5SizJyh4EEX+kjpAcTIt7HBx2cTzQ== X-Google-Smtp-Source: AIpwx4/cTUpGypg9nhlTty3j9OWbW7Uz6b2qZamgcWqwI2O3JPZVKIMMkXzX+lN8QqrBUaEvBKILu6BXX6As4biXWrc= X-Received: by 2002:a24:1c11:: with SMTP id c17-v6mr6145561itc.17.1522782194215; Tue, 03 Apr 2018 12:03:14 -0700 (PDT) MIME-Version: 1.0 Sender: tomki.camp@gmail.com Received: by 10.107.26.197 with HTTP; Tue, 3 Apr 2018 12:02:58 -0700 (PDT) From: Tomki Camp Date: Tue, 3 Apr 2018 12:02:58 -0700 X-Google-Sender-Auth: tOC4wJvhPQBzuC1E_1gdBHvYRAM Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c1b3b90568f65bdd" Archived-At: X-Mailman-Approved-At: Wed, 04 Apr 2018 08:42:13 -0700 Subject: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2018 19:09:32 -0000 --000000000000c1b3b90568f65bdd Content-Type: text/plain; charset="UTF-8" Currently defined policy discovery https://tools.ietf.org/html/ rfc7489#section-6.6.3 This begs the question (for which a real example now exists): what if a listed suffix (TLD?) itself has a DMARC record? Is the intent and expected behaviour that the TLD entry override all instances where a record is not explicitly defined? Or should there also be an Organizational level check along the way? Or something else? Current use case: qld.gov.au is in the PSL, *and* has a DMARC record of its own. When looking up whether company.qld.gov.au has a DMARC record, all public tools I tried say 'no record' except MXtoolbox, which shows that the entry inherits from qld.gov.au --000000000000c1b3b90568f65bdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently defined policy disco= very https://tools.ietf.org/html/rfc7489#section-6.6.3

This b= egs the question (for which a real example now exists): what if a listed su= ffix (TLD?) itself has a DMARC record?=C2=A0 Is the intent and expected beh= aviour that the TLD entry override all instances where a record is not expl= icitly defined?=C2=A0 Or should there also be an Organizational level check= along the way?=C2=A0 Or something else?
<= br>
Current use case:
qld.gov.au is in the PSL, *a= nd* has a DMARC record of its own.=C2=A0 When looking up whether company.qld.gov.au has a DMARC record, all = public tools I tried=C2=A0say 'no record' except MXtoolbox, which s= hows that the entry inherits from qld.gov.au<= /a>

=
--000000000000c1b3b90568f65bdd-- From paul.rock@oath.com Wed Apr 4 09:52:58 2018 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 56CE412DA49 for ; Wed, 4 Apr 2018 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamaol.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 HE1YlC9IBy-v for ; Wed, 4 Apr 2018 09:52:55 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5DB127909 for ; Wed, 4 Apr 2018 09:52:55 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 15-v6so18201567itl.1 for ; Wed, 04 Apr 2018 09:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sFnE+k3SCWy9bjVxO1DU++2FNXc0MZ16y89/SP10wRw=; b=j/rlNrFA1HbR3QPLIRDoCIo0OLLFKT4X1DatcBUH+J4PCF3wtkEcDD2x7dJ9uRcNJm HYqkeIZs845mh12CQls4XkpTtFm6QoXcDQEOc1oxnZpORFHlL78pS4ebPQmayYCEOp2C MRj7cL0cqk0mPIrE+LXq4hDmGruKnn7ssXubkzUH5lfB30+lKeGk0X3YF+/PZFPYAHRF VGsHaDGQSHncsyVKf39RlsReRgl4CT+bNWOxtL14oWnnCFGloL/R6wUAAWZ1XKWGIpRB JHBw3RHDwFYmbEV25q8EY3E/UxgY9FjowIy+ch3TgeJ9ZfP3gkbXU2haVQEHQTeF3Mbo X/jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sFnE+k3SCWy9bjVxO1DU++2FNXc0MZ16y89/SP10wRw=; b=QA8tbyNLNmh43tEnX++9QvTKsewt4wBnXXwJzUx+olCy+5SvrxyYxYmb26BeeSbSDY iiZh9bXQslBydOpb0CwaiG7zTYuySqE4HCt+VsZjz5P3pv0AgcRBge0JwIwX3n1W8DmW /PW5YiKdtAbfUJxgAMJYem9AQyHa0g6UvH8QWbDDG7NI6HXuaQSiZGMmQQgmj6Uv9ucp 1+4HX8tU8dQKLgCH29iFAH6AxyfcdO+kTNJk3nPUf3PVxR5AhlCZ3lJHARMSj3gSDH85 4MV/cnWiMWgJjPeiltVvYFJ5COd50ycmWUdNLtE7yvSCreQ3gB2V1lkWbhj+gEBmWVaa ZhrA== X-Gm-Message-State: ALQs6tCxsjtx6Shdfj6X0Wb8irR1EBUqsEPT+OXqJO1MfDr55i6ETevn qOPEeABR9WD0TBBqC4Kxr7UaaN1A+ZiT3BNUWnK/ng== X-Google-Smtp-Source: AIpwx4+IucalcP4gMWRGcM6npgl/N1hEVQWev+aGnR/rD6phJblrmJtjvH/WLDVFMGD7+8TE3eQZJIVj7y+dj9S53rc= X-Received: by 2002:a24:2d0d:: with SMTP id x13-v6mr9857671itx.54.1522860774668; Wed, 04 Apr 2018 09:52:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.7.1 with HTTP; Wed, 4 Apr 2018 09:52:53 -0700 (PDT) In-Reply-To: References: From: Paul Rock Date: Wed, 4 Apr 2018 12:52:53 -0400 Message-ID: To: Tomki Camp Cc: dmarc Content-Type: multipart/alternative; boundary="000000000000848519056908a78b" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 16:55:23 -0000 --000000000000848519056908a78b Content-Type: text/plain; charset="UTF-8" Considering that the qld.gov.au record includes an sp tag, I'd say that they intend and expect that the TLD entry does exactly that - puts DMARC reporting in place for all subdomains that don't have their own record. On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp wrote: > Currently defined policy discovery https://tools.ietf.org/html/rf > c7489#section-6.6.3 > > This begs the question (for which a real example now exists): what if a > listed suffix (TLD?) itself has a DMARC record? Is the intent and expected > behaviour that the TLD entry override all instances where a record is not > explicitly defined? Or should there also be an Organizational level check > along the way? Or something else? > > Current use case: > qld.gov.au is in the PSL, *and* has a DMARC record of its own. When > looking up whether company.qld.gov.au has a DMARC record, all public > tools I tried say 'no record' except MXtoolbox, which shows that the entry > inherits from qld.gov.au > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- PAUL ROCK *Sr Software Dev Engineer* | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --000000000000848519056908a78b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Considering that the qld.gov= .au record includes an sp tag, I'd say that they intend and expect = that the TLD entry does exactly that - puts DMARC reporting in place for al= l subdomains that don't have their own record.

On Tue, Apr 3, 2018 at 3:02 PM, Tomk= i Camp <tki=3D40tomki.com@dmarc.ietf.org> wro= te:
Currently defined policy discovery https://tools.ietf.org/html= /rfc7489#section-6.6.3

=
This begs the question (for which a real exampl= e now exists): what if a listed suffix (TLD?) itself has a DMARC record?=C2= =A0 Is the intent and expected behaviour that the TLD entry override all in= stances where a record is not explicitly defined?=C2=A0 Or should there als= o be an Organizational level check along the way?=C2=A0 Or something else?<= /div>

Curr= ent use case:
qld.gov.au is in the PSL, *and* has a DMARC record = of its own.=C2=A0 When looking up whether company.qld.gov.au has a DMARC record, all publi= c tools I tried=C2=A0say 'no record' except MXtoolbox, which shows = that the entry inherits from qld.gov.au



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




--
=
PAUL ROCK
Sr Software Dev Engineer=C2=A0| AOL Mai= l
P: 703-265-5734 | C: 70= 3-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
--000000000000848519056908a78b-- From paul.rock@oath.com Wed Apr 4 09:53:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9128127909 for ; Wed, 4 Apr 2018 09:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522860781; bh=dpXEnupqxBhzb9K4qJ0B79FNBHvzCHOF190VjIyHsfs=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=QmD5xxbn3iAvSz+rndOQnWrzzlP0pc5yraCGMX0966z3t09k+9i+aC4LY0H91s1Sx g6AAMemIE+HyShQtjqSdYa6aLK7Hxl6HFqWO3nnFUrHFa90NVhg8TtYizUn981DJbo 3Fb4Jis7nyz+rRQMYR9SwindH4v7nhizJ+kDscVA= X-Mailbox-Line: From paul.rock@oath.com Wed Apr 4 09:53:01 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F6E12DA49 for ; Wed, 4 Apr 2018 09:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522860781; bh=aj5YlT3SIMAhPmYXIyGfr1X2z92YHUPQZdzSBcTKXVc=; h=In-Reply-To:References:From:Date:Subject:Cc:To; b=Mw99V7x26n/x39XjCfKAZRkOI43mFIhT7/ZpIE61qmON/+As6LpKuqZ57CV5VWbMb P+dwqiy5XqZyt6Kff2FLSjU3SdVkmBdBaegXwQT2sI0IOb0tj8nkTEpSjTYkz3IIhD 7TgEmn56YIuM8y8ZT3JzXo8Ww/9IKgBHZkCVU0ps= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA03127909 for ; Wed, 4 Apr 2018 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamaol.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 8Nl09N2DGF-w for ; Wed, 4 Apr 2018 09:52:59 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 AED4F12DA49 for ; Wed, 4 Apr 2018 09:52:55 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 71-v6so26450639ith.2 for ; Wed, 04 Apr 2018 09:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sFnE+k3SCWy9bjVxO1DU++2FNXc0MZ16y89/SP10wRw=; b=j/rlNrFA1HbR3QPLIRDoCIo0OLLFKT4X1DatcBUH+J4PCF3wtkEcDD2x7dJ9uRcNJm HYqkeIZs845mh12CQls4XkpTtFm6QoXcDQEOc1oxnZpORFHlL78pS4ebPQmayYCEOp2C MRj7cL0cqk0mPIrE+LXq4hDmGruKnn7ssXubkzUH5lfB30+lKeGk0X3YF+/PZFPYAHRF VGsHaDGQSHncsyVKf39RlsReRgl4CT+bNWOxtL14oWnnCFGloL/R6wUAAWZ1XKWGIpRB JHBw3RHDwFYmbEV25q8EY3E/UxgY9FjowIy+ch3TgeJ9ZfP3gkbXU2haVQEHQTeF3Mbo X/jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sFnE+k3SCWy9bjVxO1DU++2FNXc0MZ16y89/SP10wRw=; b=e9YrzuLs8iaHydU0G+0KjnUMatuPsY2+uQ9Qqj8Tb3Jf0c3t4SA4nfv2z3hP+cKBNs 8+ER5UPlbd+kmSMpEaXuw/4Gqiu5A22Oa2FCVf89tGfTux5JG64DF/DhBKPQw8VqvmwA TJHALbeer4jRnHrQOWMLwMWB/tMs2yoBTf/3sbAn4fgKGwSvWb2CLd21Ev9CPUFrxcjf 40LYVy5bB/j7CcN0QCF2nq7x6h47js5fhSezfkEaXXW5pEKDH+dNbhciKbJT9zu0rjjF D0eDlhHXtLp5qWoC8SI8Rlor6s8ddLEb51dMUZSmfltrZ495YZjp0QEQ/UsZCDrYp7Je PiIA== X-Gm-Message-State: ALQs6tDgR3hVtHgI+DOLe14BX255M34PX12MbfaUzUKgVOxA+oZVjN3U /AIAo3nvuZ5GlSLQMzIndXkMdTFaL15Ti37fnPq1BF0WOSs= X-Google-Smtp-Source: AIpwx4+IucalcP4gMWRGcM6npgl/N1hEVQWev+aGnR/rD6phJblrmJtjvH/WLDVFMGD7+8TE3eQZJIVj7y+dj9S53rc= X-Received: by 2002:a24:2d0d:: with SMTP id x13-v6mr9857671itx.54.1522860774668; Wed, 04 Apr 2018 09:52:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.7.1 with HTTP; Wed, 4 Apr 2018 09:52:53 -0700 (PDT) In-Reply-To: References: From: Paul Rock Date: Wed, 4 Apr 2018 12:52:53 -0400 Message-ID: Cc: dmarc Content-Type: multipart/alternative; boundary="000000000000848519056908a78b" To: Tomki Camp Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 16:55:42 -0000 --000000000000848519056908a78b Content-Type: text/plain; charset="UTF-8" Considering that the qld.gov.au record includes an sp tag, I'd say that they intend and expect that the TLD entry does exactly that - puts DMARC reporting in place for all subdomains that don't have their own record. On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp wrote: > Currently defined policy discovery https://tools.ietf.org/html/rf > c7489#section-6.6.3 > > This begs the question (for which a real example now exists): what if a > listed suffix (TLD?) itself has a DMARC record? Is the intent and expected > behaviour that the TLD entry override all instances where a record is not > explicitly defined? Or should there also be an Organizational level check > along the way? Or something else? > > Current use case: > qld.gov.au is in the PSL, *and* has a DMARC record of its own. When > looking up whether company.qld.gov.au has a DMARC record, all public > tools I tried say 'no record' except MXtoolbox, which shows that the entry > inherits from qld.gov.au > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- PAUL ROCK *Sr Software Dev Engineer* | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --000000000000848519056908a78b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Considering that the qld.gov= ..au record includes an sp tag, I'd say that they intend and expect = that the TLD entry does exactly that - puts DMARC reporting in place for al= l subdomains that don't have their own record.

On Tue, Apr 3, 2018 at 3:02 PM, Tomk= i Camp <tki=3D40tomki.com@dmarc.ietf.org> wro= te:
Currently defined policy discovery https://tools.ietf.org/html= /rfc7489#section-6.6.3

=
This begs the question (for which a real exampl= e now exists): what if a listed suffix (TLD?) itself has a DMARC record?=C2= =A0 Is the intent and expected behaviour that the TLD entry override all in= stances where a record is not explicitly defined?=C2=A0 Or should there als= o be an Organizational level check along the way?=C2=A0 Or something else?<= /div>

Curr= ent use case:
qld.gov.au is in the PSL, *and* has a DMARC record = of its own.=C2=A0 When looking up whether company.qld.gov.au has a DMARC record, all publi= c tools I tried=C2=A0say 'no record' except MXtoolbox, which shows = that the entry inherits from qld.gov.au



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




--
=
PAUL ROCK
Sr Software Dev Engineer=C2=A0| AOL Mai= l
P: 703-265-5734 | C: 70= 3-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
--000000000000848519056908a78b-- From nobody Wed Apr 4 10:45:23 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8C7129C53 for ; Wed, 4 Apr 2018 10:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522863921; bh=9Gjj3JZNyAW5SgaYJnb35GBna97DCCAeTevHEbkB9Ag=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=jWY9uBtSpEEKVwynjAGWr+5KiuSri45YgN5LAYF3rqJcBXkIfS+ho2H/Ts5FwliX4 pvpPXX0OEEiVCEVivYZu4iN2Jfq0KbjDr7lH+L2cd38afsvWAJGCjMvrb21waFJp9o 2fMtR5hKeioFegebNO0Pem8X1X9OrWI2xtVNJ/Pc= X-Mailbox-Line: From kurta@drkurt.com Wed Apr 4 10:45:21 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49163126BF6; Wed, 4 Apr 2018 10:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1522863921; bh=gt503lR7negemhviJAC9RS1mCYYXONyQYLumRVQ78BM=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=JxB0VAYujNGHALYys/acDLADXpDrQe9WOVEFLeGLlFqQkevq7DGzgWmo80LcDpXn6 Z/T9qEv3Unn0n9DgVdN3obtTPb6B9k8oFBULqDgjIRGr4pUYmFpLylnFg7WghpU1eS Bqz4Q5Og/DEdtXJhmOm7k5KvsjjK4gCEBDE7gc/0= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A4E129C53 for ; Wed, 4 Apr 2018 10:45: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 FQE8RoQdFJx7 for ; Wed, 4 Apr 2018 10:45:18 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99127126BF6 for ; Wed, 4 Apr 2018 10:45:18 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id b127so42729613wmf.5 for ; Wed, 04 Apr 2018 10:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jXDEXmOhgPoMzFIius+zdkGwoJjhk0pq40pL4qqLdl0=; b=NjhXJ15s97vvdtzHI6nMpPnpyyJrvM+kmrj6wjPyzrOum0VLx5bZwwK1nwSOmeIqaK vwfUo6Iu+LYmueuEq/UA42qEvvta5hkEpR7tobOuyzP2EtsgmXwypj628G0EpGsSSiPM jYnFY13LSk+x1uNHD5vCSvak0Fzy9gMufwsaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jXDEXmOhgPoMzFIius+zdkGwoJjhk0pq40pL4qqLdl0=; b=bGIiweleF1E3m9oTH7mGhXPmei8qICLFiPSXhdmRlIfldsl3jQGmlnNBDt60tZXOX8 w02h71dua/UVzCDO1xISJkXC4wmEgOYQm+wlaQG05+9daDD4cqEKmCsjbed9lmmvXHcI O39FjJKFEBIBCm1M/RJoBIpJjy8ovzIFGkC3KxZKMDEjzbRUjLAF1waUr6fN3qg4dB4O CJ3Z4S/QyNiibHDPWgvqTIc3S981iBIlfjBbuEwXd3mEz4Puw054mZEKgYocBa1+UOWo DhHO27H9QKqWGkzk7QKy8Gwk4imOWMjCybuRemq4+tTwooY7AUMmtdpcri8HSlB+tyjE jzEQ== X-Gm-Message-State: ALQs6tDTzRoaWKhA0Y82MrqwEDoW2G4OerVnvEk/F714+eVkyTltk+r5 Kq5E+5O5I6GQti7Nj0lMgXP/ggsf3O7g5LGTuztYiw== X-Google-Smtp-Source: AIpwx497KHFaHEqO/nwSKfPBGkthu4gxRDg8pCWXwc05n5iA3zyXvAX+cvPiNqcsnKqEWXshY7Y4U9QOkXWQ41SkHp8= X-Received: by 10.46.134.89 with SMTP id i25mr8851487ljj.121.1522863916950; Wed, 04 Apr 2018 10:45:16 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:e504:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 10:45:15 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 4 Apr 2018 10:45:15 -0700 X-Google-Sender-Auth: l5LCXMWazjDqelmepmZTOC7zjo0 Message-ID: To: Paul Rock Content-Type: multipart/alternative; boundary="f4f5e80eea8ccfbac905690962f8" Cc: Tomki Camp Cc: dmarc Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 17:45:21 -0000 --f4f5e80eea8ccfbac905690962f8 Content-Type: text/plain; charset="UTF-8" Apologies for the top-posting, but this is exactly the scenario that has been discussed earlier on the list: https://www.ietf.org/mail-archive/web/dmarc/current/msg04151.html as well as during the recent IETF101 meeting: https://datatracker.ietf.org/doc/minutes-101-dmarc/ The problem really is (at the moment) that there is no basis in the lookup algorithm to ever query the "last public" domain (aka "org-1"). Would the community be open to adding a third potential lookup to the algorithm? 1 - check the domain itself 2 - check the org domain 3 - check org-1 --Kurt On Wed, Apr 4, 2018 at 9:52 AM, Paul Rock wrote: > Considering that the qld.gov..au record includes an > sp tag, I'd say that they intend and expect that the TLD entry does exactly > that - puts DMARC reporting in place for all subdomains that don't have > their own record. > > On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp > wrote: > >> Currently defined policy discovery https://tools.ietf.org/html/rf >> c7489#section-6.6.3 >> >> This begs the question (for which a real example now exists): what if a >> listed suffix (TLD?) itself has a DMARC record? Is the intent and expected >> behaviour that the TLD entry override all instances where a record is not >> explicitly defined? Or should there also be an Organizational level check >> along the way? Or something else? >> >> Current use case: >> qld.gov.au is in the PSL, *and* has a DMARC record of its own. When >> looking up whether company.qld.gov.au has a >> DMARC record, all public tools I tried say 'no record' except MXtoolbox, >> which shows that the entry inherits from qld.gov.au >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > > -- > PAUL ROCK > *Sr Software Dev Engineer* | AOL Mail > P: 703-265-5734 | C: 703-980-8380 > AIM: paulsrock > 22070 Broderick Dr.| Dulles, VA | 20166-9305 > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f4f5e80eea8ccfbac905690962f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the top-posting, but this is exactly the sce= nario that has been discussed earlier on the list:=C2=A0https://www.ietf= ..org/mail-archive/web/dmarc/current/msg04151.html as well as during the= recent IETF101 meeting:=C2=A0https://datatracker.ietf.org/doc/minutes-101-dmarc/<= div>
The problem really is (at the moment) that there is no b= asis in the lookup algorithm to ever query the "last public" doma= in (aka "org-1"). Would the community be open to adding a third p= otential lookup to the algorithm?
=C2=A0 =C2=A01 - check the doma= in itself
=C2=A0 =C2=A02 - check the org domain
=C2=A0 = =C2=A03 - check org-1

--Kurt

On Wed, Apr 4, 2018 at 9:52= AM, Paul Rock <paul.rock@teamaol.com> wrote:
Considering that the qld.gov..au record includes an sp ta= g, I'd say that they intend and expect that the TLD entry does exactly = that - puts DMARC reporting in place for all subdomains that don't have= their own record.

On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp <tki=3D40tomki.com@dmarc.ietf.org> wrote:=
Currently defined policy discovery = https://tools.ietf.org/html/rfc7489#section-6.6.3

This begs the q= uestion (for which a real example now exists): what if a listed suffix (TLD= ?) itself has a DMARC record?=C2=A0 Is the intent and expected behaviour th= at the TLD entry override all instances where a record is not explicitly de= fined?=C2=A0 Or should there also be an Organizational level check along th= e way?=C2=A0 Or something else?

=
Current use case:
qld.gov.au is in th= e PSL, *and* has a DMARC record of its own.=C2=A0 When looking up whether <= a href=3D"http://company.qld.gov..au" target=3D"_blank">company.qld.gov.au<= /a> has a DMARC record, all public tools I tried=C2=A0say 'no record= 9; except MXtoolbox, which shows that the entry inherits from qld.gov.au



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


<= br clear=3D"all">

--
<= div dir=3D"ltr">
PAUL ROCK
Sr Software Dev Engineer=C2=A0| AOL Mail
P: 703-265-5734 | C: 703-980= -8380
= AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305

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


--f4f5e80eea8ccfbac905690962f8-- From nobody Wed Apr 4 10:45:28 2018 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 F3994126BF6 for ; Wed, 4 Apr 2018 10:45: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 YAzra3pVvps4 for ; Wed, 4 Apr 2018 10:45:18 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 93A68124C27 for ; Wed, 4 Apr 2018 10:45:18 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id r82so45141245wme.0 for ; Wed, 04 Apr 2018 10:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jXDEXmOhgPoMzFIius+zdkGwoJjhk0pq40pL4qqLdl0=; b=NjhXJ15s97vvdtzHI6nMpPnpyyJrvM+kmrj6wjPyzrOum0VLx5bZwwK1nwSOmeIqaK vwfUo6Iu+LYmueuEq/UA42qEvvta5hkEpR7tobOuyzP2EtsgmXwypj628G0EpGsSSiPM jYnFY13LSk+x1uNHD5vCSvak0Fzy9gMufwsaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jXDEXmOhgPoMzFIius+zdkGwoJjhk0pq40pL4qqLdl0=; b=iwxRV+iyP6XL9cKZJtr3haCxxCd8e33DJ0kXu9efsidWjllFmlQldXk9ZnCPZuJjBr mAQsmYTFKZwCDbBXTOP/xa88cJGkit0AxhS8BOXARyoHJrgtmTrdTKsefgttpl/v1yim CbAocjXTbid6Q9GlT2lpvWAgtr/vRD0PjPMGxo8nIt2p4UFC41uxbiCArdOl7g5oEAwR OObWbf4EcOBajKsutTeTo4GRoNqflYGTVhxVDvkMYfRGmLOCfVPv/J32s+jFgq+G4ZNG vz67K9sGNJmArcaDzph+NsxqY6rGgNyjc7NztrUvGeU2rEynE1hqOXsWHLL5x+mFi0Yp dDnA== X-Gm-Message-State: ALQs6tAPVQlkcye8066BrBRYDgWykyLCAaIU2XBs1MK4ik/VpgluMdyA y+0AhyMiob9RZLtvceLRuk6zZFlYFjUAvGETBkaEdlriErU= X-Google-Smtp-Source: AIpwx497KHFaHEqO/nwSKfPBGkthu4gxRDg8pCWXwc05n5iA3zyXvAX+cvPiNqcsnKqEWXshY7Y4U9QOkXWQ41SkHp8= X-Received: by 10.46.134.89 with SMTP id i25mr8851487ljj.121.1522863916950; Wed, 04 Apr 2018 10:45:16 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:e504:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 10:45:15 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 4 Apr 2018 10:45:15 -0700 X-Google-Sender-Auth: l5LCXMWazjDqelmepmZTOC7zjo0 Message-ID: To: Paul Rock Cc: Tomki Camp , dmarc Content-Type: multipart/alternative; boundary="f4f5e80eea8ccfbac905690962f8" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 17:45:22 -0000 --f4f5e80eea8ccfbac905690962f8 Content-Type: text/plain; charset="UTF-8" Apologies for the top-posting, but this is exactly the scenario that has been discussed earlier on the list: https://www.ietf.org/mail-archive/web/dmarc/current/msg04151.html as well as during the recent IETF101 meeting: https://datatracker.ietf.org/doc/minutes-101-dmarc/ The problem really is (at the moment) that there is no basis in the lookup algorithm to ever query the "last public" domain (aka "org-1"). Would the community be open to adding a third potential lookup to the algorithm? 1 - check the domain itself 2 - check the org domain 3 - check org-1 --Kurt On Wed, Apr 4, 2018 at 9:52 AM, Paul Rock wrote: > Considering that the qld.gov..au record includes an > sp tag, I'd say that they intend and expect that the TLD entry does exactly > that - puts DMARC reporting in place for all subdomains that don't have > their own record. > > On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp > wrote: > >> Currently defined policy discovery https://tools.ietf.org/html/rf >> c7489#section-6.6.3 >> >> This begs the question (for which a real example now exists): what if a >> listed suffix (TLD?) itself has a DMARC record? Is the intent and expected >> behaviour that the TLD entry override all instances where a record is not >> explicitly defined? Or should there also be an Organizational level check >> along the way? Or something else? >> >> Current use case: >> qld.gov.au is in the PSL, *and* has a DMARC record of its own. When >> looking up whether company.qld.gov.au has a >> DMARC record, all public tools I tried say 'no record' except MXtoolbox, >> which shows that the entry inherits from qld.gov.au >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > > -- > PAUL ROCK > *Sr Software Dev Engineer* | AOL Mail > P: 703-265-5734 | C: 703-980-8380 > AIM: paulsrock > 22070 Broderick Dr.| Dulles, VA | 20166-9305 > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f4f5e80eea8ccfbac905690962f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the top-posting, but this is exactly the sce= nario that has been discussed earlier on the list:=C2=A0https://www.ietf= .org/mail-archive/web/dmarc/current/msg04151.html as well as during the= recent IETF101 meeting:=C2=A0https://datatracker.ietf.org/doc/minutes-101-dmarc/<= div>
The problem really is (at the moment) that there is no b= asis in the lookup algorithm to ever query the "last public" doma= in (aka "org-1"). Would the community be open to adding a third p= otential lookup to the algorithm?
=C2=A0 =C2=A01 - check the doma= in itself
=C2=A0 =C2=A02 - check the org domain
=C2=A0 = =C2=A03 - check org-1

--Kurt

On Wed, Apr 4, 2018 at 9:52= AM, Paul Rock <paul.rock@teamaol.com> wrote:
Considering that the qld.gov..au record includes an sp ta= g, I'd say that they intend and expect that the TLD entry does exactly = that - puts DMARC reporting in place for all subdomains that don't have= their own record.

On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp <tki=3D40tomki.com@dmarc.ietf.org> wrote:=
Currently defined policy discovery = https://tools.ietf.org/html/rfc7489#section-6.6.3

This begs the q= uestion (for which a real example now exists): what if a listed suffix (TLD= ?) itself has a DMARC record?=C2=A0 Is the intent and expected behaviour th= at the TLD entry override all instances where a record is not explicitly de= fined?=C2=A0 Or should there also be an Organizational level check along th= e way?=C2=A0 Or something else?

=
Current use case:
qld.gov.au is in th= e PSL, *and* has a DMARC record of its own.=C2=A0 When looking up whether <= a href=3D"http://company.qld.gov..au" target=3D"_blank">company.qld.gov.au<= /a> has a DMARC record, all public tools I tried=C2=A0say 'no record= 9; except MXtoolbox, which shows that the entry inherits from qld.gov.au



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


<= br clear=3D"all">

--
<= div dir=3D"ltr">
PAUL ROCK
Sr Software Dev Engineer=C2=A0| AOL Mail
P: 703-265-5734 | C: 703-980= -8380
= AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305

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


--f4f5e80eea8ccfbac905690962f8-- From nobody Wed Apr 4 11:19:27 2018 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 C7A53124239 for ; Wed, 4 Apr 2018 11:19:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzPrRGa9MPhC for ; Wed, 4 Apr 2018 11:19:23 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370551200C1 for ; Wed, 4 Apr 2018 11:19:23 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r82so45388889wme.0 for ; Wed, 04 Apr 2018 11:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=F8p72EhBSKj9AkJB7nS7o2oZTbL77uzwH7Mt6hLjeS0=; b=oS61lGn7Q525ECT7TLp6CQ4sLOBj4sFIArk7Y81CZz1WnYBrrnHvRui0YftqCoukxx 7MfhegMw6W3QDtqJVzijmmVnNIFgolhG4oJdeho2AiET6mK9RypkCqq/Jsdz29UtAl1p cqlZNfuzs9oGQuCfZNDUfIK3ahYhqSFKchHN0U0QhmSDG883ugp7A3zCZt61YJs4ZnV0 cK+YGWfWtv8k/R5IbSocI/rdhIx9/DRSZt/m3i6sVCQVARdVd9XenV1ot4fFkvCKOXYC gyhvZap+CorpQuQ52sNB1EK2VWOfDdMepsnJamtbVp/0jPSYvshbKsDiEM7fNFDGQr3K fs0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=F8p72EhBSKj9AkJB7nS7o2oZTbL77uzwH7Mt6hLjeS0=; b=QC+Rbxck55BeYv9np7pGP4HP7cH/+mk/DoYOz7tbwJ/ssB2P36HrBNZ+QmY6kKSq6t o0sV6LW7jDNCTX/et43XwxUuvwwpPLCPf847ltSpci3XLa9Tvj6MMdJfdKMFQBu7TYZ/ nTOMQ0FFL+Sh7qac4KCfW0mZSiF5V3IV+koJJAtXUb3xg09aYB/ZrQzgQhU0ITmrOYuo s+QZe+OQBRkp6iPfz6/mo4SqC3sV0111cg7SAN5VZ6dF3KgXp54h82tRCi+iD1NEEtjQ 24TQkliRKWHi8ywJIOhw/Vr2UYpYX669kwUiE8jjkUdYU2JgnfQG8cFA4EMCNGdD71/m Z0xw== X-Gm-Message-State: ALQs6tBcNNJxfYYK2OJILZcJz0VvYom7Kp2IfAEPM70nGPt3zgVDydCj rxrtKHc79beoEIR75+sIdKKQ+OkxwpoFr/aFNL07eQ== X-Google-Smtp-Source: AIpwx4+XsfYs3etil+5pWwm0OepXvosPD7/8DPPCzeLsajTHZE9DW7OojSdSPqmulQu2KKhby3fQ7KZ3MBz87pRppH4= X-Received: by 10.46.85.196 with SMTP id g65mr11819095lje.10.1522865961607; Wed, 04 Apr 2018 11:19:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d013:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 11:19:20 -0700 (PDT) In-Reply-To: References: From: "Peter M. Goldstein" Date: Wed, 4 Apr 2018 11:19:20 -0700 Message-ID: To: "Kurt Andersen (b)" , dmarc Content-Type: multipart/alternative; boundary="94eb2c1aa700aea814056909dcca" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 18:19:27 -0000 --94eb2c1aa700aea814056909dcca Content-Type: text/plain; charset="UTF-8" Kurt, As you note, this issue has been discussed on-list (and off) a few times. And it definitely seems clear that some sort of modification to the lookup algorithm would be required to address the issue. As part of that discussion, there are a few scenarios that I think should be considered: 1. *A domain which contains two public suffixes* - i.e. abc.gov.uk, which contains the public suffixes .gov.uk, .uk. In the proposed lookup scheme we'd be assuming that the manager of the registry for the "last" organizational domain represented a controlling authority that should be able to impose DMARC policy on and view data for all subdomains. I'm not sure whether that's true in all cases, and that would have bearing on your proposal. 2. *A domain which contains three or more public suffixes* - I'm not sure given the content of the public suffix list today that you can actually construct one of these. But from what I can see, there's nothing restricting a future update of the public suffix list that would allow such a domain. If we update the lookup algorithm, we should at least speak to this case - even if it's just to say we ignore it. 3. *New gTLDs* - With the recent expansion of the list of TLDs, many of the new TLDs are controlled by a single organization. It may make sense to allow those gTLDs to define a DMARC record on the TLD itself or on some 'default' domain - both for administrative simplification and to ensure against abuse. It may be possible to handle this case outside of a lookup change with wildcarded DNS records, but I know it's something that's come up in discussions with some of those TLD owners. I'd suggest that if we're going to make a modification to the lookup algorithm that we consider each of these scenarios, and ensure there's consensus on how they should each be addressed. To your specific question, I think it's desirable to address these cases and it's worth discussing how the lookup algorithm can be modified to do so. Best, Peter On Wed, Apr 4, 2018 at 10:45 AM, Kurt Andersen (b) wrote: > Apologies for the top-posting, but this is exactly the scenario that has > been discussed earlier on the list: https://www.ietf...org/ > mail-archive/web/dmarc/current/msg04151.html > as > well as during the recent IETF101 meeting: https://datatracker. > ietf.org/doc/minutes-101-dmarc/ > > The problem really is (at the moment) that there is no basis in the lookup > algorithm to ever query the "last public" domain (aka "org-1"). Would the > community be open to adding a third potential lookup to the algorithm? > 1 - check the domain itself > 2 - check the org domain > 3 - check org-1 > > --Kurt > > On Wed, Apr 4, 2018 at 9:52 AM, Paul Rock wrote: > >> Considering that the qld.gov..au record includes an >> sp tag, I'd say that they intend and expect that the TLD entry does exactly >> that - puts DMARC reporting in place for all subdomains that don't have >> their own record. >> >> On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp > g > wrote: >> >>> Currently defined policy discovery https://tools.ietf.org/html/rf >>> c7489#section-6.6.3 >>> >>> This begs the question (for which a real example now exists): what if a >>> listed suffix (TLD?) itself has a DMARC record? Is the intent and expected >>> behaviour that the TLD entry override all instances where a record is not >>> explicitly defined? Or should there also be an Organizational level check >>> along the way? Or something else? >>> >>> Current use case: >>> qld.gov.au is in the PSL, *and* has a DMARC record of its own. When >>> looking up whether company.qld.gov.au has >>> a DMARC record, all public tools I tried say 'no record' except MXtoolbox, >>> which shows that the entry inherits from qld.gov.au >>> >>> >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> >> >> >> -- >> PAUL ROCK >> *Sr Software Dev Engineer* | AOL Mail >> P: 703-265-5734 | C: 703-980-8380 >> AIM: paulsrock >> 22070 Broderick Dr.| Dulles, VA | 20166-9305 >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --94eb2c1aa700aea814056909dcca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kurt,

As you note, this issue has been = discussed on-list (and off) a few times.=C2=A0 And it definitely seems clea= r that some sort of modification to the lookup algorithm would be required = to address the issue.

As part of that discussion, = there are a few scenarios that I think should be considered:

=
1. A domain which contains two public suffixes - i.e. abc.gov.uk, which contains the public suffix= es .gov.uk, .uk.=C2=A0 In the proposed lookup= scheme we'd be assuming that the manager of the registry for the "= ;last" organizational domain represented a controlling authority that = should be able to impose DMARC policy on and view data for all subdomains.= =C2=A0 I'm not sure whether that's true in all cases, and that woul= d have bearing on your proposal.

2. A domain wh= ich contains three or more public suffixes - I'm not sure given the= content of the public suffix list today that you can actually construct on= e of these.=C2=A0 But from what I can see, there's nothing restricting = a future update of the public suffix list that would allow such a domain.= =C2=A0 If we update the lookup algorithm, we should at least speak to this = case - even if it's just to say we ignore it.

= 3. New gTLDs - With the recent expansion of the list of TLDs, many o= f the new TLDs are controlled by a single organization.=C2=A0 It may make s= ense to allow those gTLDs to define a DMARC record on the TLD itself or on = some 'default' domain - both for administrative simplification and = to ensure against abuse.=C2=A0 It may be possible to handle this case outsi= de of a lookup change with wildcarded DNS records, but I know it's some= thing that's come up in discussions with some of those TLD owners.=C2= =A0=C2=A0

I'd suggest that if we're going = to make a modification to the lookup algorithm that we consider each of the= se scenarios, and ensure there's consensus on how they should each be a= ddressed.

To your specific question, I think it= 9;s desirable to address these cases and it's worth discussing how the = lookup algorithm can be modified to do so.

Best,

Peter

On Wed, Apr 4, 2018 at 10:45 AM, Kurt Andersen (b) = <kboth@drkurt.com> wrote:
<= div dir=3D"ltr">Apologies for the top-posting, but this is exactly the scen= ario that has been discussed earlier on the list:=C2=A0https://www.ietf...org/mail-archive/web/dmarc/current/msg04151.h= tml as well as during the recent IETF101 meeting:=C2=A0https://d= atatracker.ietf.org/doc/minutes-101-dmarc/

The problem really is (at the moment) that there is no basis in the lookup= algorithm to ever query the "last public" domain (aka "org-= 1"). Would the community be open to adding a third potential lookup to= the algorithm?
=C2=A0 =C2=A01 - check the domain itself
=C2=A0 =C2=A02 - check the org domain
=C2=A0 =C2=A03 - check or= g-1

--Kurt

On Wed, Apr 4, 2018= at 9:52 AM, Paul Rock <paul.rock@teamaol.com> wrote:
Considering that the qld.gov..au record includes = an sp tag, I'd say that they intend and expect that the TLD entry does = exactly that - puts DMARC reporting in place for all subdomains that don= 9;t have their own record.

On Tue, Apr 3= , 2018 at 3:02 PM, Tomki Camp <tki=3D40tomki.com@dmarc.i= etf.org> wrote:
Currently defined policy discovery https://tools.= ietf.org/html/rfc7489#section-6.6.3

This begs the question (for which = a real example now exists): what if a listed suffix (TLD?) itself has a DMA= RC record?=C2=A0 Is the intent and expected behaviour that the TLD entry ov= erride all instances where a record is not explicitly defined?=C2=A0 Or sho= uld there also be an Organizational level check along the way?=C2=A0 Or som= ething else?

Current use case:
qld.gov.au is in the PSL, *and* has a = DMARC record of its own.=C2=A0 When looking up whether company.qld.gov.au has a DMARC rec= ord, all public tools I tried=C2=A0say 'no record' except MXtoolbox= , which shows that the entry inherits from qld.gov.au

<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif;font-size:small">

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




--
PAUL ROCK
Sr Software Dev Engineer=C2=A0| AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick D= r.| Dulles, VA | 20166-9305

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



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


--94eb2c1aa700aea814056909dcca-- From nobody Wed Apr 4 11:42:07 2018 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 8AB0A12D7E2 for ; Wed, 4 Apr 2018 11:41:53 -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 6DSoyoVLwFCl for ; Wed, 4 Apr 2018 11:41:51 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 C80C11243F6 for ; Wed, 4 Apr 2018 11:41:50 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id z73so24326149wrb.0 for ; Wed, 04 Apr 2018 11:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PUhLll6wysu3+zIAxJHaXWSALzBQalQIIGT6dpWzd14=; b=I6vAX8YX/TkII5F33Qm2BEFZBkit8+1qwgGP2TqxHwnOEmMcqdKn20aXMtAa9aMYVi W459S9Oh5LJp/TDDaUR9CFfnELbM/YzFc65BbHxH2n/McH9clRBnzwTp43oV9dLJW/FQ TjTLKetWuxG+oRv5zFgargB5ihLEiGAHs5pO8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PUhLll6wysu3+zIAxJHaXWSALzBQalQIIGT6dpWzd14=; b=QmUFsON6c0tKJwM1/4/hElqOgD1213Wp6Ox0CwWTqrj1zQJze+Lh0hGbnOvNp+hlcu apgwrIu9K+ZnYHugRyRBErdf8lHZOo+pnwiZFfMYHGgcfkYiUef/BwJco6OU7Ju3aqh3 t70eN+5yUPsFRXcCi/2XR4BC2nI8Ww4BDbZbzVUQxwhKUwABrI2dU/uYoll1EBnwiHnu 7UT+fcZlJvjmOhDQZ+yuf6DYsRl2g6aMS+m3GG9lolyZMBcW7VoA6RDWDr3k518hn8Di Os+K6jkFaKd/H/a7+V3ch/vmb7mwJECjnbI5IE20PEVhTKmSTNY+oqTApCRFXuE3Ol8J p3fw== X-Gm-Message-State: AElRT7EhrzKY+DyBlZIdfkwAINS3Gk5+lU5CpPALZQnCHGrRmk4Ojd7w dIbKsljQsmGLi9pbFU7olNTlALsOnyhl2oQr757xGQ== X-Google-Smtp-Source: AIpwx491NIgmNQmZQnAHrCEaSAe1zqIf6RZhxUgyZvqygXlMAmGGW7RETnv5YI/oDgdcYXxgw7KRl+Q8GZ2TQCLDGNI= X-Received: by 2002:a19:911a:: with SMTP id t26-v6mr11561466lfd.101.1522867309075; Wed, 04 Apr 2018 11:41:49 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:e504:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 11:41:48 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 4 Apr 2018 11:41:48 -0700 X-Google-Sender-Auth: W7I_uoWXvlOsKliNnxiWX-ZKg6U Message-ID: To: "Peter M. Goldstein" Cc: dmarc Content-Type: multipart/alternative; boundary="000000000000ff749f05690a2c8d" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 18:41:53 -0000 --000000000000ff749f05690a2c8d Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 11:19 AM, Peter M. Goldstein < peter.m.goldstein@gmail.com> wrote: > Kurt, > > As you note, this issue has been discussed on-list (and off) a few times. > And it definitely seems clear that some sort of modification to the lookup > algorithm would be required to address the issue. > > As part of that discussion, there are a few scenarios that I think should > be considered: > > 1. *A domain which contains two public suffixes* - i.e. abc.gov.uk, which > contains the public suffixes .gov.uk, .uk. In the proposed lookup scheme > we'd be assuming that the manager of the registry for the "last" > organizational domain represented a controlling authority that should be > able to impose DMARC policy on and view data for all subdomains. I'm not > sure whether that's true in all cases, and that would have bearing on your > proposal. > > 2. *A domain which contains three or more public suffixes* - I'm not sure > given the content of the public suffix list today that you can actually > construct one of these. But from what I can see, there's nothing > restricting a future update of the public suffix list that would allow such > a domain. If we update the lookup algorithm, we should at least speak to > this case - even if it's just to say we ignore it. > This is quite easily accomplished, as are scenarios where there are public blocks embedded "down chain" with intervening private domains in between. See the notes from the DBOUND working group if you want to delve into these sorts of things. 3. *New gTLDs* - With the recent expansion of the list of TLDs, many of the > new TLDs are controlled by a single organization. It may make sense to > allow those gTLDs to define a DMARC record on the TLD itself or on some > 'default' domain - both for administrative simplification and to ensure > against abuse. It may be possible to handle this case outside of a lookup > change with wildcarded DNS records, but I know it's something that's come > up in discussions with some of those TLD owners. > > I'd suggest that if we're going to make a modification to the lookup > algorithm that we consider each of these scenarios, and ensure there's > consensus on how they should each be addressed. > > To your specific question, I think it's desirable to address these cases > and it's worth discussing how the lookup algorithm can be modified to do so. > My opinion is that we should strive for simplicity and attempt to craft a proposal which would handle both scenarios 1 & 2 in a single mechanism. It would be even better if we can solve for case #3 with the same solution :-) --Kurt --000000000000ff749f05690a2c8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 4, 2018 at 11:19 AM, Peter M. Goldstein <peter.m.goldste= in@gmail.com> wrote:
Kurt,

As you note, this issue has been discus= sed on-list (and off) a few times.=C2=A0 And it definitely seems clear that= some sort of modification to the lookup algorithm would be required to add= ress the issue.

As part of that discussion, there = are a few scenarios that I think should be considered:

=
1. A domain which contains two public suffixes - i.e. abc.gov.uk, which contains the= public suffixes .gov.uk, .= uk.=C2=A0 In the proposed lookup scheme we'd be assuming that the manag= er of the registry for the "last" organizational domain represent= ed a controlling authority that should be able to impose DMARC policy on an= d view data for all subdomains.=C2=A0 I'm not sure whether that's t= rue in all cases, and that would have bearing on your proposal.
<= br>
2. A domain which contains three or more public suffixes - I'm not sure given the content of the public suffix list today tha= t you can actually construct one of these.=C2=A0 But from what I can see, t= here's nothing restricting a future update of the public suffix list th= at would allow such a domain.=C2=A0 If we update the lookup algorithm, we s= hould at least speak to this case - even if it's just to say we ignore = it.

This is quite easily accomp= lished, as are scenarios where there are public blocks embedded "down = chain" with intervening private domains in between. See the notes from= the DBOUND working group if you want to delve into these sorts of things.<= /div>

3.= New gTLDs - With the recent expansion of the list of TLDs, many of = the new TLDs are controlled by a single organization.=C2=A0 It may make sen= se to allow those gTLDs to define a DMARC record on the TLD itself or on so= me 'default' domain - both for administrative simplification and to= ensure against abuse.=C2=A0 It may be possible to handle this case outside= of a lookup change with wildcarded DNS records, but I know it's someth= ing that's come up in discussions with some of those TLD owners.=C2=A0= =C2=A0

I'd suggest that if we're going to = make a modification to the lookup algorithm that we consider each of these = scenarios, and ensure there's consensus on how they should each be addr= essed.

To your specific question, I think it's= desirable to address these cases and it's worth discussing how the loo= kup algorithm can be modified to do so.

My opinion is that we should strive for simplicity and attemp= t to craft a proposal which would handle both scenarios 1 & 2 in a sing= le mechanism. It would be even better if we can solve for case #3 with the = same solution :-)=C2=A0

--Kurt
=C2=A0=C2= =A0
--000000000000ff749f05690a2c8d-- From nobody Wed Apr 4 15:32:59 2018 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 11C9012D87E for ; Wed, 4 Apr 2018 15:32: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 Db4Iz16gaDkb for ; Wed, 4 Apr 2018 15:32:54 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 B80A612D86C for ; Wed, 4 Apr 2018 15:32:54 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v194-v6so800553itb.0 for ; Wed, 04 Apr 2018 15:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BqwYk5RxEyEHdBfjcnrrJgn4iOAAavncvZpeek3yz6w=; b=BPGQD2yXQG32yak+oC3LY8TrgG/r+NfQwiDgMCuTCJk7Xrgw63dOocFD6R6HSDAWnF 88Blj3VNYlqqnZZ2rDKlc843cp3txzbkdLenxR+kbSftAWlAdk6IwDJY0t6TYJ5CxwQc ce9IhFZy/l5m13CYFiks7v77Bc/k21goxv/KyILTasnP2vD2ZHg5/8Sac1YSmytoTKk7 0dSaTpwVTGbFjgkDVbeHV5e00zZKfYBV7XV7Yvhl7f5krrx5edmtfqUGLi7blTTpGqnW 2BTCNb+jHq/79nPbGlzopX6qXGtn0yluk9L/1M3m6P7pf+qHjL1mW61EJJ8sUhqFWH+6 8sfg== 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=BqwYk5RxEyEHdBfjcnrrJgn4iOAAavncvZpeek3yz6w=; b=gkW2BnXJTspmz6cpyKzqbQ3C79gjIcQejHSItSIUaxUHNCMYr4WSVXFXHIjfi7VwHE /H6pxy7QTNVdw1T7zqyIbnWZENjmRT44yc5CPwzsHzD4rpeTtrt2djZ7uVso5IcwQaRd XIB5rN5KYcZmeg3L0egCUFo2NuXQQrTRvDlht/gp83llWUCxVedJoruKVw+Y/dZid15b Ln2wozl/o9epvNRxhiLaz+YNKW4/jyoZLm22g67fugI9vZKmjzw/tRdzy53fK3277ZNT ds7ze3zB/pwZTHnZfp4x4+QIxmm3fJGVYmxYpPrMM0PmdDzLNv/uDe92oDlIEahEg+bQ Pe0Q== X-Gm-Message-State: AElRT7FxR5TmHpeDiPonRZvE6ST6CnxCY1wj1CRvtTq+l7NfOJErvI5i mYOgXHAlnN135UU0U6eGUjLmqPve X-Google-Smtp-Source: AIpwx4/3H1GIbjeody54ZsxHKzqwvq+dBKTsj30Vma3o1253auDhDwTi+DoTaZReYfufpvMGAUlilQ== X-Received: by 2002:a24:1c11:: with SMTP id c17-v6mr10922231itc.17.1522881173849; Wed, 04 Apr 2018 15:32:53 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id 124-v6sm3034315itw.25.2018.04.04.15.32.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 15:32:52 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id x77so21983651ioi.2 for ; Wed, 04 Apr 2018 15:32:52 -0700 (PDT) X-Received: by 10.107.132.197 with SMTP id o66mr17809952ioi.119.1522881171883; Wed, 04 Apr 2018 15:32:51 -0700 (PDT) MIME-Version: 1.0 References: <152164445995.7425.14367704532798414761.idtracker@ietfa.amsl.com> In-Reply-To: From: Brandon Long Date: Wed, 04 Apr 2018 22:32:40 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Kurt Andersen (b)" Cc: jgh@wizmail.org, dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113f0dec49de3b05690d6730" Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 22:32:58 -0000 --001a113f0dec49de3b05690d6730 Content-Type: text/plain; charset="UTF-8" Hmm, I guess this means the set of required/optional fields now stretches between the DKIM and ARC specs, eh? Is t the only one that's now optional? For Seal, I have i, a, s, d, b, cv (removed t based on this thread) For AMS, I have i, a, s, c, d, d, b, h, bh Brandon On Tue, Apr 3, 2018 at 4:05 PM Kurt Andersen (b) wrote: > Please implement -13, but there are almost no protocol changes between -6 > and -13. It's mostly editorial. We may have made some tags optional but if > Google wants 'em, it's probably best to include them, but that doesn't mean > you aren't implementing -13. > > --Kurt > > On Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris wrote: > >> On 21/03/18 15:18, Murray S. Kucherawy wrote: >> > On Wed, Mar 21, 2018 at 3:00 PM, wrote: >> > >> >> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt >> >> has been successfully submitted by Kurt Andersen and posted to the >> >> IETF repository. >> >> I see that Google are still listed as implementing Version 6 - >> and indeed, if you don't supply a t= tag in the AS (which is not >> required, as far as I can find in Version 13) then gmail.com says: >> >> "arc=fail (missing mandatory fields);" >> >> in it's A-R. >> >> Which should I implement? >> De-jure, or de-facto (and too-big-to-fail)? >> >> -- >> Cheers, >> Jeremy >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a113f0dec49de3b05690d6730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, I guess this means the set of required/optional field= s now stretches between the DKIM and ARC specs, eh?

Is t= the only one that's now optional?

For Seal, I= have i, a, s, d, b, cv (removed t based on this thread)
For AMS,= I have i, a, s, c, d, d, b, h, bh

Brandon

On Tue, Apr 3, 2018 at = 4:05 PM Kurt Andersen (b) <kboth@drk= urt.com> wrote:
Please implement -13, but there are almost no protocol changes between= -6 and -13. It's mostly editorial. We may have made some tags optional= but if Google wants 'em, it's probably best to include them, but t= hat doesn't mean you aren't implementing -13.

--= Kurt

O= n Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris <jgh@wizmail.org> wrote:
On 21/03/18 15:18, Murray = S. Kucherawy wrote:
> On Wed, Mar 21, 2018 at 3:00 PM, <internet-drafts@ietf.org> wrote:
>
>> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt
>> has been successfully submitted by Kurt Andersen and posted to the=
>> IETF repository.

I see that Google are still listed as implementing Version 6 -
and indeed, if you don't supply a t=3D tag in the AS (which is not
required, as far as I can find in Version 13) then gmail.com says:

=C2=A0 "arc=3Dfail (missing mandatory fields);"

in it's A-R.

Which should I implement?
De-jure, or de-facto (and too-big-to-fail)?

--
Cheers,
=C2=A0 Jeremy

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

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--001a113f0dec49de3b05690d6730-- From nobody Wed Apr 4 16:05:15 2018 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 2C7AC127909 for ; Wed, 4 Apr 2018 16:05:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 vobmz2luPlOR for ; Wed, 4 Apr 2018 16:05:12 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CAC126FB3 for ; Wed, 4 Apr 2018 16:05:12 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id r131so1532117wmb.2 for ; Wed, 04 Apr 2018 16:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3yetXm1pgXdi7BKNbW3SZrACqj5BIrNBxqXldKRlayU=; b=eYlm3u9GhYT6FT9yUwTiS6w7C6PYH5nECg/XicNgJjl1cI0QMHV6oCoWHe2xuCdT1j RKZsd6i296KSQKwnKnFODJfrr+IaJjglfOfp5tu/JY4iRT0BlflOvzdTDoMSFnqetdRv M1llin5vF8yPMSdeG2Qb/2QwF/ZIMfeic0mdg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3yetXm1pgXdi7BKNbW3SZrACqj5BIrNBxqXldKRlayU=; b=bc71djsZAXqcwcTNn374sKLqCVpptAJIt1NcILj1kkSF2+2dM02Av4UCQDjriNxYPw /J/hMu669QnopQMXrbWsmRMSb0uUtylUok6I5ZoeqhlmyQ+oE6AYsaXL4dYouT11IjHH rHneZZM4cD7MrKmyPpuy7sM909ae9IubytH0W6pyUz8jrk1S6duVzx5SOaToiAM7Zqsf r9FaPQn3zmg48EeXQlZEcP4ISphtLq5kIJk2PlKWVGhjM75BnehTkuKakBkgRcA9F5d9 rWN9ZC39sQo2bPqcom2EIrUPvzBmfrRcGw1nDellufJ7ssARKbNcII61RDr84LI+xFpv I8YQ== X-Gm-Message-State: ALQs6tCHGjGAPAnmuiyNqz1SD3i/wLZUjW4TTc8DfLELPoPzRoS/DBYf F9vpIh6py5+b3Vj5mt0mIMnE3FX4zdBvnKOE4iLAbPCT X-Google-Smtp-Source: AIpwx49PaS5VMW5IfOcBUDpjJRju1nZmvm0T/zDVeUGE00jmuUrs//Ya6m022o4JnMRg+eWxlTx0iCpxNAWrjEpZsZs= X-Received: by 10.80.177.234 with SMTP id n39mr691450edd.108.1522883110863; Wed, 04 Apr 2018 16:05:10 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Wed, 4 Apr 2018 16:05:10 -0700 (PDT) In-Reply-To: References: <152164445995.7425.14367704532798414761.idtracker@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Wed, 4 Apr 2018 16:05:10 -0700 X-Google-Sender-Auth: dioHcyCjv9Kdjs7njG0UEnrxJUc Message-ID: To: Brandon Long Cc: Jeremy Harris , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045c1f22db919605690ddaf2" Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 23:05:14 -0000 --f403045c1f22db919605690ddaf2 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 3:32 PM, Brandon Long wrote: > Hmm, I guess this means the set of required/optional fields now stretches > between the DKIM and ARC specs, eh? > > Is t the only one that's now optional? > > For Seal, I have i, a, s, d, b, cv (removed t based on this thread) > For AMS, I have i, a, s, c, d, d, b, h, bh > > Brandon > Looks like that was an unintended casualty of picking up more of the DKIM-based definitions when we restructured the ARC protocol between -06 and -07. At this point, I don't feel that it's critical to the evaluation of the ARC chain so making it optional seems reasonable. --Kurt --f403045c1f22db919605690ddaf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 4, 2018 at 3:32 PM, Brandon Long <blong@fiction.net>= wrote:
Hmm, I guess thi= s means the set of required/optional fields now stretches between the DKIM = and ARC specs, eh?

Is t the only one that's now opti= onal?

For Seal, I have i, a, s, d, b, cv (removed = t based on this thread)
For AMS, I have i, a, s, c, d, d, b, h, b= h

B= randon

Looks like= that was an unintended casualty of picking up more of the DKIM-based defin= itions when we restructured the ARC protocol between -06 and -07. At this p= oint, I don't feel that it's critical to the evaluation of the ARC = chain so making it optional seems reasonable.

--Ku= rt=C2=A0

--f403045c1f22db919605690ddaf2-- From nobody Thu Apr 5 02:18:14 2018 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 C17B6126DED for ; Thu, 5 Apr 2018 02:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 bWzDU2Lpwsof for ; Thu, 5 Apr 2018 02:18:11 -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 AF6DD126579 for ; Thu, 5 Apr 2018 02:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1522919888; bh=zrEKJnU42rSlLVWo08CxlGeXvFSonw7mTNAccHhHmgw=; l=1599; h=To:References:From:Date:In-Reply-To; b=B9vFRI056wzyzSMiGdh+QoLAJ423aiIIzH+DT68eKJ7Xnu2HO/gTI6+B/MaHIc+UY 7FIvTkpociK1askagBf0jbNoB26RE5kRFp/iam7M2eL6LUA+EZSqHElKdXTcscMRr7 TMWEGG4o4XSGcj+xpyJ5Pbp0EQf0cn2vUiwj2ptTKypq5N9C/FeM5qgNCoc4x 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; Thu, 05 Apr 2018 11:18:08 +0200 id 00000000005DC073.000000005AC5E9D0.000041D0 To: dmarc@ietf.org References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <07350e8b-23a5-e2d7-c15c-110966a2ffe3@tana.it> Date: Thu, 5 Apr 2018 11:18:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 09:18:13 -0000 On Wed 04/Apr/2018 20:19:20 +0200 Peter M. Goldstein wrote:  > > 1. *A domain which contains two public suffixes* - i.e. abc.gov.uk, which > contains the public suffixes .gov.uk, .uk. In the proposed lookup scheme > we'd be assuming that the manager of the registry for the "last" > organizational domain represented a controlling authority that should be > able to impose DMARC policy on and view data for all subdomains. Just to clarify, I have: $ psl --print-reg-domain mail.abc.gov.uk mail.abc.gov.uk: abc.gov.uk and $ psl --print-reg-domain mail.sub.qld.gov.au mail.sub.qld.gov.au: sub.qld.gov.au The method https://tools.ietf.org/html/rfc7489#section-3.2 defines just one Organizational Domain, so using the term "last" above is pleonastic. I reckon psl --print-reg-domain (at least in the above cases) matches that method well. If that's correct, I don't see how the txt record at _dmarc.qld.gov.au could ever have a chance of being discovered. > 3. *New gTLDs* [...] It may make sense to allow those gTLDs to define a > DMARC record on the TLD itself or on some 'default' domain - both for > administrative simplification and to ensure against abuse. I strongly disagree. If a domain owner --the target of a delegation, i.e. the one who controls the relevant subtree-- has to submit to a parent domain policy which provides for yielding reports about their private mail, then the parent domain is not a public registry, not in the commonly accepted meaning of the term "public". DMARC policies are not akin to abuse mailboxes, are they? Ale -- From nobody Thu Apr 5 06:08:33 2018 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 94F65127241 for ; Thu, 5 Apr 2018 06:08:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=BidbNKcc; dkim=pass (1024-bit key) header.d=yitter.info header.b=VjCtfnUH 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 HRcRChVufnCX for ; Thu, 5 Apr 2018 06:08:29 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C107D12751F for ; Thu, 5 Apr 2018 06:08:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 56ED0BECAD for ; Thu, 5 Apr 2018 13:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1522933678; bh=G9y+mZb7V5JU3pfFVcGTjlZKrvaL8DaNpdhSV5kdPmM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BidbNKcc2poR0g2gdSZ7P1vlMtA4C0c1A2K+rYjxXNrEeEUUkXBXjO3ME6PKMVHB8 +Z/OhSXmuoxOxKu7wvUIqORX/diFR0Fn3owsecHY6qm7lE/YuKGr87Dp8Jh/4cBPQJ MLxRlrAHfkA8NC3g+Ne3xFwjda+HZ6SE8JfxVmtY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtumzTZmdq2E for ; Thu, 5 Apr 2018 13:07:56 +0000 (UTC) Date: Thu, 5 Apr 2018 09:07:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1522933676; bh=G9y+mZb7V5JU3pfFVcGTjlZKrvaL8DaNpdhSV5kdPmM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=VjCtfnUHzvePa0iXKYol1EwC51X0m/eDQOgjLxv457Re8Iogt71uqaUX1L8NaKugY B+ueXLJ6tLicPeVHQ/5yPR5y7ZcZIm1bFtir8bTHct5TTCoXJ/hLSXcXQBSlJ5AqyP 2gn+ymPRbDNVkXMGopE1NFuBaBBlDMkI4WAm2eb0= From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 13:08:32 -0000 Hi, On Wed, Apr 04, 2018 at 11:19:20AM -0700, Peter M. Goldstein wrote: > it definitely seems clear that some sort of modification to the lookup > algorithm would be required to address the issue. Right. We attempted to specify some system that would sort this all out over in the DBOUND WG, but that WG failed because of disagreement about whether we cared about web-type (cross-site issues, cookies, &c.) problems or anti-spam (roughly, "parent's policy wins") issues. > 1. A domain which contains two public suffixes - i.e. abc.gov.uk, which > contains the public suffixes .gov.uk, .uk. > 2. A domain which contains three or more public suffixes - I'm not sure given > the content of the public suffix list today that you can actually construct one > of these. These are both a species of the same problem, yes. The solution so far has been to say that you're supposed to match the longest of the candidate set. There is a possible hitch because of non-terminals, which never have any real records in them but that might have subordinate things that are also public suffixes. Except for .jp (and I'm not sure there), I think nobody is doing that any more. Some of us argued that the system ought to accommodate such uses anyway, and others argued that we shouldn't solve any problem nobody has today (and tell people who later invent this problem, "Don't do that"). > 3. New gTLDs - With the recent expansion of the list of TLDs, many of the new > TLDs are controlled by a single organization.  It may make sense to allow those > gTLDs to define a DMARC record on the TLD itself or on some 'default' domain - > both for administrative simplification and to ensure against abuse. Do you mean this _across_ TLDs (e.g. the "variants" case such as differnet spellings of China depending on the writing system) or do you just mean that the top most label and everything flowing down from there is all under the same policy? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Apr 5 07:22:45 2018 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 ADC4512D88F for ; Thu, 5 Apr 2018 07:22:43 -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 B1bdt3sWxw-4 for ; Thu, 5 Apr 2018 07:22:41 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 7FB731205D3 for ; Thu, 5 Apr 2018 07:22:40 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id p53so28727642wrc.10 for ; Thu, 05 Apr 2018 07:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qb5jnREmwALeD2CQVmA2xriBi/RXT5MCPei4T0hQwPM=; b=tElu3BCjAXM4bLbn2vg3dSPeSBFsFVO8wP8St1CVipYf/Dr3zTTtv69LO1J0/i/PUb Vs1gihXFhRDTMhgES26hauK66qyfR+njjsS7UhYv8vYfcpzv8a5qt4EVxSH5PY3J/Lj4 MSSKCSTVn7xw0YL6VJ4ShH8R2j+1pxn+3LYwXYXfH31AxjjA88fXGfQpahvm+k1bs/J9 LO09QbD2ZbRrIhl38xN2iO4/VseAa29sset7gnjTEnNRnGqpKKc/YnKkH2qlpoFLpuYt XTixJqBcUr4QtLQ+byAcK5jr1iMMy+hkey6EPxqzjQ/YWaZ7EOwuPwLruDms6Bv4k8CL K9Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qb5jnREmwALeD2CQVmA2xriBi/RXT5MCPei4T0hQwPM=; b=tOxYtu4StY7e0fdHx11d9MAgB0hLk+EKMm0yPbpvj6M/xO2Wla7V5n+CLa/Y4YyZPU 7gzw8WlzoD1VOr29eyyKn4Ffs84v1vmYe1yt8mHQQXgsnSrNNcahYgwuQp1hlBoteFQK JzNttD4fi4k9BZZuC6I18K2B8sDQigESxkPm48bLZ9LO6w89eqDA7YHyaw1bd1evGIbW EpnIIZiZ4UCiH2kDnbZbzcapA7+ps+9wogeGfEazKpmBCOpw90oZs89ZbXDfE24H72Vd dSWs74aWw/iLU1h9T9eNnNb18zPd07GW5yRanHk5IJZq+XKyHcfhNmoRxrZAQn1nChXC CNfg== X-Gm-Message-State: ALQs6tDH4e2MpYVEUgaEIO49M/1ouJEeqq7Dau2hnSJE+ohM3dBURykb 0SaOOWqxyxKXC8X0uL+l9/MWQS3PrdCr4E9/TrqFx3na X-Google-Smtp-Source: AIpwx4+zSBUV66UYGqjZGjF75xQuSTlaXIbCT8JmEOZYQBXFgP17iz3PsYKD/C2e8UoOlU1yni/HuQetBCfCzRbYHI8= X-Received: by 2002:a19:730d:: with SMTP id o13-v6mr14122213lfc.88.1522938158951; Thu, 05 Apr 2018 07:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d013:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 07:22:37 -0700 (PDT) In-Reply-To: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> References: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> From: "Peter M. Goldstein" Date: Thu, 5 Apr 2018 07:22:37 -0700 Message-ID: To: Andrew Sullivan Cc: dmarc Content-Type: multipart/alternative; boundary="000000000000fab1aa05691aab1a" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 14:22:44 -0000 --000000000000fab1aa05691aab1a Content-Type: text/plain; charset="UTF-8" Hi, These are both a species of the same problem, yes. The solution so > far has been to say that you're supposed to match the longest of the > candidate set... Right. And the suggestion that Kurt made was to modify this to: 1. Check the domain itself 2. Check the longest of the organizational domain candidate set 3. Check the shortest of the organizational domain candidate set Which covers the case where that candidate set has cardinality 2 or less, but leaves some question about cases where the cardinality is 3 or more. I don't know how common the latter is - not sure if we have stats on that. Do you mean this _across_ TLDs (e.g. the "variants" case such as > differnet spellings of China depending on the writing system) or do > you just mean that the top most label and everything flowing down from > there is all under the same policy? The latter. To be more clear, there are now a significant number of TLDs that are managed exclusively by one entity (e.g. .microsoft, .google) as well as other TLDs that make specific guarantees around DMARC (e.g. .bank). In those cases it may make sense to give the registry owners some defined mechanism for imposing global DMARC policy across the TLD. This is especially important for organizational domain names that don't resolve for that TLD. So, for example, let's consider an email seemingly sent from support@iamareal.bank . A query to the domain iamareal.bank returns an NXDOMAIN, as does the a TXT query to the corresponding DMARC record _dmarc.iamareal.bank domain. So there's no DMARC policy in place. So a receiver may wind up delivering this email to the inbox, especially if it passes SPF and DKIM in an unaligned fashion. But to an end user it looks like this is an email from a '.bank' domain, which undermines the .bank TLDs goal of providing a higher trust set of domains. And it is therefore attractive to bad actors as a possible channel of abuse. The question is whether the DMARC lookup scheme should somehow address this issue. Alternately, we could simply say that this is a case that DMARC itself doesn't handle, and that the registry owner may choose to modify their DNS responses to ensure they always return a DMARC record for any organizational domain on that TLD. Best, Peter On Thu, Apr 5, 2018 at 6:07 AM, Andrew Sullivan wrote: > Hi, > > On Wed, Apr 04, 2018 at 11:19:20AM -0700, Peter M. Goldstein wrote: > > > it definitely seems clear that some sort of modification to the lookup > > algorithm would be required to address the issue. > > Right. We attempted to specify some system that would sort this all > out over in the DBOUND WG, but that WG failed because of disagreement > about whether we cared about web-type (cross-site issues, cookies, > &c.) problems or anti-spam (roughly, "parent's policy wins") issues. > > > 1. A domain which contains two public suffixes - i.e. abc.gov.uk, which > > contains the public suffixes .gov.uk, .uk. > > > 2. A domain which contains three or more public suffixes - I'm not sure > given > > the content of the public suffix list today that you can actually > construct one > > of these. > > These are both a species of the same problem, yes. The solution so > far has been to say that you're supposed to match the longest of the > candidate set. There is a possible hitch because of non-terminals, > which never have any real records in them but that might have > subordinate things that are also public suffixes. Except for .jp (and > I'm not sure there), I think nobody is doing that any more. Some of > us argued that the system ought to accommodate such uses anyway, and > others argued that we shouldn't solve any problem nobody has today > (and tell people who later invent this problem, "Don't do that"). > > > > 3. New gTLDs - With the recent expansion of the list of TLDs, many of > the new > > TLDs are controlled by a single organization. It may make sense to > allow those > > gTLDs to define a DMARC record on the TLD itself or on some 'default' > domain - > > both for administrative simplification and to ensure against abuse. > > Do you mean this _across_ TLDs (e.g. the "variants" case such as > differnet spellings of China depending on the writing system) or do > you just mean that the top most label and everything flowing down from > there is all under the same policy? > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000fab1aa05691aab1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

These are both a species of the sa= me problem, yes.=C2=A0 The solution so
= far has been to say that you're supposed to match the longest of thecandidate set...
=
Right.=C2=A0 And the suggestion that Kurt made was to modify this= to:

1. Check the domain itself
2. Check= the longest of the organizational domain candidate set
3. Check = the shortest of the organizational domain candidate set

Which covers the case where that candidate set has cardinality 2 or l= ess, but leaves some question about cases where the cardinality is 3 or mor= e.=C2=A0 I don't know how common the latter is - not sure if we have st= ats on that.

Do you mean this _across_ TLDs (e.g.= the "variants" case such as
= differnet spellings of China depending on the writing system) or do
you just mean that the top most label and ever= ything flowing down from
there is all u= nder the same policy?

The= latter.

To be more clear, there are now a significant number of TLDs that are ma= naged exclusively by one entity (e.g. .microsoft, .google) as well as other= TLDs that make specific guarantees around DMARC (e.g. .bank). In those cas= es it may make sense to give the registry owners some defined mechanism for= imposing global DMARC policy across the TLD.=C2=A0 This is especially impo= rtant for organizational domain names that don't resolve for that TLD.<= /div>

So, fo= r example, let's consider an email seemingly sent from support@iamareal= .bank .=C2=A0 A query to the domain iamareal.bank returns an NXDOMAIN, as d= oes the a TXT query to the corresponding DMARC record _dmarc.iamareal.bank = domain.=C2=A0 So there's no DMARC policy in place.=C2=A0 So a receiver = may wind up delivering this email to the inbox, especially if it passes SPF= and DKIM in an unaligned fashion.

But to an end user it looks like this is an em= ail from a '.bank' domain, which undermines the .bank TLDs goal of = providing a higher trust set of domains.=C2=A0 And it is therefore attracti= ve to bad actors as a possible channel of abuse.

The question is whether the DMAR= C lookup scheme should somehow address this issue.=C2=A0 Alternately, we co= uld simply say that this is a case that DMARC itself doesn't handle, an= d that the registry owner may choose to modify their DNS responses to ensur= e they always return a DMARC record for any organizational domain on that T= LD.

Be= st,

Pe= ter

On Thu, = Apr 5, 2018 at 6:07 AM, Andrew Sullivan <ajs@anvilwalrusden.com&g= t; wrote:
Hi,

On Wed, Apr 04, 2018 at 11:19:20AM -0700, Peter M. Goldstein wrote:

> it definitely seems clear that some sort of modification to the lookup=
> algorithm would be required to address the issue.

Right.=C2=A0 We attempted to specify some system that would sort thi= s all
out over in the DBOUND WG, but that WG failed because of disagreement
about whether we cared about web-type (cross-site issues, cookies,
&c.) problems or anti-spam (roughly, "parent's policy wins&quo= t;) issues.

> 1. A domain which contains two public suffixes - i.e. abc.gov.uk, which > contains the public suffixes .gov.uk, .uk.

> 2. A domain which contains three or more publi= c suffixes - I'm not sure given
> the content of the public suffix list today that you can actually cons= truct one
> of these.

These are both a species of the same problem, yes.=C2=A0 The solutio= n so
far has been to say that you're supposed to match the longest of the candidate set.=C2=A0 There is a possible hitch because of non-terminals, which never have any real records in them but that might have
subordinate things that are also public suffixes.=C2=A0 Except for .jp (and=
I'm not sure there), I think nobody is doing that any more.=C2=A0 Some = of
us argued that the system ought to accommodate such uses anyway, and
others argued that we shouldn't solve any problem nobody has today
(and tell people who later invent this problem, "Don't do that&quo= t;).


> 3. New gTLDs - With the recent expansion of the list of TLDs, many of = the new
> TLDs are controlled by a single organization.=C2=A0 It may make sense = to allow those
> gTLDs to define a DMARC record on the TLD itself or on some 'defau= lt' domain -
> both for administrative simplification and to ensure against abuse.
Do you mean this _across_ TLDs (e.g. the "variants" case s= uch as
differnet spellings of China depending on the writing system) or do
you just mean that the top most label and everything flowing down from
there is all under the same policy?

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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

--000000000000fab1aa05691aab1a-- From nobody Thu Apr 5 08:19:26 2018 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 3AD3012DB6E for ; Thu, 5 Apr 2018 08:19:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 PWUQQXYKumbS for ; Thu, 5 Apr 2018 08:19:16 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 7908A12DA46 for ; Thu, 5 Apr 2018 08:19:12 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id g8so6704991wmd.2 for ; Thu, 05 Apr 2018 08:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UdRwsHa6rBsizc5odWZixllJvvWpZuyDOaA7UnXZ6ak=; b=Co1sTKgXX0P8Xdtv8UPsAwkcY6W4vP9dYG0tlBofAgU99P2/GbAFcN+zbWCKIYPALS FwUaWwYJcn6Ptho/nuCTdTZ01GGntZ/mYKLWt032kVFpVeN79avZHBU6sjqoxbcYcyn1 COI8KDXewb1Ty5PE2ovyzaTyw1hEXsJ96H5EI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UdRwsHa6rBsizc5odWZixllJvvWpZuyDOaA7UnXZ6ak=; b=nKV7M4WR3YlRkDY3x2YZovYBJ85oYYognRDii++3IdUn95zsGFu+hN84UL/F4SzyfG J5u6Qq66RWHF1tpfjwd3ACNz273ch1aT1UWTU3UCCqPg/DzbR1RZVa383PvtFuSUCIDl CdhP1uKRs/yGuBLbXmo6PygsYcwnFFV8zv4NAltFjpymoa9zkZu3kJRgnTznu8fjwrUd afxGcOPf/Itnd0njSLXZQELz8mqBMXe/1FxS83ASjJv1R/WobMGj6S6jgyADSt9PYCuF 9k5bySjLtp8gxh8Y+WlZP59sDSxjwgXZTihFTQIOuCK4aMl17AWdZTAdQVbUtHoRE7gT g9gA== X-Gm-Message-State: ALQs6tC5wHeo5xknyDG2AWsfx8aRyZe2ShsGzMeubO5DazMShWxW8Veh KhJ/MIQ5FTCY46EgNopASCuTcnbFGvrYabcZJLZNOIKd X-Google-Smtp-Source: AIpwx486g0DCFpB6bb78a3g21DWBGxhbERSRdNK10Q0yIbZFBSzkQNdhGDb0Dg8UO5JGzl/eG32+5FgISTPN2AlT8sw= X-Received: by 10.80.146.234 with SMTP id l39mr3317216eda.125.1522941550701; Thu, 05 Apr 2018 08:19:10 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Thu, 5 Apr 2018 08:19:10 -0700 (PDT) In-Reply-To: References: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> From: "Kurt Andersen (b)" Date: Thu, 5 Apr 2018 08:19:10 -0700 X-Google-Sender-Auth: mT-AbzauxhhhC6EXobOsy-Y8zPQ Message-ID: To: "Peter M. Goldstein" Cc: Andrew Sullivan , dmarc Content-Type: multipart/alternative; boundary="f403045c1f3424be9e05691b7603" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 15:19:21 -0000 --f403045c1f3424be9e05691b7603 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein < peter.m.goldstein@gmail.com> wrote: > Hi, > > These are both a species of the same problem, yes. The solution so >> far has been to say that you're supposed to match the longest of the >> candidate set... > > > Right. And the suggestion that Kurt made was to modify this to: > > 1. Check the domain itself > 2. Check the longest of the organizational domain candidate set > 3. Check the shortest of the organizational domain candidate set > Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC spec itself): 2. (from 3.2 step 3) "search the PSL for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". / (step 4) Construct a new DNS domain name using the name matched form the PSL and prefixing to it the "x+1"th label"...[this] is the org domain. 3. Check the name created from the "x" labels determined in step 2 (hence my designation as "org-1"). These are not the same as "longest" and "shortest" names from the org domain candidate set unless the psl code follows that specified construction algorithm. Which covers the case where that candidate set has cardinality 2 or less, > but leaves some question about cases where the cardinality is 3 or more. I > don't know how common the latter is - not sure if we have stats on that. > I still don't know why the cardinality matters with the approach I've proposed. Do you mean this _across_ TLDs (e.g. the "variants" case such as >> differnet spellings of China depending on the writing system) or do >> you just mean that the top most label and everything flowing down from >> there is all under the same policy? > > > The latter. > > To be more clear, there are now a significant number of TLDs that are > managed exclusively by one entity (e.g. .microsoft, .google) as well as > other TLDs that make specific guarantees around DMARC (e.g. .bank). In > those cases it may make sense to give the registry owners some defined > mechanism for imposing global DMARC policy across the TLD. This is > especially important for organizational domain names that don't resolve for > that TLD. > > So, for example, let's consider an email seemingly sent from > support@iamareal..bank . A query to the domain iamareal.bank returns an > NXDOMAIN, as does the a TXT query to the corresponding DMARC record > _dmarc.iamareal.bank domain. So there's no DMARC policy in place. So a > receiver may wind up delivering this email to the inbox, especially if it > passes SPF and DKIM in an unaligned fashion. > If .bank, i.e. "1", is the largest number of labels found in the PSL (step 2), why would this approach not protect NXDOMAINs under .bank? --Kurt --f403045c1f3424be9e05691b7603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein <peter.m.goldstei= n@gmail.com> wrote:
Hi,

These are both a species= of the same problem, yes.=C2=A0 The solution so
far has been to say that you're supposed to match the longest= of the
candidate set...<= /blockquote>

Right.=C2=A0 And the suggestion that Kurt made w= as to modify this to:

1. Check the domain itself
2. Check the longest of the organizational domain candidate set
3. Check the shortest of the organizational domain candidate set

Not quite. Steps 2 & 3 would = be (adapted from the language of the DMARC spec itself):

2.=C2=A0 (from 3.2 step 3) "search the PSL for the name that ma= tches the largest number of labels found in the subject DNS domain. Let tha= t number be "x". / (step 4) Construct a new DNS domain name using= the name matched form the PSL and prefixing to it the "x+1"th la= bel"...[this] is the org domain.

3. Check the= name created from the "x" labels determined in step 2 (hence my = designation as "org-1").

These are not t= he same as "longest" and "shortest" names from the org = domain candidate set unless the psl code follows that specified constructio= n algorithm.

Which covers the case where that candidate set has cardinality 2= or less, but leaves some question about cases where the cardinality is 3 o= r more.=C2=A0 I don't know how common the latter is - not sure if we ha= ve stats on that.

I still d= on't know why the cardinality matters with the approach I've propos= ed.=C2=A0

= Do you mean this _across_ TLDs (e.g. the "va= riants" case such as
differnet spe= llings of China depending on the writing system) or do
you just mean that the top most label and everything flowin= g down from
there is all under the same= policy?

The latte= r.

To = be more clear, there are now a significant number of TLDs that are managed = exclusively by one entity (e.g. .microsoft, .google) as well as other TLDs = that make specific guarantees around DMARC (e.g. .bank). In those cases it = may make sense to give the registry owners some defined mechanism for impos= ing global DMARC policy across the TLD.=C2=A0 This is especially important = for organizational domain names that don't resolve for that TLD.
<= div class=3D"gmail_extra">
So, for exam= ple, let's consider an email seemingly sent from support@iamareal..bank= .=C2=A0 A query to the domain iamareal.bank returns an NXDOMAIN, as does t= he a TXT query to the corresponding DMARC record _dmarc.iamareal.bank domai= n.=C2=A0 So there's no DMARC policy in place.=C2=A0 So a receiver may w= ind up delivering this email to the inbox, especially if it passes SPF and = DKIM in an unaligned fashion.

=
If .bank, i.e. "1", is the largest number of labels found in= the PSL (step 2), why would this approach not protect NXDOMAINs under .ban= k?

--Kurt=C2=A0

--f403045c1f3424be9e05691b7603-- From nobody Thu Apr 5 08:46:12 2018 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 483DC12D87D for ; Thu, 5 Apr 2018 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 CNkn1SrrQTNz for ; Thu, 5 Apr 2018 08:46:08 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4523012D574 for ; Thu, 5 Apr 2018 08:46:08 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id x4so8380287wmh.5 for ; Thu, 05 Apr 2018 08:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oRVPTn11eqAR/8u3EHDFkQz3yLRjRYKiPrBWBjhTIXE=; b=AFY/QwCMmjr0rHDOc7EcIcU2VDN9Vchtn43j7THq3QLtZ7o8w/+ryd7n0/4TtIom3w cM75PUFjYYbdL1b79cdXxpiq6rzh3j4m6Lhj8OV3rNDPbGGL0rCfK/i/qadolpvPgA52 iwoDGltWoyova2VDJQJLLwgDDCk+pl9LqnresNGMhu7g58cjAVZTqLYISOEqAn0ekbpE ZkM9oSULxKd4oSOq899sNQKOcOJAuobv5C5BoR32HMHlYmuSmTs/KljtWEE6YJK47qHx jRZo+MNUnSqMBeO8P/YMk6GpmlBvXJxi9jjl291K43KpCL4hJx6I2Ero4iLjU/5GcA+e xLEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oRVPTn11eqAR/8u3EHDFkQz3yLRjRYKiPrBWBjhTIXE=; b=TMpe6qAd741mzWkZkt2nQBk4AuuidGrxEj3nlYF26i7WB66vxzL1X6w9Dcm++JVSL8 ZSQI7cin8c3GUEsQfubXyexPJFtyX4JXSohZ2neHDKS4kCGd4t8A15BD63mvR0xaB7bG Cc/Vc+8JnivYzZ2bkBWjdbTVPVsfcnP4h+QTzGzQxSLyVC82+Z7XtQEm0PgYVD0z0Eia YmI8dBE7Y2iIEmMyXiFVgvCV0rJ3D/2Yi1xZVWc3HNHzQsTR+IgL3TC2bEWjpzxAsrgt F95IzxV01olNfao/RaLtzA3Vhdg9khwz2FlrrbbYW7KNgSDUP4x/+C5jO+7cjWquXkaG bsOA== X-Gm-Message-State: ALQs6tCzsKLRdT6BLyZoMiIxpC+ZheHjjDQNrO5TJEOuINdQpfxm4M/J +7H2CkQQNF3NTlat1nhBCoQT+JEwYuGP6ypFhuhc5QHY X-Google-Smtp-Source: AIpwx4/fCM4fmmJBxkFFUg64RgkYVWgZAB50a/pG3TvbHCW0ThTU8+eaUAqWlR6/4oBSpLyPPcZTckddhh12HXEGy/0= X-Received: by 10.46.156.68 with SMTP id t4mr6177843ljj.86.1522943166737; Thu, 05 Apr 2018 08:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d013:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 08:46:06 -0700 (PDT) In-Reply-To: References: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> From: "Peter M. Goldstein" Date: Thu, 5 Apr 2018 08:46:06 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Andrew Sullivan , dmarc Content-Type: multipart/alternative; boundary="f4f5e80eff9077709805691bd688" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 15:46:11 -0000 --f4f5e80eff9077709805691bd688 Content-Type: text/plain; charset="UTF-8" Kurt, Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC > spec itself): > 2. (from 3.2 step 3) "search the PSL for the name that matches the > largest number of labels found in the subject DNS domain. Let that number > be "x". / (step 4) Construct a new DNS domain name using the name matched > form the PSL and prefixing to it the "x+1"th label"...[this] is the org > domain. > 3. Check the name created from the "x" labels determined in step 2 (hence > my designation as "org-1"). > These are not the same as "longest" and "shortest" names from the org > domain candidate set unless the psl code follows that specified > construction algorithm. Ah, I misunderstood the proposal. I viewed your '-1' as subtracting an index against the PSL set, not subtracting an actual label from the organizational domain. I'm also a little confused by terminology - "org-1" above is just the largest number of labels entry on the PSL, isn't it? In that case, yes it would address point #3, but would also potentially introduce problems for the county code TLDs (does a country-level registrar have the right to dictate policy for all domains in the country?) and some of the non-sponsored generics (.com, .edu, .org, etc.) The cardinality is still a potential issue, because you may want the DMARC management to devolve to the most general authority in the tree. But as I said, it's easy enough to state "DMARC doesn't handle that case" if it's not an effective abuse vector or a significant management problem. Best, Peter On Thu, Apr 5, 2018 at 8:19 AM, Kurt Andersen (b) wrote: > On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein < > peter.m.goldstein@gmail.com> wrote: > >> Hi, >> >> These are both a species of the same problem, yes. The solution so >>> far has been to say that you're supposed to match the longest of the >>> candidate set... >> >> >> Right. And the suggestion that Kurt made was to modify this to: >> >> 1. Check the domain itself >> 2. Check the longest of the organizational domain candidate set >> 3. Check the shortest of the organizational domain candidate set >> > > Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC > spec itself): > > 2. (from 3.2 step 3) "search the PSL for the name that matches the > largest number of labels found in the subject DNS domain. Let that number > be "x". / (step 4) Construct a new DNS domain name using the name matched > form the PSL and prefixing to it the "x+1"th label"...[this] is the org > domain. > > 3. Check the name created from the "x" labels determined in step 2 (hence > my designation as "org-1"). > > These are not the same as "longest" and "shortest" names from the org > domain candidate set unless the psl code follows that specified > construction algorithm. > > Which covers the case where that candidate set has cardinality 2 or less, >> but leaves some question about cases where the cardinality is 3 or more. I >> don't know how common the latter is - not sure if we have stats on that. >> > > I still don't know why the cardinality matters with the approach I've > proposed. > > Do you mean this _across_ TLDs (e.g. the "variants" case such as >>> differnet spellings of China depending on the writing system) or do >>> you just mean that the top most label and everything flowing down from >>> there is all under the same policy? >> >> >> The latter. >> >> To be more clear, there are now a significant number of TLDs that are >> managed exclusively by one entity (e.g. .microsoft, .google) as well as >> other TLDs that make specific guarantees around DMARC (e.g. .bank). In >> those cases it may make sense to give the registry owners some defined >> mechanism for imposing global DMARC policy across the TLD. This is >> especially important for organizational domain names that don't resolve for >> that TLD. >> >> So, for example, let's consider an email seemingly sent from >> support@iamareal..bank . A query to the domain iamareal.bank returns an >> NXDOMAIN, as does the a TXT query to the corresponding DMARC record >> _dmarc.iamareal.bank domain. So there's no DMARC policy in place. So a >> receiver may wind up delivering this email to the inbox, especially if it >> passes SPF and DKIM in an unaligned fashion. >> > > If .bank, i.e. "1", is the largest number of labels found in the PSL (step > 2), why would this approach not protect NXDOMAINs under .bank? > > --Kurt > > --f4f5e80eff9077709805691bd688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kurt,

Not quite. Steps 2 & 3 would be (adapted from the language= of the DMARC spec itself):
2.=C2=A0 (from 3.2 step 3) "search the = PSL for the name that matches the largest number of labels found in the sub= ject DNS domain. Let that number be "x". / (step 4) Construct a n= ew DNS domain name using the name matched form the PSL and prefixing to it = the "x+1"th label"...[this] is the org domain.
3. Check t= he name created from the "x" labels determined in step 2 (hence m= y designation as "org-1").
These are not the same as "lon= gest" and "shortest" names from the org domain candidate set= unless the psl code follows that specified construction algorithm.
Ah, I misunderstood the proposal.=C2=A0 I viewed your '-1= ' as subtracting an index against the PSL set, not subtracting an actua= l label from the organizational domain.=C2=A0=C2=A0

I'm also a little confused by terminology - "org-1" above i= s just the largest number of labels entry on the PSL, isn't it?=C2=A0= =C2=A0

In that case, yes it would address point #3= , but would also potentially introduce problems for the county code TLDs (d= oes a country-level registrar have the right to dictate policy for all doma= ins in the country?) and some of the non-sponsored generics (.com, .edu, .o= rg, etc.)

The cardinality is still a potential iss= ue, because you may want the DMARC management to devolve to the most genera= l authority in the tree.=C2=A0 But as I said, it's easy enough to state= "DMARC doesn't handle that case" if it's not an effectiv= e abuse vector or a significant management problem.

Best,

Peter


On Thu, Apr 5, 2018 at 8:19= AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Thu, Apr 5, 2018 at 7:22 AM, Peter M.= Goldstein <peter.m.goldstein@gmail.com> wrote:
Hi,

These are both a species of the same problem, yes.=C2=A0 The solution s= o
far has been to say that you're s= upposed to match the longest of the
candidate set...

Right.=C2=A0 And the= suggestion that Kurt made was to modify this to:

= 1. Check the domain itself
2. Check the longest of the organizati= onal domain candidate set
3. Check the shortest of the organizati= onal domain candidate set

Not quite. Steps 2 & 3 would be (adapted from the language of the DMA= RC spec itself):

2.=C2=A0 (from 3.2 step 3) "= search the PSL for the name that matches the largest number of labels found= in the subject DNS domain. Let that number be "x". / (step 4) Co= nstruct a new DNS domain name using the name matched form the PSL and prefi= xing to it the "x+1"th label"...[this] is the org domain.

3. Check the name created from the "x" lab= els determined in step 2 (hence my designation as "org-1").
=

These are not the same as "longest" and "= ;shortest" names from the org domain candidate set unless the psl code= follows that specified construction algorithm.
=
Which covers= the case where that candidate set has cardinality 2 or less, but leaves so= me question about cases where the cardinality is 3 or more.=C2=A0 I don'= ;t know how common the latter is - not sure if we have stats on that.

I still don't know wh= y the cardinality matters with the approach I've proposed.=C2=A0
<= div>
Do you mean this _across_ TLDs (e.g. the "variants&quo= t; case such as
differnet spellings of = China depending on the writing system) or do
you just mean that the top most label and everything flowing down fro= m
there is all under the same policy?

The latter.

To be more cl= ear, there are now a significant number of TLDs that are managed exclusivel= y by one entity (e.g. .microsoft, .google) as well as other TLDs that make = specific guarantees around DMARC (e.g. .bank). In those cases it may make s= ense to give the registry owners some defined mechanism for imposing global= DMARC policy across the TLD.=C2=A0 This is especially important for organi= zational domain names that don't resolve for that TLD.

So, for exampl= e, let's consider an email seemingly sent from support@iamareal..bank .= =C2=A0 A query to the domain iamareal.bank returns an NXDOMAIN, as does the= a TXT query to the corresponding DMARC record _dmarc.iamareal.bank domain.= =C2=A0 So there's no DMARC policy in place.=C2=A0 So a receiver may win= d up delivering this email to the inbox, especially if it passes SPF and DK= IM in an unaligned fashion.

If .bank, i.e. "1", is the largest number of labels found in t= he PSL (step 2), why would this approach not protect NXDOMAINs under .bank?=

--= Kurt=C2=A0


--f4f5e80eff9077709805691bd688-- From nobody Thu Apr 5 10:35:30 2018 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 D0C9612DA48 for ; Thu, 5 Apr 2018 10:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 THug4NvBGnAV for ; Thu, 5 Apr 2018 10:35:27 -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 EA433124D6C for ; Thu, 5 Apr 2018 10:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1522949724; bh=h3rZpAOE1tWrBc3dffdTWCt0LPVOhUkKSYxqvkKhDcU=; l=1775; h=To:References:From:Date:In-Reply-To; b=A08LzGTF4+M8J6PUabMt8xSfy4Os4CCAXgz2KWJKOPL8pgm+7DpaAHCr6aqMYuYaK H4ARGQBfSZ71Erv+6d+dUkrrXAFc9QPG7rcUEwbzZDR6Mtxtg9oirplAys2ylpSPIm ymvROnYbICfQc+dGCVGjOQVx0/BdQ+uNrhqlJpl9eW9Qy+0pqfMpyUQWRrur4 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; Thu, 05 Apr 2018 19:35:24 +0200 id 00000000005DC02A.000000005AC65E5C.00007658 To: dmarc@ietf.org References: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <3ef35136-71ca-d95a-80b0-60ecfc5f0e16@tana.it> Date: Thu, 5 Apr 2018 19:35:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 17:35:29 -0000 On Thu 05/Apr/2018 17:19:10 +0200 Kurt Andersen (b) wrote:  > On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein wrote: > >>> Hi, >>> >>> These are both a species of the same problem, yes. The solution so >>> far has been to say that you're supposed to match the longest of the >>> candidate set... >> >> >> Right. And the suggestion that Kurt made was to modify this to: >> >> 1. Check the domain itself >> 2. Check the longest of the organizational domain candidate set >> 3. Check the shortest of the organizational domain candidate set >> > > Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC > spec itself): > > 2. (from 3.2 step 3) "search the PSL for the name that matches the largest > number of labels found in the subject DNS domain. Let that number be "x". / > (step 4) Construct a new DNS domain name using the name matched form the > PSL and prefixing to it the "x+1"th label"...[this] is the org domain. > > 3. Check the name created from the "x" labels determined in step 2 (hence > my designation as "org-1"). > > These are not the same as "longest" and "shortest" names from the org > domain candidate set unless the psl code follows that specified > construction algorithm. FWIW, here's the wording of the PSL(1) man page: --print-unreg-domain Returned data: the longest public suffix part for each domain. --print-reg-domain Returned data: the shortest private suffix part for each domain. [...] COPYRIGHT libpsl and `psl' are copyright © 2014-2016 Tim Ruehsen under an MIT- style License. This documentation was written by Daniel Kahn Gillmor for the Debian project, but may be used by others under the same license as libpsl itself. psl 0.13.0 July 2016 PSL(1) -- From nobody Thu Apr 5 10:51:28 2018 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 765C612E039 for ; Thu, 5 Apr 2018 10:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dTGUSGBqGtAh for ; Thu, 5 Apr 2018 10:51:24 -0700 (PDT) Received: from zimbra1.uniregistry.com (zimbra1.uniregistry.com [162.221.214.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221C512DDD2 for ; Thu, 5 Apr 2018 10:51:24 -0700 (PDT) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTPS id BA77A241243; Thu, 5 Apr 2018 17:51:22 +0000 (UTC) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTPS id 6A844241038; Thu, 5 Apr 2018 17:51:22 +0000 (UTC) Received: from [64.96.166.230] (unknown [64.96.166.230]) by zimbra1.uniregistry.com (Postfix) with ESMTPSA id CCF5B241024; Thu, 5 Apr 2018 17:51:21 +0000 (UTC) From: "Luis E. =?utf-8?q?Mu=C3=B1oz?=" To: "Peter M. Goldstein" Cc: "Kurt Andersen" , dmarc Date: Thu, 05 Apr 2018 10:51:18 -0700 X-Mailer: MailMate (1.11r5462) Message-ID: <29ECE2D2-6AFD-4E78-95CB-FA770E790BCC@uniregistry.link> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C33DF967-F929-4585-A9A0-2C92F119561A_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 17:51:26 -0000 --=_MailMate_C33DF967-F929-4585-A9A0-2C92F119561A_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4 Apr 2018, at 11:19, Peter M. Goldstein wrote: > 3. *New gTLDs* - With the recent expansion of the list of TLDs, many > of the > new TLDs are controlled by a single organization. It may make sense > to > allow those gTLDs to define a DMARC record on the TLD itself or on > some > 'default' domain - both for administrative simplification and to > ensure > against abuse. It may be possible to handle this case outside of a > lookup > change with wildcarded DNS records, but I know it's something that's > come > up in discussions with some of those TLD owners. Keep in mind that gTLD operators are restricted in the records they can include in their respective DNS zones. This would require the use of a well known name specifically for this purpose. Best regards Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 lem@uniregistry.link --=_MailMate_C33DF967-F929-4585-A9A0-2C92F119561A_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 4 Apr 2018, at 11:19, Peter M. Goldstein wrote:

3. *New gTLDs* - With the recent expansion of the list of TLDs, many= of the
new TLDs are controlled by a single organization. It may make sense to allow those gTLDs to define a DMARC record on the TLD itself or on some 'default' domain - both for administrative simplification and to ensure against abuse. It may be possible to handle this case outside of a looku= p
change with wildcarded DNS records, but I know it's something that's come=
up in discussions with some of those TLD owners.

Keep in mind that gTLD operators are restricted in the re= cords they can include in their respective DNS zones. This would require = the use of a well known name specifically for this purpose.

Best regards

Luis Mu=C3=B1oz
Director, Registry Operations

http://www.unire= gistry.link/
2161 San Joaquin Hills Road
Newport Beach, CA 92660
lem@uniregistry.link

--=_MailMate_C33DF967-F929-4585-A9A0-2C92F119561A_=-- From nobody Thu Apr 5 13:05:00 2018 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 A409F12D779 for ; Thu, 5 Apr 2018 13:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sFvHI53EMS28 for ; Thu, 5 Apr 2018 13:04:57 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1393012D77B for ; Thu, 5 Apr 2018 13:04:56 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Thu, 5 Apr 2018 16:04:55 -0400 From: "MH Michael Hammer (5304)" To: =?utf-8?B?THVpcyBFLiBNdcOxb3o=?= , "Peter M. Goldstein" CC: dmarc , Kurt Andersen Thread-Topic: [dmarc-ietf] inheritance and public suffix list Thread-Index: AQHTzCuEasjk2KpRUkqY3B0drfXp2KPxFXWAgAAOooCAAAmGAIABioAA///h9PA= Date: Thu, 5 Apr 2018 20:04:55 +0000 Message-ID: References: <29ECE2D2-6AFD-4E78-95CB-FA770E790BCC@uniregistry.link> In-Reply-To: <29ECE2D2-6AFD-4E78-95CB-FA770E790BCC@uniregistry.link> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.6.199] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES533.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 4/5/2018 3:38:00 PM x-kse-dlp-scaninfo: Skipped Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B05373FE99FUSCLES544agnaam_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 20:05:00 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B05373FE99FUSCLES544agnaam_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBfZG1hcmMgYXMgYSBUWFQgcmVjb3JkIGlzIGZhaXJseSB3ZWxsIGtub3duLiBJcyB0 aGVyZSBhbnl0aGluZyB0aGF0IHdvdWxkIHNwZWNpZmljYWxseSBwcm9oaWJpdCB0aGlzPw0KDQpN aWtlDQoNCkZyb206IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEx1aXMgRS4gTXXDsW96DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMTo1 MSBQTQ0KVG86IFBldGVyIE0uIEdvbGRzdGVpbg0KQ2M6IGRtYXJjOyBLdXJ0IEFuZGVyc2VuDQpT dWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIGluaGVyaXRhbmNlIGFuZCBwdWJsaWMgc3VmZml4IGxp c3QNCg0KDQpPbiA0IEFwciAyMDE4LCBhdCAxMToxOSwgUGV0ZXIgTS4gR29sZHN0ZWluIHdyb3Rl Og0KDQozLiAqTmV3IGdUTERzKiAtIFdpdGggdGhlIHJlY2VudCBleHBhbnNpb24gb2YgdGhlIGxp c3Qgb2YgVExEcywgbWFueSBvZiB0aGUNCm5ldyBUTERzIGFyZSBjb250cm9sbGVkIGJ5IGEgc2lu Z2xlIG9yZ2FuaXphdGlvbi4gSXQgbWF5IG1ha2Ugc2Vuc2UgdG8NCmFsbG93IHRob3NlIGdUTERz IHRvIGRlZmluZSBhIERNQVJDIHJlY29yZCBvbiB0aGUgVExEIGl0c2VsZiBvciBvbiBzb21lDQon ZGVmYXVsdCcgZG9tYWluIC0gYm90aCBmb3IgYWRtaW5pc3RyYXRpdmUgc2ltcGxpZmljYXRpb24g YW5kIHRvIGVuc3VyZQ0KYWdhaW5zdCBhYnVzZS4gSXQgbWF5IGJlIHBvc3NpYmxlIHRvIGhhbmRs ZSB0aGlzIGNhc2Ugb3V0c2lkZSBvZiBhIGxvb2t1cA0KY2hhbmdlIHdpdGggd2lsZGNhcmRlZCBE TlMgcmVjb3JkcywgYnV0IEkga25vdyBpdCdzIHNvbWV0aGluZyB0aGF0J3MgY29tZQ0KdXAgaW4g ZGlzY3Vzc2lvbnMgd2l0aCBzb21lIG9mIHRob3NlIFRMRCBvd25lcnMuDQoNCktlZXAgaW4gbWlu ZCB0aGF0IGdUTEQgb3BlcmF0b3JzIGFyZSByZXN0cmljdGVkIGluIHRoZSByZWNvcmRzIHRoZXkg Y2FuIGluY2x1ZGUgaW4gdGhlaXIgcmVzcGVjdGl2ZSBETlMgem9uZXMuIFRoaXMgd291bGQgcmVx dWlyZSB0aGUgdXNlIG9mIGEgd2VsbCBrbm93biBuYW1lIHNwZWNpZmljYWxseSBmb3IgdGhpcyBw dXJwb3NlLg0KDQpCZXN0IHJlZ2FyZHMNCg0KTHVpcyBNdcOxb3oNCkRpcmVjdG9yLCBSZWdpc3Ry eSBPcGVyYXRpb25zDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmh0dHA6 Ly93d3cudW5pcmVnaXN0cnkubGluay88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3d3dy51bmlyZWdpc3RyeS5saW5rXyZkPUR3TUZhUSZjPXg3QjZi amotbGJXNy1BNWR1U3d0VlpCd2RQVnNJRUpieGw5NnVsMEhpWFEmcj1KYjNBaU1oa3B3NGJWQUhu Z2hENVZBJm09LXRCZW0yNkFqVDVONC1PMURiSGZocTUxekpxQXYwRURzS2RVd0hibTdMUSZzPWo4 OFEwLThtdzUwUDF3LUllbkMwWll3dy1IaksxQ2NIeEtsWVB2TWVJMkkmZT0+DQoyMTYxIFNhbiBK b2FxdWluIEhpbGxzIFJvYWQNCk5ld3BvcnQgQmVhY2gsIENBIDkyNjYwDQpsZW1AdW5pcmVnaXN0 cnkubGluazxtYWlsdG86bGVtQHVuaXJlZ2lzdHJ5Lmxpbms+DQo= --_000_CE39F90A45FF0C49A1EA229FC9899B05373FE99FUSCLES544agnaam_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHRoaW5rIF9kbWFyYyBhcyBhIFRYVCByZWNvcmQgaXMgZmFpcmx5IHdlbGwga25vd24uIElzIHRo ZXJlIGFueXRoaW5nIHRoYXQgd291bGQgc3BlY2lmaWNhbGx5IHByb2hpYml0IHRoaXM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5NaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRt YXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ THVpcyBFLiBNdcOxb3o8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA1LCAyMDE4 IDE6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IFBldGVyIE0uIEdvbGRzdGVpbjxicj4NCjxiPkNjOjwv Yj4gZG1hcmM7IEt1cnQgQW5kZXJzZW48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1p ZXRmXSBpbmhlcml0YW5jZSBhbmQgcHVibGljIHN1ZmZpeCBsaXN0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gNCBBcHIgMjAxOCwgYXQgMTE6 MTksIFBldGVyIE0uIEdvbGRzdGVpbiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgIzEzNkJDRSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxMzZCQ0UiPjMuICpOZXcgZ1RMRHMqIC0gV2l0aCB0aGUgcmVjZW50IGV4cGFuc2lvbiBv ZiB0aGUgbGlzdCBvZiBUTERzLCBtYW55IG9mIHRoZTxicj4NCm5ldyBUTERzIGFyZSBjb250cm9s bGVkIGJ5IGEgc2luZ2xlIG9yZ2FuaXphdGlvbi4gSXQgbWF5IG1ha2Ugc2Vuc2UgdG88YnI+DQph bGxvdyB0aG9zZSBnVExEcyB0byBkZWZpbmUgYSBETUFSQyByZWNvcmQgb24gdGhlIFRMRCBpdHNl bGYgb3Igb24gc29tZTxicj4NCidkZWZhdWx0JyBkb21haW4gLSBib3RoIGZvciBhZG1pbmlzdHJh dGl2ZSBzaW1wbGlmaWNhdGlvbiBhbmQgdG8gZW5zdXJlPGJyPg0KYWdhaW5zdCBhYnVzZS4gSXQg bWF5IGJlIHBvc3NpYmxlIHRvIGhhbmRsZSB0aGlzIGNhc2Ugb3V0c2lkZSBvZiBhIGxvb2t1cDxi cj4NCmNoYW5nZSB3aXRoIHdpbGRjYXJkZWQgRE5TIHJlY29yZHMsIGJ1dCBJIGtub3cgaXQncyBz b21ldGhpbmcgdGhhdCdzIGNvbWU8YnI+DQp1cCBpbiBkaXNjdXNzaW9ucyB3aXRoIHNvbWUgb2Yg dGhvc2UgVExEIG93bmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+S2VlcCBpbiBtaW5kIHRoYXQgZ1RMRCBvcGVyYXRv cnMgYXJlIHJlc3RyaWN0ZWQgaW4gdGhlIHJlY29yZHMgdGhleSBjYW4gaW5jbHVkZSBpbiB0aGVp ciByZXNwZWN0aXZlIEROUyB6b25lcy4gVGhpcyB3b3VsZCByZXF1aXJlIHRoZSB1c2Ugb2YgYSB3 ZWxsIGtub3duIG5hbWUgc3BlY2lmaWNhbGx5IGZvciB0aGlzIHB1cnBvc2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5MdWlzIE11w7Fvejxicj4NCkRpcmVjdG9yLCBSZWdpc3RyeSBPcGVy YXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxociBzaXpl PSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHAtM0FfX3d3dy51bmlyZWdpc3RyeS5saW5rXyZhbXA7ZD1Ed01GYVEmYW1wO2M9eDdCNmJq ai1sYlc3LUE1ZHVTd3RWWkJ3ZFBWc0lFSmJ4bDk2dWwwSGlYUSZhbXA7cj1KYjNBaU1oa3B3NGJW QUhuZ2hENVZBJmFtcDttPS10QmVtMjZBalQ1TjQtTzFEYkhmaHE1MXpKcUF2MEVEc0tkVXdIYm03 TFEmYW1wO3M9ajg4UTAtOG13NTBQMXctSWVuQzBaWXd3LUhqSzFDY0h4S2xZUHZNZUkySSZhbXA7 ZT0iPmh0dHA6Ly93d3cudW5pcmVnaXN0cnkubGluay88L2E+PGJyPg0KMjE2MSBTYW4gSm9hcXVp biBIaWxscyBSb2FkPGJyPg0KTmV3cG9ydCBCZWFjaCwgQ0EgOTI2NjA8YnI+DQo8YSBocmVmPSJt YWlsdG86bGVtQHVuaXJlZ2lzdHJ5LmxpbmsiPmxlbUB1bmlyZWdpc3RyeS5saW5rPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CE39F90A45FF0C49A1EA229FC9899B05373FE99FUSCLES544agnaam_-- From nobody Thu Apr 5 13:06:41 2018 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 C239012D77B for ; Thu, 5 Apr 2018 13:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 GviV9LebslNR for ; Thu, 5 Apr 2018 13:06:38 -0700 (PDT) Received: from zimbra1.uniregistry.com (zimbra1.uniregistry.com [162.221.214.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE9A12D779 for ; Thu, 5 Apr 2018 13:06:38 -0700 (PDT) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTPS id CC8D2240DAA; Thu, 5 Apr 2018 20:06:35 +0000 (UTC) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTPS id F3A52241295; Thu, 5 Apr 2018 20:06:34 +0000 (UTC) Received: from [64.96.166.230] (unknown [64.96.166.230]) by zimbra1.uniregistry.com (Postfix) with ESMTPSA id 68AA4240DAA; Thu, 5 Apr 2018 20:06:33 +0000 (UTC) From: "Luis E. =?utf-8?q?Mu=C3=B1oz?=" To: "MH Michael Hammer" Cc: "Peter M. Goldstein" , dmarc , "Kurt Andersen" Date: Thu, 05 Apr 2018 13:06:30 -0700 X-Mailer: MailMate (1.11r5462) Message-ID: In-Reply-To: References: <29ECE2D2-6AFD-4E78-95CB-FA770E790BCC@uniregistry.link> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E9B2BA91-2934-40D5-8B6D-1FADEC896E3A_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 20:06:40 -0000 --=_MailMate_E9B2BA91-2934-40D5-8B6D-1FADEC896E3A_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5 Apr 2018, at 13:04, MH Michael Hammer (5304) wrote: > I think _dmarc as a TXT record is fairly well known. Is there anything > that would specifically prohibit this? gTLDs are not permitted to place TXT records in their zones. Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link --=_MailMate_E9B2BA91-2934-40D5-8B6D-1FADEC896E3A_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 5 Apr 2018, at 13:04, MH Michael Hammer (5304) wrote:

I think _dmarc as a TXT recor= d is fairly well known. Is there anything that would specifically prohibi= t this?

gTLDs are not permitted to place TXT records= in their zones.

Luis Mu=C3=B1oz
Director, Registry Operations
____________________________

3D=

2161 San Joaquin Hills Road
Newport Beach, CA 92660

= Office +1 949 706 2300 x 4242
= lem@uniregistry.li= nk

=
--=_MailMate_E9B2BA91-2934-40D5-8B6D-1FADEC896E3A_=-- From nobody Thu Apr 5 13:59:23 2018 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 BEA5B12D7E4 for ; Thu, 5 Apr 2018 13:59:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 7GX2nWrHhHvf for ; Thu, 5 Apr 2018 13:59:20 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 21EB712D7F8 for ; Thu, 5 Apr 2018 13:58:50 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id x4so10811663wmh.5 for ; Thu, 05 Apr 2018 13:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=91T/M6DK5E3vd7PlOOppuxZmgvfmSwyWpwn+N8jcBak=; b=dOlAla+W+rhvjyAPypaIydIzURwPEFK38nQDY10oyBIW9GTguWjzq0J88pYOg9qVtH nuA5+uGqQ8FLtbdyJ556HEXP6IBGtkeJx3PIRGb3ZLick3IQtHAK8XJxmYWgPpjP4Su0 f3FsU+pRoUbvZkHuT5tV5WD7duCytAFXA0iMU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=91T/M6DK5E3vd7PlOOppuxZmgvfmSwyWpwn+N8jcBak=; b=pNzSBDicy11hX733ZyeTvk3yaCA4xhohBK+eKGKwUTdYovRKEzUAdeYSaceC4uqmNg Q+NBsOYpHibTgkGIVknkM+WbnXi6Zz/yaH62XoxSVWi9huyEKyQ180tQnuBsCcuLHuE7 p1Tjb2QeBv5UYaPPYNWdf9NQVFIB8icGWY9P9BnA+hSeWlSSgg84TZTP1cgYpzt7B5Px 7xVXPDKGjZB2dGQ4tfH6b8wZIEXgV9VHTHrxaUiiWwv5UXfkiJfGpayRw5+luUbrJOkT +H+rPRx8gbd1/ndQD7V27D+Z/Y7NljodliMXQ7RBGsQgs234u3WShVPHum34H+7eaquj /Cqw== X-Gm-Message-State: ALQs6tC/iBwZccUrd+fv/BE8CYT6LiJ2npMU2YtS5u99YjHQOQGX++Oo c+7ZCyDr7ZnAaZ7X0osAJrQTVAPkHq7z9rhO0ybhabVH X-Google-Smtp-Source: AIpwx482Q6llY1QsHLkZl3l+kdZdEqDxirsRvxptlX0AMMyNxzBtnNiaiqQx3dh+p/XqXJ9wH3LWcDHcj/hArjVq4To= X-Received: by 10.80.202.8 with SMTP id d8mr4225489edi.227.1522961928603; Thu, 05 Apr 2018 13:58:48 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Thu, 5 Apr 2018 13:58:48 -0700 (PDT) In-Reply-To: References: <29ECE2D2-6AFD-4E78-95CB-FA770E790BCC@uniregistry.link> From: "Kurt Andersen (b)" Date: Thu, 5 Apr 2018 13:58:48 -0700 X-Google-Sender-Auth: d8-c-25AvE_pe2xbjEBXFPLq0qk Message-ID: To: =?UTF-8?B?THVpcyBFLiBNdcOxb3o=?= , dmarc Content-Type: multipart/alternative; boundary="f4030438a310c2daa905692034b4" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 20:59:22 -0000 --f4030438a310c2daa905692034b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2018 at 1:06 PM, Luis E. Mu=C3=B1oz w= rote: > On 5 Apr 2018, at 13:04, MH Michael Hammer (5304) wrote: > > I think _dmarc as a TXT record is fairly well known. Is there anything > that would specifically prohibit this? > > gTLDs are not permitted to place TXT records in their zones. > That seems like a regrettable limitation. Would we need further definition around the "well known" aspect from IETF to fix this or would it require ICANN-level changes to contractual terms? --Kurt --f4030438a310c2daa905692034b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 5, 2018 at 1:06 PM, Luis E. Mu=C3=B1oz <lem@uniregistry.link> wrote:

On 5 Apr 2018, at 13:04, MH Michael Hammer (5= 304) wrote:

I think _dmarc as a TXT record is fa= irly well known. Is there anything that would specifically prohibit this?

gTLDs are not permitted to place TXT re= cords in their zones.

That seems lik= e a regrettable limitation. Would we need further definition around the &qu= ot;well known" aspect from IETF to fix this or would it require ICANN-= level changes to contractual terms?

--Kurt
--f4030438a310c2daa905692034b4-- From nobody Thu Apr 5 14:04:07 2018 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 CED8312D7EC for ; Thu, 5 Apr 2018 14:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sOBl3j6g5I7d for ; Thu, 5 Apr 2018 14:04:04 -0700 (PDT) Received: from zimbra1.uniregistry.com (zimbra1.uniregistry.com [162.221.214.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B8512D7E4 for ; Thu, 5 Apr 2018 14:04:03 -0700 (PDT) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTPS id 0B0AA240DAA; Thu, 5 Apr 2018 21:04:03 +0000 (UTC) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTPS id D5FEE241295; Thu, 5 Apr 2018 21:04:02 +0000 (UTC) Received: from [64.96.166.230] (unknown [64.96.166.230]) by zimbra1.uniregistry.com (Postfix) with ESMTPSA id 3BD34240DAA; Thu, 5 Apr 2018 21:04:02 +0000 (UTC) From: "Luis E. =?utf-8?q?Mu=C3=B1oz?=" To: "Kurt Andersen" Cc: dmarc Date: Thu, 05 Apr 2018 14:03:59 -0700 X-Mailer: MailMate (1.11r5462) Message-ID: <91EFB193-9A81-4626-92CA-BF116826F23A@uniregistry.link> In-Reply-To: References: <29ECE2D2-6AFD-4E78-95CB-FA770E790BCC@uniregistry.link> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B9AB0239-0F0D-41D5-9804-338B51A0BD91_=" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 21:04:06 -0000 --=_MailMate_B9AB0239-0F0D-41D5-9804-338B51A0BD91_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 5 Apr 2018, at 13:58, Kurt Andersen (b) wrote: > That seems like a regrettable limitation. Would we need further = > definition > around the "well known" aspect from IETF to fix this or would it = > require > ICANN-level changes to contractual terms? Contractual changes. This is the relevant text from = https://newgtlds.icann.org/sites/default/files/agreements/agreement-appro= ved-31jul17-en.html 1.1. For the =E2=80=9CInternet=E2=80=9D (IN) Class: 1.1.1. Apex SOA record 1.1.2. Apex NS records and in-bailiwick glue for the TLD=E2=80=99s DN= S = servers 1.1.3. NS records and in-bailiwick glue for DNS servers of = registered names in the TLD 1.1.4. DS records for registered names in the TLD 1.1.5. Records associated with signing the TLD zone (e.g., RRSIG, = DNSKEY, NSEC, NSEC3PARAM and NSEC3) 1.1.6. Apex TXT record for zone versioning purposes 1.1.7. Apex TYPE65534 record for automatic dnssec signing signaling 1.2. For the =E2=80=9CChaos=E2=80=9D (CH) Class: 1.2.1. TXT records for server version/identification (e.g., TXT = records for =E2=80=9Cversion.bind.=E2=80=9D, =E2=80=9Cid.server.=E2=80=9D= , =E2=80=9Cauthors.bind=E2=80=9D = and/or =E2=80=9Chostname.bind.=E2=80=9D) Luis Mu=C3=B1oz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link --=_MailMate_B9AB0239-0F0D-41D5-9804-338B51A0BD91_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 5 Apr 2018, at 13:58, Kurt Andersen (b) wrote:

That seems like a regrettable limitation. Would we need further defi= nition
around the "well known" aspect from IETF to fix this or would it require<= br> ICANN-level changes to contractual terms?

Contractual changes. This is the relevant text from https://newgtlds.icann.org/sites/default/files= /agreements/agreement-approved-31jul17-en.html

    1.1.   For the =E2=80=9CInternet=E2=80=9D =
(IN) Class:

    1.1.1.   Apex SOA record

    1.1.2.   Apex NS records and in-bailiwick glue for the TLD=E2=80=99s =
DNS servers

    1.1.3.   NS records and in-bailiwick glue for DNS servers of register=
ed names in the TLD

    1.1.4.   DS records for registered names in the TLD

    1.1.5.   Records associated with signing the TLD zone (e.g., RRSIG, D=
NSKEY, NSEC, NSEC3PARAM and NSEC3)

    1.1.6.   Apex TXT record for zone versioning purposes

    1.1.7.   Apex TYPE65534 record for automatic dnssec signing signaling=


    1.2.   For the =E2=80=9CChaos=E2=80=9D (CH) Class:

    1.2.1.   TXT records for server version/identification (e.g., TXT rec=
ords for =E2=80=9Cversion.bind.=E2=80=9D, =E2=80=9Cid.server.=E2=80=9D, =E2=
=80=9Cauthors.bind=E2=80=9D and/or =E2=80=9Chostname.bind.=E2=80=9D)

Luis Mu=C3=B1oz
Director, Registry Operations
____________________________

3D=

2161 San Joaquin Hills Road
Newport Beach, CA 92660

= Office +1 949 706 2300 x 4242
= lem@uniregistry.li= nk

=
--=_MailMate_B9AB0239-0F0D-41D5-9804-338B51A0BD91_=-- From nobody Thu Apr 5 15:54:13 2018 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 C1BCB12706D for ; Thu, 5 Apr 2018 15:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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=umich.edu 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 DclxrTpofg8B for ; Thu, 5 Apr 2018 15:54:09 -0700 (PDT) Received: from tombraider.mr.itd.umich.edu (smtp.mail.umich.edu [141.211.12.86]) (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 0062D126BF0 for ; Thu, 5 Apr 2018 15:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2016-05-12; t=1522968847; bh=TrIpEwp/XUEaBLL4ElFZ7u+QFSBJSxVXuL0eMyXQh5E=; h=Date:From:To:Subject:References:In-Reply-To; b=YSVJHJTA8Fd2NAEqkVU7iQz914f8ojKANDV5twe6Nt0Zku0RIlYr26fkc2xMw6Uc7 ouIho78Q4bqkPMZujXHbJSle3QJCk/FuiDH3i1TPFqkhukmy5xv8FYLGCyhuB3RG8k HjBL4mxPxLT+DQDkHzcNvmAk+vvL5F5VIUtoCL6yEJaWYN6+FSf5m6sETWMFrqVTJ3 W0GuvhW1+zThxGOg4rZHMMQo87YtAhNo7WEc9mAtBYccbZOAOrZm6VojFbCrCJ70Hc iovPA2TXG/LgUDMmVAjqsrB5xPtQj2C2rHJoqvEjXPlv4MF0ypS+jy5oSndmvC2fgj S+7caVVd3I2sQ== Authentication-Results: tombraider.mr.itd.umich.edu; iprev=pass policy.iprev=45.79.218.81 (vereveel.marwnad.com); auth=pass smtp.auth=ezekielh Received: FROM marwnad.com (vereveel.marwnad.com [45.79.218.81]) By tombraider.mr.itd.umich.edu ID 5AC6A90F.CA9CE.31220; Authuser ezekielh; Thu, 05 Apr 2018 18:54:07 -0400 Date: Thu, 5 Apr 2018 22:54:05 +0000 From: Zeke Hendrickson To: dmarc@ietf.org Message-ID: <20180405225405.GA5947@marwnad.com> References: <20180405130754.wwsurl5zy4gzeu3n@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 22:54:12 -0000 On Thu, Apr 05, 2018 at 07:22:37AM -0700, Peter M. Goldstein wrote: > On Thu, Apr 5, 2018 at 6:07 AM, Andrew Sullivan > wrote: > > > Do you mean this _across_ TLDs (e.g. the "variants" case such as > > differnet spellings of China depending on the writing system) or do > > you just mean that the top most label and everything flowing down from > > there is all under the same policy? > > The latter. > > To be more clear, there are now a significant number of TLDs that are > managed exclusively by one entity (e.g. .microsoft, .google) as well as > other TLDs that make specific guarantees around DMARC (e.g. .bank). In > those cases it may make sense to give the registry owners some defined > mechanism for imposing global DMARC policy across the TLD. This is > especially important for organizational domain names that don't resolve for > that TLD. > > So, for example, let's consider an email seemingly sent from > support@iamareal.bank . A query to the domain iamareal.bank returns an > NXDOMAIN, as does the a TXT query to the corresponding DMARC record > _dmarc.iamareal.bank domain. So there's no DMARC policy in place. So a > receiver may wind up delivering this email to the inbox, especially if it > passes SPF and DKIM in an unaligned fashion. > > But to an end user it looks like this is an email from a '.bank' domain, > which undermines the .bank TLDs goal of providing a higher trust set of > domains. And it is therefore attractive to bad actors as a possible > channel of abuse. > > The question is whether the DMARC lookup scheme should somehow address this > issue. Alternately, we could simply say that this is a case that DMARC > itself doesn't handle, and that the registry owner may choose to modify > their DNS responses to ensure they always return a DMARC record for any > organizational domain on that TLD. My initial thought was that handling this in DMARC would be unnecessary, since mail from nonexistent domains can be rejected without needing an opt-in compliance record. However, that thought completely neglected the "R" portion of DMARC, and I can certainly see how including attempts from nonexistent domains in aggregate reports would be useful. Further, while the requirement that RFC5321.MailFrom domains be resolvable is codified in section 2.3.5 of that RFC, a similar explicit requirement for the RFC5322.From address was deliberately removed from the DMARC spec (see https://tools.ietf.org/html/rfc7489#appendix-A.4). Absent a better way to determine domain ownership boundaries than the current heuristic, I don't think the resolution for domains that exist should be altered. Domains should retain the ability to opt out of DMARC by not publishing a DMARC record, rather than being unexpectedly affected by one that their TLD or other public suffix has chosen to publish. Requiring that pseudo-public suffixes like .google publish DMARC records for their valid Organizational Domains doesn't seem onerous. I would suggest that if there's no policy found for the two domains that are currently checked, the receiver should attempt to resolve those domains (checking for MX or address records, or a CNAME that points to a name with MX or address records), and only if they cannot be resolved move on to querying the name that matched from the public suffix list. This represents a significant increase in the number of DNS queries required to process a nonexistent domain, but I think it's the best balance between retaining the opt-in nature of DMARC and allowing public suffixes to publish DMARC policies for nonexistent domains in their namespace. -- Zeke Hendrickson (ezekielh@umich.edu) University of Michigan | Information and Technology Services Infrastructure | Application Operations | Application Delivery Support From nobody Fri Apr 6 09:48:17 2018 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 4E4AE1200C5 for ; Fri, 6 Apr 2018 09:48:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 vfm0u2n8Ho9Q for ; Fri, 6 Apr 2018 09:48:13 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 F2DDE12025C for ; Fri, 6 Apr 2018 09:48:12 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id p9so4718221wmc.3 for ; Fri, 06 Apr 2018 09:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=vChVOYEiZRbGxOQS5djz2WxLkwYYamyl8ncSsMFr5Mk=; b=ReRo82dgdB/eeMXLtkbQQv6WtreuohO7dhqxpK2nIwOUzSOZGp2tHJp7CoVjAB2FBn 2PUkpYi5xjLdkOcHChQdi6Pt/0M24fAxf187/MUXKNGqRcAHb6LP1Yjq53G9z6N6WLBI c4N3JNt+r6w2Pbo3D4ZIz31WS4j3vkn1Y56d4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=vChVOYEiZRbGxOQS5djz2WxLkwYYamyl8ncSsMFr5Mk=; b=p63wS08WTHe5xQLnvdsljVwMrIQegd/34ytzjixgg5gZIpQb+MXp+LaxON47GDAQy/ OYmLyYmmLPEdFMdgqTV0gl6xUEYV/Nb0OJDxRJZghHDCfhFcPw4Q2FjPuUjbQEg4HaPl QNoPQeWphoLMvE3QkTfKNRLSBlEKd8xtJzuAH1nNAxCg6WnS3tijyHenwN+wlhZIwSyU n1LChvf7xtTvyf0EjZnpgsZhtm6e9/60VbBHrrpHuxag/9cJErdVJgG3IdLMtU3ntBvt Dpsdqpp9489KMcchJ1fmVafkBET/prU34Ss72LxVIO62b+M03+PVpp6QIdZnfCvMgkMN Bcbg== X-Gm-Message-State: ALQs6tD9FGtH0CfpIrgB3grjsA+TYNTpZ56HiEX0s3/6m/CEUPT6qnHx PPCCscYFgFGjS8xRVeOdh1XvZxQoLiYDAB/dtGHT1sVNISs= X-Google-Smtp-Source: AIpwx488OV0OotIPONOJHtlA5gHIgPDWuQ1KRwM5veyTmlMXr3lZ62w88rH6chyu8XooMv5m6i0Wzv+ul/HeY2Y/6BI= X-Received: by 10.80.152.227 with SMTP id j90mr7695041edb.89.1523033291156; Fri, 06 Apr 2018 09:48:11 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Fri, 6 Apr 2018 09:48:10 -0700 (PDT) From: "Kurt Andersen (b)" Date: Fri, 6 Apr 2018 09:48:10 -0700 X-Google-Sender-Auth: 63CYfvWJ_IjQtuN7iAOKiEVYgPk Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1957fe4cff60056930d269" Archived-At: Subject: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 06 Apr 2018 16:48:16 -0000 --94eb2c1957fe4cff60056930d269 Content-Type: text/plain; charset="UTF-8" *I filed issue 22 after observing a discussion today on another list:* Pursuant to an email thread on the mailop list, we may want to consider how (or if) to do something about the ways that people have developed different processing handling for p=none vs. p!=none. Here's the example: Does anyone know of any negative side effects of setting a DMARC policy: p=quarantine pct=0 ? Is it equivalent to: p=none ? I'm curious because I want to trigger Google Groups (and maybe others list forwarders?) to rewrite the From in a DMARC compliant fashion *prior* to changing the domain's DMARC policy... to avoid the "leap of faith" that p=none's monitoring mode was supposed to alleviate. (https://trac.ietf.org/trac/dmarc/ticket/22#ticket) --94eb2c1957fe4cff60056930d269 Content-Type: text/html; charset="UTF-8"

I filed issue 22 after observing a discussion today on another list:

Pursuant to an email thread on the mailop list, we may want to consider how (or if) to do something about the ways that people have developed different processing handling for p=none vs. p!=none. Here's the example:

Does anyone know of any negative side effects of setting a DMARC policy: p=quarantine pct=0 ?

Is it equivalent to: p=none ?

I'm curious because I want to trigger Google Groups (and maybe others list forwarders?) to rewrite the From in a DMARC compliant fashion *prior* to changing the domain's DMARC policy... to avoid the "leap of faith" that p=none's monitoring mode was supposed to alleviate.

(https://trac.ietf.org/trac/dmarc/ticket/22#ticket)
--94eb2c1957fe4cff60056930d269-- From nobody Tue Apr 10 08:42:06 2018 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 D390D12DA05 for ; Tue, 10 Apr 2018 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lk84u7569Qi4 for ; Tue, 10 Apr 2018 08:42:01 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 702DB12D95D for ; Tue, 10 Apr 2018 08:42:01 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id x77so14185914ioi.2 for ; Tue, 10 Apr 2018 08:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=ky47xUFNnemIlnV59na/8MhXlGj2gnbDd4BC8T6KgTI=; b=TUo2B94r7xwguTPNYfjsD6IAfZQ0GFYCBE8ku7Xp/QV6BDUybK3V1/HQ1IhoyN0per OVuGxYn1HTcFvfAyujAN0AMET3/3OVgfD8D7srFZFTsnaA3UY+4MZ88ucd+OuT5fFfMI GNomeDUF6qCnLS5GgP1/3dqG055T4VMYt3DbDqVZ5ef+2BrV7T4krSUBEdJ1FZkSXTKo 7R3FVDXi3jXYIjaFzdGko0YA6t9znN1Kbb9NJ4LLG5zw8faiStwz2DxRkOCHDeGY95Ub UN1BfmL65l0s4B5lF7MKPse2UIo0VVSJ56dflkm75Y7dTbsdcICULSMdM60lHCy7R21w tioA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ky47xUFNnemIlnV59na/8MhXlGj2gnbDd4BC8T6KgTI=; b=GyE3xUgCEUQfcffC+8kNXtTlY01pOzgbmcIpUsWsvtUOHXXdxiADiur2sf8UnTP6Jn PlwaOXeoAhRNHdCFqaa/fWsdhOYoJeC13xBlYkiYOTQV4hErpIRf2RgSWA6sUN2aNAW2 NvFj7+5c7txyfGW4ju+VTjqGf5Jq3AcbR2oMthr84NAPPZPnNklWd9BPuZzz/JPZU85v DmDjKeECtEN0Wj56PKreVTsLHL+LPnZjfLt67gDor4G3eE5TjsFAW4dRR0kU4tcaZ98o M60D9Ek3qCb8bK7usCTjBPkOx+9RXbLaHG2Vg1urYKXGfCfD435Wda9/jwwi1N/Dmf5H gWXA== X-Gm-Message-State: ALQs6tALYuNE1EW3eOeyw9gowZBMc2Vb3QZ7wdh7e/Jec1J7++zxPVpL Db3AiJmLy9H0Sz61JNuoN/lAAL2urVjf2F0zcSNWAQ== X-Google-Smtp-Source: AIpwx4+Gv0oo0OnglMiR3n/4Ae5R437onbmyoLMvw2ZVLdp6YLmQFGT0DZWjTCI9VbgTrceuwCBQPoC1kE/bF/YQ0UM= X-Received: by 10.107.140.86 with SMTP id o83mr1046015iod.114.1523374920537; Tue, 10 Apr 2018 08:42:00 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.192.142.161 with HTTP; Tue, 10 Apr 2018 08:41:59 -0700 (PDT) From: Barry Leiba Date: Tue, 10 Apr 2018 11:41:59 -0400 X-Google-Sender-Auth: xdBKIDbQsm7bxVdmmiX8126T4Jw Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] DMARC workaround test 1 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 15:42:04 -0000 I understand we now have the DMARC workaround test up in this list. That means that "from" addresses should get rewritten if they identify domains with DMARC p=reject. Let's check that out. This message is from my usual computer.org address, and shouldn't get rewritten. It should say sender: barryleiba@gmail.com from: barryleiba@computer.org Barry From nobody Tue Apr 10 08:52:01 2018 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 37B001270A3 for ; Tue, 10 Apr 2018 08:52:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 V2CapfaxKGDc for ; Tue, 10 Apr 2018 08:51:57 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0E0126DED for ; Tue, 10 Apr 2018 08:51:57 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r131so24283321wmb.2 for ; Tue, 10 Apr 2018 08:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zV8fdZG4Is1TPDGJpz1T0U65zub8wURxrr2dXK+jv6g=; b=VCSfvqNqPCY7O6fpIrvfn1WK13VM25I2sYjrkfN6kHV3eIrpcGGjciqOtIilrdg+ZJ QlESJkqEIgZlzC5pKQSXpk5Kuanr3koKGot0nNWWE9oHriYzsc593MxIhBUCsZpCa6Km 316/anP3a2ahKTIFsJgAnDzOs4tT45jR/Srm8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zV8fdZG4Is1TPDGJpz1T0U65zub8wURxrr2dXK+jv6g=; b=BFjuMsD6YVtfv3eUBwNF34ly4Hm8AoasG/N/A8KQV0tdHyudbLCMCnscGNo3E/zEtp 9eBjBtnYZnl41szkF45XzFTi4VP05h76mpbUVQOPkPsFCtUzH/oByJMSH0N/VuCajUa5 yon4Z/eT/ootBH2HeyNI6/PhU0VmDVAFMgIA5EZJQm1Pf+jBzUILjUty0KNdBi4HeA7s R6PPx17vB0YfjdY04/Ukq326R8dyR6bWVhHPRSgrosW82XPwaK8vX7Zlr9pPzyw18RMP CyG8lBngq82M0ULerUQTmOpVUajpUUPc23zKDyWSWCxKx5IuWvwAM97V0KeM2HqTYUgi kHnA== X-Gm-Message-State: ALQs6tDSPeZnrjwEbdd0Ow3Jz/IzfG98dH5Sz5aZUH+jgt3+Zzayuwml vmsRIn8DZqn5dHYT3S+C4eqHAHbRPPfyrDVWYZVB2Vm3eHs= X-Google-Smtp-Source: AIpwx496JP01f84nXR8fjdROpmcN53p1oGfH/JKcncsSXISP37AxG+T9uUKxdehW7iydgzuPbkg3ymvGBURRlhMcNIM= X-Received: by 10.80.177.234 with SMTP id n39mr4310624edd.108.1523375515710; Tue, 10 Apr 2018 08:51:55 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Tue, 10 Apr 2018 08:51:55 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 10 Apr 2018 08:51:55 -0700 X-Google-Sender-Auth: 5WN0EFY6zQ_TK6k-J-z8TmFKa-A Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045c1f227949cb0569808081" Archived-At: Subject: Re: [dmarc-ietf] DMARC workaround test 1 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 15:52:00 -0000 --f403045c1f227949cb0569808081 Content-Type: text/plain; charset="UTF-8" Here's what I saw reported on it: Authentication-Results: mx.google.com; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=bJFPnWzx; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=BcDgnOt9; dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20161025 header.b=TUo2B94r; spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) smtp.mailfrom= dmarc-bounces@ietf.org From: Barry Leiba Date: Tue, 10 Apr 2018 11:41:59 -0400 Errors-To: dmarc-bounces@ietf.org Sender: dmarc ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=bJFPnWzx; dkim=pass header.i=@ietf.org header.s=ietf1 header.b=BcDgnOt9; dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20161025 header.b=TUo2B94r; spf=pass (google.com: domain of dmarc-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) smtp.mailfrom= dmarc-bounces@ietf.org --Kurt On Tue, Apr 10, 2018 at 8:41 AM, Barry Leiba wrote: > I understand we now have the DMARC workaround test up in this list. > That means that "from" addresses should get rewritten if they identify > domains with DMARC p=reject. Let's check that out. > > This message is from my usual computer.org address, and shouldn't get > rewritten. It should say > sender: barryleiba@gmail.com > from: barryleiba@computer.org > > Barry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f403045c1f227949cb0569808081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's what I saw reported on it:

<= div>Authentication-Results: mx.google.com;
=C2=A0 =C2=A0 =C2=A0 =C2=A0dkim=3Dpass header.i=3D@ietf.org header.s=3Dietf1 header.b=3DbJFPnWzx;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0dkim=3Dpass header.i=3D@ietf.org head= er.s=3Dietf1 header.b=3DBcDgnOt9;
=C2=A0 =C2=A0 =C2=A0 =C2=A0dkim=3Dneutral (body hash did not ve= rify) header.i=3D@gmail.com header.s=3D201= 61025 header.b=3DTUo2B94r;
=C2=A0 =C2=A0 =C2=A0 =C2=A0spf=3Dpass (g= oogle.com: domain of dmarc-bo= unces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) sm= tp.mailfrom=3Ddmarc-bounces@ietf.= org
Fro= m: Barry Leiba <barryleiba@co= mputer.org>
Dat= e: Tue, 10 Apr 2018 11:41:59 -0400
Sender: dmarc <dmarc-= bounces@ietf.org>
ARC-Authentication-Results: i=3D1; mx.g= oogle.com;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0dkim=3Dpass header.i=3D@ietf.org header.s=3Dietf1 header.b=3DbJFPnWzx;
=C2=A0 =C2=A0 =C2=A0 =C2=A0dkim=3Dpass header= .i=3D@ietf.org header.s=3Dietf1 header.b=3D= BcDgnOt9;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0dkim=3Dneutral (body hash did not verify) header.i=3D@gmail.com header.s=3D20161025 header.b=3DTUo2B= 94r;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0spf=3Dpass (google.com: domain = of dmarc-bounces@ietf.org des= ignates 2001:1900:3001:11::2c as permitted sender) smtp.mailfrom=3Ddmarc-bounces@ietf.org
<= /div>


--Kurt


On Tue, Apr 10, 201= 8 at 8:41 AM, Barry Leiba <barryleiba@computer.org> wr= ote:
I understand we now have the DMARC w= orkaround test up in this list.
That means that "from" addresses should get rewritten if they ide= ntify
domains with DMARC p=3Dreject.=C2=A0 Let's check that out.

This message is from my usual computer.org address, and shouldn't get
rewritten.=C2=A0 It should say
=C2=A0 =C2=A0sender: barryleiba@gma= il.com
=C2=A0 =C2=A0from: barryleiba@co= mputer.org

Barry

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

--f403045c1f227949cb0569808081-- From nobody Tue Apr 10 09:13:35 2018 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 5384A12D878 for ; Tue, 10 Apr 2018 09:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cCccSNsgltHA for ; Tue, 10 Apr 2018 09:13:31 -0700 (PDT) Received: from mx-out-rotate7.simplymailsolutions.com (mx-out-rotate7.simplymailsolutions.com [88.151.129.182]) (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 6A3C112D0C3 for ; Tue, 10 Apr 2018 09:13:31 -0700 (PDT) Received: from SHA-EXSP2-HUB01.exsp2.ifeltd.com (unknown [10.1.40.31]) by halon01.simplyms.com (Halon) with ESMTPS id 16136644-3cda-11e8-b924-005056892a69; Tue, 10 Apr 2018 17:13:20 +0100 (BST) Received: from [172.20.1.215] (62.232.206.186) by smtp.mse2010.com (10.1.40.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Apr 2018 17:13:28 +0100 To: From: Alexey Melnikov Message-ID: <1f23d7a4-d76c-a74e-93b8-8ea25a32603b@melnikov.ca> Date: Tue, 10 Apr 2018 17:13:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [dmarc-ietf] Testing DMARC workaround code X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 16:13:33 -0000 Hi, My appologies for spamming everybody, but considering that this is a mailing list that works on DMARC, testing DMARC related issues seems appropriate. I am sending this email from a domain that advertises p=reject DMARC policy. My From address should be rewritten to be a @dmarc.ietf.org email address. Best Regards, Alexey. P.S. If you see this email address in your auto-collected addressbooks, this is very likely not an email address you want to use to reach me. Please use alexey.melnikov@isode.com instead. From nobody Tue Apr 10 09:19:37 2018 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 AA32012D7EA for ; Tue, 10 Apr 2018 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Y4+YlR0X; dkim=pass (1536-bit key) header.d=taugh.com header.b=X/lpKTEt 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 WtoNoF3c3_4f for ; Tue, 10 Apr 2018 09:19: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 F02C712D0C3 for ; Tue, 10 Apr 2018 09:19:33 -0700 (PDT) Received: (qmail 67010 invoked from network); 10 Apr 2018 16:19: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=105c0.5acce414.k1804; bh=iAQ8coZzj0y32GUQrE44kC5wRo+4SHciLmoBn0QeCkk=; b=Y4+YlR0X74dQQoYi/9ZVmQUYfFE++OYjnfrb1qyOoO8P/YJHYTf+Oe1hnBJOJE2K2e7rcNmWNrpJWJt1mzJ4aAuxfSR3nWeAI2tTsbaRmNh1Hv6/Q95Xukka9F/JkNsvnCFxW5QdXBRukWeUgznAmc4svV8pk0XbUYZVWJyrpKXSn2GYvDbBmAunTdHR9CNqRJ0kHrZ67TyQ5eOrpjmkKxed/4eADXD7W6E3IOS6dE1h2kmOIL/XEEPPOZ960aPx 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=105c0.5acce414.k1804; bh=iAQ8coZzj0y32GUQrE44kC5wRo+4SHciLmoBn0QeCkk=; b=X/lpKTEtjFvw/8T/MzrZ5lWXX6LMaN1Pj9uErocmDjCPZIk7Raz8MQq1U8/MRQYuPsZ9L+QFv3HJ973k2W5y+0WDYSGNMXLQ16Rhw4UTVa0we3ECle04yL/cKwxR93WGU25/r6Oftg19iVnS424t8eVMDk2JCZ+o7ByW8P5KoXvtc8fTM4KzYEex8SzMb5ShJ+AlFVElJ5xAcsaGSDinDxl9AG5lh8L4n0nhlWTB5JCFtRNdFqG6H4B0d9Z6qDhF 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; 10 Apr 2018 16:19:32 -0000 Received: by ary.qy (Postfix, from userid 501) id 492762460CBB; Tue, 10 Apr 2018 12:19:31 -0400 (EDT) Date: 10 Apr 2018 12:19:31 -0400 Message-Id: <20180410161932.492762460CBB@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: lem@uniregistry.link 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] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 16:19:36 -0000 In article you write: >> I think _dmarc as a TXT record is fairly well known. Is there anything >> that would specifically prohibit this? > >gTLDs are not permitted to place TXT records in their zones. That's mostly right. There is detailed language in the registry contracts about what's allowed in the TLD zones, dating back to the sitefinder fiasco when Verisign put a *.com wildcard in the .com zone. See Exhibit A in the Base Registry Agreement: https://www.icann.org/resources/pages/registries/registries-agreements-en TLDs are allowed to put in txt records for zone status. See, for example, the TXT records at __zone_status.sharp or at total. I doubt that anyone would object to a _dmarc. TXT record, but it's debatable whether it would qualify as zone status. Otherwise the registry would have to make an RSEP request to ICANN for permission to do so, which is expensive and slow. https://www.icann.org/resources/pages/rsep-2014-02-19-en R's, John From nobody Tue Apr 10 12:47:23 2018 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 9A08212DA73 for ; Tue, 10 Apr 2018 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ6erA4YWcD6 for ; Tue, 10 Apr 2018 12:47:19 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569FF12DA6C for ; Tue, 10 Apr 2018 12:47:19 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id e98-v6so16324791itd.4 for ; Tue, 10 Apr 2018 12:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+rLLDAZZdtN7fDKpGsQ6PXRHiWvC/CFE578CelwAByU=; b=s+aHTOyUGfWTloj6jQrN4biaHf5JWWrrr7ivbUGP5sNxTMSBaLqlQGA7v82jYZXQLt 5rK4PMI4JgKbQQzs12W0gCWAytyKG7rdGmTJSGP+FCej3nzKeYT37e+ebvKUHY0LRPGv BSHs2ZQS4+RXe1NItUcaBAKsXr7P9hQ7EIBKUGf4tGytJ0X2MiCSuf9cyphWPHwAYKnv pFpruHDdR/mcGIOSTMGoOHvvqsjf/yuhF3Zn1ZJFCpVdmoKGXWFjVb3fZ3+7+X6QZKyE sv6IwIw/spYiHoZ10P/HO3lrF5dSY40ik2eIdYdMIp6Uznoh6cqPMs0v4pGHEvD0XR/V dz/g== 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=+rLLDAZZdtN7fDKpGsQ6PXRHiWvC/CFE578CelwAByU=; b=WAGtnrZM06b6kp9DFwsSROEQzw2W9BdX2yISslSKJ0SzJjREIKaQZOw6RXqj7ox7F6 Pv+MWw68ElYdsSuluWbdSOJ1tpjo4iHRYcKK4EZ/+2hSyiPUTP93rHeJxZQ01xcsVVtU u8cQn+J+CjiiWmn1fyI1P5G4dywbQjI54KFpxGi9Lm9uya9yfdLfHKYb5Gd9su/YB8YQ odmUUXo4t21Q2mDz5G8saohe/8l8jDodd8KwLbRWO+/NXHFGrUFlW3nCVdyylFSqRxqo 0QP4TGTJzoMhtOzbOQ4W4tVuqeiD5q/JEowr1dABE2RNpUVNRUMpbf9jREBA3X7nyMLR qrMg== X-Gm-Message-State: ALQs6tAtxwS+zqq+5AAuqgInhr5qOshTZXdvIfK0low2qHKEU9dHCB2Z oWxUIt+uw+Y1r4wDJLZf+l63EiEHvQACiDYOKaY7 X-Google-Smtp-Source: AIpwx4/FWWWlagyAeV1KwNs32Cu9rOzBI8cFPFJQWpDtAGAXSWwn5QXAkZBmAV1IP4GR4jP2VvNDD4ygRCVNUZy8K+0= X-Received: by 2002:a24:f685:: with SMTP id u127-v6mr885007ith.131.1523389638152; Tue, 10 Apr 2018 12:47:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Tue, 10 Apr 2018 19:47:06 +0000 Message-ID: To: "Kurt Andersen (b)" Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d35bc056983ca2f" Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 19:47:22 -0000 --0000000000003d35bc056983ca2f Content-Type: text/plain; charset="UTF-8" Trying a reply from my dmarc protected address... What are you proposing we do? Specify what handling should be done more specifically in that case? Brandon On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) wrote: > *I filed issue 22 after observing a discussion today on another list:* > > Pursuant to an email thread on the mailop list, we may want to consider > how (or if) to do something about the ways that people have developed > different processing handling for p=none vs. p!=none. Here's the example: > > Does anyone know of any negative side effects of setting a DMARC policy: > p=quarantine pct=0 ? > > Is it equivalent to: p=none ? > > I'm curious because I want to trigger Google Groups (and maybe others list > forwarders?) to rewrite the From in a DMARC compliant fashion *prior* to > changing the domain's DMARC policy... to avoid the "leap of faith" that > p=none's monitoring mode was supposed to alleviate. > > (https://trac.ietf.org/trac/dmarc/ticket/22#ticket) > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000003d35bc056983ca2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Trying a reply from my dmarc protected address...

=
What are you proposing we do?=C2=A0 Specify what handling should= be done more specifically in that case?

Brandon

On Fri, Apr 6, 20= 18 at 9:48 AM Kurt Andersen (b) <kbo= th@drkurt.com> wrote:

I filed issue 22 after observing a discussion today on ano= ther list:

Pursuant to an email thread on the mailop list, we may= want to consider=20 how (or if) to do something about the ways that people have developed=20 different processing handling for p=3Dnone vs. p!=3Dnone. Here's the= =20 example:

Does anyone know of any negative side effects of setting a DMARC policy: p= =3Dquarantine pct=3D0 ?

Is it equivalent to: p=3Dnone ?

I'm curious because I want to trigger Google Groups (and maybe others= =20 list forwarders?) to rewrite the From in a DMARC compliant fashion=20 *prior* to changing the domain's DMARC policy... to avoid the "lea= p of=20 faith" that p=3Dnone's monitoring mode was supposed to alleviate.<= /p>

(https://trac.ietf.org/trac/dmarc/ticket/22#ticket= )
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000003d35bc056983ca2f-- From nobody Tue Apr 10 12:54:11 2018 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 6D7E7127876 for ; Tue, 10 Apr 2018 12:54:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 IQfL2rmq4uzC for ; Tue, 10 Apr 2018 12:54:07 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 0B4E612DA4A for ; Tue, 10 Apr 2018 12:54:07 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id b127so28668119wmf.5 for ; Tue, 10 Apr 2018 12:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cc5KF0nqNw/VNtiN3TlOn7vmoFFtjA5gvYyKXCsN14Q=; b=OYYcXG5wZX3Jrkq/j1qvhuNIPGYAbk/3LzqRxLPSWoXf26v7UGRJgY9SkcYun8doqh Ns9nFE+5Obw+MwEvYDdptQGoTdk3CeV5UPvTEJ0zOBn600Kus0Fi2Bc1nEbCe99lNqr3 bDxVf8/GLcPywdQYQ2aJMWlc8ZDp8CuzdwixU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cc5KF0nqNw/VNtiN3TlOn7vmoFFtjA5gvYyKXCsN14Q=; b=uX/iOkBCYYtHgnKlgNGCn9VeXJfCBPSV0pHF3p8xS74Y6l05YPtBLCfOqi1zwPVj07 GGHUS7M5Df+LF1jkr7qI1IMqvsTOEJxqzmkQb+AT/jusujbMwXvdpFOWwTlzawVwyssW Z50auLCgV3Y/NgTVuIYPP7fr+J8EgKi7NRGUccf2YyNCIEzk+EFLUuxHgwgarBQ/BfQy UV21aRzYLxAuVh9p/lEnqIGgwPnI1Iqf7xBbrgvgRF82r50m9iFbU163FqoZ/x5vOew9 TXSyHfFngUAhdlRM9iTbc+eBkBs5FH7N2Jm69mks6SecRCgKEBqIMozOJGuSpFKrdJlM FuAw== X-Gm-Message-State: ALQs6tAOYSZY8kt8AEQpK34XI811ebXBnorl2cSZe8VkGrOsG+BhRpra 5uTUAmAH1C47weTD22e7JDMjagzi2oX+cXVd6OFf+9BMAkc= X-Google-Smtp-Source: AIpwx4/bFI+4Ic0Ecrm4CSXsV/XHrtDCJG4mId8H8pC+gc3gLEOaNKEPZCfEkJJATLm+kimBUiJBv7Jg9ubaIHgPx8I= X-Received: by 10.80.152.227 with SMTP id j90mr5415087edb.89.1523390045407; Tue, 10 Apr 2018 12:54:05 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Tue, 10 Apr 2018 12:54:04 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 10 Apr 2018 12:54:04 -0700 X-Google-Sender-Auth: OklYZuOCKbFjEpkA0No_8nGoC20 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1957fe82d946056983e20c" Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 19:54:09 -0000 --94eb2c1957fe82d946056983e20c Content-Type: text/plain; charset="UTF-8" On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long wrote: > > On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) wrote: > >> *I filed issue 22 after observing a discussion today on another list:* >> >> Pursuant to an email thread on the mailop list, we may want to consider >> how (or if) to do something about the ways that people have developed >> different processing handling for p=none vs. p!=none. Here's the example: >> >> Does anyone know of any negative side effects of setting a DMARC policy: >> p=quarantine pct=0 ? >> >> Is it equivalent to: p=none ? >> >> I'm curious because I want to trigger Google Groups (and maybe others >> list forwarders?) to rewrite the From in a DMARC compliant fashion *prior* >> to changing the domain's DMARC policy... to avoid the "leap of faith" that >> p=none's monitoring mode was supposed to alleviate. >> >> (https://trac.ietf.org/trac/dmarc/ticket/22#ticket) >> > [looks like your email worked] > > Trying a reply from my dmarc protected address... > What are you proposing we do? Specify what handling should be done more > specifically in that case? > Brandon It may not be palatable, but I would consider some sort of recommendation along the lines of "SHOULD NOT" in the to-be-revised standards-track spec for DMARC to discourage special case processing of p=none. --Kurt --94eb2c1957fe82d946056983e20c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 10, 2018 at 12:47 PM, Brandon Long <blong@google.com>= wrote:

On Fri, Apr 6,= 2018 at 9:48 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:

I = filed issue 22 after observing a discussion today on another list:

<= p>Pursuant to an email thread on the mailop list, we may want to consider= =20 how (or if) to do something about the ways that people have developed=20 different processing handling for p=3Dnone vs. p!=3Dnone. Here's the= =20 example:

Does anyone know of any negative side effects of setting a DMARC policy: p= =3Dquarantine pct=3D0 ?

Is it equivalent to: p=3Dnone ?

I'm curious because I want to trigger Google Groups (and maybe others= =20 list forwarders?) to rewrite the From in a DMARC compliant fashion=20 *prior* to changing the domain's DMARC policy... to avoid the "lea= p of=20 faith" that p=3Dnone's monitoring mode was supposed to alleviate.<= /p>

(https://trac.ietf.org/trac/dmarc/ticket/22#ticke= t)
=C2=A0
[looks like your email worked]
=C2= =A0
Trying a reply from my dmarc protected address...
What = are you proposing we do?=C2=A0 Specify what handling should be done more sp= ecifically in that case?
Brandon

It may not be palatable= , but I would consider some sort of recommendation along the lines of "= ;SHOULD NOT" in the to-be-revised standards-track spec for DMARC to di= scourage special case processing of p=3Dnone.

--Kurt
--94eb2c1957fe82d946056983e20c-- From nobody Tue Apr 10 13:44:22 2018 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 2645112895E for ; Tue, 10 Apr 2018 13:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dd5X4507; dkim=pass (1536-bit key) header.d=taugh.com header.b=Cuuy0XuL 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 71umQnE7B_gE for ; Tue, 10 Apr 2018 13:44: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 AA9041272E1 for ; Tue, 10 Apr 2018 13:44:19 -0700 (PDT) Received: (qmail 19248 invoked from network); 10 Apr 2018 20:44:18 -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=4b2e.5acd2222.k1804; bh=OUGMwlOuV8Az04H3fhQXUH2Gzz83cyTyCyCgfCtj9OY=; b=dd5X4507O4zZRbIf6KwbCcUNfDb1DfFbm0hHOJ0+tx3s9lK9C4dzz86awZ+Ujj8NiPL1j22GKBpb2cBcX3lE84jbxXblmSbEPdp0Q8+bzevqsf0Kay+9RnPZiymv7wx1Mcr/xCYKYEIMjIzGdEH6IzTJ8tST+IxEWLWlJepZX6BaNnq6VWeC3vPZVrWnwrNZacdElZSGraZjS+8iX85b7CNYYx80DBxPAzLel/DUtBXvGFlk3Z+o2SkimII08As7 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=4b2e.5acd2222.k1804; bh=OUGMwlOuV8Az04H3fhQXUH2Gzz83cyTyCyCgfCtj9OY=; b=Cuuy0XuLtHbMsAEX0GgeUBEtFcg6HUeUsN6ZRtwdL2H+O2BOpb+xY6+g4drVPEeOqadibOqhWcfTXVLRau4rLxLwyCW9vWybnknFcjPHqg4vXkI5nUa6C/3l0X0QDkKliWCQJSjbKqnKBCxPcOqyzZC/3Nz07RXoeHYzWiEqlLF/uRjmCZar7+Csc6O5oajurVXaINdZSnTcyFAMG0AxWZjLdEgSr8+A6y+7i9+le1t3o0/WoZ0XPfV9nOR+Scgy 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; 10 Apr 2018 20:44:17 -0000 Received: by ary.qy (Postfix, from userid 501) id BA3302466349; Tue, 10 Apr 2018 16:44:17 -0400 (EDT) Date: 10 Apr 2018 16:44:17 -0400 Message-Id: <20180410204417.BA3302466349@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: lem@uniregistry.link In-Reply-To: <91EFB193-9A81-4626-92CA-BF116826F23A@uniregistry.link> 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] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 20:44:21 -0000 In article <91EFB193-9A81-4626-92CA-BF116826F23A@uniregistry.link> you write: >Contractual changes. Not really. This is the relevant text from >https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html But the paragraph at the end of that section, Exhibit A, says: If Registry Operator wishes to place any DNS resource record type or class into its TLD DNS service (other than those listed in Sections 1.1 or 1.2 above), it must describe in detail its proposal and submit a Registry Services Evaluation Process (RSEP) request. This will be evaluated per RSEP to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS. Registry Operator recognizes and acknowledges that a service based on the use of less-common DNS resource records and/or classes in the TLD zone, even if approved, might not work as intended for all users due to lack of software support. Registries make RSEP requests all the time. They're tedious and fairly expensive, but the process is straightforward. R's, John From nobody Tue Apr 10 13:54:56 2018 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 1BD8412D77D for ; Tue, 10 Apr 2018 13:54:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 UmW1XNONG0q9 for ; Tue, 10 Apr 2018 13:54:53 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B3A1272E1 for ; Tue, 10 Apr 2018 13:54:52 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id x82so25747549wmg.1 for ; Tue, 10 Apr 2018 13:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6OEqALZa3HOA59tp824vnihskGt7+H/YeTSZ5YfNqUA=; b=gSz39jM3c9gzixZ9YdPd4a5cve06Qx9xZIS3FS6y+ex56mgb56l5WYvra6o03/yEAE b832F+ksDzpI+ywc4aJ64SCE80/wE7PqWZ1FdA6pmbXvTSqNXxEnzCXivXae71+xl7ok aPtjR9VrVRgY7SvZqlYRu7mTlss4fcZgrg1Ks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6OEqALZa3HOA59tp824vnihskGt7+H/YeTSZ5YfNqUA=; b=P1MmHYyOlp+LrM/WOTAKYDfgq78Zv9zcofvaTQ+yjODSG0RN6UwrEmpNzlf+aekM9z tti0+A1UxpkGPfbp6jBVFjK5VGpkx+caLLQPCserfYj4fLkdm2v4yTHo7R35YHqgO004 4RqkuDBuE05u7RYeRlyIjtc5yDn3iS2ITE7obYd2ik4jni1DScqXt+lXp48OqLOvO533 ylpnucR22vC2Rb7KJruN10+8kNRxPKUWIIXSl2k5bBs1uHHVfdToX0m/d9oO+lVQFdNx d8BrEq2bFq5juArfW1DxFf2dJhJLmzsdxiv4mixS6uGEpcldoFcgEyUIkb+cCpses4u2 jMfQ== X-Gm-Message-State: ALQs6tB3u9i7gMtd/H97msTfaCGsYE6tw7rmkeG3AYU8qGSxR+iEn1Eb D4/HNMil47G+HPgD+SlvZlMJV5GS5Kf4GLnX7L8Z5EZn X-Google-Smtp-Source: AIpwx49WEU5v6HBIvWFFuRHkQi6IYQeI63Gv4EXpXWp/adKKkyp+CY6yiqjwfCuNtQrhYwzk3Bqdb/k4w1EqbBMWNaM= X-Received: by 10.80.146.234 with SMTP id l39mr5587415eda.125.1523393691208; Tue, 10 Apr 2018 13:54:51 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.163.183 with HTTP; Tue, 10 Apr 2018 13:54:50 -0700 (PDT) In-Reply-To: <20180410204417.BA3302466349@ary.qy> References: <91EFB193-9A81-4626-92CA-BF116826F23A@uniregistry.link> <20180410204417.BA3302466349@ary.qy> From: "Kurt Andersen (b)" Date: Tue, 10 Apr 2018 13:54:50 -0700 X-Google-Sender-Auth: xwaRphPVZzTw35pYqoMpsoj50EM Message-ID: To: John Levine Cc: "dmarc@ietf.org" , =?UTF-8?B?THVpcyBFLiBNdcOxb3o=?= Content-Type: multipart/alternative; boundary="f403045c1f34d16041056984bb92" Archived-At: Subject: Re: [dmarc-ietf] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 20:54:55 -0000 --f403045c1f34d16041056984bb92 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 10, 2018 at 1:44 PM, John Levine wrote: > In article <91EFB193-9A81-4626-92CA-BF116826F23A@uniregistry.link> you > write: > > This is the relevant text from > >https://newgtlds.icann.org/sites/default/files/ > agreements/agreement-approved-31jul17-en.html > > But the paragraph at the end of that section, Exhibit A, says: > > If Registry Operator wishes to place any DNS resource record type or > class into its TLD DNS service (other than those listed in Sections > 1.1 or 1.2 above), it must describe in detail its proposal and submit > a Registry Services Evaluation Process (RSEP) request. This will be > evaluated per RSEP to determine whether the service would create a > risk of a meaningful adverse impact on security or stability of the > DNS. Registry Operator recognizes and acknowledges that a service > based on the use of less-common DNS resource records and/or classes in > the TLD zone, even if approved, might not work as intended for all > users due to lack of software support. > > Registries make RSEP requests all the time. They're tedious and fairly > expensive, but the process is straightforward. Is this something that could be within the remit of the dmarc-wg if we wanted to pave the way with ICANN across the board? --Kurt --f403045c1f34d16041056984bb92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 10, 2018 at 1:44 PM, John Levine <johnl@taugh.com> wro= te:
In article <91EFB193-9A81-4626-92C= A-BF116826F23A@uniregistry.link> you write:
=C2=A0This is the relevant text from
>http= s://newgtlds.icann.org/sites/default/files/agreements/agreement-a= pproved-31jul17-en.html

But the paragraph at the end of that section, Exhibit A, says:

=C2=A0If Registry Operator wishes to place any DNS resource record type or<= br> =C2=A0class into its TLD DNS service (other than those listed in Sections =C2=A01.1 or 1.2 above), it must describe in detail its proposal and submit=
=C2=A0a Registry Services Evaluation Process (RSEP) request.=C2=A0 This wil= l be
=C2=A0evaluated per RSEP to determine whether the service would create a =C2=A0risk of a meaningful adverse impact on security or stability of the =C2=A0DNS.=C2=A0 Registry Operator recognizes and acknowledges that a servi= ce
=C2=A0based on the use of less-common DNS resource records and/or classes i= n
=C2=A0the TLD zone, even if approved, might not work as intended for all =C2=A0users due to lack of software support.

Registries make RSEP requests all the time.=C2=A0 They're tedious and f= airly
expensive, but the process is straightforward.

<= div>Is this something that could be within the remit of the dmarc-wg if we = wanted to pave the way with ICANN across the board?

--Kurt=C2=A0

--f403045c1f34d16041056984bb92-- From nobody Tue Apr 10 15:44:20 2018 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 C62F012D7F5 for ; Tue, 10 Apr 2018 15:44:18 -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=CqxN6xGt; dkim=pass (1536-bit key) header.d=taugh.com header.b=lmfEcAlY 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 Re_eYH8YV4fg for ; Tue, 10 Apr 2018 15:44:16 -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 6D0EF12D7F4 for ; Tue, 10 Apr 2018 15:44:16 -0700 (PDT) Received: (qmail 45404 invoked from network); 10 Apr 2018 22:44:15 -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=b15a.5acd3e3f.k1804; bh=O/PQ/mNba0WE651JOV2xFmL+odzh6husTehTWihoDHE=; b=CqxN6xGtw+ixKTCZflmXjDYm3OwU92B2TWZ4OUtnXGqvKWpRhMPJJM+pEE5j+OAvWkFRI9khnJ9C00+rimL5Ktu9kBUMF6eegFtg2oF3vEafbfiwfUkCAQ2bcTHTks3PO+x9EEaGFUTyCH3EHBBFgfQlJgsjJrCW3IDpE0Jy4ZC8htVzBxxvDjQc6+srnFsQ/afPlHZC/l08q8/0C2KweKqqPK4FVlEygH3FCKMXjFWX/aXFXjSn1RbJpoJOrpKe 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=b15a.5acd3e3f.k1804; bh=O/PQ/mNba0WE651JOV2xFmL+odzh6husTehTWihoDHE=; b=lmfEcAlYIVXhYSWtb9QPZ7dMlvhtQyLLQwUYNVbEuLEDg7OBk2DYneo3GXPU5wRaAPQfNUFrI+KIN5AKdZKS9o7D4htd0X4DG722Nqf22pHei3CZvBj4WdbpzeZ21FY2/8s9bQ9RuONWlv+hZ3qBrg8zo1aDJb6UMIchNWspLGBVWc/xrfRQeIYG6yb6j8HKXthZaexTF/djFFbBto+TFRReKjvZSYd6Jb6TTfJkBEdBKFidEsgIYnwkBc44Wjae 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/X.509/AEAD) via TCP6; 10 Apr 2018 22:44:14 -0000 Date: 10 Apr 2018 18:44:14 -0400 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" In-Reply-To: References: <91EFB193-9A81-4626-92CA-BF116826F23A@uniregistry.link> <20180410204417.BA3302466349@ary.qy> 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] inheritance and public suffix list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 22:44:19 -0000 On Tue, 10 Apr 2018, Kurt Andersen (b) wrote: >> Registries make RSEP requests all the time. They're tedious and fairly >> expensive, but the process is straightforward. > > Is this something that could be within the remit of the dmarc-wg if we > wanted to pave the way with ICANN across the board? I believe that RSEPs have to be one registry at a time. The registry can apply for all of its domains. If we wanted it to apply to everyone, that would be a contract change. On the other hand, few of the private TLDs are used much, and I see very little mail from any of them, real or otherwise, so it doesn't seem super urgent. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Apr 10 16:49:08 2018 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 8450412D80F for ; Tue, 10 Apr 2018 16:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoI2fV9jHbSp for ; Tue, 10 Apr 2018 16:49:04 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 11C001205D3 for ; Tue, 10 Apr 2018 16:49:04 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q80so378785ioi.13 for ; Tue, 10 Apr 2018 16:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Xb4R02p0AbHEFfq7VJYwWrLsfbAZQ7GWelkvUpiHAs=; b=rXpzQbmna6vP45mENmdtj8T7AU5asdHARQfP7gcshpdQPhUT3jPBQB64yei7/TJ1hu xojeennNd232jCfPb0l6ZaJg/0wJ9HE33/FatDqU2NrfDhDvZGZXSWIjb8XhuEh5bldi H9732CZY2F0YpapwqyjkPV9yxXyGKbyyuQJbCtbf+wfnmK7OWyVXMizeT+3MFe0g0SW9 kWBhu2iuc5SpJfYBs4dHwWl5BUov2Fm50/m+LpZzy2a/x8egl7tSlF95Y8hMvrHuzoyX 37pm/PKurk/E4L/zBXAOFLld76msTj6zU1oXetmCD47bWHVpxv4VE9+EvGCchJDyBuwk zFDw== 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=9Xb4R02p0AbHEFfq7VJYwWrLsfbAZQ7GWelkvUpiHAs=; b=DtJJAFjpi+dQmlvteFGmjxB7m28GaTAj5oilLWFOVs7eucDZG77XE82s3dX/mcJk1/ HkQ7cWj3FhIQGzX0V9sklKSN7q8tzAt0nqQWnWITf9wpHdmoESuznd4Y2RttRV8v60ox lts4vtw/OaHKMHQrJxhHCvGm/qHDUf+0quD+jxLgLlKG49/KZ49Ufleexukfbv54llVb +H+jqown7xiw1rU+LMLviRaY+80gVE8ipHE7e6q4V8yr2QV4tb/lrZPmkAKqAfW+HO4P psfW//BXaP26B6vjasFyx836lNquHp/mu1QpeYyXNe0tFuWwbr17ddwgmRJEZ7yqdaTE 1TsA== X-Gm-Message-State: ALQs6tBk5mZPIHmihwUoVG8XHsd+SQqeQDfQDyqu8IHjf2W04WDGupFc 5UKLDxqqf6DMiumnTro6JDgl6AtLlkI7jIbmsu9Q X-Google-Smtp-Source: AIpwx4+1gKC27wHHxfRdW0vumIurSRB5Ke/h1PmwscDCKDXc/h6iSrudYMPE74Y5e7Mv0RHgTEgMUxGYwTkF4oul9Q4= X-Received: by 10.107.51.207 with SMTP id z198mr2692681ioz.112.1523404142817; Tue, 10 Apr 2018 16:49:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Tue, 10 Apr 2018 23:48:48 +0000 Message-ID: To: "Kurt Andersen (b)" Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a11441a96c8d8dd0569872afb" Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2018 23:49:06 -0000 --001a11441a96c8d8dd0569872afb Content-Type: text/plain; charset="UTF-8" On Tue, Apr 10, 2018 at 12:54 PM Kurt Andersen (b) wrote: > On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long wrote: > >> >> On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) >> wrote: >> >>> *I filed issue 22 after observing a discussion today on another list:* >>> >>> Pursuant to an email thread on the mailop list, we may want to consider >>> how (or if) to do something about the ways that people have developed >>> different processing handling for p=none vs. p!=none. Here's the example: >>> >>> Does anyone know of any negative side effects of setting a DMARC policy: >>> p=quarantine pct=0 ? >>> >>> Is it equivalent to: p=none ? >>> >>> I'm curious because I want to trigger Google Groups (and maybe others >>> list forwarders?) to rewrite the From in a DMARC compliant fashion *prior* >>> to changing the domain's DMARC policy... to avoid the "leap of faith" that >>> p=none's monitoring mode was supposed to alleviate. >>> >>> (https://trac.ietf.org/trac/dmarc/ticket/22#ticket) >>> >> > [looks like your email worked] > >> > >> Trying a reply from my dmarc protected address... >> What are you proposing we do? Specify what handling should be done more >> specifically in that case? >> Brandon > > > It may not be palatable, but I would consider some sort of recommendation > along the lines of "SHOULD NOT" in the to-be-revised standards-track spec > for DMARC to discourage special case processing of p=none. > Well, obviously there is some difference in handling of p=quarantine and p=none ;) I guess the question is, in terms of forwarders, should they handle those differently or not. I'm not sure how many are p=none vs p=quarantine vs no dmarc (I could look at our mail flow for some numbers, but some others on the list may have better numbers), but if a lot are at p=none, things will be yucky if it changes. Ie, right now, gmail.com/hotmail.com/outlook.com are all p=none, so changing Groups or mailman for p=none will affect a lot of folks. Brandon --001a11441a96c8d8dd0569872afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Apr 10, 2018 at 12:54 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long <blong@google.com>= wrote:

On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) <kboth@drkurt.com> wro= te:

I filed issue 22 after obse= rving a discussion today on another list:

Pursuant to an email th= read on the mailop list, we may want to consider=20 how (or if) to do something about the ways that people have developed=20 different processing handling for p=3Dnone vs. p!=3Dnone. Here's the= =20 example:

Does anyone know of any negative side effects of setting a DMARC policy: p= =3Dquarantine pct=3D0 ?

Is it equivalent to: p=3Dnone ?

I'm curious because I want to trigger Google Groups (and maybe others= =20 list forwarders?) to rewrite the From in a DMARC compliant fashion=20 *prior* to changing the domain's DMARC policy... to avoid the "lea= p of=20 faith" that p=3Dnone's monitoring mode was supposed to alleviate.<= /p>

(https://trac.ietf.org/trac/dmarc/ticket/22#ticket= )
=C2=A0
<= div>[looks like your email worked]
=C2=A0<= /div>
Trying a reply from my dmarc protected address...
What are = you proposing we do?=C2=A0 Specify what handling should be done more specif= ically in that case?
Brandon

It may= not be palatable, but I would consider some sort of recommendation along t= he lines of "SHOULD NOT" in the to-be-revised standards-track spe= c for DMARC to discourage special case processing of p=3Dnone.
<= /blockquote>

Well, obviously there is some difference in= handling of p=3Dquarantine and p=3Dnone ;)

I guess the quest= ion is, in terms of forwarders, should they handle those differently or not= .=C2=A0 I'm not sure how many are p=3Dnone vs p=3Dquarantine vs no dmar= c (I could look at our mail flow for some numbers, but some others on the l= ist may have better numbers), but if a lot are at p=3Dnone, things will be = yucky if it changes.=C2=A0 Ie, right now, gmail.com/hotmail.com/outlook.com are all p=3Dnone,= so changing Groups or mailman for p=3Dnone will affect a lot of folks.

Brandon=C2=A0
--001a11441a96c8d8dd0569872afb-- From nobody Tue Apr 10 19:36:00 2018 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 BD389129C6D for ; Tue, 10 Apr 2018 19:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Kl3qwl1I; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=jUvZJxzR 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 CLER-_i917rU for ; Tue, 10 Apr 2018 19:35:56 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23321201F8 for ; Tue, 10 Apr 2018 19:35:56 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1523414155; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ZLPMgUvvt4jOnAFGJq3EuzbF6kMef8NKL8grB8PSscE=; b=Kl3qwl1IvTBmFQqKKRXL+Nt1fqBGYyg4JDFjsVcOMd8b3Emi2oF2nkml IB3f3IjpmAbaJUqxPAozfulHa5nLBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1523414155; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ZLPMgUvvt4jOnAFGJq3EuzbF6kMef8NKL8grB8PSscE=; b=jUvZJxzRPTxAEHQ6cD1lmREw5xiRrTh6UZu13owzmEXo48QkJphiCPUf EIrab1jhp9Flx0yx5Sc6ioscanUy4HGfsEVAhI1X2ZWf2gP9lXinbbXipN ppP4uxauTtUE9IFMaYYCO1CHxCswhBhcn9t05WUIyT0V813sTjES9EVgQh HHhwCHO3gwlbNBVlcWh/lf6rZXfsqnccCd1oqEMjJm3/NLYLAC20UY0eMV UwZsuxJb4gslqKceQHiu849GEWA+AnZMdwBYd6vD9gFr4eJKXU2LBYOL81 Y/23pNN51Wqh5ph69FjHEsIl2cTZnvdJjGUNvUf58NaaMaqFVWhCwg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4733DC40284 for ; Tue, 10 Apr 2018 21:35:55 -0500 (CDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 10 Apr 2018 22:35:54 -0400 Message-ID: <4932916.R6qcFiWbi0@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-144-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] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 02:35:59 -0000 On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: > On Tue, Apr 10, 2018 at 12:54 PM Kurt Andersen (b) wrote: > > On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long wrote: > >> On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) > >> > >> wrote: > >>> *I filed issue 22 after observing a discussion today on another list:* > >>> > >>> Pursuant to an email thread on the mailop list, we may want to consider > >>> how (or if) to do something about the ways that people have developed > >>> different processing handling for p=none vs. p!=none. Here's the > >>> example: > >>> > >>> Does anyone know of any negative side effects of setting a DMARC policy: > >>> p=quarantine pct=0 ? > >>> > >>> Is it equivalent to: p=none ? > >>> > >>> I'm curious because I want to trigger Google Groups (and maybe others > >>> list forwarders?) to rewrite the From in a DMARC compliant fashion > >>> *prior* > >>> to changing the domain's DMARC policy... to avoid the "leap of faith" > >>> that > >>> p=none's monitoring mode was supposed to alleviate. > >>> > >>> (https://trac.ietf.org/trac/dmarc/ticket/22#ticket) > > > > [looks like your email worked] > > > >> Trying a reply from my dmarc protected address... > >> What are you proposing we do? Specify what handling should be done more > >> specifically in that case? > >> Brandon > > > > It may not be palatable, but I would consider some sort of recommendation > > along the lines of "SHOULD NOT" in the to-be-revised standards-track spec > > for DMARC to discourage special case processing of p=none. > > Well, obviously there is some difference in handling of p=quarantine and > p=none ;) > > I guess the question is, in terms of forwarders, should they handle those > differently or not. I'm not sure how many are p=none vs p=quarantine vs no > dmarc (I could look at our mail flow for some numbers, but some others on > the list may have better numbers), but if a lot are at p=none, things will > be yucky if it changes. Ie, right now, gmail.com/hotmail.com/outlook.com > are all p=none, so changing Groups or mailman for p=none will affect a lot > of folks. > > Brandon I'd have to rethink if p=none was really worth publishing if that happened. I guess we'd need p=none-really then. Scott K From nobody Fri Apr 13 10:28:02 2018 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 3D0BB1243F3 for ; Fri, 13 Apr 2018 10:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgkTSw5rJxbP for ; Fri, 13 Apr 2018 10:27:57 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 B085912702E for ; Fri, 13 Apr 2018 10:27:57 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f6-v6so4136753ita.2 for ; Fri, 13 Apr 2018 10:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vQC2nkR+wDluZ51wkd0yPaPxfz3i39gqa+6qB36Opa4=; b=irp8Y+nLHJhzdalxizf4WXbsSvaRgmBQUTNh7T9/yhsEwGZ2GaHxYJx8ESWYa/TKCk 9X/3/RV+KpNqY3U4AaDDPPuDW4hvbsNUf0v4Te2dnMvxIdVVt3s0eHtwaISE4teb1OrH HTsL95d+1kzv5xuO3psuBLaCZB7/3ZUp9A8PGkj5fJygK/Wyawf0Ty+cGJAzLFLi0TWv AIchxRV4AyKwspY898HB5KS1t8CvoesTZuu3lNwXSiEp3FXPp0r9bsFZMM27stkazoUf f21bLTf/5IzGAtmc7W1wh21uV2o6ESL6Zi4/c7xYXqGMyf8iARc/JnEBwZ/lgwcp7TFq JJJA== 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=vQC2nkR+wDluZ51wkd0yPaPxfz3i39gqa+6qB36Opa4=; b=H572FNK/m+oQKtyxiPyGLBqtmWt3QB3XOkt0D1MYxBW/YNe3j460rbS/lNRYPZRTr6 6KV4PdwWyvas7l8st3qpafCJpNoHYDVFuSNzhGECJKRTaIyWy5v2aAOYYCYi2IwtJNGd SlSTyy0yNKs1ppSY7rL4TP/y9LnTbP7odO9oUJfUbJeffpiQWmauQ34XNq/Wz2qKSVMJ 8lDzSEuHBtNSB55I77WZWpvUymufb97iF1N0EpxowcwUm7UvT/gc4brdqIGqGiVZ7uxK 2it0zbz3CCWr8uXJH8JvF0xJ1e9OPN04VCkYcPLFQGcH0aptJ7vaAd6W/AV8OrBpEkkt /o8Q== X-Gm-Message-State: ALQs6tC5lwBwOmcq5u8+RQJYnhkfo3YNnTqx5PdKGC83LW+mjvS4M6vL NxeuP7pifaxeyZspJ0FoTo+uOrqvR+zPTDYv1r2cB8k= X-Google-Smtp-Source: AIpwx4/wgsWCt+XLcgiyFBipjiTv0yekJvHoiG64ZVm1zQk3slKa1UkhdYOVZcCQSjNbm5ghaBI4uLBAeZTV7gQ4bSI= X-Received: by 2002:a24:3c53:: with SMTP id m80-v6mr445281ita.131.1523640476492; Fri, 13 Apr 2018 10:27:56 -0700 (PDT) MIME-Version: 1.0 References: <4932916.R6qcFiWbi0@kitterma-e6430> In-Reply-To: <4932916.R6qcFiWbi0@kitterma-e6430> From: Brandon Long Date: Fri, 13 Apr 2018 17:27:42 +0000 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ea3e30569be3181" Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 17:28:00 -0000 --0000000000005ea3e30569be3181 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 10, 2018, 7:36 PM Scott Kitterman wrote: > On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: > > On Tue, Apr 10, 2018 at 12:54 PM Kurt Andersen (b) > wrote: > > > On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long > wrote: > > >> On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) > > >> > > >> wrote: > > >>> *I filed issue 22 after observing a discussion today on another > list:* > > >>> > > >>> Pursuant to an email thread on the mailop list, we may want to > consider > > >>> how (or if) to do something about the ways that people have developed > > >>> different processing handling for p=none vs. p!=none. Here's the > > >>> example: > > >>> > > >>> Does anyone know of any negative side effects of setting a DMARC > policy: > > >>> p=quarantine pct=0 ? > > >>> > > >>> Is it equivalent to: p=none ? > > >>> > > >>> I'm curious because I want to trigger Google Groups (and maybe others > > >>> list forwarders?) to rewrite the From in a DMARC compliant fashion > > >>> *prior* > > >>> to changing the domain's DMARC policy... to avoid the "leap of faith" > > >>> that > > >>> p=none's monitoring mode was supposed to alleviate. > > >>> > > >>> (https://trac.ietf.org/trac/dmarc/ticket/22#ticket) > > > > > > [looks like your email worked] > > > > > >> Trying a reply from my dmarc protected address... > > >> What are you proposing we do? Specify what handling should be done > more > > >> specifically in that case? > > >> Brandon > > > > > > It may not be palatable, but I would consider some sort of > recommendation > > > along the lines of "SHOULD NOT" in the to-be-revised standards-track > spec > > > for DMARC to discourage special case processing of p=none. > > > > Well, obviously there is some difference in handling of p=quarantine and > > p=none ;) > > > > I guess the question is, in terms of forwarders, should they handle those > > differently or not. I'm not sure how many are p=none vs p=quarantine vs > no > > dmarc (I could look at our mail flow for some numbers, but some others on > > the list may have better numbers), but if a lot are at p=none, things > will > > be yucky if it changes. Ie, right now, > gmail.com/hotmail.com/outlook.com > > are all p=none, so changing Groups or mailman for p=none will affect a > lot > > of folks. > > > > Brandon > > I'd have to rethink if p=none was really worth publishing if that > happened. I > guess we'd need p=none-really then. > p=none pct=0 Brandon > --0000000000005ea3e30569be3181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Tue, Apr 10, 2018, 7:36 PM Scott Kitterman <sklist@kitterman.com> wrote:
On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote:<= br> > On Tue, Apr 10, 2018 at 12:54 PM Kurt Andersen (b) <kboth@drkurt.com<= /a>> wrote:
> > On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long <blong@google.com= > wrote:
> >> On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) <kboth@drk= urt.com>
> >>
> >> wrote:
> >>> *I filed issue 22 after observing a discussion today on a= nother list:*
> >>>
> >>> Pursuant to an email thread on the mailop list, we may wa= nt to consider
> >>> how (or if) to do something about the ways that people ha= ve developed
> >>> different processing handling for p=3Dnone vs. p!=3Dnone.= Here's the
> >>> example:
> >>>
> >>> Does anyone know of any negative side effects of setting = a DMARC policy:
> >>> p=3Dquarantine pct=3D0 ?
> >>>
> >>> Is it equivalent to: p=3Dnone ?
> >>>
> >>> I'm curious because I want to trigger Google Groups (= and maybe others
> >>> list forwarders?) to rewrite the From in a DMARC complian= t fashion
> >>> *prior*
> >>> to changing the domain's DMARC policy... to avoid the= "leap of faith"
> >>> that
> >>> p=3Dnone's monitoring mode was supposed to alleviate.=
> >>>
> >>> (https://trac.ietf.org= /trac/dmarc/ticket/22#ticket)
> >
> > [looks like your email worked]
> >
> >> Trying a reply from my dmarc protected address...
> >> What are you proposing we do?=C2=A0 Specify what handling sho= uld be done more
> >> specifically in that case?
> >> Brandon
> >
> > It may not be palatable, but I would consider some sort of recomm= endation
> > along the lines of "SHOULD NOT" in the to-be-revised st= andards-track spec
> > for DMARC to discourage special case processing of p=3Dnone.
>
> Well, obviously there is some difference in handling of p=3Dquarantine= and
> p=3Dnone ;)
>
> I guess the question is, in terms of forwarders, should they handle th= ose
> differently or not.=C2=A0 I'm not sure how many are p=3Dnone vs p= =3Dquarantine vs no
> dmarc (I could look at our mail flow for some numbers, but some others= on
> the list may have better numbers), but if a lot are at p=3Dnone, thing= s will
> be yucky if it changes.=C2=A0 Ie, right now, gmail.com/hotmail.com/outlook.com
> are all p=3Dnone, so changing Groups or mailman for p=3Dnone will affe= ct a lot
> of folks.
>
> Brandon

I'd have to rethink if p=3Dnone was really worth publishing if that hap= pened.=C2=A0 I
guess we'd need p=3Dnone-really then.

p=3Dnone pct=3D0

Brandon
--0000000000005ea3e30569be3181-- From nobody Sun Apr 15 21:19:43 2018 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 53535126B6D for ; Sun, 15 Apr 2018 21:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.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 2glNyZrB28uj for ; Sun, 15 Apr 2018 21:19:39 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 37CAD124205 for ; Sun, 15 Apr 2018 21:19:39 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id y66so9911405pfi.7 for ; Sun, 15 Apr 2018 21:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=mH0l5kP7mq15aih9jgdUe9C1JnIGET+eCKFX1VRRKjw=; b=dDP7OPdN826/V+YjXKkn3kaRkR1TRpdZjqUcE38JZ+VjxGmWM2KkyUIb/mcAYnlZzO A/QwS+Rw61vTPQsgvM4RSz0PI5t4VwJDzLp2pIlyA97F2LZj7g2m/Ar6fOit20t4w5Tp kLx4RDHj9idXR9cPRNl6TBhjL+VG8fWzVacVA1nK0eQG8xc8dGHJe7+i3CieXePJIkWq gv2pPPflDj98y9esU4VDvX5EegZqRGpIBG66hDh3jcl2GD9VFqwvTgLy39kHTzs74mjh OAs7oZ+yuS7WKv4wPqiirQlqhlFx2juEBQFy8G4IVP3cWHMr0OLcFYBogUYCsG9W2tyw u1OA== 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=mH0l5kP7mq15aih9jgdUe9C1JnIGET+eCKFX1VRRKjw=; b=fLZhwlJOYShL6oBYEs9jVvqme8BMY/ez/8iFJCN1hsYvApAjkPD53/Q1SAK7ZPHWlb 7aPLzA7bL+8f28OaxcNs4cgQyYtuJHDR1TIcyhIkYEdg3824phiMWi4K+yeGM1le0r08 tKci7bMxk/qbWIBrub7+CnSG3Vk2chFWvqhQ1G16cxGTT72tt53gJKSw37K5TSZOm4Wg EcD+G7hyrD3XsICxZfw3UkfHupnlmWs4ngNfOJ7CxXbwi3xbdA5Q31JwpwYbcvb/KeB7 NIUT1pvNt4mZWlLn2GKkSX8FHd4hukn/EbBitYg3A387VKvnOr9i5OettgrZV1m56mQt sw7A== X-Gm-Message-State: ALQs6tBjBJDm9HNJxEbd+xWlpwbwuHrTSpPjKtpxTAA4vQ59LzF2xetK uLVvwL1EcM2dM0jDxVJk2NFJFBcGD7IAhPZkicU1sA8MGraMyRpesLfqVjzSr76YJeQoH6/TKkW ChbhCV0FL76CriIYNEqHaT1Q6JJ8mjMKtEt63vmJZTRaebX9BHz/4tA8axC1W X-Google-Smtp-Source: AIpwx4/3Blao8N4Fyc/0D6UhCqeu6lZ0GmPvoYYRDJTNcEnpZ76I87AJk/AcLMGzQQpzNNk2Ytzmig== X-Received: by 10.167.128.217 with SMTP id a25mr20178766pfn.132.1523852378080; Sun, 15 Apr 2018 21:19:38 -0700 (PDT) Received: from [192.168.30.84] ([150.249.212.66]) by smtp.gmail.com with ESMTPSA id g127sm18268868pgc.6.2018.04.15.21.19.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Apr 2018 21:19:37 -0700 (PDT) To: dmarc@ietf.org References: <5AA30505.6080901@isdg.net> <401ecb2f-6dae-24d3-06dc-fa91584844cd@crash.com> From: Shoko YONEZAWA Message-ID: <3cfa6921-e5ed-192b-3c04-b771f4ab1453@lepidum.co.jp> Date: Mon, 16 Apr 2018 13:19:33 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 04:19:41 -0000 Dear all, In IETF 101, Genki gave a presentation about "virtual DMARC." https://datatracker.ietf.org/meeting/101/materials/slides-101-dmarc-virtual-dmarc-dmarc-verification-without-record-definitions-00 https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/ Here is an implementation of virtual DMARC, based on a milter program YENMA. https://github.com/lepidum/yenma/tree/vDMARC Your trial use and feedback are appreciated. Thank you for your comments on virtual DMARC. We know there are a lot of things to be considered. Further comments are welcome. Best regards, Shoko On 2018/03/20 18:35, Kurt Andersen (b) wrote: > On Mon, Mar 19, 2018 at 7:14 PM, Steven M Jones > wrote: > > I want to thank Yasutaka san for presenting the Virtual DMARC > proposal. I believe the situation he and his colleagues are > addressing would benefit from more attention. > > Aside from changes to the "dmarc=" allowed values in > Authentication-Results: - and I think this echos a point made during > the session - the underlying issue seems to be the use of > DMARC-style alignment checks in the absence of a DMARC policy record. > > > In some hallway discussion after the session yesterday, we discussed the > assertion (made during the meeting) that all of the necessary > information to evaluate alignment is already present within the headers > on a message. While that is true for the initial receiver, there are > scenarios for intermediated mail where the 5322.From may be modified > (for instance, SRS processing) and as such, the alignment of the > original message may not be able to be deduced by downstream MTAs. It > may be worthwhile to consider earmarking the 5322.From domain into ARC's > AAR header to cover such a scenario. Whether that information should > also be recorded into the A-R header is less clear. > > I think it is pretty clear that this is not and can not be "DMARC" > without sender participation, but alignment of identifiers can certainly > be recorded for downstream usage. > > --Kurt > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Mon Apr 16 11:01:39 2018 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 EFF47127909 for ; Mon, 16 Apr 2018 11:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 dP6-ce99bFWx for ; Mon, 16 Apr 2018 11:01:36 -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 3B64C12426E for ; Mon, 16 Apr 2018 11:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1523901694; bh=RYZ574vt6mLYGg+7xKX9Ie1r/e3keDf5iJr7T8GuMWI=; l=1446; h=To:References:From:Date:In-Reply-To; b=AqXh3yLVEH6EUypkybuZXRCccNbPs1I5INYjsOWfQN3DYHHyNv7KuOCocBKZAvx3s t8d74fw6OQ0uYHdoVJZZir71S6LKZaqX0mlAl5UpIp89i8FfomKbWp9TqB9QuGkDNi xmoECBzOQyG7ZToK8/x7Cr0W1hjefnmi+ypZdCdaHMQG703TD4LW9LJBPd41A 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; Mon, 16 Apr 2018 20:01:34 +0200 id 00000000005DC077.000000005AD4E4FE.00007CE2 To: dmarc@ietf.org References: <4932916.R6qcFiWbi0@kitterma-e6430> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> Date: Mon, 16 Apr 2018 20:01:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <4932916.R6qcFiWbi0@kitterma-e6430> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:01:38 -0000 On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote:  > On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: >> >> Well, obviously there is some difference in handling of p=quarantine and >> p=none ;) >> >> I guess the question is, in terms of forwarders, should they handle those >> differently or not. I'm not sure how many are p=none vs p=quarantine vs no >> dmarc (I could look at our mail flow for some numbers, but some others on >> the list may have better numbers), but if a lot are at p=none, things will >> be yucky if it changes. Ie, right now, gmail.com/hotmail.com/outlook.com >> are all p=none, so changing Groups or mailman for p=none will affect a lot >> of folks. > > I'd have to rethink if p=none was really worth publishing if that happened. I > guess we'd need p=none-really then. Given that From: rewriting is the de-facto standard, this WG should publish an RFC about that, including recommendations and caveats about how to do it. Its Security Considerations, for example, should mention cases like, say: From: The POTUS via phishing-attempt X-Original-From: The POTUS For a personal opinion, I don't know what is the purpose of having GG rewrite From:'s of a given domain. Perhaps, it is to let users participate to groups without revealing their real addresses to spammers. That sounds legitimate to me... Ale -- From nobody Mon Apr 16 16:23:40 2018 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 5B70F12D7F6 for ; Mon, 16 Apr 2018 16:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5fov2s7yZXT for ; Mon, 16 Apr 2018 16:23:29 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CAB12D779 for ; Mon, 16 Apr 2018 16:23:29 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id v13so20159578iob.6 for ; Mon, 16 Apr 2018 16:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x6/i4UrjBhimLEJeBQdj1MiEXpUOhIOrPB+bz5r3mgA=; b=o4MIot1fK6Gxo54OE2YkceiqTie503gDPsA7apDQbaihNT77EprE06rs88ZiuKhi0U zWs1AqQwnrUwY2CLLhqrmnMm7F4ApRUPVFheE4eUQ+yspXSU9gsCOYaUP15L0nYv1mqb TgVaq6fCVKmljF7EO1g6F4B0RK9Kin0Tb1avdI39oUlzeVlPmmM14lVB/a7D1XV2Ee1L tvxstmechoImkyAx7rGBBYi/zukYbiC2w8HngyCDydhpxse4SvlbksI8NAReest+bY/+ fHgeQj3h8+vhwyL4uzPadW6fe8gWtu3R+9/WxIODgg7W9Ur9TKYuUyPvWtz7XMQBP+ab k4Xg== 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=x6/i4UrjBhimLEJeBQdj1MiEXpUOhIOrPB+bz5r3mgA=; b=ow8u8Q7SptJBD9Znsk9o/OCivTie3inNeTjMnkfFz9lqqWD89sTNkttJLxMtck59kS KgDujWBecT5xcroEfT8JSQ+k+pHb+C5iY5NNDVS7gW7PAUD0BEGxDjCYrWSOJ2bQzdQN b8jOnvUGJOQHLD15tY5VJ2Ftv8yK+rBPZQT15bhkwhsAObU7QIKGusG+7/nBjfieNvuE Bg5gU1aLcSaWdpbbhYZ0CzyrgaFE0tbAaNuEZQYaj2W7tdsmo90CbxWOlozCGkh9HFf1 U+yY5A767MTKcK63gEwiw4sxPsjAZI43XzZ5ewVgrPnrqB/dM4su+uxe9771xdLwlPvl Nmcw== X-Gm-Message-State: ALQs6tDOZ0Fg7B7Hnfjj8OJezAVCJqHncIIynuLshDmBS+RiA7GX2ZJP uTGRrFC0URqH7D6aOpua9HZHrehFGzoQPvcft6GPjX0= X-Google-Smtp-Source: AIpwx489xZi09RPW8b4oHeFQQ5KEMheOJNZ+b6FegjtnQGcCs3b+WTu2jZwCMn729E2/LEsh2C4vTbekoSKJDuTL0QY= X-Received: by 10.107.158.79 with SMTP id h76mr25314390ioe.199.1523921008481; Mon, 16 Apr 2018 16:23:28 -0700 (PDT) MIME-Version: 1.0 References: <4932916.R6qcFiWbi0@kitterma-e6430> <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> In-Reply-To: <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> From: Brandon Long Date: Mon, 16 Apr 2018 23:23:17 +0000 Message-ID: To: Alessandro Vesely Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1140c1ba60fc6c0569ff8211" Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 23:23:34 -0000 --001a1140c1ba60fc6c0569ff8211 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely wrote: > On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote: > > On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: > >> > >> Well, obviously there is some difference in handling of p=quarantine and > >> p=none ;) > >> > >> I guess the question is, in terms of forwarders, should they handle > those > >> differently or not. I'm not sure how many are p=none vs p=quarantine > vs no > >> dmarc (I could look at our mail flow for some numbers, but some others > on > >> the list may have better numbers), but if a lot are at p=none, things > will > >> be yucky if it changes. Ie, right now, > gmail.com/hotmail.com/outlook.com > >> are all p=none, so changing Groups or mailman for p=none will affect a > lot > >> of folks. > > > > I'd have to rethink if p=none was really worth publishing if that > happened. I > > guess we'd need p=none-really then. > > Given that From: rewriting is the de-facto standard, this WG should > publish an > RFC about that, including recommendations and caveats about how to do it. > > Its Security Considerations, for example, should mention cases like, say: > > From: The POTUS via phishing-attempt > X-Original-From: The POTUS > > > For a personal opinion, I don't know what is the purpose of having GG > rewrite > From:'s of a given domain. Perhaps, it is to let users participate to > groups > without revealing their real addresses to spammers. That sounds > legitimate to > me... > Do you mean, that user's don't understand why some are rewritten and some aren't? That's definitely true, and an interesting question as to whether Groups should always rewrite. Brandon --001a1140c1ba60fc6c0569ff8211 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Apr 16, 2018 at 11:01 AM Alessandro Vesely <vesely@tana.it> wrote:
On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote:=C2=A0
> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote:
>>
>> Well, obviously there is some difference in handling of p=3Dquaran= tine and
>> p=3Dnone ;)
>>
>> I guess the question is, in terms of forwarders, should they handl= e those
>> differently or not.=C2=A0 I'm not sure how many are p=3Dnone v= s p=3Dquarantine vs no
>> dmarc (I could look at our mail flow for some numbers, but some ot= hers on
>> the list may have better numbers), but if a lot are at p=3Dnone, t= hings will
>> be yucky if it changes.=C2=A0 Ie, right now, gmail.= com/hotmail.com/outlook.com
>> are all p=3Dnone, so changing Groups or mailman for p=3Dnone will = affect a lot
>> of folks.
>
> I'd have to rethink if p=3Dnone was really worth publishing if tha= t happened.=C2=A0 I
> guess we'd need p=3Dnone-really then.

Given that From: rewriting is the de-facto standard, this WG should publish= an
RFC about that, including recommendations and caveats about how to do it.
Its Security Considerations, for example, should mention cases like, say:
=C2=A0 =C2=A0 From: The POTUS via phishing-attempt <obscure@phisherman.example.= com>
=C2=A0 =C2=A0 X-Original-From: The POTUS <potus@whitehouse.gov>


For a personal opinion, I don't know what is the purpose of having GG r= ewrite
From:'s of a given domain.=C2=A0 Perhaps, it is to let users participat= e to groups
without revealing their real addresses to spammers.=C2=A0 That sounds legit= imate to
me...

Do you mean, that user's don&= #39;t understand why some are rewritten and some aren't?

=
That's definitely true, and an interesting question as to wh= ether Groups should always rewrite.

Brandon=C2=A0<= /div>
--001a1140c1ba60fc6c0569ff8211-- From nobody Mon Apr 16 23:08:01 2018 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 02F4712D93E for ; Mon, 16 Apr 2018 23:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 (1024-bit key) header.d=bbsec.co.jp 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 mo2EH6HBeFrP for ; Mon, 16 Apr 2018 23:07:57 -0700 (PDT) Received: from sproxy42.aams4.jp (sproxy42.aams4.jp [IPv6:2001:278:1047:410::30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D106126D3F for ; Mon, 16 Apr 2018 23:07:57 -0700 (PDT) Received: from aquarius.bbsec.co.jp ([IPv6:2404:7a00:100:4232:60a2:98ac:ec42:495a]) (authenticated bits=0) by sproxy42.aams4.jp (Sentrion-MTA-4.0.2/Switch-3.3.4) with ESMTP id w3H67rsB002677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 17 Apr 2018 15:07:54 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbsec.co.jp; s=20150430; t=1523945274; bh=fzPQtNlhqZYw9Cxoz83pq+YNZ13aR6UrTDrh47 kN4F0=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YliBG4+JLHfy uEHER52sAkqPoVrXg00iUhYOyQeR+Vmoqk2J6YeiNnubz5lagOlf2o5sRQKv0x8r23Q Ul9S+TtPxFgCuzsGKuBZNu+hHzir4TnudEV52Ybl4D4qt7pKEbsB3f5LPHLwn2yFARR MWPMAqI/F98sNnBoH0mC0NUuA= To: dmarc@ietf.org References: <401ecb2f-6dae-24d3-06dc-fa91584844cd@crash.com> <3441720.hKJZRnDj7p@kitterma-e6430> From: Kazunori ANDO Message-ID: <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> Date: Tue, 17 Apr 2018 15:07:52 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3441720.hKJZRnDj7p@kitterma-e6430> Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Language: en-US Content-Transfer-Encoding: 7bit X-AAMS-Virus-Status: clean Archived-At: Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 06:08:00 -0000 +1. I think "virtual DMARC" is out of DMARC scope, because it's a purely internal policy decision. On 2018/03/20 6:17, Scott Kitterman wrote: > Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in > nature of SPF and DMARC and should be considered harmful. If an entity wants > to apply this kind of test, it's a purely internal policy decision. No RFC > needed.-- Kazunori ANDO / ando@bbsec.co.jp From nobody Tue Apr 17 04:16:20 2018 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 BE64A129C53 for ; Tue, 17 Apr 2018 04:16:18 -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 nobgFZAOiocA for ; Tue, 17 Apr 2018 04:16:17 -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 41C4C1275FD for ; Tue, 17 Apr 2018 04:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1523963465; bh=BAyRi6UdukjennGdd8NeLGUiBViM6ItzKn60CPCFICM=; l=2724; h=To:Cc:References:From:Date:In-Reply-To; b=AsaIa9IPF60aPvBN5qYVAPs+lQtj/RBN8W/LuyVAtL7C4Ky1b5CGRcpb5nGm9oSRz kpi6a6rvS1xpf18YKssPLx1qT+XQGHyzboXd3DYv2Jy4UBmB3pL6A7tVf8ABAZ1ly3 oX4MrDAJIZYo8Px9ET7ZKwbt9hAikt0CUQ069qpqgHArQvo+GR2tT0ZTp5AA7 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; Tue, 17 Apr 2018 13:11:05 +0200 id 00000000005DC07C.000000005AD5D649.000074AC To: Brandon Long Cc: dmarc@ietf.org References: <4932916.R6qcFiWbi0@kitterma-e6430> <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 17 Apr 2018 13:11:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 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] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 11:16:19 -0000 On Tue 17/Apr/2018 01:23:17 +0200 Brandon Long wrote:  > On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely wrote: >> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote: >>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: >>>> >>>> Well, obviously there is some difference in handling of p=quarantine and >>>> p=none ;) >>>> >>>> I guess the question is, in terms of forwarders, should they handle >>>> those differently or not. I'm not sure how many are p=none vs >>>> p=quarantine vs no dmarc (I could look at our mail flow for some >>>> numbers, but some others on the list may have better numbers), but if >>>> a lot are at p=none, things will be yucky if it changes. Ie, right >>>> now, gmail.com/hotmail.com/outlook.com are all p=none, so changing >>>> Groups or mailman for p=none will affect a lot of folks.>>> >>> I'd have to rethink if p=none was really worth publishing if that happened. I >>> guess we'd need p=none-really then. >> >> Given that From: rewriting is the de-facto standard, this WG should >> publish an RFC about that, including recommendations and caveats about how >> to do it.>> >> Its Security Considerations, for example, should mention cases like, say: >> >> From: The POTUS via phishing-attempt >> X-Original-From: The POTUS >> >> >> For a personal opinion, I don't know what is the purpose of having GG >> rewrite From:'s of a given domain. Perhaps, it is to let users >> participate to groups without revealing their real addresses to spammers. >> That sounds legitimate to me...> > Do you mean, that user's don't understand why some are rewritten and some > aren't? Some may understand. I recall when it was rather common to see addresses like, say, blong@NOSPAMgoogle.com, supposedly obvious to human subscribers. As email authentication took on, tools tended to disallow such kind of free editing of From: (a trend that possibly impacted negatively on posters' ability to understand email mechanisms.) Now, servers should supply something else to provide a similar grade of privacy to mailing list subscribers. The address blong=40google.com@dmarc.ietf.org (to which I'm writing) results in a similar soft concealing as the former example. However, the X-Original-From betrays such purpose. > That's definitely true, and an interesting question as to whether Groups > should always rewrite. Yes, and I bet there are various other interesting questions as well. rfc7960 quickly covers the whole topic in the first bullet of Section 4.1.3.3. And, as an informative rfc, it makes no recommendations. This WG can do better than that. Ale -- From nobody Tue Apr 17 04:16:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8612EB65 for ; Tue, 17 Apr 2018 04:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523963786; bh=1Gx7lLkTT+spZHWtgeKJ9viT0lsQrOj9d8vHUJVp3pg=; h=Subject:Cc:References:From:Date:In-Reply-To:To; b=JbYyq+hed7ahIUDgCzBLErjZ5tLmPkRmmG42Ct/RtwXkmwcK7jb/MVJEnzzfNyvl6 FiUFAw3GdTQ25buiLNnbwVlmDOdx0I0b+3HoS8tg/bhGRNS1tFWFVMNdGjYtrl7i7q P7ISgXLUfTGfj521FwwSqmbgGou2xAkaeGCK+/Fc= X-Mailbox-Line: From vesely@tana.it Tue Apr 17 04:16:24 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFE312EB42 for ; Tue, 17 Apr 2018 04:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523963784; bh=1Gx7lLkTT+spZHWtgeKJ9viT0lsQrOj9d8vHUJVp3pg=; h=Subject:Cc:References:From:Date:In-Reply-To:To; b=D2Z7arGf+CDfCCu7hI98r9em1xXDimLa3pjJ6AdkFQJUdrXYKPv/Y9+AUXRTWujC6 Xq8JCIVoGmRbQOa9NyMpNJ78/P/2OdhOCJEfSOBf3szEj7HVcVVn6Akq07/jfEet1J YpLorTrzecFqPYiC9wx/CIqXYLO1+d9GQFC+CC5I= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5EB12EB28 for ; Tue, 17 Apr 2018 04:16:22 -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=unavailable 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 XKG9TjfeTrr9 for ; Tue, 17 Apr 2018 04:16:20 -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 72E881275FD for ; Tue, 17 Apr 2018 04:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1523963465; bh=BAyRi6UdukjennGdd8NeLGUiBViM6ItzKn60CPCFICM=; l=2724; h=To:Cc:References:From:Date:In-Reply-To; b=AsaIa9IPF60aPvBN5qYVAPs+lQtj/RBN8W/LuyVAtL7C4Ky1b5CGRcpb5nGm9oSRz kpi6a6rvS1xpf18YKssPLx1qT+XQGHyzboXd3DYv2Jy4UBmB3pL6A7tVf8ABAZ1ly3 oX4MrDAJIZYo8Px9ET7ZKwbt9hAikt0CUQ069qpqgHArQvo+GR2tT0ZTp5AA7 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; Tue, 17 Apr 2018 13:11:05 +0200 id 00000000005DC07C.000000005AD5D649.000074AC Cc: dmarc@ietf.org References: <4932916.R6qcFiWbi0@kitterma-e6430> <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 17 Apr 2018 13:11:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit To: Brandon Long Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 11:16:27 -0000 On Tue 17/Apr/2018 01:23:17 +0200 Brandon Long wrote:  > On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely wrote: >> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote: >>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: >>>> >>>> Well, obviously there is some difference in handling of p=quarantine and >>>> p=none ;) >>>> >>>> I guess the question is, in terms of forwarders, should they handle >>>> those differently or not. I'm not sure how many are p=none vs >>>> p=quarantine vs no dmarc (I could look at our mail flow for some >>>> numbers, but some others on the list may have better numbers), but if >>>> a lot are at p=none, things will be yucky if it changes. Ie, right >>>> now, gmail.com/hotmail.com/outlook.com are all p=none, so changing >>>> Groups or mailman for p=none will affect a lot of folks.>>> >>> I'd have to rethink if p=none was really worth publishing if that happened. I >>> guess we'd need p=none-really then. >> >> Given that From: rewriting is the de-facto standard, this WG should >> publish an RFC about that, including recommendations and caveats about how >> to do it.>> >> Its Security Considerations, for example, should mention cases like, say: >> >> From: The POTUS via phishing-attempt >> X-Original-From: The POTUS >> >> >> For a personal opinion, I don't know what is the purpose of having GG >> rewrite From:'s of a given domain. Perhaps, it is to let users >> participate to groups without revealing their real addresses to spammers. >> That sounds legitimate to me...> > Do you mean, that user's don't understand why some are rewritten and some > aren't? Some may understand. I recall when it was rather common to see addresses like, say, blong@NOSPAMgoogle.com, supposedly obvious to human subscribers. As email authentication took on, tools tended to disallow such kind of free editing of From: (a trend that possibly impacted negatively on posters' ability to understand email mechanisms.) Now, servers should supply something else to provide a similar grade of privacy to mailing list subscribers. The address blong=40google.com@dmarc.ietf.org (to which I'm writing) results in a similar soft concealing as the former example. However, the X-Original-From betrays such purpose. > That's definitely true, and an interesting question as to whether Groups > should always rewrite. Yes, and I bet there are various other interesting questions as well. rfc7960 quickly covers the whole topic in the first bullet of Section 4.1.3.3. And, as an informative rfc, it makes no recommendations. This WG can do better than that. Ale -- From nobody Tue Apr 17 08:41:57 2018 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 C376412D94B for ; Tue, 17 Apr 2018 08:41: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, 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=wordtothewise.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 TFlamv5upRGu for ; Tue, 17 Apr 2018 08:41:54 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4A86612D941 for ; Tue, 17 Apr 2018 08:41:54 -0700 (PDT) Received: from [192.168.80.21] (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1A45123379 for ; Tue, 17 Apr 2018 08:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1523979770; bh=j+wXVCO6Rf1mByROBKCDC2epz4XxLlRhytSKfPJlrco=; h=From:Subject:Date:References:To:In-Reply-To:From; b=TzFKBFhIjLtlI06F8zovJG86c+r0KAaMUczZvVYzmPpqkBIXfc9YhAEq30vlkcJFa PeZbTGOzJPZQuCpIrzmZvew4uVZRvwh/Tls7cNtfDmm2hFM3vsPHUtuB37bRDxnnxX SswjOWzkLWYjK7nfIjYh6A1s3hDDrf9Zz24JniUg= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 17 Apr 2018 08:41:52 -0700 References: <401ecb2f-6dae-24d3-06dc-fa91584844cd@crash.com> <3441720.hKJZRnDj7p@kitterma-e6430> <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> To: dmarc In-Reply-To: <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> Message-Id: <7252667E-627B-4249-9168-5D1E2A30FEB9@wordtothewise.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:41:56 -0000 > On Apr 16, 2018, at 11:07 PM, Kazunori ANDO wrote: >=20 > I think "virtual DMARC" is out of DMARC scope, > because it's a purely internal policy decision. +1 for the (not entirely unreasonable, but entirely internal) algorithm = used, -1 for the terminology. Where it's in scope is that it's using the term DMARC for something that = is really not DMARC and as part of that it seems to suggest squatting on = the dmarc=3D namespace in Authentication-Results.=20 On 2018/03/20 6:17, Scott Kitterman wrote: > Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the = opt-in > nature of SPF and DMARC and should be considered harmful. +1 Again, please don't do this. Cheers, Steve From nobody Tue Apr 17 08:59:39 2018 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 4A53B12D942 for ; Tue, 17 Apr 2018 08:59:38 -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, 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=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 SqIrDFpanxDU for ; Tue, 17 Apr 2018 08:59:36 -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 8FE3312D86A for ; Tue, 17 Apr 2018 08:59:36 -0700 (PDT) Received: from [192.168.99.63] (SANTA-CLARA.ear2.SanJose1.Level3.net [4.53.30.222]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w3HG1DmB018446 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Apr 2018 09:01:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1523980874; bh=O6LJs4fkhURzCvfhKiNrbJrULjQnhkWc59wYYi4CEwo=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=kY8Q8LTWeT41xQZD1tTD78I2Sj83oaEtqVYicvj1OFTJkmq9JgfnJlmZF7vqYyeS+ Htv8A3K9I/82KE6F4G2/YGedm2VlKMJC32uOwY/gfmtuocKA6qwhdRHqP3z4ORK3mU dPuUGiXli7KjpUiJtUfofvaUcA5nqlYJ/WjzERrM= To: dmarc References: <401ecb2f-6dae-24d3-06dc-fa91584844cd@crash.com> <3441720.hKJZRnDj7p@kitterma-e6430> <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> <7252667E-627B-4249-9168-5D1E2A30FEB9@wordtothewise.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <08a3c8b7-8419-48ec-17e0-6dc4c3e89c0a@dcrocker.net> Date: Tue, 17 Apr 2018 08:59:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7252667E-627B-4249-9168-5D1E2A30FEB9@wordtothewise.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:59:38 -0000 +1, for all of the below. d/ On 4/17/2018 8:41 AM, Steve Atkins wrote: > >> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO wrote: >> >> I think "virtual DMARC" is out of DMARC scope, >> because it's a purely internal policy decision. > > +1 for the (not entirely unreasonable, but entirely internal) algorithm used, -1 for the terminology. > > Where it's in scope is that it's using the term DMARC for something that is really not DMARC and as part of that it seems to suggest squatting on the dmarc= namespace in Authentication-Results. > > On 2018/03/20 6:17, Scott Kitterman wrote: >> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in >> nature of SPF and DMARC and should be considered harmful. > > +1 > > Again, please don't do this. > > Cheers, > Steve > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Apr 17 16:46:45 2018 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 8EB4A1272E1 for ; Tue, 17 Apr 2018 16:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw3aMmMwf94U for ; Tue, 17 Apr 2018 16:46:42 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 134261270A0 for ; Tue, 17 Apr 2018 16:46:42 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id a7-v6so258506ioc.12 for ; Tue, 17 Apr 2018 16:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zNcz9ZEteupfcDaWQSUDuDUD+J1VqFBKFyA1ZFUjRLc=; b=JfC7RRWuk1t4uKRDbiEJZgEqkldZZ9Lyd7Gvxo4CP9E0pnfc5XCvFM8VCRgPGfgkia DcYY80du6E6wmNAd2pS7OSf2gSiv0d9NIGg5MrhyOt1ZQ80vMU3GHfpsVhXUkm3cfsBN W+mdXh8rxHUsrx7BQe4o/+MNG9G6i6CWCY8OApVbjFrDlYTNfwJYQ9xOmaxBDNe53ztb 9Ydsn/T3SoeRe+HKwamqlOFL8IP5/lVvhdivTq40dkZbuSEW43d0zyFZwbv+qxZw8O0s oz7pFlIRjAXDFqUbyR6VTwozQhcZPhLKfTYQVpIcbt6iQ9JH0RGwBr35Lwz8RtFIeCnA ZU1g== 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=zNcz9ZEteupfcDaWQSUDuDUD+J1VqFBKFyA1ZFUjRLc=; b=pKe0Lu4d3wLTPygqwuvqm3dgD9M5Sb3oYAHoKYzpIihVtOt8AhejRcrOJVLWwE80oa TsFERwYlRo6h8Y3YqTeQL5RD9yRjAb0karawuPh/F5tlrw4HFBBWFDQp9pxpj8FkxioZ GJ0/Brw0/6SB7J/a5ibA8ADHMq50aaE53fC5OfBZOtfjTp8yKYOa076evGZ70TraDG2d RTX/q/ZoRP21Zee9mv22HTMO4aDY/BZUdLPBM717OvUTtKEibutHAMhzvY2bITUMgiYM M1vNgThxpjZisriGSpk1LKv/XKI1x7E1TkWOFc1k8EXN7SeyuDyOG2nw+yLtkLa7obaf 6DOA== X-Gm-Message-State: ALQs6tARngsqOLDsoIK4STxJvNFZScunMocKJn6vjAtaWLLWkTdZHa2F hkfSqnaExlMOdg4ycOSmxvC3qteK+h0aM9FLjbzpfeU= X-Google-Smtp-Source: AIpwx4990lLaHZXMGhDaEyVIbHZaqldslYL1TKHBBQtOoa3VnRIXZH3DnehqevK3ayKcoUdUXjgW3FKzUw+ZBImpYEA= X-Received: by 10.107.158.66 with SMTP id h63mr3839310ioe.30.1524008800796; Tue, 17 Apr 2018 16:46:40 -0700 (PDT) MIME-Version: 1.0 References: <4932916.R6qcFiWbi0@kitterma-e6430> <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> In-Reply-To: From: Brandon Long Date: Tue, 17 Apr 2018 23:46:26 +0000 Message-ID: To: Alessandro Vesely Cc: blong=40google.com@dmarc.ietf.org, dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1140c830354c65056a13f335" Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 23:46:44 -0000 --001a1140c830354c65056a13f335 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 17, 2018 at 4:16 AM Alessandro Vesely wrote: > On Tue 17/Apr/2018 01:23:17 +0200 Brandon Long wrote: > > On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely > wrote: > >> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote: > >>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: > >>>> > >>>> Well, obviously there is some difference in handling of p=quarantine > and > >>>> p=none ;) > >>>> > >>>> I guess the question is, in terms of forwarders, should they handle > >>>> those differently or not. I'm not sure how many are p=none vs > >>>> p=quarantine vs no dmarc (I could look at our mail flow for some > >>>> numbers, but some others on the list may have better numbers), but if > >>>> a lot are at p=none, things will be yucky if it changes. Ie, right > >>>> now, gmail.com/hotmail.com/outlook.com are all p=none, so changing > >>>> Groups or mailman for p=none will affect a lot of folks.>>> > >>> I'd have to rethink if p=none was really worth publishing if that > happened. I > >>> guess we'd need p=none-really then. > >> > >> Given that From: rewriting is the de-facto standard, this WG should > >> publish an RFC about that, including recommendations and caveats about > how > >> to do it.>> > >> Its Security Considerations, for example, should mention cases like, > say: > >> > >> From: The POTUS via phishing-attempt < > obscure@phisherman.example.com> > >> X-Original-From: The POTUS > >> > >> > >> For a personal opinion, I don't know what is the purpose of having GG > >> rewrite From:'s of a given domain. Perhaps, it is to let users > >> participate to groups without revealing their real addresses to > spammers. > >> That sounds legitimate to me...> > > Do you mean, that user's don't understand why some are rewritten and some > > aren't? > > Some may understand. I recall when it was rather common to see addresses > like, > say, blong@NOSPAMgoogle.com, supposedly obvious to human subscribers. As > email > authentication took on, tools tended to disallow such kind of free editing > of > From: (a trend that possibly impacted negatively on posters' ability to > understand email mechanisms.) Now, servers should supply something else to > provide a similar grade of privacy to mailing list subscribers. The > address > blong=40google.com@dmarc.ietf.org (to which I'm writing) results in a > similar > soft concealing as the former example. However, the X-Original-From > betrays > such purpose. > Frankly, the number of people who did that was vanishingly small, and the general utility of such things was also pretty tiny. The major mailing list providers did a better job of just not publishing the email address unhidden in the archives. Brandon --001a1140c830354c65056a13f335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Apr 17, 2018 at 4:16 AM Alessandro Vesely <vesely@tana.it> wrote:
vesely@tana.it> wrote:
>> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote:
>>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote:
>>>>
>>>> Well, obviously there is some difference in handling of p= =3Dquarantine and
>>>> p=3Dnone ;)
>>>>
>>>> I guess the question is, in terms of forwarders, should th= ey handle
>>>> those differently or not.=C2=A0 I'm not sure how many = are p=3Dnone vs
>>>> p=3Dquarantine vs no dmarc (I could look at our mail flow = for some
>>>> numbers, but some others on the list may have better numbe= rs), but if
>>>> a lot are at p=3Dnone, things will be yucky if it changes.= =C2=A0 Ie, right
>>>> now, gmail.com/hotmail.com/outlook.com = are all p=3Dnone, so changing
>>>> Groups or mailman for p=3Dnone will affect a lot of folks.= >>>
>>> I'd have to rethink if p=3Dnone was really worth publishin= g if that happened.=C2=A0 I
>>> guess we'd need p=3Dnone-really then.
>>
>> Given that From: rewriting is the de-facto standard, this WG shoul= d
>> publish an RFC about that, including recommendations and caveats a= bout how
>> to do it.>>
>> Its Security Considerations, for example, should mention cases lik= e, say:
>>
>>=C2=A0 =C2=A0 =C2=A0From: The POTUS via phishing-attempt <obscure@phish= erman.example.com>
>>=C2=A0 =C2=A0 =C2=A0X-Original-From: The POTUS <potus@whitehouse.gov>
>>
>>
>> For a personal opinion, I don't know what is the purpose of ha= ving GG
>> rewrite From:'s of a given domain.=C2=A0 Perhaps, it is to let= users
>> participate to groups without revealing their real addresses to sp= ammers.
>> That sounds legitimate to me...>
> Do you mean, that user's don't understand why some are rewritt= en and some
> aren't?

Some may understand.=C2=A0 I recall when it was rather common to see addres= ses like,
say, blong@NOSPAMgoogle.com, supposedly obvious to human subscribers.=C2=A0= As email
authentication took on, tools tended to disallow such kind of free editing = of
From: (a trend that possibly impacted negatively on posters' ability to=
understand email mechanisms.)=C2=A0 Now, servers should supply something el= se to
provide a similar grade of privacy to mailing list subscribers.=C2=A0 The a= ddress
blong=3D40= google.com@dmarc.ietf.org (to which I'm writing) results in a simil= ar
soft concealing as the former example.=C2=A0 However, the X-Original-From b= etrays
such purpose.

Frankly, the number of pe= ople who did that was vanishingly small, and the general utility
= of such things was also pretty tiny.=C2=A0 The major mailing list providers= did a better job of just
not publishing the email address unhidd= en in the archives.=C2=A0

Brandon
--001a1140c830354c65056a13f335-- From nobody Tue Apr 17 16:46:52 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4F1272E1 for ; Tue, 17 Apr 2018 16:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524008805; bh=2FrryL/qzIpC0DnK1b1jq8384tJ6DNY/SknzmUZh12E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:Cc; b=VudvxasZoACWUMMY6uPH7aYL+IVzIkNqyeADj0tx3NOgoWpaU+0cP5h9+I1bDeP7F l3RdUP4yE7XSbicnmPENoYRXCdrx7sTjLFto5K8fDIBrpLOq6WUiTF/EMZy//6LwdY 5HMHT48ep9ElUdSe6FJbL2sxJx2JJKOSW41iPcrQ= X-Mailbox-Line: From blong@google.com Tue Apr 17 16:46:45 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 843891270AB; Tue, 17 Apr 2018 16:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524008805; bh=2FrryL/qzIpC0DnK1b1jq8384tJ6DNY/SknzmUZh12E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:Cc; b=VudvxasZoACWUMMY6uPH7aYL+IVzIkNqyeADj0tx3NOgoWpaU+0cP5h9+I1bDeP7F l3RdUP4yE7XSbicnmPENoYRXCdrx7sTjLFto5K8fDIBrpLOq6WUiTF/EMZy//6LwdY 5HMHT48ep9ElUdSe6FJbL2sxJx2JJKOSW41iPcrQ= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6611270A0 for ; Tue, 17 Apr 2018 16:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzBkfCijJe9d for ; Tue, 17 Apr 2018 16:46:42 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 16EE11270AB for ; Tue, 17 Apr 2018 16:46:42 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g9-v6so262576iob.11 for ; Tue, 17 Apr 2018 16:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zNcz9ZEteupfcDaWQSUDuDUD+J1VqFBKFyA1ZFUjRLc=; b=JfC7RRWuk1t4uKRDbiEJZgEqkldZZ9Lyd7Gvxo4CP9E0pnfc5XCvFM8VCRgPGfgkia DcYY80du6E6wmNAd2pS7OSf2gSiv0d9NIGg5MrhyOt1ZQ80vMU3GHfpsVhXUkm3cfsBN W+mdXh8rxHUsrx7BQe4o/+MNG9G6i6CWCY8OApVbjFrDlYTNfwJYQ9xOmaxBDNe53ztb 9Ydsn/T3SoeRe+HKwamqlOFL8IP5/lVvhdivTq40dkZbuSEW43d0zyFZwbv+qxZw8O0s oz7pFlIRjAXDFqUbyR6VTwozQhcZPhLKfTYQVpIcbt6iQ9JH0RGwBr35Lwz8RtFIeCnA ZU1g== 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=zNcz9ZEteupfcDaWQSUDuDUD+J1VqFBKFyA1ZFUjRLc=; b=rcYU1siRNdr2FkH6XcqzwrL6qPow/0IgAo2oBJU+Pcmc030x7VGdM0XrPMMuWINb5C 2AB/gZjtuOOTSqgBl+E0u/Iwh+9wpDAVYry6NCHdvsDjNMyj6qu8f96Y6tiVEjgRkPH/ duEUYbw+ic/cgSs/MZrp4I12kXN9XU8UwgIo20OUii059PvhzVNoNUQ0huigTaVRVb2A prn0q2DnMQfESZPWtboEmXNcwm1H2yuhIGxu4opqeoItKkjx9L+a6a0+o6tEpjgvuGrs XEHJuQEYx1GWc+C7GX/DYp4CzHw2h6ZhTDfyNCZ0UPEDL9KLq1HsM+ahFFxMKKG95RpC YJcQ== X-Gm-Message-State: ALQs6tAb0bj1GH4lapoJ/FBeFgROS5ox/k51h/4bd6l6br1mrdGKW40d Wu4P4TzDT7y81EccDfVikjPrOc4RpECEqPl2Benq X-Google-Smtp-Source: AIpwx4990lLaHZXMGhDaEyVIbHZaqldslYL1TKHBBQtOoa3VnRIXZH3DnehqevK3ayKcoUdUXjgW3FKzUw+ZBImpYEA= X-Received: by 10.107.158.66 with SMTP id h63mr3839310ioe.30.1524008800796; Tue, 17 Apr 2018 16:46:40 -0700 (PDT) MIME-Version: 1.0 References: <4932916.R6qcFiWbi0@kitterma-e6430> <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> In-Reply-To: From: Brandon Long Date: Tue, 17 Apr 2018 23:46:26 +0000 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary="001a1140c830354c65056a13f335" Cc: blong@google.com Cc: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 23:46:46 -0000 --001a1140c830354c65056a13f335 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 17, 2018 at 4:16 AM Alessandro Vesely wrote: > On Tue 17/Apr/2018 01:23:17 +0200 Brandon Long wrote: > > On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely > wrote: > >> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote: > >>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: > >>>> > >>>> Well, obviously there is some difference in handling of p=quarantine > and > >>>> p=none ;) > >>>> > >>>> I guess the question is, in terms of forwarders, should they handle > >>>> those differently or not. I'm not sure how many are p=none vs > >>>> p=quarantine vs no dmarc (I could look at our mail flow for some > >>>> numbers, but some others on the list may have better numbers), but if > >>>> a lot are at p=none, things will be yucky if it changes. Ie, right > >>>> now, gmail.com/hotmail.com/outlook.com are all p=none, so changing > >>>> Groups or mailman for p=none will affect a lot of folks.>>> > >>> I'd have to rethink if p=none was really worth publishing if that > happened. I > >>> guess we'd need p=none-really then. > >> > >> Given that From: rewriting is the de-facto standard, this WG should > >> publish an RFC about that, including recommendations and caveats about > how > >> to do it.>> > >> Its Security Considerations, for example, should mention cases like, > say: > >> > >> From: The POTUS via phishing-attempt < > obscure@phisherman.example.com> > >> X-Original-From: The POTUS > >> > >> > >> For a personal opinion, I don't know what is the purpose of having GG > >> rewrite From:'s of a given domain. Perhaps, it is to let users > >> participate to groups without revealing their real addresses to > spammers. > >> That sounds legitimate to me...> > > Do you mean, that user's don't understand why some are rewritten and some > > aren't? > > Some may understand. I recall when it was rather common to see addresses > like, > say, blong@NOSPAMgoogle.com, supposedly obvious to human subscribers. As > email > authentication took on, tools tended to disallow such kind of free editing > of > From: (a trend that possibly impacted negatively on posters' ability to > understand email mechanisms.) Now, servers should supply something else to > provide a similar grade of privacy to mailing list subscribers. The > address > blong=40google.com@dmarc.ietf.org (to which I'm writing) results in a > similar > soft concealing as the former example. However, the X-Original-From > betrays > such purpose. > Frankly, the number of people who did that was vanishingly small, and the general utility of such things was also pretty tiny. The major mailing list providers did a better job of just not publishing the email address unhidden in the archives. Brandon --001a1140c830354c65056a13f335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Apr 17, 2018 at 4:16 AM Alessandro Vesely <vesely@tana.it> wrote:
vesely@tana.it> wrote:
>> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote:
>>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote:
>>>>
>>>> Well, obviously there is some difference in handling of p= =3Dquarantine and
>>>> p=3Dnone ;)
>>>>
>>>> I guess the question is, in terms of forwarders, should th= ey handle
>>>> those differently or not.=C2=A0 I'm not sure how many = are p=3Dnone vs
>>>> p=3Dquarantine vs no dmarc (I could look at our mail flow = for some
>>>> numbers, but some others on the list may have better numbe= rs), but if
>>>> a lot are at p=3Dnone, things will be yucky if it changes.= =C2=A0 Ie, right
>>>> now, gmail.com/hotmail.com/outlook.com = are all p=3Dnone, so changing
>>>> Groups or mailman for p=3Dnone will affect a lot of folks.= >>>
>>> I'd have to rethink if p=3Dnone was really worth publishin= g if that happened.=C2=A0 I
>>> guess we'd need p=3Dnone-really then.
>>
>> Given that From: rewriting is the de-facto standard, this WG shoul= d
>> publish an RFC about that, including recommendations and caveats a= bout how
>> to do it.>>
>> Its Security Considerations, for example, should mention cases lik= e, say:
>>
>>=C2=A0 =C2=A0 =C2=A0From: The POTUS via phishing-attempt <obscure@phish= erman.example.com>
>>=C2=A0 =C2=A0 =C2=A0X-Original-From: The POTUS <potus@whitehouse.gov>
>>
>>
>> For a personal opinion, I don't know what is the purpose of ha= ving GG
>> rewrite From:'s of a given domain.=C2=A0 Perhaps, it is to let= users
>> participate to groups without revealing their real addresses to sp= ammers.
>> That sounds legitimate to me...>
> Do you mean, that user's don't understand why some are rewritt= en and some
> aren't?

Some may understand.=C2=A0 I recall when it was rather common to see addres= ses like,
say, blong@NOSPAMgoogle.com, supposedly obvious to human subscribers.=C2=A0= As email
authentication took on, tools tended to disallow such kind of free editing = of
From: (a trend that possibly impacted negatively on posters' ability to=
understand email mechanisms.)=C2=A0 Now, servers should supply something el= se to
provide a similar grade of privacy to mailing list subscribers.=C2=A0 The a= ddress
blong=3D40= google.com@dmarc.ietf.org (to which I'm writing) results in a simil= ar
soft concealing as the former example.=C2=A0 However, the X-Original-From b= etrays
such purpose.

Frankly, the number of pe= ople who did that was vanishingly small, and the general utility
= of such things was also pretty tiny.=C2=A0 The major mailing list providers= did a better job of just
not publishing the email address unhidd= en in the archives.=C2=A0

Brandon
--001a1140c830354c65056a13f335-- From nobody Wed Apr 18 02:38:04 2018 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 9C8E212D86C for ; Wed, 18 Apr 2018 02:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 DQgPH6zcfr0D for ; Wed, 18 Apr 2018 02:38:00 -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 E3218126BFD for ; Wed, 18 Apr 2018 02:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1524044277; bh=rzaasog0OYMhq39JJrQVpkXlvZ45MFVU2rrYtHUBoOI=; l=3679; h=To:Cc:References:From:Date:In-Reply-To; b=B6eeKHbrN2IeKTCIz1ou07CTaoqyJfIcfioGNcduzZ8bSwR9AGBJRSvSC93g7w0wl Zk9Yxsfqw9A0+JtTse7NkVtXEnRA6RuLwcA0++ZhskMXH6tjRV6OHUHW5Kbb+cNRgB XqNlXUNSE8SzVSy+a1LY1uUH8ty+A+Wb472kHGCFKIqgZTFYrMzC3GGdLlFoy 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, 18 Apr 2018 11:37:57 +0200 id 00000000005DC077.000000005AD711F5.00002638 To: Brandon Long Cc: dmarc@ietf.org References: <4932916.R6qcFiWbi0@kitterma-e6430> <5fc0dd04-3030-b207-72f6-bf4d98f868fd@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <79978497-0ef7-60d1-b147-b7fc4f20d59a@tana.it> Date: Wed, 18 Apr 2018 11:37:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 09:38:02 -0000 On Wed 18/Apr/2018 01:46:26 +0200 Brandon Long wrote: > On Tue, Apr 17, 2018 at 4:16 AM Alessandro Vesely wrote: >> On Tue 17/Apr/2018 01:23:17 +0200 Brandon Long wrote: >>> On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely wrote: >>>> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote: >>>>> On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote: >>>>>> >>>>>> Well, obviously there is some difference in handling of >>>>>> p=quarantine and p=none ;)>>>>>> >>>>>> I guess the question is, in terms of forwarders, should they >>>>>> handle those differently or not. I'm not sure how many are p=none >>>>>> vs p=quarantine vs no dmarc (I could look at our mail flow for >>>>>> some numbers, but some others on the list may have better >>>>>> numbers), but if a lot are at p=none, things will be yucky if it >>>>>> changes. Ie, right now, gmail.com/hotmail.com/outlook.com are all >>>>>> p=none, so changing Groups or mailman for p=none will affect a lot >>>>>> of folks.>>>>> >>>>> I'd have to rethink if p=none was really worth publishing if that happened. >>>>> I guess we'd need p=none-really then. >>>> >>>> Given that From: rewriting is the de-facto standard, this WG should >>>> publish an RFC about that, including recommendations and caveats about how >>>> to do it. >>>> >>>> Its Security Considerations, for example, should mention cases like, say: >>>> >>>> From: The POTUS via phishing-attempt >>>> X-Original-From: The POTUS >>>> >>>> >>>> For a personal opinion, I don't know what is the purpose of having GG >>>> rewrite From:'s of a given domain. Perhaps, it is to let users >>>> participate to groups without revealing their real addresses to spammers. >>>> That sounds legitimate to me... >>> >>> Do you mean, that user's don't understand why some are rewritten and some >>> aren't? >> >> Some may understand. I recall when it was rather common to see addresses >> like, say, blong@NOSPAMgoogle.com, supposedly obvious to human >> subscribers. As email authentication took on, tools tended to disallow >> such kind of free editing of From: (a trend that possibly impacted >> negatively on posters' ability to understand email mechanisms.) Now, >> servers should supply something else to provide a similar grade of privacy >> to mailing list subscribers. The address >> blong=40google.com@dmarc.ietf.org (to which I'm writing) results in a >> similar soft concealing as the former example. However, the >> X-Original-From betrays such purpose.> > Frankly, the number of people who did that was vanishingly small, and the > general utility of such things was also pretty tiny. The major mailing list > providers did a better job of just not publishing the email address unhidden > in the archives. You mean spammers would rather harvest from web archives than subscribe to mailing lists directly? Many lists restrict archive access, or have no archive at all. I slightly disagree about the general utility of those tricks. The more spammers have to code around idioms such as "@NOSPAM" or "user at domain dot", the slipperier their harvesting. Anyway, what's the practical merit of X-Original-From or added Reply-To? Don't posters enjoy better privacy when From:-rewriter omit them? However old-fashioned, the @NOSPAM idiom had an advantage over =40...@, namely that it just bounced rather than creating duplicates[*]. Grr... fixing To: now. Ale -- [*] Hm... that might be a bug somewhere in dmarc-reverse handling. The copy collects four signatures by d=ietf.org instead of two as usual. From nobody Wed Apr 18 06:22:58 2018 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 896BC12D7F8 for ; Wed, 18 Apr 2018 06:22:57 -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 uHhubRtmcSC8 for ; Wed, 18 Apr 2018 06:22:55 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753D11267BB for ; Wed, 18 Apr 2018 06:22:55 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id w3-v6so4813608wrg.2 for ; Wed, 18 Apr 2018 06:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=GXXXQNLsR6ABH8UX4gPrsU2zkCPJC9bUOVS5g8Ex46I=; b=Q8E1DIEuRHr+USBOa86pXdv4xCrZgOhix4Iz392qOAmTCd8AdnoTOzBQLhwlVo3o6A 5QVTw+uXg08G5w9nqyhkfZHS4AbSZk4g4snTlDr8J/VslILxMhyijWZjOwEYyZ0x0PhB RM1bsd62h8+P55Bj8m2bBMso0z1o6mZLy2JZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=GXXXQNLsR6ABH8UX4gPrsU2zkCPJC9bUOVS5g8Ex46I=; b=bYXcR9GScd5IjCEK7NRlvGr2kdTSEXVU/moDVo2cgnf8EMsA05iydfVc6DfbH4IY7c bDwMD05bMGbL/Oe/waf7spxBVlURrZY7IOQiRYEr1QxmBnfbWSEgaQfaubNegEqenfu3 LtW9FbzN8EP+Uk8yXajGYKZvi+zQb+TGNi3I9dahQLA2jcYj8gmWf9T6YpPtbtoWAaPj vgHd10y4MpXRkN0Uqsb+Af0Rk9sP/cX1FlNepfgZal8B5yAfpNqZ+dj1oJmOk5vF06vJ mClSvFqP+9gx6akvBDGfCIedp5dWzaootiLzrMKU5LEq5kkde5HV0W0kD+waoyr+8saM FuDQ== X-Gm-Message-State: ALQs6tAZdVRgRwHoZu1uoySZEfW4ENcQmK/q9IAxyYDphUptZo7s0pfj ZKZmnFbJXxqVomgOp7toiN12aN5hACFrFQUw0j+pRdPt6UM= X-Google-Smtp-Source: AIpwx4/waPtPsrv1YiTB0fI52I0zYYtUPcUo99aMHtn+kuOGlMJyxKpzdsracLC2XgVaj+8DdJf3fBkpD1aBCRs4+QE= X-Received: by 10.80.163.229 with SMTP id t34mr3107051edb.227.1524057773634; Wed, 18 Apr 2018 06:22:53 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.142.201 with HTTP; Wed, 18 Apr 2018 06:22:52 -0700 (PDT) From: "Kurt Andersen (b)" Date: Wed, 18 Apr 2018 15:22:52 +0200 X-Google-Sender-Auth: tSLT8qai2O-LrN0OxQXR-hM1xTc Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045c4410371a9b056a1f5ae9" Archived-At: Subject: [dmarc-ietf] Resolving issue #9 (clarify conditions under which to sign and what is being asserted) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 13:22:57 -0000 --f403045c4410371a9b056a1f5ae9 Content-Type: text/plain; charset="UTF-8" https://trac.ietf.org/trac/dmarc/ticket/9 Per my comment on the ticket, I think that this has now been addressed with the updates done in version -13 (primarily the overview in section 1.1: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-13#section-1.1) Any objections to closing this issue? --Kurt --f403045c4410371a9b056a1f5ae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Per = my comment on the ticket, I think that this has now been addressed with the= updates done in version -13 (primarily the overview in section 1.1:=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-13#sect= ion-1.1">https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-13#secti= on-1.1)

Any objections to closing this issue?
<= div>
--Kurt
--f403045c4410371a9b056a1f5ae9-- From nobody Wed Apr 18 07:52:50 2018 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 D976C1275AB for ; Wed, 18 Apr 2018 07:52:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyrKth1z_dPm for ; Wed, 18 Apr 2018 07:52:46 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED411243FE for ; Wed, 18 Apr 2018 07:52:46 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 40R4q10p9Tz1L93P; Wed, 18 Apr 2018 16:52:45 +0200 (CEST) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx14.mailtransaction.com (Postfix) with ESMTP id 40R4q06pYmz5MgY1; Wed, 18 Apr 2018 16:52:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id D03374222CB; Wed, 18 Apr 2018 16:52:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jkS5_lupHj78; Wed, 18 Apr 2018 16:52:44 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [192.168.30.2]) by tiger.sonnection.nl (Postfix) with ESMTP id B8F154222CA; Wed, 18 Apr 2018 16:52:44 +0200 (CEST) Date: Wed, 18 Apr 2018 16:52:44 +0200 (CEST) From: "Rolf E. Sonneveld" To: "Kurt Andersen (b)" Cc: dmarc@ietf.org Message-ID: <876921866.1126121.1524063164477.JavaMail.zimbra@sonnection.nl> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1126120_964194675.1524063164476" X-Originating-IP: [192.168.20.2] X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF59 (Linux)/8.6.0_GA_1182) Thread-Topic: Resolving issue #9 (clarify conditions under which to sign and what is being asserted) Thread-Index: HyZl7L5/hb+8KE/RQAOwGuff1M08Vw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1524063165; bh=PquWrw7bLO7JGeOSbZD6AnrUefuShjz2e2VsV3YtJkY=; h=Date:From:To:Message-ID:Subject:From; b=LoamgLTr3zuM8YtVac7b63B994uDMYmonBCIuagb6Vd4G1VFo7p3ZY3vipXWXWRnk AWiYL6INAjRyJWHNg12N+L4D1xOiRLVslqeNbQP7sfbAP+JOjVzoJka1v1Sk5bZNUA u7qVjw6yC2vSChajPNYTCsLF7HIWbKa2VAe2tqTw= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 40R4q10p9Tz1L93P Archived-At: Subject: Re: [dmarc-ietf] Resolving issue #9 (clarify conditions under which to sign and what is being asserted) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:52:50 -0000 ------=_Part_1126120_964194675.1524063164476 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > https://trac.ietf.org/trac/dmarc/ticket/9 > Per my comment on the ticket, I think that this has now been addressed with the > updates done in version -13 (primarily the overview in section 1.1: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-13#section-1.1 ) > Any objections to closing this issue? no objection. /rolf ------=_Part_1126120_964194675.1524063164476 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Per my co= mment on the ticket, I think that this has now been addressed with the upda= tes done in version -13 (primarily the overview in section 1.1: https://tools.ietf.org/html/draft-ietf-dmarc-arc-prot= ocol-13#section-1.1)
Any objections to closing this issue?

no objection.

/rolf

------=_Part_1126120_964194675.1524063164476-- From nobody Mon Apr 23 20:02:47 2018 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 6B0FE126D73; Mon, 23 Apr 2018 20:02:43 -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.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152453896340.28895.14878580069071012803@ietfa.amsl.com> Date: Mon, 23 Apr 2018 20:02:43 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 03:02:43 -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 : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-14.txt Pages : 51 Date : 2018-04-23 Abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination, and create an attached, authenticated record of the status at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. Changes in the message that might break existing authentication mechanisms can be identified through the ARC Set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-14 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 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 Mon Apr 23 20:03:08 2018 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 4B8C912E874; Mon, 23 Apr 2018 20:02:46 -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.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152453896629.28899.13612521072653161934@ietfa.amsl.com> Date: Mon, 23 Apr 2018 20:02:46 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 03:02:49 -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 Jones Kurt Andersen John Rae-Grant J. Trent Adams Filename : draft-ietf-dmarc-arc-usage-05.txt Pages : 16 Date : 2018-04-23 Abstract: The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-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 Tue Apr 24 09:01:37 2018 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 4D9D312E8CE for ; Tue, 24 Apr 2018 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-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 FVrxAAOKaij8 for ; Tue, 24 Apr 2018 09:01:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 C24A0129C6E for ; Tue, 24 Apr 2018 09:01:33 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v2-v6so4387300oif.3 for ; Tue, 24 Apr 2018 09:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XWGy7mAbaZVVgsZN4PKlk3/h+9psaSmHzsGGBgkiBwc=; b=XeRBfMo6+oFsEIUhDyG968SkvINvVwm7yuJO9/ToquuxiIkOLhz5FNOJb91+1sxeZ/ GRo04738op5DLbP5v7Bppk2usIwwKmBiwFY5MTi3yu8AOD+yVZUg1AtPP0cTkkAA74w0 iPsZhrq1eXDv8Uc2DlF9ejKZPNj2GwRxqCDjSyCQtCc+kyWYePhOlQ7NX4rkVHm1SZ6F 3gKFa/0zmh7wzbQqG+eWR+0byVcjOrWGoqGAqAIiSq8yhHaO33IrJjUlJEzf5NdrAER1 7dWKrfAICfnSIi7Y41SXASYKajwLvxOvd3HDjHEGhVaigHroe7hOOI0kRRTQuPz5A7m6 Go5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XWGy7mAbaZVVgsZN4PKlk3/h+9psaSmHzsGGBgkiBwc=; b=CjU6AsCyWLe+p2vSbrloYaaTYCEVx9o+RRKjILuyYrn4kn+Rxy5mzrCHlwkr1AnCgi RkS62nyAvxPQK/ke8x/STh+NQAYiDxqPPMrFFDK2O1ZroIll5s3ZG3bmkzBECb6ZXVJ/ cfOkgS9XWIN9PD5Eb5N7lZQv5/JzBN3oc3SvIRoevVa+dmmWcGb5VBbGowhkUfwyvd3Q cAihR9Q0/FtD+3rH6zFFwgDlek+uWl+Xi0XNvFG/HgJqtwFbt+LOGIaRr4XYEW5WrvGt U/ehpQjcZ7/AiT9tETHsygZu9YfayBQtCesHFF1XYsTA/ElVV325HeMyqodZ8Vf7tvwQ 17yA== X-Gm-Message-State: ALQs6tBzD8cOeTTdQltmZFmULk1YBskoVfUY1+y7BDNUbfd4XRx0pAOF 7FnVyRfdBvTYdjhmS2+UqUyQKf/Q5QRjyLQkRWBxP0C7Ak4= X-Google-Smtp-Source: AIpwx4/OUi9/oKLdGuQsKTxZ+5OvItUy40rfKsnX3SSx9zlV8H7bc5xr5ututGje2qRozSd98ENeLZLcH95yDBB5DeE= X-Received: by 2002:aca:ac51:: with SMTP id v78-v6mr10260579oie.350.1524585691931; Tue, 24 Apr 2018 09:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:7399:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 09:01:11 -0700 (PDT) In-Reply-To: <152453896340.28895.14878580069071012803@ietfa.amsl.com> References: <152453896340.28895.14878580069071012803@ietfa.amsl.com> From: Seth Blank Date: Tue, 24 Apr 2018 18:01:11 +0200 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="00000000000099050f056a9a44c9" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 16:01:36 -0000 --00000000000099050f056a9a44c9 Content-Type: text/plain; charset="UTF-8" This update is an editing pass for readability, clarity, and conciseness. It also addressed several open items in the issue tracker. On Tue, Apr 24, 2018 at 5:02 AM, 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 : Authenticated Received Chain (ARC) Protocol > Authors : Kurt Andersen > Brandon Long > Steven Jones > Seth Blank > Murray Kucherawy > Filename : draft-ietf-dmarc-arc-protocol-14.txt > Pages : 51 > Date : 2018-04-23 > > Abstract: > The Authenticated Received Chain (ARC) protocol creates a mechanism > whereby a series of handlers of an email message can conduct > authentication of the email message as it passes among them on the > way to its destination, and create an attached, authenticated record > of the status at each step along the handling path, for use by the > final recipient in making choices about the disposition of the > message. Changes in the message that might break existing > authentication mechanisms can be identified through the ARC Set of > header fields. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-14 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 > > > 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/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000099050f056a9a44c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This update is an editing pass for readability, clarity, a= nd conciseness. It also addressed several open items in the issue tracker.<= /div>

On Tue, Apr = 24, 2018 at 5:02 AM, <internet-drafts@ietf.org> wrot= e:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Authenticated Received Chain (ARC) Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Kurt= Andersen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brandon Long
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Steven Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Seth Blank
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Murray Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-arc-protocol-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 51
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-04-23

Abstract:
=C2=A0 =C2=A0The Authenticated Received Chain (ARC) protocol creates a mech= anism
=C2=A0 =C2=A0whereby a series of handlers of an email message can conduct =C2=A0 =C2=A0authentication of the email message as it passes among them on= the
=C2=A0 =C2=A0way to its destination, and create an attached, authenticated = record
=C2=A0 =C2=A0of the status at each step along the handling path, for use by= the
=C2=A0 =C2=A0final recipient in making choices about the disposition of the=
=C2=A0 =C2=A0message.=C2=A0 Changes in the message that might break existin= g
=C2=A0 =C2=A0authentication mechanisms can be identified through the ARC Se= t of
=C2=A0 =C2=A0header fields.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-dmarc-arc-protocol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-dmarc-arc-protocol-14
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-dmarc-arc-protocol-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-14


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--00000000000099050f056a9a44c9-- From nobody Tue Apr 24 13:11:06 2018 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 4C81012D96A for ; Tue, 24 Apr 2018 13:11:05 -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, URIBL_BLOCKED=0.001] 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 v0ND4wSzkTXe for ; Tue, 24 Apr 2018 13:11:02 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F17312D94E for ; Tue, 24 Apr 2018 13:11:02 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1524600662; b=ld6li4lSKrBDuL8Tc3ZXUVp5uF66IrxJmPqJnmQAE7//0XPqw+dP+53DHF/rIBB7qhOnk/uyJ0 mbuoNPo4GZIEfF+rScP13e4wVrbDfbvR0eAVjaz+rQxJ1ScsWSgkocnDytBSK0w1mjEzv962Su IfaaCRQ/WFNERbssJjByNUE=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1524600662; bh=JxjWVIwLFu+wNTWggRI+yHNup67EC3AsZFdKP8e1fLQ=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=Zl//j/DX11eElMagIjDlZ6YMKwEW8cmTdqt2eileiP4g5CrFuBBzaY/nPR9CHtF6hCD59gw0DJ xezU/S+sAUQqF8RuYbi0w0y+T75LKGEAM59cv2WAOuRpyV/7xIECJGRjVBdvGIrIu1KL9/VbyV 6Cen512d1iz259cFPuBBYtE=; 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=HZ4An8cmk+Qtxunix4l7Hg6KHFZUhueWmR4h7UPcTyY=; b=U zFI/ej5VMB8V5CUORma65bEjGIf0bwtjvU65gZKPPooEXNKPPgKAdEnHS1NTQHz4BiZcJl7V93MUS hJ4fQROvuUCJFwbhI8H8ON9NykQryKsxjsF//vQ4bybEb7vELbZxlFdftJ2e7ijDAc8KzKwTmJtD5 IkMd6DzFvnt7RmVw=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.119) id 1fB4HE-0007jn-E7 for dmarc@ietf.org (return-path ); Tue, 24 Apr 2018 20:11:00 +0000 To: dmarc@ietf.org References: <152453896340.28895.14878580069071012803@ietfa.amsl.com> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAHNJkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+wsB7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGzsBNBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAHCwF8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <3ec2ec8f-0de7-f901-d7ae-51d97734b6ab@wizmail.org> Date: Tue, 24 Apr 2018 21:10:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152453896340.28895.14878580069071012803@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 20:11:05 -0000 On 24/04/18 04:02, internet-drafts@ietf.org wrote: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 Section 3.3: For AMS generation, what is the intention regarding oversigning? Section 11: Additional implementation: Organization: Exim developers Status of Operation: Operational; requires specific enabling for compile. Coverage: Full spec implemented as of [ARC-DRAFT-13] Licensing: GPL Contact Info: exim-users@exim.org Implementation notes: - Exim 4.91 From nobody Tue Apr 24 14:45:51 2018 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 59D7512D946 for ; Tue, 24 Apr 2018 14:45:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Y9MJQtoCvWPJ for ; Tue, 24 Apr 2018 14:45:48 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2477E124BAC for ; Tue, 24 Apr 2018 14:45:48 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id j4so3788158wme.1 for ; Tue, 24 Apr 2018 14:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0GdX+M3R8paCu/VvF1BEZlB/lw1oETJ5UwWbVzt/kFc=; b=FziOw0NR9TAApdmEACsbg/OKsZtBMT7U1xQlW2eqi3qqhHx2t/CdQiJDkrFuSrby2N LTmUSkhxIEMUkIglxbA2tcMtSesNVbd98qLq8r3c/cZT8YF8obyNiDNQjvOX3X6AFQ3H ae3gmpOe6jIHgO0vBHbtl1/oazyUAiyZ8YeVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0GdX+M3R8paCu/VvF1BEZlB/lw1oETJ5UwWbVzt/kFc=; b=RxFAJFodBzYsA7FKkfd7WNMBXS7STUh+BOhyj86Sc8otc8aud451yLZnlyDZixXuJs fh4JBo/U+YwMIMpePJwTwhfPILKltBH5VqvPErF+6mw0jTSbrLlHn8oAx+M94M7WFAS+ ixrCGKNPa5mKYv7LGX1KxP7L6vHHcGUaYlEgIYDkSx8e0bWFD1R7MeT6YjLSVvzva0xG 9pDcTHs/9OXIC53kk6y879Y9vp9xCk1nssBulq5zWk7/xhkfDWbfuvUWxCu2MuhH2zRA aneNS3i7dSPNWOaHh9zivJzkBwPN4Xsp5cnFNb59kiC/FZEbxXUIlMqTSdh94VKSCI42 Uknw== X-Gm-Message-State: ALQs6tD/hfvQMjPt6pJ2bKLLkp/P1fDJEBRfotGebvDXckULSiDq2mAk I7lGSaFyMX1FA0r+IqN2shvu+CVNT9iZzzTmFdQHfG4j X-Google-Smtp-Source: AIpwx49S2t2MEPOfxOAPIUWvGcmSsV20IkszCSFF8qrZb9S6Rl9bNnEIXjTcXcMgsZhfWZwDySh0e4NUJ/1Ob+eieaI= X-Received: by 10.80.169.197 with SMTP id n63mr35159450edc.20.1524606346599; Tue, 24 Apr 2018 14:45:46 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.142.201 with HTTP; Tue, 24 Apr 2018 14:45:46 -0700 (PDT) In-Reply-To: <3ec2ec8f-0de7-f901-d7ae-51d97734b6ab@wizmail.org> References: <152453896340.28895.14878580069071012803@ietfa.amsl.com> <3ec2ec8f-0de7-f901-d7ae-51d97734b6ab@wizmail.org> From: "Kurt Andersen (b)" Date: Tue, 24 Apr 2018 14:45:46 -0700 X-Google-Sender-Auth: v8vndbAkbqxW5C673LDpamvLFco Message-ID: To: Jeremy Harris Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c194a12b62f5c056a9f1364" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 21:45:50 -0000 --94eb2c194a12b62f5c056a9f1364 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris wrote: > On 24/04/18 04:02, internet-drafts@ietf.org wrote: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 > > Section 3.3: > For AMS generation, what is the intention regarding oversigning? > Can you clarify what you mean by "oversigning"? > Section 11: > Additional implementation: > > Organization: Exim developers > Status of Operation: Operational; requires specific enabling > for compile. > Coverage: Full spec implemented as of [ARC-DRAFT-13] > Licensing: GPL > Contact Info: exim-users@exim.org > Implementation notes: > - Exim 4.91 > ack - will include for the next version (but we're looking to have last call review on the current one). --Kurt --94eb2c194a12b62f5c056a9f1364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 24, 2018 at 1:10 PM, Jeremy Harris <jgh@wizmail.org> w= rote:
On 24/04/18 04:02, internet-drafts@ietf.org wrote:
> https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-dmarc-arc-protocol-14

Section 3.3:
=C2=A0 For AMS generation, what is the intention regarding oversigning?
=

Can you clarify what you mean by "ove= rsigning"?
=C2=A0
Sectio= n 11:
=C2=A0 Additional implementation:

=C2=A0 =C2=A0 Organization: Exim developers
=C2=A0 =C2=A0 Status of Operation: Operational; requires specific enabling<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0for compile.
=C2=A0 =C2=A0 Coverage: Full spec implemented as of [ARC-DRAFT-13]
=C2=A0 =C2=A0 Licensing: GPL
=C2=A0 =C2=A0 Contact Info: exim-use= rs@exim.org
=C2=A0 =C2=A0 Implementation notes:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Exim 4.91

=
ack - will include for the next version (b= ut we're looking to have last call review on the current one).

--Kurt
--94eb2c194a12b62f5c056a9f1364-- From nobody Tue Apr 24 14:54:38 2018 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 86B5D12D94B for ; Tue, 24 Apr 2018 14:54: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, URIBL_BLOCKED=0.001] 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 9HMNoywefiIK for ; Tue, 24 Apr 2018 14:54:35 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD08124BAC for ; Tue, 24 Apr 2018 14:54:35 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1524606875; b=lHQZDxzDgjbGzMxddYDz0qJtfvHufCr1ZfLXyUwUz3fCjPSko1vKXTrhK9axT4Zj5+kMbrkzaY WXl3BdAqvN148ruQkXL/I4ghrLU1GKcP0MMyZjJyoUzV69xit/6AXg5PgNqvrc7uFsCnZLtrCZ O86omgWAUN25t4Tx+SRMfl8=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1524606875; bh=cMC3Tz44Lk2sD36q4sH463zF3iRW6Oq6hQqJ0nB0xI8=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=eMwrtAApKXYObbyyDOz98cd/UGU9F3Kr4NpIJVzH4D/Ct/26U3E/GCNojv8b1WjwgiUYYdxRR9 c/kDpu57kk+nBB0kjrR7itKNymeja7gyCp+A8YUbdgWafpT6UJyL+AP0P2ztyUqujs4BzAyTg0 hJNiQ8jI4iJ8+TON8Azguo4=; 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=7VgjpG0aZTb7Q2vVAvZ6MqwsEVzBak0d0NXkxlWJv6I=; b=g 9oks+Ih61ktAJW3GVFTwdbrsJ+9qT7zBx3wRu2FJlizDBIgLxfx9w6PnKS9brmD72J0y3f+eIDVTf 3cnDNguSfTIPqp+LBasEUcrF4DnvPYcQA7KlmMAgPb6mnq9+gjfXGNovmU7LhjdqYVt9IGFoEQqKU E28vq1Au0QIp7XJo=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.119) id 1fB5tR-0002HD-EZ for dmarc@ietf.org (return-path ); Tue, 24 Apr 2018 21:54:33 +0000 To: dmarc@ietf.org References: <152453896340.28895.14878580069071012803@ietfa.amsl.com> <3ec2ec8f-0de7-f901-d7ae-51d97734b6ab@wizmail.org> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAHNJkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+wsB7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGzsBNBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAHCwF8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: Date: Tue, 24 Apr 2018 22:54:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 21:54:37 -0000 On 24/04/18 22:45, Kurt Andersen (b) wrote: > On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris wrote: > >> On 24/04/18 04:02, internet-drafts@ietf.org wrote: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 >> >> Section 3.3: >> For AMS generation, what is the intention regarding oversigning? >> > > Can you clarify what you mean by "oversigning"? In DKIM you can, in the signature, list a header more times than are actually present in the message. If you do, the addition of another header of that name will break the signature; if you do not it will not, and could obscure the original (depending on the receiving MUA choice). Consider that being done to the Subject: header. (Any more than degree-one oversigning is pointless) -- Cheers, Jeremy From nobody Tue Apr 24 16:32:21 2018 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 D9D4B124BE8 for ; Tue, 24 Apr 2018 16:32:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 1E2GkDIbGdOz for ; Tue, 24 Apr 2018 16:32:17 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 C81AE124319 for ; Tue, 24 Apr 2018 16:32:16 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 66so4070189wmd.3 for ; Tue, 24 Apr 2018 16:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8m8WpEKEn2MmOxA9oOC7QyQ3Fk9UDVGeKXLQOOGULJ0=; b=CbzxJxCY0Q1cTHXMN9WrSZiNss1c15HNdldjANsXEHq6CuCYGLH9zzGPvUxO4L497V yALf6EI/2QpdSIklCo/OeWbqF90mafVuQeKynoVI5TRMvmzJTecjlq24C8wSLgGDeITX XyIVCoOMJ7eoOwSpz9TUHAfUpbnQgmr2N4Fg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8m8WpEKEn2MmOxA9oOC7QyQ3Fk9UDVGeKXLQOOGULJ0=; b=mluQI+GZ/WHBmrGt1ZexvWJWpgnZBwjWgNegF3x5+RaMCSNgbHA0PETc2f6vD+PkiK fTXdRwY63fip2khHtGIrD+wYsudb220SyyWPd3kVUR0Ex4guG7tWmOeMsDZNBC2xeheT TI3Tp9Y8Z6oeHJaahSbGwbK8SWZJPZN8+Djx4CpIfUHA2TvY3ZafQFca0N1/Vunoqtrp SFVN1kjmrFJ7FHciQJxU6yhYQ3DwXPhLV5D7aoF9aSE6uyAzzMHh5GfwVjbpFf1fQPAg n+4hXKBdhgC2AhoweVUXquz04/KcSKeFt7oLuPmaABEEYt1a0hvyd9Lb995KEqJ2v9Zo hq0w== X-Gm-Message-State: ALQs6tATlcIKT3NDxYdw5eIZlcTCLaLI75J2qEFI316g+m5wVKxVmWUV a6xtjzwxLUE/TExgg1PTphm82zOSVUf647Dkauefcbi1 X-Google-Smtp-Source: AB8JxZqo+djDmX+4dXAWh28I/qVXrbrrfANfgvgWEuLDaPSlZSQqNm6HW/E++VGcOLWXVK9AUpYHoJQOL18ibDCpv3I= X-Received: by 10.80.242.146 with SMTP id f18mr1548296edm.176.1524612735198; Tue, 24 Apr 2018 16:32:15 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.142.201 with HTTP; Tue, 24 Apr 2018 16:32:14 -0700 (PDT) In-Reply-To: References: <152453896340.28895.14878580069071012803@ietfa.amsl.com> <3ec2ec8f-0de7-f901-d7ae-51d97734b6ab@wizmail.org> From: "Kurt Andersen (b)" Date: Tue, 24 Apr 2018 16:32:14 -0700 X-Google-Sender-Auth: YL4zfoucnnYLYvMt15zeIrzmufA Message-ID: To: Jeremy Harris Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="089e0825bad880740a056aa09068" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 23:32:19 -0000 --089e0825bad880740a056aa09068 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 24, 2018 at 2:54 PM, Jeremy Harris wrote: > On 24/04/18 22:45, Kurt Andersen (b) wrote: > > On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris wrote: > > > >> On 24/04/18 04:02, internet-drafts@ietf.org wrote: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 > >> > >> Section 3.3: > >> For AMS generation, what is the intention regarding oversigning? > >> > > > > Can you clarify what you mean by "oversigning"? > > In DKIM you can, in the signature, list a header more times than > are actually present in the message. If you do, the addition of > another header of that name will break the signature; if you do > not it will not, and could obscure the original (depending on > the receiving MUA choice). > > Consider that being done to the Subject: header. I think that you could use the same set of header fields to be oversigned by AMS as you use for DKIM. --Kurt --089e0825bad880740a056aa09068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 24, 2018 at 2:54 PM, Jeremy Harris <jgh@wizmail.org> w= rote:
On 24/04/18 22:45,= Kurt Andersen (b) wrote:
> On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris <jgh@wizmail.org> wrote:
>
>> On 24/04/18 04:02, int= ernet-drafts@ietf.org wrote:
>>> https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-14
>>
>> Section 3.3:
>>=C2=A0 =C2=A0For AMS generation, what is the intention regarding ov= ersigning?
>>
>
> Can you clarify what you mean by "oversigning"?

In DKIM you can, in the signature, list a header more times than
are actually present in the message. If you do, the addition of
another header of that name will break the signature; if you do
not it will not, and could obscure the original (depending on
the receiving MUA choice).

Consider that being done to the Subject: header.

I think that you could use the same set of header fields to be oversi= gned by AMS as you use for DKIM.

--Kurt=C2=A0

--089e0825bad880740a056aa09068-- From nobody Thu Apr 26 00:38:38 2018 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 B3D6D127023 for ; Thu, 26 Apr 2018 00:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.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 UwrZZmMd4NZr for ; Thu, 26 Apr 2018 00:38:34 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 97CBD1204DA for ; Thu, 26 Apr 2018 00:38:34 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id g14so17579080pfh.3 for ; Thu, 26 Apr 2018 00:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=50/+BuTvOunzjjo5do2C6L/SvOIalzn/finPuIM/ABc=; b=2MnscOcL59VquoAYxXPajLwtsq95OLCTAqecFbKwxX6WQM8+kZrKHLZ5Eld5VtmLjP zzKHqfsTMRjn/LPzjCdsvLel/GkrfARZ23sf7G/OfZUUUMf27I6h8VmrDcZhH2wgVMBd zHZMkb66Dk7lY6C2I8Aly/i1tqmnWEPHqk2p5356h9755ShZpit5ZdM/3FE5MZqLW6yk AB2QT/e5E3U6A1iG6BzCVG6KYmJ/EiqOKh8nZWoUV1I1GocwpruWHJegQE7mzX4GzPDx bRwygVYxkpXbWbHurb8GnWy3gWT0aujWV+yamiCpR/dzqIJd5f5nXDPkTyt9OSVJHre5 9o9A== 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=50/+BuTvOunzjjo5do2C6L/SvOIalzn/finPuIM/ABc=; b=hYlUlDywmVDJ0tO2FjWq3RILy42XI5apoZNqiaJ5gP2c+t3T+I5zhCZpinPY1oBgNC D4hgLF567HtkeNwTaUS6dIe90F2Cnru8kXsjBBNHvS5td/9uVJ7VYzcG9+I2kKZdZdt/ m4rk+8YyWRMsa7pQxJgULc0EE1tOs3YZOdSfPPuFoyPnpwaL8SYWZ3XL/7UwbplMx+qO rSS7oTqxHXk9RwL5LErRoRG4RPtPmKHeOufRecXJUGPs+9K5XExmJCIIGx381Z5HnlpH H7kWCso+3SXpFyrPz5g2xrK5gyVCVy9zDYCMdvMvm/72l27lfedgTH4MC0IfN8qiFJgf qB8Q== X-Gm-Message-State: ALQs6tC3eislLvGVXNbLbgpuF7fwteq0IRjflyLpEallZk21/yftvZ15 p5if8ZOdQRa2VwHLnnmxocDkDcd/7+FXN+0tfKaUO5FJyjJ0C3dflVyT9G/uxH30N/xMOj2SbTP XScAlrRWbV1S0aANGs3X6WUDy7cikgMixN/GaA8Laves5n6abvXd2CckrYkwf X-Google-Smtp-Source: AIpwx4/7lWXziTh40Jf4zcxhVebDT9mb54Ssf9wEdPj+Spd4rEc78YbN4GuBhQ/YMGc3tfSdp2jVrA== X-Received: by 10.101.70.72 with SMTP id k8mr24554174pgr.47.1524728313489; Thu, 26 Apr 2018 00:38:33 -0700 (PDT) Received: from [192.168.179.5] (KD111239190182.au-net.ne.jp. [111.239.190.182]) by smtp.gmail.com with ESMTPSA id v8sm12663812pff.89.2018.04.26.00.38.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Apr 2018 00:38:32 -0700 (PDT) To: dmarc@ietf.org References: <401ecb2f-6dae-24d3-06dc-fa91584844cd@crash.com> <3441720.hKJZRnDj7p@kitterma-e6430> <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> <7252667E-627B-4249-9168-5D1E2A30FEB9@wordtothewise.com> <08a3c8b7-8419-48ec-17e0-6dc4c3e89c0a@dcrocker.net> From: Shoko YONEZAWA Message-ID: <13ea17cb-0493-9a16-333f-5945ef1eccbe@lepidum.co.jp> Date: Thu, 26 Apr 2018 16:38:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <08a3c8b7-8419-48ec-17e0-6dc4c3e89c0a@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 07:38:37 -0000 My opinion is that there seems no trouble in the case that the receiver issues dmarc=pass to the mail, whose domain has no DMARC record, and which is determined dmarc=pass even if DMARC record exists. In such case, dmarc=pass will be issued for any DMARC record where "strict" decision policy is set. Shoko On 2018/04/18 0:59, Dave Crocker wrote: > +1, for all of the below. > > > d/ > > On 4/17/2018 8:41 AM, Steve Atkins wrote: >> >>> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO wrote: >>> >>> I think "virtual DMARC" is out of DMARC scope, >>> because it's a purely internal policy decision. >> >> +1 for the (not entirely unreasonable, but entirely internal) >> algorithm used, -1 for the terminology. >> >> Where it's in scope is that it's using the term DMARC for something >> that is really not DMARC and as part of that it seems to suggest >> squatting on the dmarc= namespace in Authentication-Results. >> >> On 2018/03/20 6:17, Scott Kitterman wrote: >>> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the >>> opt-in >>> nature of SPF and DMARC and should be considered harmful. >> >> +1 >> >> Again, please don't do this. >> >> Cheers, >>    Steve >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > -- Shoko YONEZAWA Lepidum Co. Ltd. yonezawa@lepidum.co.jp TEL: +81-3-6276-5103 From nobody Thu Apr 26 02:49:56 2018 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 B90C31241F3 for ; Thu, 26 Apr 2018 02:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=officerakuten.onmicrosoft.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 QS_79sFcrJYW for ; Thu, 26 Apr 2018 02:49:51 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0114.outbound.protection.outlook.com [104.47.124.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E34120726 for ; Thu, 26 Apr 2018 02:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=OFFICERAKUTEN.onmicrosoft.com; s=selector1-rakuten-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7nkCXl7zK6C5RYJb2l0heRbZC+PYdwKYX7UgVu1JzOU=; b=CuUwXAZgmAmF5xE0wEzzBG42GmqsShhsQ+Gf3nk0gI+jpLrgQPQXur77dpYuDuQaKBx3gKnUTgjQ9WB/gBaINpH5+WRQzjEm23rRhIwTHRTJFILZGhkTu71Ep+TLrCuxKa4qXPrYJ9i0aXDpiCXlT/0aO8pvcvecuneXb+rXGcE= Received: from HKXPR03MB0677.apcprd03.prod.outlook.com (10.161.180.22) by HKXPR03MB2231.apcprd03.prod.outlook.com (10.141.135.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.7; Thu, 26 Apr 2018 09:49:47 +0000 Received: from HKXPR03MB0677.apcprd03.prod.outlook.com ([fe80::691a:3859:d833:1635]) by HKXPR03MB0677.apcprd03.prod.outlook.com ([fe80::691a:3859:d833:1635%2]) with mapi id 15.20.0735.005; Thu, 26 Apr 2018 09:49:46 +0000 From: "Yasutaka, Genki | Dkim | OPS" To: Shoko YONEZAWA , "dmarc@ietf.org" CC: "Yasutaka, Genki | Dkim | OPS" Thread-Topic: [dmarc-ietf] [Request] Presentation in IETF101 Thread-Index: AQHTte1NZwluylSpg0ekDSDbqtpQJaPIeXKAgAkXENCABnCmAIAAHP7wgAAFawCALJVqAIAAoGAAgAAE7ICADZkBgIAAJCXQ Date: Thu, 26 Apr 2018 09:49:46 +0000 Message-ID: References: <401ecb2f-6dae-24d3-06dc-fa91584844cd@crash.com> <3441720.hKJZRnDj7p@kitterma-e6430> <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> <7252667E-627B-4249-9168-5D1E2A30FEB9@wordtothewise.com> <08a3c8b7-8419-48ec-17e0-6dc4c3e89c0a@dcrocker.net> <13ea17cb-0493-9a16-333f-5945ef1eccbe@lepidum.co.jp> In-Reply-To: <13ea17cb-0493-9a16-333f-5945ef1eccbe@lepidum.co.jp> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=genki.yasutaka@rakuten.com; x-originating-ip: [133.237.7.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HKXPR03MB2231; 7:7oVpzsV7FmNHCS+UVPE0XUAYg2jXa1RbcZ5lAG9FzW1t/DzpbmyLN7Lgz6VMrz9KI0jXiPiZB6iYMBY5gop1YMhX96y+49ER59daqLUPF+OQPsulteeXHkQi0deJpOjP6Z88vkFz6ctYAmkK+6o0xwSJvLF/U/Bs/ddkPEjJTMTCSe4F3UTPHQ8cWbEzA5VEJB5N5Uxk1kp/KvDrsqphTh9IT/fsDhzvoTHpbspeJtCu6ltop2egXy3qFGBO2nVl; 20:wdLzGs2jhR1Tt9NsQk46AXdRXZpYbBS3kv9Vv93aFDAwUFz1V2UgEsOwKWVH3Iyra5F7JHglbzbi1OrDiQlVAZoqSOHrjZ5ce789y9qH+qpMn0wblazv4fsRa67nwYQf9olfRuK+D9NdwUYKkKG1/JaDnG2VX6+vycN+Z8QwyjFaZm4GaQwJD9iRpEzMycnJNUgbLrDJROJ4DdyILh+Plm6n+tTOT895k5M14s9QrC3uS2Dkl9mtg8+0MoztaHc7ck0/+T7qtwyA3Bsu3kiKQTfBN483iX6RxVfdEzPXiIpcrXa8iBshasME0fbg6MsaTlMrxQFl54mA3ugzc+rjpiv2S/O6dyKIfRnWAIxKcMkMmybLrQ9xugBVblOHjnLp1xHPZ90UeWYubA0jos6b4X9PELyFo2WepExhMYP8j1oj17UdxptK3DfP5YehVytks7ur24nqdYjKCef0UX+ryWOYgNCRKXHkomcQIC95XDcfRM2qtMZ5odwN0zEQYfAL x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:HKXPR03MB2231; x-ms-traffictypediagnostic: HKXPR03MB2231: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(83146419253472)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:HKXPR03MB2231; BCL:0; PCL:0; RULEID:; SRVR:HKXPR03MB2231; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39380400002)(39860400002)(366004)(13464003)(199004)(189003)(11346002)(86362001)(68736007)(3846002)(5660300001)(4326008)(8936002)(6116002)(66066001)(305945005)(81156014)(107886003)(74316002)(53936002)(3280700002)(6246003)(229853002)(33656002)(7736002)(8676002)(105586002)(3660700001)(106356001)(2906002)(81166006)(97736004)(6436002)(14454004)(446003)(2900100001)(59450400001)(478600001)(2501003)(25786009)(99286004)(476003)(76176011)(102836004)(186003)(486006)(5250100002)(7696005)(110136005)(9686003)(26005)(316002)(93886005)(966005)(6506007)(53546011)(6306002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:HKXPR03MB2231; H:HKXPR03MB0677.apcprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: rakuten.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: f1Xjy1IcUjt5XFpxvqOshXpbYeAYLiF/assf2I7srYl6iLY0mVdKjc8P2TRZaKA6pytQNjFnfe/5MW6cWP/vWS/qZ1YyDoyPI6lfbPMQlIA2Giz6UFioO3O8gkMxyrQZULek8pCRXKp1A2rpbeqXilarVmkEQH2SPbz5tiDmL626k5iUnbFh1IkvcmFBAN92 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 85962a28-706a-4023-45f0-08d5ab5b0b8e X-OriginatorOrg: rakuten.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85962a28-706a-4023-45f0-08d5ab5b0b8e X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 09:49:46.6571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53a8b0d9-d900-48cc-9d7e-5935dc8d5b17 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HKXPR03MB2231 Archived-At: Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 09:49:55 -0000 TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHdlIGhhdmUgcmVjZWl2ZWQgc29tZSBjb21tZW50cyBz byBmYXIgYWdhaW5zdCBWaXJ0dWFsIERNQVJDLg0KDQpUaGUgbWFpbiBjb21tZW50cyBhcmUgYXMg Zm9sbG93czoNCi0gREtJTSBoYXMgb3B0LWluIG5hdHVyZS4NCi0gRE1BUkMgaXMgY29tcG9zZWQg YnkgcG9saWN5IGFuZCByZXBvcnRpbmcsIGJ1dCBWaXJ0dWFsIERNQVJDIGRvZXMgbm90IGhhdmUg cmVwb3J0aW5nLg0KLSBSZWNlaXZlcnMgY2FuIHdvcmsgdGhpcyBraW5kIG9mIG9wZXJhdGlvbnMg dXNpbmcgbG9ncyBhcyB0aGV5IGxpa2UuDQoNClJlZ2FyZHMsDQpHZW5raQ0KDQotLS0NCkdlbmtp IFlBU1VUQUtBDQpSYWt1dGVuLCBJbmMuDQpNYWlsOiBnZW5raS55YXN1dGFrYUByYWt1dGVuLmNv bQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZG1hcmMgW21haWx0bzpkbWFy Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hva28gWU9ORVpBV0ENClNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAyNiwgMjAxOCA0OjM4IFBNDQpUbzogZG1hcmNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbZG1hcmMtaWV0Zl0gW1JlcXVlc3RdIFByZXNlbnRhdGlvbiBpbiBJRVRGMTAxDQoN Ck15IG9waW5pb24gaXMgdGhhdCB0aGVyZSBzZWVtcyBubyB0cm91YmxlIGluIHRoZSBjYXNlIHRo YXQgdGhlIHJlY2VpdmVyIGlzc3VlcyBkbWFyYz1wYXNzIHRvIHRoZSBtYWlsLCB3aG9zZSBkb21h aW4gaGFzIG5vIERNQVJDIHJlY29yZCwgYW5kIHdoaWNoIGlzIGRldGVybWluZWQgZG1hcmM9cGFz cyBldmVuIGlmIERNQVJDIHJlY29yZCBleGlzdHMuDQoNCkluIHN1Y2ggY2FzZSwgZG1hcmM9cGFz cyB3aWxsIGJlIGlzc3VlZCBmb3IgYW55IERNQVJDIHJlY29yZCB3aGVyZSAic3RyaWN0IiBkZWNp c2lvbiBwb2xpY3kgaXMgc2V0Lg0KDQpTaG9rbw0KDQpPbiAyMDE4LzA0LzE4IDA6NTksIERhdmUg Q3JvY2tlciB3cm90ZToNCj4gKzEsIGZvciBhbGwgb2YgdGhlIGJlbG93Lg0KPiANCj4gDQo+IGQv DQo+IA0KPiBPbiA0LzE3LzIwMTggODo0MSBBTSwgU3RldmUgQXRraW5zIHdyb3RlOg0KPj4NCj4+ PiBPbiBBcHIgMTYsIDIwMTgsIGF0IDExOjA3IFBNLCBLYXp1bm9yaSBBTkRPIDxhbmRvQGJic2Vj LmNvLmpwPiB3cm90ZToNCj4+Pg0KPj4+IEkgdGhpbmsgInZpcnR1YWwgRE1BUkMiIGlzIG91dCBv ZiBETUFSQyBzY29wZSwgYmVjYXVzZSBpdCdzIGEgcHVyZWx5IA0KPj4+IGludGVybmFsIHBvbGlj eSBkZWNpc2lvbi4NCj4+DQo+PiArMSBmb3IgdGhlIChub3QgZW50aXJlbHkgdW5yZWFzb25hYmxl LCBidXQgZW50aXJlbHkgaW50ZXJuYWwpDQo+PiBhbGdvcml0aG0gdXNlZCwgLTEgZm9yIHRoZSB0 ZXJtaW5vbG9neS4NCj4+DQo+PiBXaGVyZSBpdCdzIGluIHNjb3BlIGlzIHRoYXQgaXQncyB1c2lu ZyB0aGUgdGVybSBETUFSQyBmb3Igc29tZXRoaW5nIA0KPj4gdGhhdCBpcyByZWFsbHkgbm90IERN QVJDIGFuZCBhcyBwYXJ0IG9mIHRoYXQgaXQgc2VlbXMgdG8gc3VnZ2VzdCANCj4+IHNxdWF0dGlu ZyBvbiB0aGUgZG1hcmM9IG5hbWVzcGFjZSBpbiBBdXRoZW50aWNhdGlvbi1SZXN1bHRzLg0KPj4N Cj4+IE9uIDIwMTgvMDMvMjAgNjoxNywgU2NvdHQgS2l0dGVybWFuIHdyb3RlOg0KPj4+IEZ1bmRh bWVudGFsbHksIGJvdGggU1BGICJCZXN0IEd1ZXNzIiBhbmQgIlZpcnR1YWwgRE1BUkMiIGRlc3Ry b3kgdGhlIA0KPj4+IG9wdC1pbiBuYXR1cmUgb2YgU1BGIGFuZCBETUFSQyBhbmQgc2hvdWxkIGJl IGNvbnNpZGVyZWQgaGFybWZ1bC4NCj4+DQo+PiArMQ0KPj4NCj4+IEFnYWluLCBwbGVhc2UgZG9u J3QgZG8gdGhpcy4NCj4+DQo+PiBDaGVlcnMsDQo+PiDCoMKgIFN0ZXZlDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRtYXJjIG1haWxp bmcgbGlzdA0KPj4gZG1hcmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1hcmMNCj4+DQo+IA0KPiANCg0KLS0NClNob2tvIFlPTkVaQVdBDQpMZXBp ZHVtIENvLiBMdGQuDQp5b25lemF3YUBsZXBpZHVtLmNvLmpwDQpURUw6ICs4MS0zLTYyNzYtNTEw Mw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1h cmMgbWFpbGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kbWFyYw0K From nobody Thu Apr 26 05:19:53 2018 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 088441201FA for ; Thu, 26 Apr 2018 05:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=regumi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zpdA6xPnP3g for ; Thu, 26 Apr 2018 05:19:50 -0700 (PDT) Received: from mx01.regumi.net (153-149-28-102.compute.jp-e1.cloudn-service.com [153.149.28.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6701201F8 for ; Thu, 26 Apr 2018 05:19:50 -0700 (PDT) Received: from zcs04.regumi.org (210-129-15-205.jp-east-2.compute.idcfcloud.com [210.129.15.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx01.regumi.net (Postfix) with ESMTPS id D73823558; Thu, 26 Apr 2018 21:19:48 +0900 (JST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx01.regumi.net D73823558 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=regumi.net; s=s161204a; t=1524745188; bh=WJFt2YyI8nISkBXJ3kWTqH+YLvP/ZThRZArlPx5ugJw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=MXcc5+sxiBQigbIcNsF4Qmr4LYoxM1nU9sMwX9qpokjcG0zwqAyMHySATLJHRqjZq SOYmtUfT039X9BzVMVvqCEZuA9A6yaXv/e69+ClnTzUbWfCNJiKWla7zMh9Dfkr+PX I63PALJ67yHn4uwB908Bm6bEE5MIot9SH/H5TpN0= Received: from localhost (localhost [127.0.0.1]) by zcs04.regumi.org (Postfix) with ESMTP id 9F046F07D3; Thu, 26 Apr 2018 21:19:48 +0900 (JST) X-Virus-Scanned: amavisd-new at regumi.net Received: from zcs04.regumi.org ([127.0.0.1]) by localhost (zcs04.regumi.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PDDMP_0yMAFZ; Thu, 26 Apr 2018 21:19:48 +0900 (JST) Received: from zcs04.regumi.org (zcs04.regumi.org [10.33.0.142]) by zcs04.regumi.org (Postfix) with ESMTP id 7312FF07C4; Thu, 26 Apr 2018 21:19:48 +0900 (JST) Date: Thu, 26 Apr 2018 21:19:48 +0900 (JST) From: Takehito Akagiri To: "Yasutaka, Genki | Dkim | OPS" Cc: Shoko YONEZAWA , dmarc@ietf.org Message-ID: <1500683461.2769.1524745188267.JavaMail.zimbra@regumi.net> In-Reply-To: References: <3441720.hKJZRnDj7p@kitterma-e6430> <43dc57eb-01e5-2c34-242f-7a97ad475f60@bbsec.co.jp> <7252667E-627B-4249-9168-5D1E2A30FEB9@wordtothewise.com> <08a3c8b7-8419-48ec-17e0-6dc4c3e89c0a@dcrocker.net> <13ea17cb-0493-9a16-333f-5945ef1eccbe@lepidum.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [124.215.221.11] X-Mailer: Zimbra 8.8.5_GA_1894 (ZimbraWebClient - GC65 (Mac)/8.8.5_GA_1894) Thread-Topic: Presentation in IETF101 Thread-Index: AQHTte1NZwluylSpg0ekDSDbqtpQJaPIeXKAgAkXENCABnCmAIAAHP7wgAAFawCALJVqAIAAoGAAgAAE7ICADZkBgIAAJCXQvR27040= Archived-At: Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 12:19:52 -0000 Hi,=20 > DKIM has opt-in nature. If opt-in means that DMARC record exists, our proposal is to change this op= t-in nature because, as Shoko mentioned, virtual DMARC only focuses on the = case which is obviously determined PASS. No one will not be in troubled, so I think we can modify about that. If not, I would like to know the specific situation.=20 > Receivers can work this kind of operations using logs as they like. Yes, receivers can do by themselves if they do not care about the complianc= e with RFC7489. It specifies that the receiver adds dmarc=3Dnone in case there is no DMARC = record, while dmarc=3Dpass will be added if DMARC record exists. So I think we should discuss this contradiction. ---From RFC7489-- 11.2. Authentication-Results Result Registry Update IANA has added the following in the "Email Authentication Result Names" registry: Code: none Existing/New Code: existing Defined: [AUTH-RESULTS] Auth Method: dmarc (added) Meaning: No DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted. ---- > DMARC is composed by policy and reporting, but Virtual DMARC does not hav= e reporting. Is it acceptable to introduce the new AR code, such as dmarc=3DSoftPass, and add it if no reporting policy is published ? With this new code, one can distinguish DMARC with reporting from DMARC wit= hout reporting. # In the current I-D, it specifies as PASS. To summarize,=20 1. Whether DMARC always requires opt-in 2. Whether dmarc=3Dnone is appropriate for the case where there is no DMARC= record 3. Whether reporting is mandatory for DMARC Best regards, --Takehito Akagiri ----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 ----- =E5=B7=AE=E5=87=BA=E4=BA=BA: "Yasutaka, Genki | Dkim | OPS" =E5=AE=9B=E5=85=88: "Shoko YONEZAWA" , dmarc@ietf.o= rg Cc: "Yasutaka, Genki | Dkim | OPS" =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2018=E5=B9=B44=E6=9C=8826=E6=97=A5, = =E6=9C=A8=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 6:49:46 =E4=BB=B6=E5=90=8D: Re: [dmarc-ietf] [Request] Presentation in IETF101 My understanding is that we have received some comments so far against Virt= ual DMARC. The main comments are as follows: - DKIM has opt-in nature. - DMARC is composed by policy and reporting, but Virtual DMARC does not hav= e reporting. - Receivers can work this kind of operations using logs as they like. Regards, Genki --- Genki YASUTAKA Rakuten, Inc. Mail: genki.yasutaka@rakuten.com -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Shoko YONEZAWA Sent: Thursday, April 26, 2018 4:38 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101 My opinion is that there seems no trouble in the case that the receiver iss= ues dmarc=3Dpass to the mail, whose domain has no DMARC record, and which i= s determined dmarc=3Dpass even if DMARC record exists. In such case, dmarc=3Dpass will be issued for any DMARC record where "stric= t" decision policy is set. Shoko On 2018/04/18 0:59, Dave Crocker wrote: > +1, for all of the below. >=20 >=20 > d/ >=20 > On 4/17/2018 8:41 AM, Steve Atkins wrote: >> >>> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO wrote: >>> >>> I think "virtual DMARC" is out of DMARC scope, because it's a purely=20 >>> internal policy decision. >> >> +1 for the (not entirely unreasonable, but entirely internal) >> algorithm used, -1 for the terminology. >> >> Where it's in scope is that it's using the term DMARC for something=20 >> that is really not DMARC and as part of that it seems to suggest=20 >> squatting on the dmarc=3D namespace in Authentication-Results. >> >> On 2018/03/20 6:17, Scott Kitterman wrote: >>> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the=20 >>> opt-in nature of SPF and DMARC and should be considered harmful. >> >> +1 >> >> Again, please don't do this. >> >> Cheers, >> =C2=A0=C2=A0 Steve >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >=20 >=20 -- Shoko YONEZAWA Lepidum Co. Ltd. yonezawa@lepidum.co.jp TEL: +81-3-6276-5103 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc