Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

Dotzero <dotzero@gmail.com> Thu, 06 May 2021 16:56 UTC

Return-Path: <dotzero@gmail.com>
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 7821B3A28EF for <dmarc@ietfa.amsl.com>; Thu, 6 May 2021 09:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7zzvIsivVrDu for <dmarc@ietfa.amsl.com>; Thu, 6 May 2021 09:55:56 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 7A8353A28ED for <dmarc@ietf.org>; Thu, 6 May 2021 09:55:56 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id r13so3401566qvm.7 for <dmarc@ietf.org>; Thu, 06 May 2021 09:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VwyHel0F/r80zRtTRZG5kNTxSWWyFur5jxmjO3/uvZ8=; b=P1ozxsqt7IytSeDKMPczyMmVhEn0QH2S8d5mglRwee08I9togdfoJCQjUDKfBm/qmW iwqo37hfl02Ysxy+puduunSPZ04Mb+nMUAzerdUwSsfSe9DK4Ce07HzLDa5N6kg/x+aV RL4FCMEqZvRiofgMbqWClsZwiOFI7+8reM802dA5DUmlONfmEvTYGlzdLB1Cv3cV71T6 uYh3x3xMJDUA6ssYomA4OOU8WsJxASHh7dbk5sF+GoGKMh7b/Fn/CenO3mx7iRfp6wkX imLT5qdlIja5NJ9pXGe7X/sy9OqZGJoTv72ym5MivSZVi8B0xYYcKlAfq+a9iuO6PI/N zWRQ==
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=VwyHel0F/r80zRtTRZG5kNTxSWWyFur5jxmjO3/uvZ8=; b=WO+nF/duIzmoqYOC2mPsKcLkIQ7Dhw8iDRT1l5B4EIQr4OHJ3VJfmLR1blMfiZ/NUV MRDYBZy/9v3AcjOLuy0Ook8HMysD/YIBCVVzUsNOKTZAwktfR28CjfMW7+4VP5rsn1uB rQSMezM7goECcoh2UCYoVqtFNxORjR1cX38oFXtljhP+qlngKs0c9pQiaptlAQUcNBHr i6NK2UEV29Iew76W0eDgZXFK4eomz9aq/zlGB30zR43CRfGi9elC+CmrURyNeKJlVKxE nYKKc4vjxkxOQPQdAfVP5z/Bzek+E1INgZp+j6Bv7VeBPwxUKX6RnpvvlWo4/Z+4ME0e i7Hw==
X-Gm-Message-State: AOAM533qAHrIr0fZkI67i/fH3HgrMyjLpu871BEFYM/ZPCDKjMM5YJAh d0sZGbemlyRFykf8bkg9S6NGYpQvTgOW9KaTIp8w31yQHBTMgg==
X-Google-Smtp-Source: ABdhPJzUUio7YBB+UlhiYe0zLF5qSPq78QhKsuWWLyfJXkA7LcXVtU+Ie4nwDZh+ko9e3Dt5SGbgjCeks+9f89n7a9k=
X-Received: by 2002:a05:6214:d84:: with SMTP id e4mr5529816qve.48.1620320154787; Thu, 06 May 2021 09:55:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8mU58N60MLmc4qRrUPjfUojxxv8MFzkwSZRSk5uCE8o6A@mail.gmail.com> <7bb7bb44-e9fc-d52a-6430-d54c5717ab34@tana.it> <CAHej_8mCEC4GPJHJAz=EOTwhTtkoEwrDvPVg1kDzn8BcfCAj2A@mail.gmail.com>
In-Reply-To: <CAHej_8mCEC4GPJHJAz=EOTwhTtkoEwrDvPVg1kDzn8BcfCAj2A@mail.gmail.com>
From: Dotzero <dotzero@gmail.com>
Date: Thu, 6 May 2021 12:55:44 -0400
Message-ID: <CAJ4XoYcT_cqNanUsqZOQVK8rjgv9rC21LQqVbHdiUrRvg_ZQaA@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003fa56905c1ac2f8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DBUEA8gOrIFYzWZsjj2FlNfsjWw>
Subject: Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 16:56:01 -0000

