Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

Neil Anuskiewicz <neil@marmot-tech.com> Wed, 12 August 2020 13:23 UTC

Return-Path: <neil@marmot-tech.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 06D943A1285 for <dmarc@ietfa.amsl.com>; Wed, 12 Aug 2020 06:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=marmot-tech.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 eBQznSoPdtEg for <dmarc@ietfa.amsl.com>; Wed, 12 Aug 2020 06:23:07 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 420973A1273 for <dmarc@ietf.org>; Wed, 12 Aug 2020 06:23:07 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id j8so2435898ioe.9 for <dmarc@ietf.org>; Wed, 12 Aug 2020 06:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4DX7JFbYS8VygzRC3+OpC2AFERNe5OgnAnEsZxK2EuU=; b=Fapm44U/jUKczJ9VYim7yl3EXX5V6dGXfVHwIZ71GCJqKJZUS68IOJX/NJgUp/EN8y sRBDylzhCsA2jtbrLEqzDfSi82C/Ll1jQeyT+fS6bzEosx124DbAK4lcDE6IakYQ9P3g LPu4d0C0ydPl6SsDy6NvvZMDZ3XIqHsrYsjU8=
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=4DX7JFbYS8VygzRC3+OpC2AFERNe5OgnAnEsZxK2EuU=; b=Rh4GlOOzqITVLQN3aie2HTAoGRGD8w2+RRK7dOusJZfcu+3nYSEJJLMMMoP1sQSU2h DX/hEQdibH5owI904C265pTxpHTvau9rr3QAcHJEO30EsjWiLHp2ZhTTQgMIF5jXCh78 D1boiwXiasA3OGmJvo5Bfwl5gMVnB1Y1N80aT/ZdIAV6qv4iFCmQHtdJYnxDP0sPD57e Rnh1j5SyRH0FeUfSa26oPS2Q3I8GAGtD6LJLG07AkTBSwPrWmOs02U64fnVDkk/qNFvH GALFdQfL4q38masEZbRBSbfEmPeqQtMij5uVn/oLcHCT2gQcxHv+TvdLsw+3Jj+3xzpp iRZg==
X-Gm-Message-State: AOAM530DflhnLANly9gHRynNyGk5C7wKIcPsuPbsb7daEqUFjJme2ThX eC6lZWUFXCpEhBVcBDZdfxy4sKvA16ZxXCXPhwoJogu4ogx+8g==
X-Google-Smtp-Source: ABdhPJzet4JF4eUWw0xuyBAu4h3NbVuwIvjvvRGO8lmi/+PpdH92lgyXmP4fWA450gRDx0c9rhIHhRq6gsGLk5Op9ME=
X-Received: by 2002:a5d:8cce:: with SMTP id k14mr27326339iot.13.1597238586201; Wed, 12 Aug 2020 06:23:06 -0700 (PDT)
MIME-Version: 1.0
References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <CAOPP4WFVdTL6HywMCFbunOYMAb3aYcEjY37So6=KgyK+Fthh1A@mail.gmail.com> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> <CAOPP4WF3Bu4-EyND0yHPhDCBwCzk0_rupc9tMLAtJ9jUPGagaw@mail.gmail.com> <c9ec04e3-cb6f-2a3b-2aa5-3b249260e318@dcrocker.net>
In-Reply-To: <c9ec04e3-cb6f-2a3b-2aa5-3b249260e318@dcrocker.net>
From: Neil Anuskiewicz <neil@marmot-tech.com>
Date: Wed, 12 Aug 2020 06:22:30 -0700
Message-ID: <CAOPP4WEG0pHGH3ZuvAF=7nr9RdFK087o3MF8cCZhX0zX9a6acQ@mail.gmail.com>
To: dcrocker@bbiw.net
Cc: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008d6c6a05acae161b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/A5VwPhKjx-PO7ISEL6QN5HoPt3M>
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
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: Wed, 12 Aug 2020 13:23:09 -0000

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker <dhc@dcrocker.net> wrote:

> On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
> >
> >
> > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker <dhc@dcrocker.net
> > <mailto:dhc@dcrocker.net>> wrote:
> >
> >     On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> >      > Mr. Crocker, is there a document that describes some of these
> >     proposals
> >      > and perhaps the best arguments for an against somewhere? The
> >     firehose of
> >      > learning would a bit easier if there were a FAQ. I think it might
> >     even
> >      > help the participants if this was all documented. Yes, I know
> >     there's
> >      > the archived but I mean an organized and linear doc.
> >
> >
> >
> >     If you have particular questions, ask them.
> >
> >
> > I've just recently started lurking but I think this is a discussion
> > about semantics. What to call a proposed RFC5322.Sender field.
>
> The reference to field name was for an alternative to the rfc5322.From
> field, not sender.
>
> Ah, an alternative way for DMARC to come into alignment: RFC5322.Sender
== RFC5322.From so if tag is present permitting this alternative means of
alignment. With the tag present, the receiving system checks the DNS
of the RFC5322.Sender
domain. If the tag isn't present, it's business as usual.

My opinion is that having more ways to come into alignment available's a
good thing. I work mostly with small businesses that don't have zillions of
mail streams and moving parts. But DMARC sometimes finds rogue senders
within the organization (The Toledo office decided to do their own
marketing or Bob in sales is gonna make everything happen), legit senders
who aren't authenticated, mail streams everyone forgot about, and,
occasionally spoofers.

Even with a small business, turning the policy knob above none is
unnerving, especially if there's less than perfecto authentication across
the board on legit sources. I rarely go above none anyway but I do like the
option.



> > The problem being addressed is the munging of headers by mailing lists
> > and other forwarders, breaking things like DKIM.
>
> mailing lists pretty much always break DKIM.  One of the proposals is to
> try to recover signature validation, post hoc.
>
> > I've not been lurking long enough to grok what's going on but I'll
> > continue to lurk and learn, eventually finding a small way to contribute
> > to this effort even if it's just to sweep out the IETF Ashram. :-)
>
>
> Welcome aboard.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>