Overall I'm comfortable with the introduction verbiage. I do have one
concern:

"For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the Domain Owner and/or any, some, or all of the

   Authenticated Identifiers.  Therefore, reputation assessment of that

   stream by the mail-receiving organization does not need to be

   encumbered by accounting for unauthorized use of any domains."



My concern is with "does not need to be encumbered by accounting for
unauthorized use of any domains". This ignores cases such as DNS hijacking
and domain compromise. Perhaps changing it to "does not need to be
encumbered by accounting for unauthorized use of any domains by 3rd party
senders" or  "does not need to be encumbered by accounting for unauthorized
use of any domains by 3rd party originators"

Michael Hammer

On Thu, May 6, 2021 at 8:22 AM Todd Herr <todd.herr=
40valimail.com@dmarc.ietf.org> wrote:

> On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely <vesely@tana.it> wrote:
>
>> Todd,
>>
>> does your message assume that the relevant tickets are all accepted as
>> valid
>> indications to alter the spec?  In particular, tickets #52 and #75 have
>> never
>> been discussed on list. I'd guess they'll have to be discussed in their
>> own
>> threads.
>>
>
> I don't know if each of those individual tickets has to be discussed in
> their own threads or not, and I think it's more a decision for the chairs
> to make than for the editors or the working group, but I could be very
> wrong about that.
>
> What I will say is this:
>
>    - The design team went off and effectively created a new version of
>    draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
>    proposed text, nothing more, nothing less.
>    - The design team's work was influenced by those tickets which
>    currently show a status of 'infoneeded'.
>    - Due to the nature of the text, both of the following are true:
>       - Most, but perhaps not all, of the 'infoneeded' tickets had
>       impacts on multiple sections of draft-ietf-dmarc-dmarcbis-01
>       - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
>       that were made in producing draft-ietf-dmarc-dmarcbis-01 were influenced by
>       multiple tickets
>
> Back on April 23, when I posted here about setting expectations, I thought
> at the time that adjudicating each of the infoneeded tickets might be the
> way to go, but upon further reflection I'm not sure that's the case, since
> it can be argued that those tickets were created against a work product
> that no longer exists. It's also true that because those tickets affect the
> wording in multiple sections of the document, adjudicating the -00 tickets
> can theoretically result in a morass of edits made across multiple sections
> of -01 and subsequent revisions, and everyone eventually losing the plot.
>
> Chairs, your thoughts?
>
>
>> Discussing the resulting text before those tickets entails, for example,
>> noting
>> the cumbersomeness of the locution "severity of concern" where something
>> like
>> "desired disposition" might seem more immediate.  In fact, ticket #85 was
>> only
>> discussed as a side effect of ticket #39, where the consensus, IIRC, was
>> to
>> keep the existing policy names while wavering about how to describe them.
>>
>> The term RFC5322.From is consistently used, notwithstanding ticket #96.
>> For an
>> alternative, let me attempt to define DMARC in terms of its acronym:
>>
>>     The Domain-based Message Authentication, Reporting, and Conformance
>> (DMARC)
>>     protocol recognizes the prevailing importance of the domain appearing
>> in the
>>     From: header field of email messages.  That domain name will be
>> called the
>>     Main Identifier in this document.  DMARC leverages the Sender Policy
>>     Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
>> protocols
>>     by focusing the authentication mechanisms they provide toward the Main
>>     Identifier.  The Domain Owners corresponding to the Main Identifier
>> are
>>     endowed with the possibility to receive feedback reports about
>>     authentication results at receivers.  Finally, receivers are provided
>> with
>>     the Domain Owners' desiderata about messages that fail
>> authentication, which
>>     receivers may or may not decide to conform to.
>>
>>
> As I stated above, I believe the better path for the working group is to
> adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
> labeled "Introduction", you have proposed alternate text for that section,
> let's discuss that section on the list, come to a consensus, and do it all
> under the auspices of ticket 113.
>
> But that's just my opinion...
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.herr@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>