From nobody Sat Aug 1 18:27:18 2020 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 B032E3A0A12 for ; Sat, 1 Aug 2020 18:27:17 -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 FqqtWRKhlaOR for ; Sat, 1 Aug 2020 18:27:15 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 A9C4E3A0A0B for ; Sat, 1 Aug 2020 18:27:15 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id z6so35344199iow.6 for ; Sat, 01 Aug 2020 18:27:15 -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=8Yryq/GcfjQp/4uxoX9XNV5+yqdWY2QsOPZ3q7b8H5s=; b=E8Tvem2eGwz68he9P7vgXi1SH7sdmk88Wf4kFV7C47S97l+kEuACwrfzb/2lmeI4hA 9jDnQmxQvxhAY97pqFMIiHm0Nwk8p5uW+NjEfRs+8jLt0HO3KhRNL20ZpuqY08Yq9MXr SBIP0JCs9kIZT/kmjCQhB0zIvSPNGSqAPbrX0= 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=8Yryq/GcfjQp/4uxoX9XNV5+yqdWY2QsOPZ3q7b8H5s=; b=SY4E1vopP03vJg3s8OZ30wCeJQdojBW80JeF/pDSu2wv3CxjslgFlexdySi+JhS6HF TrtaIXyCAZ74ErgJhJSBQQqXzAOzz1jkUp5Mln5XAh+Fqdl480Y+MsslriD/gvREVRTH V8UCnBWfx7ba4r+PsD8VKYCQeft3TtfUDQdgp/MHAuH+ZMVFAb979UnwHqIeZ1tLl3BE eB9t+agcsgWBc0hco0LrPgjgkZRtJvcHSZ94fvLk01yeucJz8M1o9LuwZ+uHhlVMPV2k XpGRt3lXlSEggiiLLLdu2DDTY0ZbPzpOsshP3wAZ7Sen5ON2DlafLVWlAYeS++tGtAns 0joA== X-Gm-Message-State: AOAM530/n4IsBGSo/tQwzISCH+3T1C/5kTmkkM+wyv/f7T+70bRNapyX ZTlL8xVisFh6+8CZGMmIwqcFgGVmrle88LAvusLhK/cKTF8mbw== X-Google-Smtp-Source: ABdhPJy5IMQRoCK2mmzmOpnx1RlqMIicU7jfQa2R86btem7yl2j/F0LC4plQUBEdEYWOsGWqXH6CtVkrggyLGubMFpk= X-Received: by 2002:a05:6602:220f:: with SMTP id n15mr10634541ion.103.1596331634822; Sat, 01 Aug 2020 18:27:14 -0700 (PDT) MIME-Version: 1.0 References: <95C85860-4C8E-4593-90B1-C9800D919E05@lem.click> In-Reply-To: From: Neil Anuskiewicz Date: Sat, 1 Aug 2020 18:26:38 -0700 Message-ID: To: =?UTF-8?B?THVpcyBFLiBNdcOxb3o=?= Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="00000000000009adcf05abdaeceb" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 01:27:18 -0000 --00000000000009adcf05abdaeceb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I looked at ~3.5 million domain names and here's some of what I found. This data might be useful to the discussion. As for me, I'm lurking and learning= . Anyway, I looked at ~3.5 million domain names and here's some of what I found: FTSE DMARC Adoption DMARC Policy 10/18/2019 No record 56% none 34% quarantine 1% reject 9% F500 DMARC Adoption DMARC Policy 10/18/2019 no record 49% none 37% quarantine 4% reject 9% ASX DMARC Adoption DMARC Policy 10/18/2019 no record 59% none 33% quarantine 1% reject 7% On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz wrote: > I looked at ~3.5 million domain names and here's some of what I found. > This wasn't a random sample but perhaps this data will be useful in this > discussion: > > FTSE DMARC Adoption > > Snapshot (10/18) > No record 56% > none 34% > quarantine 1% > reject 9% > F500 DMARC Adoption > > Snapshot (10/18) > no record 49% > none 37% > quarantine 4% > reject 9% > > ASX DMARC Adoption > > Snapshot (10/18) > no record 59% > none 33% > quarantine 1% > reject 7% > > Thanks. > > Neil > On Thu, Jul 30, 2020 at 6:02 PM Luis E. Mu=C3=B1oz 40lem.click@dmarc.ietf.org> wrote: > >> On 30 Jul 2020, at 15:52, Jim Fenton wrote: >> >> There's an underlying assumption here that I don't agree with: that >> DMARC adoption equates to the publication of a p=3Dreject DMARC policy, >> and that everyone (or at least all Fortune 500 companies) should be >> doing that. p=3Dreject should only be used when the usage patterns of th= e >> domain support that policy. I'm more inclined to say that 85% of Fortune >> 500 companies are savvy enough not to publish a policy that doesn't fit >> their usage patterns. >> >> I am currently observing ~215.5 million domain names. Out of those, ~64 >> million have a seemingly *valid* SPF record and ~113 million with at >> least one MX record. >> >> This is a current breakdown of the (valid) DMARC records I am observing >> over the general domain population above. This amounts to an adoption ra= te >> of ~1.7%. >> p count >> none 2715614 >> quarantine 238584 >> reject 726045 >> >> It is interesting that roughly half of those are not taking advantage of >> the reporting. Here are the counts for those with neither rua=3D nor ruf= =3D >> in the DMARC records: >> p count >> none 1092990 >> quarantine 107767 >> reject 307614 >> >> I do not have a definitive list of Fortune 500 domain names, but I >> compile a rolling list of domain names with most traffic using multiple >> sources, which currently holds ~1.8 million unique domain names. >> >> The breakdown of DMARC records from that high-traffic population is show= n >> below, and it amounts to about 6.3%. >> p count >> none 79367 >> quarantine 18094 >> reject 15875 >> >> For completeness, here is the same report, counting only those that have >> neither rua=3D nor ruf=3D in the DMARC record. The ratio of *silent* >> p=3Dquarantine and p=3Dreject seems around half as in the case of the >> general population. >> p count >> none 32561 >> quarantine 4534 >> reject 2760 >> >> It would seem that those high-traffic domains are ~5x more likely to >> adopt DMARC. To me, these numbers speaks of thoughtful and deliberate >> deployment that outpaces the general domain name registrations. >> >> That said, I cannot claim whether the list of high-traffic domains is >> actually a good proxy for the domain portfolio of the Fortune 500 compan= ies. >> >> Best regards >> >> -lem >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --00000000000009adcf05abdaeceb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I looked at ~3.5 million domain names and here's = some of what I found. This data might be useful to the discussion. As for m= e, I'm lurking and learning.

Anyway, I lo= oked at ~3.5 million domain names and here's some of what I found:
FTSE DMARC Adoption
DMARC Pol= icy10/18/2019
N= o record56%
none34= %
quarantine1%
reject9%
<= br>
=
F500 DMARC Adoption
DMARC Policy10/18/2019
no record49%
none37%
qua= rantine4%
reject9%=

ASX DMARC Adopti= on
DMARC Policy10/18/2019
no r= ecord59%
none33%
quarantine1%
reject7%





<= div class=3D"gmail_quote">
On Sat, Aug= 1, 2020 at 12:57 PM Neil Anuskiewicz <neil@marmot-tech.com> wrote:
I looked at ~3.5 million domain names and here's some of what I found= . This wasn't a random sample but perhaps this data will be useful in t= his discussion:

<= tr style=3D"height:20px"><= td style=3D"border-right:1px solid rgb(170,170,170);border-bottom:1px solid= rgb(170,170,170);border-left:1px solid rgb(170,170,170);overflow:hidden;pa= dding:0px;vertical-align:bottom;font-family:Calibri;color:rgb(0,0,0)">quara= ntine=
FTSE DMARC Adoption
Snapshot (10/18)
No record56%
none34%
1%
reject9%

F500 DMARC Adoption=
<= /td>
Snapshot (10/18)
no record49%
none37%
quarantine4%
reject9%
= =
ASX DMARC Adoption
Snapshot (10/18)
no re= cord59%
none33%
quarantine1%
reject7%<= /td>

Thanks.

<= div>Neil
On Thu, Jul 30, 2020 at 6:02 PM Luis E. Mu=C3=B1oz <dmarc-ietf.org=3D40lem.click@dmarc.ietf.org&= gt; wrote:

On 30 Jul 2020, at 15:52, Jim Fenton wrote:

There's an underlying assumption here that I don't = agree with: that
DMARC adoption equates to the publication of a p=3Dreject DMARC policy,
and that everyone (or at least all Fortune 500 companies) should be
doing that. p=3Dreject should only be used when the usage patterns of the domain support that policy. I'm more inclined to say that 85% of Fortun= e
500 companies are savvy enough not to publish a policy that doesn't fit=
their usage patterns.

I am currently observing ~215.5 million domain names. Out o= f those, ~64
million have a seemingly valid SPF record and ~113 million with a= t least one MX record.

This is a current breakdown of the (valid) DMARC records I = am observing over the general domain population above. This amounts to an a= doption rate of ~1.7%.

p count
none 2715614
quarantine 238584
reject 726045

It is interesting that roughly half of those are not taking= advantage of the reporting. Here are the counts for those with neither rua=3D nor ruf=3D in the DMARC records:

p count
none 1092990
quarantine 107767
reject 307614

I do not have a definitive list of Fortune 500 domain names= , but I compile a rolling list of domain names with most traffic using mult= iple sources, which currently holds ~1.8 million unique domain names.

The breakdown of DMARC records from that high-traffic popul= ation is shown below, and it amounts to about 6.3%.

p count
none 79367
quarantine 18094
reject 15875

For completeness, here is the same report, counting only th= ose that have neither rua=3D nor ruf=3D in the DM= ARC record. The ratio of silent p=3Dquarantine and p=3Dreject seems around half as in the case of the general popul= ation.

p count
none 32561
quarantine 4534
reject 2760

It would seem that those high-traffic domains are ~5x more = likely to adopt DMARC. To me, these numbers speaks of thoughtful and delibe= rate deployment that outpaces the general domain name registrations.

That said, I cannot claim whether the list of high-traffic = domains is actually a good proxy for the domain portfolio of the Fortune 50= 0 companies.

Best regards

-lem

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000009adcf05abdaeceb-- From nobody Sun Aug 2 08:01:10 2020 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 E07203A0EC9 for ; Sun, 2 Aug 2020 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrYseLPY_fmE for ; Sun, 2 Aug 2020 08:01:03 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A133A0EC6 for ; Sun, 2 Aug 2020 08:01:03 -0700 (PDT) X-ASG-Debug-ID: 1596380459-11fa3118c7b3e40001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 1mBLU8LshMXBgECb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 02 Aug 2020 11:00:59 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=BEetxqD34nMb0mMzwXXKUbop7F7LSMNTSUHJgQxxqrI=; b=jBYx9m2l6CW10eQDCim/4PbkeE8VVmxlqgcP1tpWiOLHOir+WUfE9bB8m23jH8ZmY uDmO7Kp0zUMcIFc7QGn7VnvxzTidV5ZgL5dppDYdTwGdcdCSOGna/op6ctHXN50Lu WNF1JPLsUtwV1nACdzBNXYjSaLVVxz/f4GRvrsFa4= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sun, 02 Aug 2020 15:00:52 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=4031ae4350194b919277b9af6716ffda In-Reply-To: References: <95C85860-4C8E-4593-90B1-C9800D919E05@lem.click> X-Exim-Id: cec0a539d7f34478930e2e172ace81c6 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1596380459 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 31149 X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: dmarc-ietf.org X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83643 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 15:01:08 -0000 This is a multipart message in MIME format. --4031ae4350194b919277b9af6716ffda Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have reviewed recent posts to this mailing list: Submissions have come = from 39 different people on 34 unique domains. Of these, 11 have munged h= eaders, indicating that they use an enforceable DMARC policy. This is a m= uch higher percentage than your general survey. I wonder if this is typical - are mailing list subscribers more likely to = be on DMARC-enforcing domains than the general population? Do the mailing list operators have data about what percentage of their subs= cribers (or percentage of unique domains) have DMARC policy enforcement in = place? DF ---------------------------------------- From: Neil Anuskiewicz Sent: 8/1/20 9:27 PM To: Luis E. Mu=C3=B1oz Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains I looked at ~3.5 million domain names and here's some of what I found. This= data might be useful to the discussion. As for me, I'm lurking and learnin= g. Anyway, I looked at ~3.5 million domain names and here's some of what I fou= nd: FTSE DMARC Adoption DMARC Policy 10/18/2019 No record 56% none 34% quarantine 1% reject 9% F500 DMARC Adoption DMARC Policy 10/18/2019 no record 49% none 37% quarantine 4% reject 9% ASX DMARC Adoption DMARC Policy 10/18/2019 no record 59% none 33% quarantine 1% reject 7% On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz wro= te: I looked at ~3.5 million domain names and here's some of what I found.. Thi= s wasn't a random sample but perhaps this data will be useful in this discu= ssion: FTSE DMARC Adoption Snapshot (10/18) No record 56% none 34% quarantine 1% reject 9% F500 DMARC Adoption Snapshot (10/18) no record 49% none 37% quarantine 4% reject 9% ASX DMARC Adoption Snapshot (10/18) no record 59% none 33% quarantine 1% reject 7% Thanks. Neil On Thu, Jul 30, 2020 at 6:02 PM Luis E. Mu=C3=B1oz wrote: On 30 Jul 2020, at 15:52, Jim Fenton wrote: There's an underlying assumption here that I don't agree with: that DMARC adoption equates to the publication of a p=3Dreject DMARC policy, and that everyone (or at least all Fortune 500 companies) should be doing that. p=3Dreject should only be used when the usage patterns of the domain support that policy. I'm more inclined to say that 85% of Fortune 500 companies are savvy enough not to publish a policy that doesn't fit their usage patterns. I am currently observing ~215.5 million domain names. Out of those, ~64 million have a seemingly valid SPF record and ~113 million with at least on= e MX record. This is a current breakdown of the (valid) DMARC records I am observing ove= r the general domain population above. This amounts to an adoption rate of = ~1.7%. p count none 2715614 quarantine 238584 reject 726045 It is interesting that roughly half of those are not taking advantage of th= e reporting. Here are the counts for those with neither rua=3D nor ruf=3D i= n the DMARC records: p count none 1092990 quarantine 107767 reject 307614 I do not have a definitive list of Fortune 500 domain names, but I compile = a rolling list of domain names with most traffic using multiple sources, wh= ich currently holds ~1.8 million unique domain names. The breakdown of DMARC records from that high-traffic population is shown b= elow, and it amounts to about 6.3%. p count none 79367 quarantine 18094 reject 15875 For completeness, here is the same report, counting only those that have ne= ither rua=3D nor ruf=3D in the DMARC record. The ratio of silent p=3Dquaran= tine and p=3Dreject seems around half as in the case of the general populat= ion. p count none 32561 quarantine 4534 reject 2760 It would seem that those high-traffic domains are ~5x more likely to adopt = DMARC. To me, these numbers speaks of thoughtful and deliberate deployment = that outpaces the general domain name registrations. That said, I cannot claim whether the list of high-traffic domains is actua= lly a good proxy for the domain portfolio of the Fortune 500 companies. Best regards -lem _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --4031ae4350194b919277b9af6716ffda Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I have reviewed re= cent posts to this mailing list:   Submissions have come from 39 diffe= rent people on 34 unique domains.   Of these, 11 have munged headers, = indicating that they use an enforceable DMARC policy.   This is a much= higher percentage than your general survey.

I won= der if this is typical  - are mailing list subscribers more likely to = be on DMARC-enforcing domains than the general population?

Do the mailing list operators have data about what percentage of t= heir subscribers (or percentage of unique domains) have DMARC policy enforc= ement in place?

DF


= From: Neil Anuskiewicz <neil@marmot-tech.com><= br>Sent: 8/1/20 9:27 PM
To: Luis E. Mu= =C3=B1oz <dmarc-ietf.org=3D40lem.click@dmarc.ietf.org>
Cc<= /strong>: dmarc@ietf.org
Subject: Re: [dmarc-ietf] non-= mailing list use case for differing header domains
I looked at ~3.5 million domain names and here's some of what I f= ound. This data might be useful to the discussion. As for me, I'm lurking a= nd learning.

Anyway, I looked at ~3.5 million= domain names and here's some of what I found:
= <= td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;font-fami= ly:Calibri;font-size:11pt;color:rgb(0,0,0);border:1px solid rgb(204,204,204= );">56%
FTSE DMARC Adoption
DMARC Policy10/18/2019
No record
none34%
quarantine1%
reject9%

=
<= tr style=3D"height:21px;"><= td style=3D"overflow:hidden;padding:2px 3px;vertical-align:bottom;font-fami= ly:Calibri;font-size:11pt;color:rgb(0,0,0);border:1px solid rgb(204,204,204= );">reject
F500 DMARC Adoption

DMARC Policy10/18/2019=
no record49%
none37%
quarantine4%
9%

<= tbody>=
ASX DMARC Adoption

DMARC Policy10/18/2019
no record59%
none33%
quarantine1%
reje= ct7%





On Sat, Aug 1, 2020 at 12:5= 7 PM Neil Anuskiewicz <neil@marmot-tech.com> wrote:

=
I looked at ~3.5 million domain names and here's some of what I found.= . This wasn't a random sample but perhaps this data will be useful in this = discussion:

34%
FTSE DMARC Adoption

Snapshot (10/18)
<= /td>
No record56%
none
quarantine1%
reject9%

F500 DMARC Adoption

Snapshot (10/18)
no record49%
none37%
quar= antine4%
reject9%

<= td style=3D"border-right:1px solid rgb(170,170,170);border-bottom:1px solid= rgb(170,170,170);overflow:hidden;padding:0px 3px;vertical-align:bottom;fon= t-family:Calibri;color:rgb(0,0,0);text-align:right;">1%
ASX DMARC Adoption

Snapshot (10/18)
no r= ecord59%
none33%
quarantine
reject7%

Thanks.
Neil
On Thu, Jul 30, 2020 at 6:02 PM Luis E. Mu=C3=B1oz <dmarc-ietf.org=3D40lem.click@dmarc.= ietf.org> wrote:

On 30 Jul 2020, at 15:52, Jim Fenton wrote:

There's an underly= ing assumption here that I don't agree with: that
DMARC adoption equates= to the publication of a p=3Dreject DMARC policy,
and that everyone (or = at least all Fortune 500 companies) should be
doing that. p=3Dreject sho= uld only be used when the usage patterns of the
domain support that poli= cy. I'm more inclined to say that 85% of Fortune
500 companies are savvy= enough not to publish a policy that doesn't fit
their usage patterns.

I am currently observing ~215.5 million doma= in names. Out of those, ~64
million have a seemingly valid SPF = record and ~113 million with at least one MX record.

Thi= s is a current breakdown of the (valid) DMARC records I am observing over t= he general domain population above. This amounts to an adoption rate of ~1.= 7%.

=
pcount
none2715614
quara= ntinereject726045

It is interesting that roughly half of thos= e are not taking advantage of the reporting. Here are the counts for those = with neither rua=3D nor ruf=3D in the DMARC recor= ds:

=
pcount
none1092990
quara= ntinereject307614

I do not have a definitive list of Fortune = 500 domain names, but I compile a rolling list of domain names with most tr= affic using multiple sources, which currently holds ~1.8 million unique dom= ain names.

The breakdown of DMARC records from that high= -traffic population is shown below, and it amounts to about 6.3%.

pcountnonequarantine18094reject15875<= p dir=3D"auto">For completeness, here is the same report, counting only tho= se that have neither rua=3D nor ruf=3D in the DMA= RC record. The ratio of silent p=3Dquarantine and p=3Dreject seems around half as in the case of the general popula= tion.

<= tr>
pcount
none32561
quara= ntinereject2760

It would seem that those high-traffic domains = are ~5x more likely to adopt DMARC. To me, these numbers speaks of thoughtf= ul and deliberate deployment that outpaces the general domain name registra= tions.

That said, I cannot claim whether the list of hig= h-traffic domains is actually a good proxy for the domain portfolio of the = Fortune 500 companies.

Best regards

-= lem

_______________________________________________dmarc mailing list
= dmarc@ietf.org
https://www.ietf.org/mailman/listin= fo/dmarc
--4031ae4350194b919277b9af6716ffda-- From nobody Sun Aug 2 09:58:03 2020 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 485463A044E for ; Sun, 2 Aug 2020 09:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=W5U1GfEn; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZTCSsUpB 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 6KcxqDALCG4I for ; Sun, 2 Aug 2020 09:57:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FE33A0433 for ; Sun, 2 Aug 2020 09:57:58 -0700 (PDT) Received: (qmail 12840 invoked from network); 2 Aug 2020 16:57:56 -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=3226.5f26f094.k2008; bh=HRIrKrIHu209sU7tpyfXoYELCaOf3CPF4U2bPbDOVLI=; b=W5U1GfEnpwmLHErF+QD8y3XPXfL0zMa1oyjbZfotrFdsj+DJZYAcdtvxro2zr/uY474BEMSgb86dGhJXAJtY8/OjApgqd6sLmCVs0mO+hW6BTGGREBurzI3v/nLJdNk/beN9maRHsanZ9uCOoDItbdBnApMhtQsQK0wh2SFY+jwxaWSG6RfVnQ2wyOOZjCI+n4jllhp/OWieCZrTOhJ3tRCaDwv5lTuIX8zo56Hm0LNpJODfgQAVLXayzMWI6q3Gpku5ZiqX5qtEzTQfOIa0ryqiuAGhrK9WHmSFd1IqmCNG0PqlWdmAHamKKPz7c0KFIU3Km6qERXJcQoTCQa02ZA== 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=3226.5f26f094.k2008; bh=HRIrKrIHu209sU7tpyfXoYELCaOf3CPF4U2bPbDOVLI=; b=ZTCSsUpBMeyewbF7cqjae1d4snjvt3Ro9UeYvaynAmP0Svm/hb9eG58TByB3YJGZPuifWv1nmNl/eTEaoaUdUZI7KN9qwwWwYo166DARgIxUVtGF4UcvW/lLxHNycHyhuRoDKdN9J/hT78naT6eMFVqXJpX8OFFYu660HqNUWe3PTyeZaipgk5Q9n2nny4s0X5qASC0xyddYtHbepWga7Z+1xzklqyWtrETCvZSTEnwrhoSVvEh/mcpiftlEvVezwRgKgyunWK8EAeueDj8mVMa2Z6IPvepx9Kz5zTGlqeDQGMBsG+A90jCbJ4PJGV2Zsv0HiFQSDD3fYV6zVz95ag== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Aug 2020 16:57:56 -0000 Received: by ary.qy (Postfix, from userid 501) id 3892C1DC82FD; Sun, 2 Aug 2020 12:57:56 -0400 (EDT) Date: 2 Aug 2020 12:57:56 -0400 Message-Id: <20200802165756.3892C1DC82FD@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 16:58:01 -0000 In article you write: >I wonder if this is typical - are mailing list subscribers more likely to be on DMARC-enforcing domains than the general population? > >Do the mailing list operators have data about what percentage of their subscribers (or percentage of unique domains) have DMARC policy enforcement in place? In my experience it completely depends on the list. I have a list of folk dancers with a lot of old AOL and Yahoo addresses with DMARC policies, and I have other lists where it's mostly gmail and Hotmail/Outlook, without. R's, John From nobody Sun Aug 2 10:07:03 2020 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 BC9C23A079B for ; Sun, 2 Aug 2020 10:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 JlmBNFhlLzCl for ; Sun, 2 Aug 2020 10:07:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 C79EB3A079E for ; Sun, 2 Aug 2020 10:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596388018; bh=cLehRzgleUnwaJYl21384ekFrDEtLe2bmHwTGaZOXAE=; l=2291; h=To:References:From:Date:In-Reply-To; b=Bxex0NoiDxPOyiBTOAANmgvCoY9vj8FS1rTb0GO+SSqYaCqgogQglGqDpC342p9x4 I6kP9HNObuAOgrtxFlxI5Name7CO2iWBitM2HbssSWTanKzo1HarjLE4MjyZVhtGwP qA8g6K1V/blk+GlSGgQ7QpDMozx7c79uQt4HmBHs7yDbA+GFuZaywoAm/U7rD Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.36.20]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC013.000000005F26F2B1.00004EA9; Sun, 02 Aug 2020 19:06:57 +0200 To: dmarc@ietf.org References: <32bc14d3-81b8-4b49-8fb2-597eba19d1be@taugh.com> From: Alessandro Vesely Message-ID: Date: Sun, 2 Aug 2020 19:06:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <32bc14d3-81b8-4b49-8fb2-597eba19d1be@taugh.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Apropos of the de-munging draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 17:07:03 -0000 On 2020-07-29 1:41 a.m., John R Levine (quoting Jesse) wrote: > >> I think that draft-kucherawy-dkim-transform-02 is getting at what >> I was originally thinking. In my opinion, MLMs will *always* need >> to munge, because they will never know if an arbitrary receiver >> will trust their non-munged mail. Giving the receivers a way to >> un-munge (if they can and/or want and/or trust) would be a >> productive path forward out of this situation.> > We already have a couple of ways to do reversible message munging, > starting with MIME message wrapping. In principle it works fine, in > practice it's awful because MUAs don't show wrapped messages > consistently and often in ways that are painful, e.g., you can see the > original author address but there's no button you can push to respond > to it. > > Unwrapping a MIME attachment is a lot easier than the proposed DKIM > unmunging but I doubt either is going to show up in MUAs any time > soon. Perhaps you could do it in a mail gateway. Looking at the steps required to carry out the proposed unmunging, "a lot easier" doesn't seem to be an accurate measurement. Actually, reversing the tf=footer is simpler than unwrapping a message/rfc822 attachment.[*] The major difficulty is for MLMs to produce modifications that consist of the allowed transformations _only_. Perhaps, it is a lot easier to create a message/rfc822 without breaking its signatures...? From: rewriting in particular should be added to the set of allowed transforms. The MLM should make sure the Author: field mirrors the original From: exactly. Then it rewrites From:. It may seem redundant to set a tf= tag on the one hand and undo transforms on the other, since a munged From: is enough to pass. However, if receivers send aggregate reports back to the MLM, we can hope that one day they'll all succeed and the MLM can stop rewriting From:. In the interim, an MX which verified the original signature up to allowed transforms can replace the value of From: with that of Author:. This action is legitimate if all agree that the only reason why MLMs rewrite From: is to pass DMARC checking. I'd leave footers and subject tags in place. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/2ZN7DS5NktoyEPItZ5vzr-xd0Mc From nobody Sun Aug 2 10:51:49 2020 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 0BF263A097B for ; Sun, 2 Aug 2020 10:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=NHIshBVZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=uasA/9mq 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 8Di8-DMriumS for ; Sun, 2 Aug 2020 10:51:46 -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 7E30B3A090F for ; Sun, 2 Aug 2020 10:51:46 -0700 (PDT) Received: (qmail 22415 invoked from network); 2 Aug 2020 17:51:43 -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=578d.5f26fd2f.k2008; bh=LCqSJWPVeHlcQrdQIC26sQjpjXGzWuNb96bmNscGsCs=; b=NHIshBVZ2If0GL4oWsanCtl5oUZ3wi0gfJ09ewZ+jtjofdS6Ns7rCyj5PnyB89ybhHO7TbWuvAxWEEz1LPXO9/J1CrLHj8LuARQU/bZSBNsS9KhU94zqEr39O+x4ggSieZ4YS0Gh0pVQ5p7sX6iF0zqla1j1iIkLGMSLKgSVDf/ZHcDmwEWOLCz0qIe5PVIoUVnvPSa9oNN65PIldkG9dUmZfJhYhkfiXQw2+Zobv6tru4AOsAij6s34y+z5NISjAM4WwxWQvHEaDSD1plpiEMawZ1ap7Y79lt7D4B0sh0FurJQL/nzaKg/SKcuBSrasY7cKXS3OFT8rLMflXLymJw== 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=578d.5f26fd2f.k2008; bh=LCqSJWPVeHlcQrdQIC26sQjpjXGzWuNb96bmNscGsCs=; b=uasA/9mqGkBfgCNb3cI+s11nkfN7kEvOzYEvmSTiD8cL4MOGa0Jt0leU0CYzPOW1bvsnBd5SZKSTcpnCwUPz6gjkqJ7eQ1WwMWSqH8XMHG4EBqJ0BMKoXsEYlaCyLKp7O0VygbH1tuQtWlbit+BFD42cqtxTPuHUcyWI2MESIYLiOOZzwXvjtotM5B9LqLY/rZ9ujdeqAiCqtyBtuLdnvEwQvTKumHneVE/9/fggpgWIH3/yzr+fBPKTaxSfHosNElAEEWP4ob5Pao1qjyjzDaF2VlH5ooj8G3Yk2yGN3ULhyGNNbTy/BHLAtg6vypzIoAEWYwEbjJpe3lgge3TGkQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Aug 2020 17:51:42 -0000 Received: by ary.qy (Postfix, from userid 501) id 9576E1DC8B47; Sun, 2 Aug 2020 13:51:42 -0400 (EDT) Date: 2 Aug 2020 13:51:42 -0400 Message-Id: <20200802175142.9576E1DC8B47@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it 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] Apropos of the de-munging draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 17:51:48 -0000 In article you write: >> Unwrapping a MIME attachment is a lot easier than the proposed DKIM >> unmunging but I doubt either is going to show up in MUAs any time >> soon. Perhaps you could do it in a mail gateway. > > >Looking at the steps required to carry out the proposed unmunging, "a lot easier" doesn't seem to be an accurate measurement. In python it's about two lines since there are well debugged libraries to handle MIME. Same in most other languages. I still would be amazed if any MUAs did this, also keeping in mind that the changes that MLMs make ARE USEFUL. From nobody Sun Aug 2 11:55:21 2020 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 289A53A0ACC for ; Sun, 2 Aug 2020 11:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrtdhJxHk-qk for ; Sun, 2 Aug 2020 11:55:18 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59883A0AC6 for ; Sun, 2 Aug 2020 11:55:18 -0700 (PDT) X-ASG-Debug-ID: 1596394516-11fa3118c7b4eb0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id YTnNyox7euRHGiP4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sun, 02 Aug 2020 14:55:16 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=HyFxzXG9LwRMFk5FqV0DQTFo2PFVqcuKfI4PYx2stco=; b=fXa3tYUk73zHr1fVNGtOS3SDWfYouTuCZqsUrvv8QHFb2o5GEtl8GaCDL4O6BcU29 u4dpgU3ZdRPxiTPnDYYVptJVjJoH7m/yfTTrC/+yjXzBP9BhhaBrYzxHEVLOq0+hY SoGhSuaP4ea8h6jbO4vClRRrY9p1pJPy+E2kohXmQ= From: "Douglas E. Foster" To: "John Levine" , Date: Sun, 02 Aug 2020 18:55:09 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=f99d61de702c484c9af5efd36c4acb73 In-Reply-To: <20200802165756.3892C1DC82FD@ary.qy> References: <20200802165756.3892C1DC82FD@ary.qy> X-Exim-Id: 719dce3edbc54b25b6ebf248170e7eb2 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1596394516 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2843 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83647 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 18:55:20 -0000 This is a multipart message in MIME format. --f99d61de702c484c9af5efd36c4acb73 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you= ? If they would provide a way to register a mailing list and the servers from= which it comes, and allow DMARC exceptions for traffic from those register= ed lists, your situation would be much easier? DF ---------------------------------------- From: "John Levine" Sent: 8/2/20 12:58 PM To: dmarc@ietf.org Cc: fosterd@bayviewphysicians.com Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains In article you wri= te: >I wonder if this is typical - are mailing list subscribers more likely to = be on DMARC-enforcing domains than the general population? > >Do the mailing list operators have data about what percentage of their sub= scribers (or percentage of unique domains) have DMARC policy enforcement in= place? In my experience it completely depends on the list. I have a list of folk dancers with a lot of old AOL and Yahoo addresses with DMARC policies, and I have other lists where it's mostly gmail and Hotmail/Outlook, without. R's, John --f99d61de702c484c9af5efd36c4acb73 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Is it fair to say = that AOL/Yahoo/Verizon is the core of the problem for you?    

If they would provide a way to register a mailing li= st and the servers from which it comes, and allow DMARC exceptions for traf= fic from those registered lists, your situation would be much easier? =

DF

From: "= John Levine" <johnl@taugh.com>
Sent: 8/2/20 12:58= PM
To: dmarc@ietf.org
Cc: fosterd@= bayviewphysicians.com
Subject: Re: [dmarc-ietf] non-mai= ling list use case for differing header domains
In article= <cec0a539d7f34478930e2e172ace81c6@bayviewphysicians.com> you write:<= /div>
>I wonder if this is typical - are mailing list subscribers mo= re likely to be on DMARC-enforcing domains than the general population?
>
>Do the mailing list operators have data about wha= t percentage of their subscribers (or percentage of unique domains) have DM= ARC policy enforcement in place?

In my experience = it completely depends on the list. I have a list of
folk dancers = with a lot of old AOL and Yahoo addresses with DMARC
policies, an= d I have other lists where it's mostly gmail and
Hotmail/Outlook,= without.

R's,
John

=




--f99d61de702c484c9af5efd36c4acb73-- From nobody Sun Aug 2 11:57:31 2020 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 B6CBA3A0AC7 for ; Sun, 2 Aug 2020 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=AcDCbzR0; dkim=pass (2048-bit key) header.d=taugh.com header.b=Gcckqd4I 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 xHmaOM-pdw2A for ; Sun, 2 Aug 2020 11:57:28 -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 04D8F3A0AC6 for ; Sun, 2 Aug 2020 11:57:27 -0700 (PDT) Received: (qmail 30234 invoked from network); 2 Aug 2020 18:57:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=7618.5f270c93.k2008; i=johnl-iecc.com@submit.iecc.com; bh=ne7pPUVPREqnejDWxZuQW1nWrtYZrXHINzL69316yz0=; b=AcDCbzR0/FN4mqExh512iJBtiHPXVIqc94u3FL7OxW87YeoZ2+WeaD5DCQlvmnScRkdqzvfd2r0erAE4kasHSk4BeBP0LL46NV4v7lfn8cZP2Dmo7X6uk6VkjHe7uGl8YzPHH2PZKNXn60ZfN87Wje5jSCj9QBBPtuWYO5pr+Z2EpAOKfkoWAEBYrZv1Nu53NJI19HSsbGED7nUbiqpcjXDJMd4c5s71eodAwXOUFnG05DiUa/5awj4HLmi1DSBQmjIzf0lXeG1N3yifMP9FRQCODko/WVXrETxZulImpXvMqGDkEUQ0cm29DZvv4WpEUStVittvfisnOmPXZyWDtA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=7618.5f270c93.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=ne7pPUVPREqnejDWxZuQW1nWrtYZrXHINzL69316yz0=; b=Gcckqd4IrQypBgjQQS5OMtPRtTNEQgZCeFj8C+PBIzoxRmgJepUWobk784mgh62/s1+HJqIvHHBCG6HTPwPb5angzlhuzatUNXDxygOHA8nt4JqXEXq/dQaWLMlQvwYnWC4zcWRx95H1EbTcOpEhgpPVhLJu9dwrCDPxcP8LWSksmEE4ayI5oUxtolQWf18P11wz+2hSq/u2irolBz9Q8BIb5AjDo1anRwi0qMDeVtIA9enb7Tssh4XDOm4Gg2iZxs/gkbRsxmltX7DVSj+EAXc/rdKd68xfMztib7kaBbZdjoYohAv7Hf7yMxpH6KmniljgZWV6JLbSsDbw9HkX8g== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 02 Aug 2020 18:57:23 -0000 Date: 2 Aug 2020 14:57:23 -0400 Message-ID: From: "John R Levine" To: "Douglas E. Foster" , dmarc@ietf.org In-Reply-To: <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 18:57:30 -0000 > Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you? No, it is fair to say that misuse of DMARC is the problem. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Aug 2 14:20:18 2020 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 B281F3A0C54 for ; Sun, 2 Aug 2020 14:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 1rWDFg9weJ_n for ; Sun, 2 Aug 2020 14:20:15 -0700 (PDT) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 803983A0C53 for ; Sun, 2 Aug 2020 14:20:15 -0700 (PDT) Received: by mail-vk1-xa2d.google.com with SMTP id x142so4863451vke.0 for ; Sun, 02 Aug 2020 14:20:15 -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=lP1F6tjWU5grYC6nVDexsi9QSSU38m0LUvB4yq3lJd4=; b=YWIo9uTAHhPGqiQHva2ZKCvKJU6vTh3unL6UyC+kaN1vrfUJqwbg4qLQv/sQ9MQCDf jfE0Dx6F1F3AUNg72+8KXzZFxBROzeuj4dgyiwZPhkEp+Mzc7fGReEJSXUrSRypZQl3A DOHDBGasu5EoPp+f1RjfkVQrjLdNCvZsl5Ryo2w1zGyBkGCtXzIS4NIum1GVbQdoWFTW bZCww34Br9KnT0+Y9SPYIvjeM5qXP/sKtVz7fODjpVxaS2tC76XqHTILUQwUP2XQLjkK 3Q8IdVjfmLnPmXfHfYv2xAWsyICxfBsyNrXnvG+Ga1abcas0Pg22W63DRMieXwobNPUe uuCw== 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=lP1F6tjWU5grYC6nVDexsi9QSSU38m0LUvB4yq3lJd4=; b=nl7Yu4tkaG0AYaLuHpBXZtWaheOXs0gN6YeroTkBir+j0VJgD8As/jPWDlqFJocNro T8eXMsGNfzEIEbO22uj7wpU+clyn+PL+wYOXhmjEvdKk5LkcBdOYbrb20s0ShUQc2VKt mA3Vm2dHrezM0dVBpXKDGhuaj2CI5yMpcc/ZOxrEj9XV9uiGqypkRfQmS9LRVGnyVsYO yrTxhR1h55+LccteXHA0mkfyIvbPLd77b6u/JUfe2E9JxBbHLbKDiBCB7rlpmtMzEUuR 4+u/P2wXsXmbou+tvPiQtRht5jkq6r7W4oWdHHA/lGF1EvlaLUdpUL8JzF6b72XF5b3E wObQ== X-Gm-Message-State: AOAM531CEMI/VzGnqp2vEYGV98XX5IV9Bdk9HPg8n1IKbUnj/gsMiHoD yx1+GD+s7cA+HzDsLwaNZEcTOoJM24z1z+/raxYNHw== X-Google-Smtp-Source: ABdhPJy/aQ6CC792NGKVl1PHOm7dQw4WAiNz5SA57RHHU41Yw+oRkK8QasDrGC2qrrFkl6dry4mmFL7TKFwPH3VPKm8= X-Received: by 2002:a1f:f8c5:: with SMTP id w188mr1465763vkh.15.1596403214422; Sun, 02 Aug 2020 14:20:14 -0700 (PDT) MIME-Version: 1.0 References: <20200802175142.9576E1DC8B47@ary.qy> In-Reply-To: <20200802175142.9576E1DC8B47@ary.qy> From: "Murray S. Kucherawy" Date: Sun, 2 Aug 2020 14:20:03 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="0000000000008396af05abeb9683" Archived-At: Subject: Re: [dmarc-ietf] Apropos of the de-munging draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 21:20:17 -0000 --0000000000008396af05abeb9683 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 2, 2020 at 10:51 AM John Levine wrote: > >Looking at the steps required to carry out the proposed unmunging, "a lot > easier" doesn't seem to be an accurate measurement. > > In python it's about two lines since there are well debugged libraries > to handle MIME. Same in most other languages. > I agree, the code to do this is easy and well tested, and it works so long as the MLM is doing the mutation in exactly the same way the verifier will undo it. The concern comes down to two different MIME library implementers disagreeing on their choices for where an extra newline might be helpful, for example. -MSK --0000000000008396af05abeb9683 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 2, 2020 at 10:51 AM John Levi= ne <johnl@taugh.com> wrote:
>Looking at the steps required to carry out the proposed unmu= nging, "a lot easier" doesn't seem to be an accurate measurem= ent.

In python it's about two lines since there are well debugged libraries<= br> to handle MIME.=C2=A0 Same in most other languages.
I agree, the code to do this is easy and well tested, and it w= orks so long as the MLM is doing the mutation in exactly the same way the v= erifier will undo it.=C2=A0 The concern comes down to two different MIME li= brary implementers disagreeing on their choices for where an extra newline = might be helpful, for example.

-MSK
<= /div>
--0000000000008396af05abeb9683-- From nobody Sun Aug 2 14:22:51 2020 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 203843A0C59 for ; Sun, 2 Aug 2020 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 Rgarf2Oiascr for ; Sun, 2 Aug 2020 14:22:49 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 CE25A3A0C57 for ; Sun, 2 Aug 2020 14:22:48 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id n25so4609790vsq.6 for ; Sun, 02 Aug 2020 14:22:48 -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=FGFerMg38rHBW7mCwOsS/WSYuYwuQCqFXBnnTddewd4=; b=F5IWikCfVqYvKWCfTprkrXgo5BhlznvOLtzOkrgpDxxSiTb2c34MX6r57cAGv0OPNm 9VvH2wlNFpkrtUFDKaHUom4EH/HnpFN1MbHOQl4pbOzM6trFlIXQB0+ildrJ9WAx3Ru2 Cpbqy06QxUPE6Xp6WwLuOfC8bY6jKiIh1VIDoSOZm96aA+axHPjxHeX73kpUkTNzn38t 7Wc75+PRIlJpLxiAXEeXx83VATcuL1CZh/6f3ivrERQRHKDNkd0r4ZrhprD1TRxzUgsu gcUX3S6V4NLARdZ41f0rzUQf98eLafeQ6F+/o5XXjqf0YXqK27qefrDuLnHHU/4qHpd4 k/Zw== 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=FGFerMg38rHBW7mCwOsS/WSYuYwuQCqFXBnnTddewd4=; b=Qlny6oSaiDsACGIUc6XqhY4nuSwPs7+FFrfNMm9a86GXUeUDODAGx09YBuoPodO3tT AFx9aIQUH7Qz90AeYDqQ/vi62g8W67jQOtyJqGQLLRJR68o3Bq7gPW0uVU2fTj9YL9j3 su+1LcYAgKGSINIFujQ30Qry3aMouPzu4hMzxseEVHSCfF2M+mkfpB1hM3TzItikCx0m o1xEadK4F1JrkJIfTg+IFzwNn2xqFBEg4qpo8t93Cx1W4czGuTtBI+b+4azK+SGC5Six iJqDq+mG2QuOq5dSmUnZBGNaLE7hDiZKpoNJP5LJnswSKEHo5xgW53skIWnRGO2bufOP SciA== X-Gm-Message-State: AOAM532NvfXHoGzEroejZAIV5GDczR7f8AQAlF9cpg9oUjYwszK//i64 3ijPW7Qjv33DrsghoDxAI8eQkeAcHjoMEDGUhAO0/Q== X-Google-Smtp-Source: ABdhPJx6NDQ10QlKZK+B6kIMUvc0NOkquAel44QWmfYUh2LNJqyOLinL/VpkD1BiM0giZpDkQOXFgPnGYBwEYyS2mF0= X-Received: by 2002:a67:ed8c:: with SMTP id d12mr9694615vsp.8.1596403367778; Sun, 02 Aug 2020 14:22:47 -0700 (PDT) MIME-Version: 1.0 References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> In-Reply-To: <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Sun, 2 Aug 2020 14:22:36 -0700 Message-ID: To: Doug Foster Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a79cd205abeb9f97" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 21:22:50 -0000 --000000000000a79cd205abeb9f97 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 2, 2020 at 11:55 AM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > If they would provide a way to register a mailing list and the servers > from which it comes, and allow DMARC exceptions for traffic from those > registered lists, your situation would be much easier? > Ignoring for the moment the problems of scale with any "register your lists" solution, I don't think users can reasonably be expected to keep such a registration current if, say, the servers were to move. Such a migration would no longer be transparent, as it is today. -MSK --000000000000a79cd205abeb9f97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 2, 2020 at 11:55 AM Douglas E= . Foster <fosterd@bayvi= ewphysicians.com> wrote:
If they would provide a way to register a mailing list and = the servers from which it comes, and allow DMARC exceptions for traffic fro= m those registered lists, your situation would be much easier?

Ignoring for the moment the problems of scal= e with any "register your lists" solution, I don't think user= s can reasonably be expected to keep such a registration current if, say, t= he servers were to move.=C2=A0 Such a migration would no longer be transpar= ent, as it is today.

-MSK
--000000000000a79cd205abeb9f97-- From nobody Sun Aug 2 14:23:43 2020 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 62F2F3A0C5B for ; Sun, 2 Aug 2020 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=v0iGv4lO; dkim=pass (2048-bit key) header.d=taugh.com header.b=OfHiCdQm 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 hwDU_Xlpx82G for ; Sun, 2 Aug 2020 14:23:39 -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 2C4F63A0C59 for ; Sun, 2 Aug 2020 14:23:38 -0700 (PDT) Received: (qmail 54026 invoked from network); 2 Aug 2020 21:23:37 -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; s=d308.5f272ed9.k2008; i=johnl-iecc.com@submit.iecc.com; bh=hIad4fGqlGRRpTCqO7pKByISi4wKCnXxFKYk5ADlHzQ=; b=v0iGv4lOoDiGv4tD63dIcSwAN3bShwDrrVB8UfQZT0eapCeSwRRMEQGMgubrk+80qGXKsGwogB55DGSfpez4OfMUtfhNgEXZJNT0L8qPvpFLqxyf25XiHAL+00HySesYbOSMR/umD60xSdz2BSLf1IbVsddgtAjtTpHZMzpZ83PRQwqzFMi0zmkZOITt/Dkj+uC1Yxx6ZJKK/TGDQXE84X1IFUJpdqj8Wu2xRo1WWQeS+in3aNXZpfSv573uQ5AP7SLFB6R7aTck7ZMTdq2v6O1yONX/yigmK+Z+NZcvMpNUW0DyJIzGMkSe36IIjU5ZEOERAkrh4zQYRiCQcLANFA== 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; s=d308.5f272ed9.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=hIad4fGqlGRRpTCqO7pKByISi4wKCnXxFKYk5ADlHzQ=; b=OfHiCdQm4/434I4A9xWjq5yhIYFgngXIpJrtLVtotfEfv4cRl+tc4v6ZGr6zvp1V/F9htvshbOwgNWT/z7d26dho/sImyYT3c1ijMosdNe/S9kD9zk9OFP1IUo8RgGLg/da8O7Snb2ezTlKy9jIq/pJxJq2WBxMdUUM3e+RSQZ5RbAqwoWJMbeOVU/gZgDY3tkeUS+pS3y7AtmxyuZvmD34++Ka7fBLKMtyuh7g5uHRDIh1NuyBJF1Gp1J6JIljuDPvpo5mO/wM7RBTMY4z0J7JSTfaortZgiWEKtywNiVaYZtUaulbj8DSYN37aRMW6OJi4D6beNw9UBxUdpJJHxg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 02 Aug 2020 21:23:37 -0000 Date: 2 Aug 2020 17:23:36 -0400 Message-ID: <60eab528-e73c-79f8-f530-783bf49c773f@taugh.com> From: "John R Levine" To: "Murray S. Kucherawy" , "John Levine" Cc: "IETF DMARC WG" , "Alessandro Vesely" In-Reply-To: References: <20200802175142.9576E1DC8B47@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Apropos of the de-munging draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 21:23:41 -0000 >>> Looking at the steps required to carry out the proposed unmunging, "a lot >> easier" doesn't seem to be an accurate measurement. >> >> In python it's about two lines since there are well debugged libraries >> to handle MIME. Same in most other languages. > > I agree, the code to do this is easy and well tested, and it works so long > as the MLM is doing the mutation in exactly the same way the verifier will > undo it. The concern comes down to two different MIME library implementers > disagreeing on their choices for where an extra newline might be helpful, > for example. I was actually thinking of wrapping the original message as an attachment, sort of like a one-message digest. You can always recover the original message, the problem is that MUAs display attached messages badly, and if you unwrap you lose the useful changes the list manager makes like subject tags and footers with unsubscribe instructions. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Aug 2 14:24:44 2020 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 214EF3A0C5E for ; Sun, 2 Aug 2020 14:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=GMoa+nR2; dkim=pass (2048-bit key) header.d=taugh.com header.b=vZh97gVR 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 SuYnR_4Eld45 for ; Sun, 2 Aug 2020 14:24:41 -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 9AB983A0C5B for ; Sun, 2 Aug 2020 14:24:41 -0700 (PDT) Received: (qmail 54189 invoked from network); 2 Aug 2020 21:24:40 -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; s=d3ab.5f272f18.k2008; i=johnl-iecc.com@submit.iecc.com; bh=atvtPNXmngl8htrjerUYDBjBi8j4unPA3MruTDGCPx4=; b=GMoa+nR23KBaVaucPHv7FnU+rJGEbDHXP4v4CXh/98Kk7DC32cWrLjQeMTlQAkNBrhSUVHzxQkCx3IHScASsTIwMcsiY2UYfKkJZncgxvgevVm9ipBfYnjxhlrQov0Qgq3HO8cn6o/hEgCm4jx8bPc4vGQVsVG+GDAMAjZ/e14ww1EjpHoVz2U2LGj0nYasVDoAGeildPFVdHiUhQs62iIuZ5aJGLGqJ6dyQR3fAv+h8MkDVJfLGHuz+4TUVhGPLk/uvgSlUCRwykqZNZ5vv2B4DrfRhDra/gm5zK58mLQOMgyCtyVr5W0t28zqHtM0AQlw6wXJweJE8w4MnFG2ZDQ== 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; s=d3ab.5f272f18.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=atvtPNXmngl8htrjerUYDBjBi8j4unPA3MruTDGCPx4=; b=vZh97gVRyKXtXAVMgsWqK/d+Ko/2hwB9KAy0PxE/9ay7dIgnNCnN+P0NMWIfl1uXE5w7iRXS1fLmpSzCYRT5TImtOczUnEAiDRUIQHLln+lPHfA8TZbcs+M1SVtvXVkj1SjCr+UohDyaRiZrZfPkbpduIuhSQmO32QXxd+sZPEkAYiSJauM3uVx2+DST8qznuvr5vqRN5MbiSSRGtqXByjzfgG/BiGCXsWZaojHqdVgATCbKyKerWcWtcsT4N8QlnVZpnzGQvYwtLVqn8vMlY3Srl7+NTVukjSUK/JaJHHwwu+IwrxnHsVib9v4i5PnVHxauU3pniFJiVg3aCGlr3g== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 02 Aug 2020 21:24:40 -0000 Date: 2 Aug 2020 17:24:39 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 21:24:43 -0000 >> If they would provide a way to register a mailing list and the servers >> from which it comes, and allow DMARC exceptions for traffic from those >> registered lists, your situation would be much easier? If large mail providers were willing to whitelist known mailing lists we wouldn't need ARC. See previous messages for why that isn't sufficient. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Aug 2 14:28:50 2020 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 ABA9D3A0C7A for ; Sun, 2 Aug 2020 14:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.949, 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 o4tKYPaMi09u for ; Sun, 2 Aug 2020 14:28:48 -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 D6A4C3A0C79 for ; Sun, 2 Aug 2020 14:28:48 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 072LVOAs004203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 2 Aug 2020 14:31:24 -0700 To: IETF DMARC WG References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 2 Aug 2020 14:28:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 21:28:50 -0000 On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote: > Ignoring for the moment the problems of scale with any "register your > lists" solution, I don't think users can reasonably be expected to > keep such a registration current if, say, the servers were to move.  > Such a migration would no longer be transparent, as it is today. +1 When someone proposes a scheme, it will help for them to list who the relevant actors must be and what they must do and then deal with the question of scaling.  That is, how will it be possible for this to work at Internet scale? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 2 17:44:12 2020 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 E65B33A0E56 for ; Sun, 2 Aug 2020 17:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zLZU7ONo6EJ for ; Sun, 2 Aug 2020 17:44:08 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4186A3A0E53 for ; Sun, 2 Aug 2020 17:44:08 -0700 (PDT) X-ASG-Debug-ID: 1596415444-11fa3118c7b6260001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Be7lDM9JJLPIlig2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sun, 02 Aug 2020 20:44:04 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=W9bUStkIbqrhRU7dZXEhKLZV/8v5j+ZVTB6vuGErTQA=; b=pHsmyOtlGwzIo8dDIcSoxC2tX0vmWg8vQlDFcUinjsi1DuoTnhnu/O8n9PHSzPk/E nWy1HlwWDG8GL2WV5LMmRWWjeJHqcuSDGBgaeZAhHbKxfhqgqZ7H5oSv4OfwVpU/t Bfcik+TAo1LIieFHJy8YK6Lpz+kzHF6N6f7ze/WWk= From: "Douglas E. Foster" To: , "IETF DMARC WG" Date: Mon, 03 Aug 2020 00:43:56 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=98fb3daf40474046a88018f8756fb733 In-Reply-To: References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> X-Exim-Id: 0bc56bf161c54870b4655e98d7297f64 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1596415444 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 7220 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83652 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 00:44:10 -0000 This is a multipart message in MIME format. --98fb3daf40474046a88018f8756fb733 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Murray took server too literally. I have expressed before that a system c= ould do a sender authentication lookup on List-ID as easily as on From. I= n this respect, it is similar to Dave's proposal, without the added complex= ity of additional identifiers. So think "Registerd List-ID plus DKIM sign= ature (or SPF, but DKIM seems both sufficient and preferable.) I am not sure what "Internet Scale" means to you. Most of the major recip= ients have bulk mailer registration systems. It does not guarantee whitel= isting, but it tends to produce that effect. I have had occasion to regis= ter with most of them. So "does not scale" is not obvious to me. Even more to the point, check out this link: https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing= -relevance-performance-through-vto Verizon appears to be offering a service (probably for extra cost) which is= based on: (a) a well-defined mail stream from a known sender, and (b) a mailbox user identifying that mail stream as subscribed, and therefor= e desirable. It appears that the target senders are retailers who want to ensure that th= eir sale announcements are read before the sale is over. It is an "Intern= et scale" application of the type of registration I was suggesting: Well-= identified senders, coupled with end-user endorsement, receive preferred tr= eatment. As to the transparency question, it should be clear that there will be no s= imple solution to the ML problem. As long as mailing lists appear identica= l to a malicious spoofer, their only protection is their own sterling reput= ation. But the only way to establish an acceptable reputation is to eithe= r register with the receiver directly, or register with the sender in a way= that the receiver will honor. Your proposal does nothing to distinguish= mailing lists from malicious spoofers, so it does nothing to solve the pro= blem. Mailing lists either need to send using the ML domain as the From a= ddress, not modify the message, or establish a credible reputation. There= are no other possibilities on this side of FantasyLand. DF ---------------------------------------- From: Dave Crocker Sent: 8/2/20 5:29 PM To: IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote: > Ignoring for the moment the problems of scale with any "register your > lists" solution, I don't think users can reasonably be expected to > keep such a registration current if, say, the servers were to move. > Such a migration would no longer be transparent, as it is today. +1 When someone proposes a scheme, it will help for them to list who the relevant actors must be and what they must do and then deal with the question of scaling. That is, how will it be possible for this to work at Internet scale? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --98fb3daf40474046a88018f8756fb733 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Murray took server= too literally.   I have expressed before that a system could do a sen= der authentication lookup on List-ID as easily as on From.   In this r= espect, it is similar to Dave's proposal, without the added complexity of a= dditional identifiers.   So think "Registerd List-ID plus DKIM signatu= re (or SPF, but DKIM seems both sufficient and preferable.)

<= /div>
I am not sure what "Internet Scale" means to you.   Most of = the major recipients have bulk mailer registration systems.   It does = not guarantee whitelisting, but it tends to produce that effect.   I h= ave had occasion to register with most of them.   So "does not scale" = is not obvious to me.

Even more to the point, chec= k out this link:
Verizon appears to be offering a service (probably for extra co= st) which is based on:
(a) a well-defined mail stream from a know= n sender, and 
(b) a mailbox user identifying that mail stre= am as subscribed, and therefore desirable.

It appe= ars that the target senders are retailers who want to ensure that their sal= e announcements are read before the sale is over.   It is an "Internet= scale" application of the type of registration I was suggesting:   We= ll-identified senders, coupled with end-user endorsement, receive preferred= treatment.

As to the transparency question, it sh= ould be clear that there will be no simple solution to the ML problem. &nbs= p;As long as mailing lists appear identical to a malicious spoofer, their o= nly protection is their own sterling reputation.   But the only way to= establish an acceptable reputation is to either register with the receiver= directly, or register with the sender in a way that the receiver will hono= r.    Your proposal does nothing to distinguish mailing lists fro= m malicious spoofers, so it does nothing to solve the problem.   Maili= ng lists either need to send using the ML domain as the From address, not m= odify the message, or establish a credible reputation.   There are no = other possibilities on this side of FantasyLand.

D= F 


<= /div>

From: Dave Crocker <dhc@dcrocker.net>
Sent: 8/2= /20 5:29 PM
To: IETF DMARC WG <dmarc@ietf.org>Subject: Re: [dmarc-ietf] non-mailing list use case for d= iffering header domains
On 8/2/2020 2:22 PM, Murray S. Kuc= herawy wrote:
> Ignoring for the moment the problems of scale = with any "register your
> lists" solution, I don't think users= can reasonably be expected to
> keep such a registration curr= ent if, say, the servers were to move. 
> Such a migratio= n would no longer be transparent, as it is today.

= +1

When someone proposes a scheme, it will help fo= r them to list who the
relevant actors must be and what they must= do and then deal with the
question of scaling.  That is, ho= w will it be possible for this to work
at Internet scale?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

<= div>_______________________________________________
dmarc mailing= list
dmarc@ietf.org
--98fb3daf40474046a88018f8756fb733-- From nobody Mon Aug 3 00:25:41 2020 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 AEC6E3A09A9 for ; Mon, 3 Aug 2020 00:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 lLE7p7fRAV5k for ; Mon, 3 Aug 2020 00:25:39 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 06F3E3A098B for ; Mon, 3 Aug 2020 00:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596439536; bh=X6t+Rl4a8Sg8LOZmCPxhkOu1LfjxuQA6+WH+WDBpQ64=; l=1229; h=To:References:From:Date:In-Reply-To; b=CsYS/7br62/8/M4khnJNi5ruIbkWcfqYrkBzVvKyIz7Y8GVZCkE/qB5kRfUFtEmNX f7SrwRQadgYIUqJ08l1QgGXWIZWWjZyuGwDllCB5KgYU7AVpCZiJxZspwQpjB7Ch1i VaWuF1Bm+428ThSQi/TB9GkdZf2EjTeBZdpAm2ad+UT7C+9noC0Nv/LfSQEvu Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.219]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F27BBF0.00006DC2; Mon, 03 Aug 2020 09:25:36 +0200 To: John Levine , dmarc@ietf.org References: <20200802175142.9576E1DC8B47@ary.qy> From: Alessandro Vesely Message-ID: <17517794-79d2-806c-0da2-5ff80342d63f@tana.it> Date: Mon, 3 Aug 2020 09:25:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200802175142.9576E1DC8B47@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Apropos of the de-munging draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 07:25:41 -0000 On 2020-08-02 7:51 p.m., John Levine wrote: > In article you write: >>> Unwrapping a MIME attachment is a lot easier than the proposed DKIM >>> unmunging but I doubt either is going to show up in MUAs any time >>> soon. Perhaps you could do it in a mail gateway. >> >> >> Looking at the steps required to carry out the proposed unmunging, "a lot easier" doesn't seem to be an accurate measurement. > > In python it's about two lines since there are well debugged libraries to handle MIME. Same in most other languages. If you use a library, most common operations can be done better than unusual ones, the actual complexity notwithstanding. The steps I outlined for tf=footer[*] can be done adding a few lines to Murray's library, in C. > I still would be amazed if any MUAs did this, also keeping in mind that the changes that MLMs make ARE USEFUL. Agreed. IMHO, Murray's lib should do just a virtual unmunge, while canonicalizing. To actually replace From: with the original Author: can be done by the MDA, based on trusted A-Rs, after any dot-forward. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/2ZN7DS5NktoyEPItZ5vzr-xd0Mc From nobody Mon Aug 3 05:57:00 2020 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 6E22C3A08E1 for ; Mon, 3 Aug 2020 05:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=wemonitoremail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCgTKCWTjj48 for ; Mon, 3 Aug 2020 05:56:57 -0700 (PDT) Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573143A08DB for ; Mon, 3 Aug 2020 05:56:57 -0700 (PDT) Received: from localhost [127.0.0.1] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1596459414; bh=8Ignnwm16YqCJ2+tOmlWTHOtBhevNBWm6KOoxWsYfiE=; h=Subject:To:References:From:Date:In-Reply-To; b=qxbauhpW1IxjtNVFkmbcLvL8YuKY3hfs/SG2FXBh+NHBbFFBRAv1V0XGUg4xZFfxw IIfX65mzLh/+QVdgzhb623woOMrwRyxsmmTVCzrldsynxcy3DjVvNtCgUagJB27hR9 372BcTWykDMZ/xg039pnX6Ukm9D3GGjGJjl3Ag08= To: dmarc@ietf.org References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> From: Ken O'Driscoll Organization: We Monitor Email Message-ID: <8360ceb4-d70e-9071-a8ca-21976210551a@wemonitoremail.com> Date: Mon, 3 Aug 2020 13:56:52 +0100 MIME-Version: 1.0 In-Reply-To: <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 12:56:58 -0000 On 03/08/2020 01:43, Douglas E. Foster wrote: > > I am not sure what "Internet Scale" means to you.   Most of the major > recipients have bulk mailer registration systems.   It does not > guarantee whitelisting, but it tends to produce that effect.   I have > had occasion to register with most of them.   So "does not scale" is > not obvious to me. This is not correct. In the past some large providers did offer such lists but these days most have moved away from that model for various reasons. You'll still find someone offering such as service, and pay-to-play is a thing too but none of this is a) widespread and b) based on any type of standard - it's all proprietary. The same goes for sender certification services such as ReturnPath. "Internet Scale" means being able to scale to internet level of usage and platform interoperability.  TCP/IP and DNS are good examples. Data (e.g. lists of approved senders) maintained internally by individual organisations can't scale to that level for the same reason that organisations siloing their own DNS and routing information wouldn't work. Interoperability. Organisations publishing information (e.g. an SPF record) in their DNS zone works because it's based on an existing internet scale interoperable platform. While the "heavy lifting" of interpreting the SPF record might be undertaken by a variety of different software and system platforms, the mechanism is standardised based on the RFC. Again, interoperability. Ken. From nobody Tue Aug 4 04:18:43 2020 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 8D1723A0774 for ; Tue, 4 Aug 2020 04:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=junc.eu 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 eayMS45lX8HN for ; Tue, 4 Aug 2020 04:18:40 -0700 (PDT) Received: from mx.junc.eu (mx.junc.eu [172.105.72.99]) (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 570453A0781 for ; Tue, 4 Aug 2020 04:18:26 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by mx.junc.eu (Postfix) with SMTP id CA96E804CA for ; Tue, 4 Aug 2020 11:18:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junc.eu; i=@junc.eu; l=571; q=dns/txt; s=default; t=1596539906; h=from : subject : date : to; bh=fLxlhn1dtsyv5nFYrow5SSn1lMRlo5tvP958vR0HFpU=; b=t/4uHkbY0xToYZxF+zyclw21QkdGQaNSIIXJ/EMuncxygUtv9LMBxK4W9AzFAyBiSJ2ce TYmg8ghMM1on2HvzThFAY4yg+63T6vho0ppf2dyoCsf3nPcbWrioCG7X9z2wgETGffa7v/Q hDRT+5lAT68/IuriB5LJvHwx657DHLY= Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by mx.junc.eu (Postfix) with ESMTPSA id AE897804A9 for ; Tue, 4 Aug 2020 11:18:26 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 04 Aug 2020 13:18:26 +0200 From: Benny Pedersen To: dmarc@ietf.org In-Reply-To: References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> User-Agent: Roundcube Webmail/1.4.6 Message-ID: <89db9530b14bd3aa00918b96ab48d5e0@junc.eu> X-Sender: me@junc.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 11:18:42 -0000 John R Levine skrev den 2020-08-02 23:24: > If large mail providers were willing to whitelist known mailing lists > we wouldn't need ARC. if no one breaked dkim then we did not need arc > See previous messages for why that isn't sufficient. missing arc will not break spf dkim, but it preserves state of pass TO the maillists, but only if maillists run arc at the first stage of breaking dkim, i only know dovecot maillist that have solved it as it should be, i think others could do the same of not breaking dkim, or if need to, do a fully arc sealing From nobody Tue Aug 4 08:21:25 2020 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 486EB3A07E3 for ; Tue, 4 Aug 2020 08:21:23 -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=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 B1kGYTpPRrru for ; Tue, 4 Aug 2020 08:21:22 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 0E80D3A07CB for ; Tue, 4 Aug 2020 08:21:21 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id t18so34544834ilh.2 for ; Tue, 04 Aug 2020 08:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZW0asQlQfKzlL5oqT7s8wf+rHGFdRFarw32GmUBycco=; b=QBEv9x3Ox0D0b7sI9Kse74WNh6Nj+wj68kvVOb1gdEuFz9HVEPM6soSjDcL5mMrGti cFv0y1FtH6QTEBQcDO+TUeU1qsE+mHC92p+7fgvDXqNMYsaVq9PB32l/miE7Ga+lFDaQ 8Rx+tpG4MtdMkExNxVaRc03aQE35kwsWzhhlE= 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=ZW0asQlQfKzlL5oqT7s8wf+rHGFdRFarw32GmUBycco=; b=TAWiN6D+Cv5tZEffVVDX3WCMElYheEis2Izx+5V0Zm8qtCU0pguYViDI8l0BnQv+PK Vi0FjHrzcvlYcx+YwFw83KIWqkCTc7knaJTH1+RhBpok8hyoX/7FPd3RwZ7SkZRTG1oo E1XvwNBj4+h5oaVGOXvT1aNqo0vuhSvcdrce7g7B4eqFSPr++K7yEy1h8Fw+dDZVBPgt PLv33nvG4QMqQr/nn8NoqxK2boWp74gzlryY0HqO+IdYtDt/rsZjLHexaDVOse3H0cye hyNdlRg0AW1/1xAnC/0Db5MI/hSbPfX0TNsgrb/qT3h3rEVUiRJh0w7mlPiQPYZgAYNg zY5g== X-Gm-Message-State: AOAM532D6k+MCiV9hQXXFL20MRinpy8OPQOAUHmrNvYgH7JQyLYVFj4r S6FofYKY0nX1g8VRx516sZAaQ7xXO1P6cHaRlws08wc0iG0= X-Google-Smtp-Source: ABdhPJyIfXnwX0pf3GYWXTIg20UbuxhqlDmGwGGunzfqpUuhyZwHTO3OniaRh8MSNh7ShiL8hMASi52N0+mwFPzDKUU= X-Received: by 2002:a92:d611:: with SMTP id w17mr5453555ilm.103.1596554481064; Tue, 04 Aug 2020 08:21:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 4 Aug 2020 08:21:01 -0700 Message-ID: To: Autumn Tyr-Salvia Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b577f305ac0ece61" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:21:23 -0000 --000000000000b577f305ac0ece61 Content-Type: text/plain; charset="UTF-8" This is a known issue with many calendaring frameworks. Besides the issue of delegates who are sending on behalf of someone in another domain, most calendaring systems send "forwarded" invitations by trying to resend in the name of the event originator. --Kurt --000000000000b577f305ac0ece61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a known issue with many calendari= ng frameworks. Besides the issue of delegates who are sending on behalf of = someone=C2=A0in another domain, most calendaring systems send "forward= ed" invitations by trying to resend in the name of the event originato= r.

--Kurt
--000000000000b577f305ac0ece61-- From nobody Tue Aug 4 08:35:01 2020 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 BF3BB3A098B for ; Tue, 4 Aug 2020 08:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 nZ5UbfCraD-1 for ; Tue, 4 Aug 2020 08:34:55 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 ECD1A3A0A74 for ; Tue, 4 Aug 2020 08:33:43 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:7550:6a42:3e75:ce9f]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 074FXel9024871 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 4 Aug 2020 08:33:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1596555222; bh=e0g/+qjUP74WLaB5EmVHEGIQmr1b+hp0EDewgfkXJ4k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EAoaLFFbKs3rklr1cV0NkOD7GmmYpivb0pyXq5Yln75nbjL8i1bIFzpICXd4Acmsg Uu8zjINIEgqj1CJVVEtxEh9NTxL4uZTCSD7fRonJ8VfBGymiPVKCiJx7iTPWBVseV5 PwR96ejv212jt7EA4jSOuhuUhplOp3Yj1vFB0Pd4= To: John R Levine , "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Tue, 4 Aug 2020 08:33:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:34:58 -0000 On 8/2/20 2:24 PM, John R Levine wrote: >>> If they would provide a way to register a mailing list and the servers >>> from which it comes, and allow DMARC exceptions for traffic from those >>> registered lists, your situation would be much easier? > > If large mail providers were willing to whitelist known mailing lists > we wouldn't need ARC. And as has been pointed out (perhaps also by John), ARC still requires an allowlist or some other way to determine who is allowed to make authenticated changes to a message. -Jim From nobody Tue Aug 4 08:39:34 2020 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 9C9DB3A087E for ; Tue, 4 Aug 2020 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 CkdPahmPUYTd for ; Tue, 4 Aug 2020 08:39:31 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 83DD23A07E7 for ; Tue, 4 Aug 2020 08:39:31 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:7550:6a42:3e75:ce9f]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 074FdSxo025063 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 4 Aug 2020 08:39:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1596555570; bh=NGSSrkBdbdV854/yGN2Bontz8C+rT7mkZxAKM5QmBs0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WIugo1EUa4xXcuucuUabeX2Kx2VcquDLMsa7XZWR2spPSmLJl4jQGLmbScAGDtw1Y nMOl+kCc1vFpP95XRvmIzlrqARrVoXSyowwXrW32IboXvcakA2SPTsvBfQ8ZM7hWPF lz2gD07bLoLjvodb73WVoZZ5/ROL6hRR8r6q2knk= To: fosterd@bayviewphysicians.com, IETF DMARC WG References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Tue, 4 Aug 2020 08:39:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:39:33 -0000 On 8/2/20 5:43 PM, Douglas E. Foster wrote: > As to the transparency question, it should be clear that there will be > no simple solution to the ML problem. Actually, there is: If your domain has users that use mailing lists, don't publish 'reject' or 'quarantine' policies. Generally this means to just use those policies for domains used for transactional email. Unfortunately we seem to be focused on very complex technical solutions to a misdeployment problem. -Jim From nobody Tue Aug 4 09:11:12 2020 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 1C4643A0C67 for ; Tue, 4 Aug 2020 09:11:11 -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, 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 fC7c-vKFHV5f for ; Tue, 4 Aug 2020 09:11:05 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 D1CFB3A0C3E for ; Tue, 4 Aug 2020 09:11:04 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 3so3485383wmi.1 for ; Tue, 04 Aug 2020 09:11:04 -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=6nLK0GSfqyUM+/3G2JpBxEGAJfeui+AkppO/iDEqrlA=; b=pHB7WNNB/JI3M8MouMBytF/zjnMBQ5XfnGnHV+f6bqtp6PbRlRoTwARPp5OMt7yjme x1Tx9j+JvN0hwzaTG8kBJUUGXliEk1LyjHetVUKTUL2me+nRU4O4dbom7MNjagqZ+ng1 LHgoY83KPhKyCHbfHQ5IyZ6T1Iv7AjqgLvJ1DXVS8q1NUNAvVdpcGpVGMAxIq/KBBJju D/dZY2jaNODO3RSkvKPLjOcMaC7jmQIaVdl6t3FfEoa+3fFK+vtU7vQhHGc8rOxHXUfs ZCSO9VeRQzaGg4z+sXU0ydY9fPrMl6s5XjEGjmmnQ8f9MB17S6oJoOpaHykzA10OaYZd PGOg== 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=6nLK0GSfqyUM+/3G2JpBxEGAJfeui+AkppO/iDEqrlA=; b=fMszdIY4bukZH46uG2hPdwicD1skLZ6i++66l7G35qOVm3Bb2lJjlVFZ84yLTSrX4A d59ffcdrhLhFtyG12LY08pm597d2qxgf//ehw8TJvxjogeWCuytEZ3282L36SOazlatB q6yxJvltNoHC/W1tydkFQnlEPEjD3XuhkbsCZF9b1+spYrX3R1XP6KMe9FNVCVqZlIw6 OP53czZ8LF80btlC6i9WpoqiBkN8PGEjAF9Ua2eGbw0t6C4cYfH5ygw1dQkE3zIf6hlr 9he5ST2R0QYcllzJEonScw2l9TkLYyCJ9seBK0fio5KFhQ+H5BhR70gtcnOE1umodTXR /3BA== X-Gm-Message-State: AOAM531zMYT6D7B6nSrkd2B/u96TOCTFXGQWcOVEKIDNoKkPMIQBccxc alB/4YpZmtvr0lsb2+0fwCQ9YKliLEaFWbPhgyM= X-Google-Smtp-Source: ABdhPJxM4RVrKNl+TdQR5qzMxABOIuWDjhl66KsHz1F1pRV0jushq+7Kq1hp977398kII4ZWI4Iwmuw1Pe7Rq8sxVow= X-Received: by 2002:a1c:7402:: with SMTP id p2mr4765084wmc.117.1596557463322; Tue, 04 Aug 2020 09:11:03 -0700 (PDT) MIME-Version: 1.0 References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Tue, 4 Aug 2020 12:10:52 -0400 Message-ID: To: Jim Fenton Cc: "Douglas E. Foster" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000770a4405ac0f8062" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 16:11:11 -0000 --000000000000770a4405ac0f8062 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton wrote: > On 8/2/20 5:43 PM, Douglas E. Foster wrote: > > As to the transparency question, it should be clear that there will be > > no simple solution to the ML problem. > > Actually, there is: If your domain has users that use mailing lists, > don't publish 'reject' or 'quarantine' policies. Generally this means to > just use those policies for domains used for transactional email. > > Unfortunately we seem to be focused on very complex technical solutions > to a misdeployment problem. > > -Jim > > There is another solution. Move users to a separate domain from the domain your transactional mails are sent from. You can also put users on a separate subdomain. There are many ways for this to be addressed without coming up with complex standards solutions. Michael Hammer --000000000000770a4405ac0f8062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Aug 4, 2020 at 11:39 AM Jim Fento= n <fenton@bluepopcorn.net&= gt; wrote:
On 8/= 2/20 5:43 PM, Douglas E. Foster wrote:
> As to the transparency question, it should be clear that there will be=
> no simple solution to the ML problem.

Actually, there is: If your domain has users that use mailing lists,
don't publish 'reject' or 'quarantine' policies. Genera= lly this means to
just use those policies for domains used for transactional email.

Unfortunately we seem to be focused on very complex technical solutions
to a misdeployment problem.

-Jim


There is another solution. Mov= e users to a separate domain from the domain your transactional mails are s= ent from. You can also put users on a separate subdomain.

There are many ways for this to be addressed without coming up with= complex standards=C2=A0solutions.

Michael Hammer<= /div>
--000000000000770a4405ac0f8062-- From nobody Tue Aug 4 09:52:36 2020 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 5E3483A0CCF for ; Tue, 4 Aug 2020 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 qROsPVDtv-Yc for ; Tue, 4 Aug 2020 09:52:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 891EB3A0C8E for ; Tue, 4 Aug 2020 09:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596559947; bh=rHEMdCLnnvLWEe4hPyjnmcrjCqCgf1n+XpB6/faOPt0=; l=1028; h=To:References:From:Date:In-Reply-To; b=A1DWhBPULaj99oEYy93vxwyPbfVcmoBrcyTIEuKgwK5OHm+v7acyNOwFkyeJtOI80 bgPLrFxzeYYmLi0nf0yRKEk7khFqv40h+MNwL2v7s2DGw769bbPqkZ+u//yTGPki2t 2AKaAB5zUjmiJMK01szE8ojyZyGkDe83+8zXCT4j0Vhml7qsGCsyS/mncwJx1 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.36.64]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC013.000000005F29924B.000008E0; Tue, 04 Aug 2020 18:52:27 +0200 To: dmarc@ietf.org References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> From: Alessandro Vesely Message-ID: <6053db20-b888-d597-476b-e76f47633fb3@tana.it> Date: Tue, 4 Aug 2020 18:52:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 16:52:34 -0000 On 2020-08-04 6:10 p.m., Dotzero wrote: > On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton wrote: >> On 8/2/20 5:43 PM, Douglas E. Foster wrote: >>> As to the transparency question, it should be clear that there will be >>> no simple solution to the ML problem. >> >> Actually, there is: If your domain has users that use mailing lists, >> don't publish 'reject' or 'quarantine' policies. Generally this means to >> just use those policies for domains used for transactional email. >> >> Unfortunately we seem to be focused on very complex technical solutions >> to a misdeployment problem. >> >> > There is another solution. Move users to a separate domain from the domain > your transactional mails are sent from. You can also put users on a > separate subdomain. Yet another solution would be to not use DMARC. The status quo ante. While p=none is a technically valid position, there seems to be a demand of a mail infrastructure where spoofing is not allowed. Best Ale -- From nobody Wed Aug 5 09:39:44 2020 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 5C3853A0BC0 for ; Wed, 5 Aug 2020 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 QeZIBpmky6zu for ; Wed, 5 Aug 2020 09:39:41 -0700 (PDT) Received: from wmauth1.doit.wisc.edu (wmauth1.doit.wisc.edu [144.92.197.141]) (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 D84113A0B87 for ; Wed, 5 Aug 2020 09:39:39 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2054.outbound.protection.outlook.com [104.47.37.54]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEL0068BNHHMCA0@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 05 Aug 2020 11:36:53 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-1, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.5.163017, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.37.54] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N2rWqgP/pEfmmR49GVSWxq8FrbRKCV+jETQj6hkjxDGidRxbxGc7FB3K0Vgje3oygaGXni3a+JNv8HinUCezlIvrKA5FJ0egzEM1z0rO+le/8HrmWEWfxiTCUo548/C82dkCF/0Js8ZYXDiIWCmviRbUdv369CmTcTPRwp5UPuPFkoWRvPVgGmRVInsvy/+kFm5QkcM5xOzvhGVOdfjU/SdFhPlOySIcedsuKkCOCff1kLF1KASY3lLA/PYVd1qBSmw8eYRC867dqWG4MxTz/NEjaSv1YGlgupQ2IOBBwFlf6ZEHVBr/6hu9VTkJefmSnKHLR7hOzIMO7efgr+YOXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DIpp9fhu8Y3sP/lcKvpXuHBt8CBJoV3iSOJ3uDHHvCs=; b=b8YQh0de0hPoIpCHZtZY6a8t7qEGfiWdaW0e7gNf1L9NANAW/empuk13cjxgxMIakTGYGNl/P9DuYKnw89E3cLJIqNx3NqcIbSj98E8Wq74p2ZBPnhDQGQVFgO8XUUA5s/L2+/Bu+sYp3h2pE28XpjP5nvuyyAfDVfH4AJY0gpdNSs/22rz6vK6kLmJKh55lFLIL41jmSIM2BYYnLUmgvimKlPmZl0/gmd5UVOFqK+KdhmFOCktJsTTF4USjw0wGwQis4Xw8SznOiu2eqO31Z10hc30FkGqyNy5U0pqnQ6097WS1lQehLos2mQRL++J47QA2TmYF9ttlge3XwIKLPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DIpp9fhu8Y3sP/lcKvpXuHBt8CBJoV3iSOJ3uDHHvCs=; b=X/4hWG6oGTQj+wGJIRFnGF5L6eY9tRgTdE/OKU/8CaByAlf9ZGa++5EIFKpNDN2cbdkqHfecqFiwMhGgrQ0MrplVcfjCJqSJulusaJY4fan8LhMn9B4ygJoXr0tZ1ZZXoodwJPCCjQkhvslv3ea+nsnYwrTuJj464RJIKFHx2Bg= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB3369.namprd06.prod.outlook.com (2603:10b6:4:43::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Wed, 5 Aug 2020 16:36:52 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 16:36:52 +0000 To: dmarc@ietf.org References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> <6053db20-b888-d597-476b-e76f47633fb3@tana.it> From: Jesse Thompson Message-id: Date: Wed, 5 Aug 2020 11:36:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: <6053db20-b888-d597-476b-e76f47633fb3@tana.it> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR14CA0011.namprd14.prod.outlook.com (2603:10b6:610:60::21) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR14CA0011.namprd14.prod.outlook.com (2603:10b6:610:60::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18 via Frontend Transport; Wed, 5 Aug 2020 16:36:51 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 427c021b-4383-42fc-2b92-08d8395dc1f3 X-MS-TrafficTypeDiagnostic: DM5PR06MB3369: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5dElg2eAMaN4mt0TdDkufYdfoGJxbdFVyj28C70MjAcf9Icqvk3I5IR53FOMnvoX+dQ5AczVTEFH232iNC0n1QvW7frYx/iPeCd4vmV8t1kvUhp9ShFE6Ce3Ifjgh2V3FAHHEuW2CshxD0nPDzJCS6Hj10m/f0TokSFWV9flssIT8Bkjq4fyQb16aEFG99HwG758jxrepjgixz+bfLQLMAO6CwoN1Oc1xtl+K0RSLqzB1V6VyYb6YCOXqN/vtX7qsZyTCKm9+sNtlHVv1/ReK2mmYCRSCiC9SFEdgV/eyziGK7/3F+oLcsnxssI9h6uzq4nFdcpQ823lQy3nzQ5iPl5hJ9pO/oMXMDYi2RHbHhdEt38+CdVaEmpBMrGtFI25lFlWLjXwLUeZ1oxBuClYNBL8PyuNwW0ZYQ+yZ1eVlpYT8CXAhQf6RTBFQ/RnuSRbZADJAJ0VXlvaNqnN56hWomvEZnTw/v0mDE0mKGRbwxi6JXyLFrxb18Y5XgvXTEsPB5rgZc/IMDLsZMEc0OQi4Q== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(376002)(136003)(366004)(39860400002)(396003)(956004)(2616005)(478600001)(31686004)(186003)(5660300002)(8936002)(16526019)(36756003)(66556008)(66476007)(66946007)(26005)(86362001)(83380400001)(44832011)(8676002)(53546011)(6666004)(786003)(75432002)(316002)(16576012)(6916009)(2906002)(83080400001)(6486002)(31696002)(966005)(130980200001)(223123001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: C+wEiEebvDDNumQCY8vDKdGTRf5ng0ZPagn89/6ECZmnROqaC8yrBppWcVdfOdspRX3B3sP7j1XlGD+T3BCYOddmV06Cc/WIBY5uKFKuYMlAfJTYH43joN/dh3E7VPyj2rp8JdbX8nBH/Oeb+6NLbRYwtGcQd/zs0PpgJ5yq7ZC4tJD7qSB3ISafL7aHelIlGATsFUGoImOB03DixW9B0qGNoaYBnenPVgF/YaHVO3YL//e1zc50zl3zTup7yzgy4JskH/TH1fWoke0We5KZ8g2XOBMb230gy6oFubDzCC7aXQZeuDA2mTspD7um44/s+hN3jBDVBXVHTu6TwW3HPx6YILBOkVIKHYK3HicTjyB/Zh5Q3O4pBeQAOj+8E9x9oUm1mlGsT4eAl+eLMozeQrz7e7CSU1ZlyDKtuYm30hd8U31/tpvjuHP8HLNFPZOm44/od0htEoW+/EUzggosBWNDDVwXgmMJyR8e4KpeMZ44lM28A4FLkB1zghzZPYNuivhtKUtEiVqrOQq+xW7vBolOr5AWDPhwAwIDZjGBtSp7iQEnm7+fx2YBRI5RpZfnBS3X+OrjGTdkJTPZscSujPYGeoi2YAphGAVYoSFypqYPFeUmSR2iZrIcgWj4dpa0QdVpyArs3G6cRqUk8dBNAQ== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 427c021b-4383-42fc-2b92-08d8395dc1f3 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2020 16:36:52.4324 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: l/M5h1f3B1fO40GfEzo8Thbu3lQWBRY5zVExug/ak8o6HTY+RIPMu+UfdtkacRbqBIIpUL9Lqa/4X+t0Ha2MEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3369 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:39:43 -0000 On 8/4/20 11:52 AM, Alessandro Vesely wrote: > On 2020-08-04 6:10 p.m., Dotzero wrote: >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton wrote: >>> On 8/2/20 5:43 PM, Douglas E. Foster wrote: >>>> As to the transparency question, it should be clear that there will be >>>> no simple solution to the ML problem. >>> >>> Actually, there is: If your domain has users that use mailing lists, >>> don't publish 'reject' or 'quarantine' policies. Generally this means to >>> just use those policies for domains used for transactional email. >>> >>> Unfortunately we seem to be focused on very complex technical solutions >>> to a misdeployment problem. I've never heard this misdeployment viewpoint in the context of M3AAWG, so that might be a good audience to validate the viewpoint that users' domains can't benefit from p=quarantine|reject. Perhaps it should be included in a BCP? Maybe it is, and I'm misremembering? Granted, I've only been a member for a few years. Maybe it was a common understanding years ago and no one talks about it anymore? For example, when I was invited by the technical committee to present our strategy and challenges deploying DMARC for our institution, no one told me we were misdeploying. The session was pretty well attended, and I don't think I put everyone to sleep. Now I feel like my speech was counterproductive because I may have encouraged others to misdeploy DMARC too. >> There is another solution. Move users to a separate domain from the domain Long ago we put users on our org domain as a way to unify users (in a very decentralized institution) under a single domain identity, and that branding decision is not going to be undone, politically. Any project to move users from one domain identity to another is a huge lift; it takes a lot of time, effort, and never actually completes due to stragglers with very legitimate reasons to not give up sending from their old address. I think that end-users would rather see their list mail be rewritten than be told to change their identity. I know that some people on this list think that the domain in the from header isn't commonly visible anymore, but the domain is extremely important to users' sense of identity. >> your transactional mails are sent from. You can also put users on a >> separate subdomain. To the idea of clean separation: We only encourage (without DMARC there is no way to enforce) subdomains for transactional email despite "brand minded" people insisting on using the org domain (or just using it without asking). Despite everyone having an address in the org domain, we still have many users using legacy subdomains, and some of those subdomains are mixed-use. DMARC is great for getting visibility on this "separation" problem. It's not until we moved past p=none that we could get any sticks behind our carrots. What I'm saying is that mixed-use domains are common and they proliferated due to the lack of domain alignment enforcement prior to DMARC. Even when there is intention by IT to separate the use cases, they need DMARC to get both the visibility and the manageability/enforcement. I've observed other universities using their single org domain for everything, and they don't find out they have a problem until they try to implement DMARC. It's easier for them to move the transactional email to subdomains than to move users. That is, unless they just give up on the idea of DMARC altogether. This might be a stretch, but I think the "DMARC is different for user vs transactional domains argument" dovetails with the need for sp to walk the domain tree. If the assertion is that the domain with users is fundamentally different than domains used for transactional email, and most institutions use their org domain for their users, and subdomains are a mixed bag of varying use cases, then the org domain's DMARC policy isn't the best candidate for inheritance. > Yet another solution would be to not use DMARC. The status quo ante. > > While p=none is a technically valid position, there seems to be a > demand of a mail infrastructure where spoofing is not allowed. Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/ I don't think DHS got the memo about misdeploying DMARC, either. I know that around 2018, the person maintaining the MLM for our astrophysics center had to scramble to implement header munging because of all of the .gov's publishing p=reject Jesse From nobody Wed Aug 5 12:52:33 2020 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 CA0093A0EE5 for ; Wed, 5 Aug 2020 12:52:31 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gpeyrq3Y6SPb for ; Wed, 5 Aug 2020 12:52:29 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 466573A0EE0 for ; Wed, 5 Aug 2020 12:52:29 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id 88so41789646wrh.3 for ; Wed, 05 Aug 2020 12:52:29 -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=+68YhEvrU00ywzEiBT0y0mdG/XqfZ1RSHUvHJXq68nc=; b=D/15fLqI0aqWKJacBWG4EEus36oCq5Rz/Vch1hz8B4l5DJpYT2NYUB+qdZJmUvRjO3 odv3vqtcfhCAe0lv+fbp2X39aBxrgNMPHulcptEc8zCng81uPe0NWMKtJ2le4RfTKtPw gG4KMn+/pEnURk/oegMuHg570tl5So7saPSC+u6b4pllyRqehJ3KvqxVTVaXmExRBsul HyYLpN98ZurxkbC5lBCNNwBnMOrbQSYqiY80Vgq/PKCoSYgDyO00vRtZvzKwkHt/zL7J s/UR0MURus1FgrrN2ao9SY6zW2kk9Sr2bjp66ewf8WT8Ayq+LO62SuqGExfFLg6hbpn/ C8ow== 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=+68YhEvrU00ywzEiBT0y0mdG/XqfZ1RSHUvHJXq68nc=; b=WS2epNRq5lyAbgQnGdMY7etgswj57IXUj1cMCwpP59z/7Q2jGlKwB9536MNnLlyQxP txwvEYRr7h+6MGUTMCTOrL1OfwIRJnWjweF232cZ6O458bPhrZT2X1UZpjQi/G7Lipzg at7aqfhRMCjtMYyf8vpt1rNph99dVYeCIIBTm7PyHS24AE/lxOnEOeYtxXgXEMSLhdtw LsnoZOLANDY3T9IGXAhezfXa9TPFmEKDXRIELhD6msBIftzbjfC4UYECAVQ9Ik43c5UE hiwW0vVvY7GQ4ejYR7b6TtWJUryOEeAqNN0Rr4y4AbjHRnSnWeAglgJFB7wXuzw9U7kg a5Dg== X-Gm-Message-State: AOAM530IzoEi/x77Q++Os3mK1JtPBmTQUfFQ+BwApP6vwGKiozBVhmrG +LQvzOdTs7eJbGXIQ0w9DjCFlTKZrTuJvWhTIN5nIQ== X-Google-Smtp-Source: ABdhPJy3j7F3Sunen6WbrVjXWkB0rqivpqS3KbZmNfdeJIZoN2Onq+suO7LcXiaj2Ih3rh8eRqe0Mh/ftBdh4yG2ACY= X-Received: by 2002:a5d:4ecf:: with SMTP id s15mr4165191wrv.202.1596657147657; Wed, 05 Aug 2020 12:52:27 -0700 (PDT) MIME-Version: 1.0 References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> <6053db20-b888-d597-476b-e76f47633fb3@tana.it> In-Reply-To: From: Dotzero Date: Wed, 5 Aug 2020 15:52:15 -0400 Message-ID: To: Jesse Thompson Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001d423705ac26b6c7" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 19:52:32 -0000 --0000000000001d423705ac26b6c7 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson wrote: > On 8/4/20 11:52 AM, Alessandro Vesely wrote: > > On 2020-08-04 6:10 p.m., Dotzero wrote: > >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton > wrote: > >>> On 8/2/20 5:43 PM, Douglas E. Foster wrote: > >>>> As to the transparency question, it should be clear that there will be > >>>> no simple solution to the ML problem. > >>> > >>> Actually, there is: If your domain has users that use mailing lists, > >>> don't publish 'reject' or 'quarantine' policies. Generally this means > to > >>> just use those policies for domains used for transactional email. > >>> > >>> Unfortunately we seem to be focused on very complex technical solutions > >>> to a misdeployment problem. > > I've never heard this misdeployment viewpoint in the context of M3AAWG, so > that might be a good audience to validate the viewpoint that users' domains > can't benefit from p=quarantine|reject. Perhaps it should be included in a > BCP? Maybe it is, and I'm misremembering? Granted, I've only been a > member for a few years. Maybe it was a common understanding years ago and > no one talks about it anymore? > Not a knock on M3AAWG but many of the members are more interested in deliverability than anti-abuse. The Sender side of M3AAWG is dominated by ESPs rather than Brand Senders. I say this as the Founder and Chair of Brand SIG for 10 years until I left my employer that was a member of M3AAWG. > > For example, when I was invited by the technical committee to present our > strategy and challenges deploying DMARC for our institution, no one told me > we were misdeploying. The session was pretty well attended, and I don't > think I put everyone to sleep. Now I feel like my speech was > counterproductive because I may have encouraged others to misdeploy DMARC > too. > You were presenting what you did. It may or may not have been counterproductive. > > > >> There is another solution. Move users to a separate domain from the > domain > > Long ago we put users on our org domain as a way to unify users (in a very > decentralized institution) under a single domain identity, and that > branding decision is not going to be undone, politically. Any project to > move users from one domain identity to another is a huge lift; it takes a > lot of time, effort, and never actually completes due to stragglers with > very legitimate reasons to not give up sending from their old address. > I implemented for an Enterprise with large ecommerce/social sites and 20k seats. The only people that were allowed to keep accounts on the primary domains were people who directly supported the websites and they were not allowed to use those accounts for anything other than supporting the websites. They had accounts at the other domain just as all the other users. > > I think that end-users would rather see their list mail be rewritten than > be told to change their identity. I know that some people on this list > think that the domain in the from header isn't commonly visible anymore, > but the domain is extremely important to users' sense of identity. > Their identity at that organization is subject to the determinations of the organization. It is amazing how quickly after a one time transition that users get used to their new "identity". > > > >> your transactional mails are sent from. You can also put users on a > >> separate subdomain. > > To the idea of clean separation: We only encourage (without DMARC there > is no way to enforce) subdomains for transactional email despite "brand > minded" people insisting on using the org domain (or just using it without > asking). Despite everyone having an address in the org domain, we still > have many users using legacy subdomains, and some of those subdomains are > mixed-use. > You need buy-in from senior management for any email authentication efforts. When you add up the costs of customer support contacts for dealing with fraudulent email claiming to be from your organization, reputation damage, etc., management becomes more willing to buy into a comprehensive strategy. > > DMARC is great for getting visibility on this "separation" problem. It's > not until we moved past p=none that we could get any sticks behind our > carrots. > > What I'm saying is that mixed-use domains are common and they proliferated > due to the lack of domain alignment enforcement prior to DMARC. Even when > there is intention by IT to separate the use cases, they need DMARC to get > both the visibility and the manageability/enforcement. > If it is only IT pushing this, you are probably doomed to failure. > > I've observed other universities using their single org domain for > everything, and they don't find out they have a problem until they try to > implement DMARC. It's easier for them to move the transactional email to > subdomains than to move users. That is, unless they just give up on the > idea of DMARC altogether. > Organizations make choices based on perceived benefits and costs. > > This might be a stretch, but I think the "DMARC is different for user vs > transactional domains argument" dovetails with the need for sp to walk the > domain tree. If the assertion is that the domain with users is > fundamentally different than domains used for transactional email, and most > institutions use their org domain for their users, and subdomains are a > mixed bag of varying use cases, then the org domain's DMARC policy isn't > the best candidate for inheritance. > The assumption was/is that the organizational domain most closely tracks the risk for abuse and is therefore the one that most needs protection. Therefore inheritance should be the rule rather than the exception. It also means you don't have to walk the full tree. You only need to check the base domain if the subdoain doesn't specify a policy. > > > > Yet another solution would be to not use DMARC. The status quo ante. > > > > While p=none is a technically valid position, there seems to be a > > demand of a mail infrastructure where spoofing is not allowed. > > Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/ > > I don't think DHS got the memo about misdeploying DMARC, either. I know > that around 2018, the person maintaining the MLM for our astrophysics > center had to scramble to implement header munging because of all of the > .gov's publishing p=reject > > The .gov space has an interesting and long history with regard to email authentication. In 2011, Pat Peterson (Agari) and I were asked by EOP (Executive Office of The President) to create and give training on email authentication for .gov that was turned into a virtual training environment that was available for all government employees. The specific impetus were a series of incidents that included fake malicious White House ecards purporting to be online Christmas cards that were sent to government contractors and others. Required authentication for .gov domains moved forward in fits and starts up to the point of the DHS mandate. DHS approached the use of DMARC and authentication as a blunt one size fits all instrument. The reality is that the devil is always in the details. Michael Hammer --0000000000001d423705ac26b6c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 5, 2020 at 12:39 PM Jesse= Thompson <jesse.thompson=3D40wisc.edu@dmarc.ietf.org> wrote:
On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> On 2020-08-04 6:10 p.m., Dotzero wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton <fenton@bluepopcorn.net> wro= te:
>>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>>>> As to the transparency question, it should be clear that t= here will be
>>>> no simple solution to the ML problem.
>>>
>>> Actually, there is: If your domain has users that use mailing = lists,
>>> don't publish 'reject' or 'quarantine' pol= icies. Generally this means to
>>> just use those policies for domains used for transactional ema= il.
>>>
>>> Unfortunately we seem to be focused on very complex technical = solutions
>>> to a misdeployment problem.

I've never heard this misdeployment viewpoint in the context of M3AAWG,= so that might be a good audience to validate the viewpoint that users'= domains can't benefit from p=3Dquarantine|reject.=C2=A0 Perhaps it sho= uld be included in a BCP?=C2=A0 Maybe it is, and I'm misremembering?=C2= =A0 Granted, I've only been a member for a few years.=C2=A0 Maybe it wa= s a common understanding years ago and no one talks about it anymore?

Not a knock on M3AAWG but many of the member= s are more interested in deliverability than anti-abuse. The Sender side of= M3AAWG is dominated by ESPs rather than Brand Senders. I say this as the F= ounder and Chair of Brand SIG for 10 years until I left my employer that wa= s a member of M3AAWG.


>> There is another solution. Move users to a separate domain from th= e domain

Long ago we put users on our org domain as a way to unify users (in a very = decentralized institution) under a single domain identity, and that brandin= g decision is not going to be undone, politically.=C2=A0 Any project to mov= e users from one domain identity to another is a huge lift; it takes a lot = of time, effort, and never actually completes due to stragglers with very l= egitimate reasons to not give up sending from their old address.=C2=A0
=

I implemented for an Enterprise with large= ecommerce/social sites and 20k seats. The only people that were allowed to= keep accounts on the primary domains were people who directly supported th= e websites and they were not allowed to use those accounts for anything oth= er than supporting the websites. They had accounts at the other domain just= as all the other users.

I think that end-users would rather see their list mail be rewritten than b= e told to change their identity.=C2=A0 I know that some people on this list= think that the domain in the from header isn't commonly visible anymor= e, but the domain is extremely important to users' sense of identity.= =C2=A0

Their identity at that organiza= tion is subject to the determinations of the organization. It is amazing ho= w quickly after a one time transition that users get used to=C2=A0 their ne= w "identity".


>> your transactional mails are sent from. You can also put users on = a
>> separate subdomain.

To the idea of clean separation:=C2=A0 We only encourage (without DMARC the= re is no way to enforce) subdomains for transactional email despite "b= rand minded" people insisting on using the org domain (or just using i= t without asking).=C2=A0 Despite everyone having an address in the org doma= in, we still have many users using legacy subdomains, and some of those sub= domains are mixed-use.=C2=A0

You need = buy-in from senior management for any email=C2=A0authentication efforts. Wh= en you add up the costs of customer support contacts for dealing with fraud= ulent email claiming=C2=A0to be from your organization, reputation damage, = etc., management becomes more willing to buy into a comprehensive strategy.=

DMARC is great for getting visibility on this "separation" proble= m.=C2=A0 It's not until we moved past p=3Dnone that we could get any st= icks behind our carrots.=C2=A0

What I'm saying is that mixed-use domains are common and they prolifera= ted due to the lack of domain alignment enforcement prior to DMARC.=C2=A0 E= ven when there is intention by IT to separate the use cases, they need DMAR= C to get both the visibility and the manageability/enforcement.

If it is only IT pushing this, you are probably do= omed to failure.
=C2=A0

I've observed other universities using their single org domain for ever= ything, and they don't find out they have a problem until they try to i= mplement DMARC.=C2=A0 It's easier for them to move the transactional em= ail to subdomains than to move users.=C2=A0 That is, unless they just give = up on the idea of DMARC altogether.

Org= anizations make choices=C2=A0based on perceived benefits and costs.=C2=A0

This might be a stretch, but I think the "DMARC is different for user = vs transactional domains argument" dovetails with the need for sp to w= alk the domain tree.=C2=A0 If the assertion is that the domain with users i= s fundamentally different than domains used for transactional email, and mo= st institutions use their org domain for their users, and subdomains are a = mixed bag of varying use cases, then the org domain's DMARC policy isn&= #39;t the best candidate for inheritance.=C2=A0

<= /div>
The assumption was/is that the organizational=C2=A0domain most cl= osely tracks the risk for abuse and is therefore the one that most needs pr= otection. Therefore inheritance should be the rule rather than the exceptio= n. It also means you don't have to walk the full tree. You only need to= check the base domain if the subdoain=C2=A0doesn't specify a policy.


> Yet another solution would be to not use DMARC.=C2=A0 The status quo a= nte.
>
> While p=3Dnone is a technically valid position, there seems to be a > demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-0= 1/

I don't think DHS got the memo about misdeploying DMARC, either.=C2=A0 = I know that around 2018, the person maintaining the MLM for our astrophysic= s center had to scramble to implement header munging because of all of the = .gov's publishing p=3Dreject

The .gov space ha= s an interesting and long history with regard to email authentication. In 2= 011, Pat Peterson (Agari) and I were asked by EOP (Executive Office of The = President) to create and give training on email authentication=C2=A0for .go= v that was turned into a virtual training environment that was available fo= r all government employees. The specific impetus were a series of incidents= that included fake malicious=C2=A0White House ecards purporting to be onli= ne Christmas cards that were sent to government contractors and others. Req= uired authentication for .gov domains moved forward in fits and starts up t= o the point of the DHS mandate. DHS approached the use of DMARC and authent= ication as a blunt one size fits all instrument.

T= he reality is that the devil is always in the details.

=
Michael Hammer
--0000000000001d423705ac26b6c7-- From nobody Thu Aug 6 01:16:19 2020 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 3DAF03A1056 for ; Thu, 6 Aug 2020 01:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 H8wqycdkRuvn for ; Thu, 6 Aug 2020 01:16:10 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 17F1D3A1050 for ; Thu, 6 Aug 2020 01:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596701768; bh=t/eTmMhtuby/7KFxQnShHyCQUOhyAUm2PUH1mig82C8=; l=734; h=To:References:From:Date:In-Reply-To; b=AmgVFAGewKMdk0/cDPOEdf94XEAtxf9C+Sbdm0Fy6eesdeGWnZtxHTU+0mBqqP73q pNcaihOkRrbWNU98XQgBdEn1O705MNmsCdgnFp0cNwsjKYbu7FjqwqEm22xgPlgvBX jQeRUgLYOFVXxUytQS++vEWAEfki2xsL8fKMOUFqktgDsmiAyIUfY8HGqrUQy Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.167]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0D8.000000005F2BBC48.0000171C; Thu, 06 Aug 2020 10:16:07 +0200 To: dmarc@ietf.org References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> <6053db20-b888-d597-476b-e76f47633fb3@tana.it> From: Alessandro Vesely Message-ID: Date: Thu, 6 Aug 2020 10:16:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 08:16:18 -0000 On 2020-08-05 9:52 p.m., Dotzero wrote: > Required authentication for .gov domains moved forward in fits and > starts up to the point of the DHS mandate. DHS approached the use > of DMARC and authentication as a blunt one size fits all > instrument. That makes sense! If you look at email from a user POV, how can you justify the fact that transactional mail is protected while ordinary people's identities can be seized scot-free? I think DHS interprets a general feeling. > > The reality is that the devil is always in the details. Right, and we're the fairy godmother who gotta work them out. With From: rewriting, Author: Sender:, To:, and DKIM transforms we're well into it, aren't we? Best Ale -- From nobody Fri Aug 7 03:32:04 2020 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 EE2A83A0EEA for ; Fri, 7 Aug 2020 03:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.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 oWkOGqrU6j9B for ; Fri, 7 Aug 2020 03:31:59 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2136.outbound.protection.outlook.com [40.107.220.136]) (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 DE1113A0EE7 for ; Fri, 7 Aug 2020 03:31:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k0XDEWrAQoSb4OgIzeA+24JymagzgbQcRtDpeyQ0XMN9lz1rSV9fB31nQ6OEB7D3mGBuocLrZfvwWxEudNvnRO2rFDMmiUN+N+lQZ4Mt8wF1CFoJMBFdHK7w3heET4kpDo+Ao3kytVIbHe+mawv0AL7EgEQec8Bp9qKOqf0EPp4FImHLNcXJYanYkurya8dJcutygpBbU8P5PQ+bHpcVHlXAf1Bmm8cIJnXKgsNcs2Th8vMj+82Q5OkF3VT0YCP3MP5Bx5J8Z9aoqFYk0T9dakwJZfKpupULabLMUVxx/MLVh2m4lSeinX/QVcizIBX8k2SKG89sEEqKKNxWKIywYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ffecMmgGtA/KsJ1DJnFY0b+o7gEOHIJf9TZrxXjQcSs=; b=iFGjYT1PfliX/uJdiYobbRPKjzBZSZbRpssrJYr0KLR+WxrgZGFM3KGT/N5ZzuJ4Xy3QSfSSI9u3yg1vbUo/3pzSZZzGh34lC2jxBFTks500oBjfhMy6tFrOuBd/QQsFJzYGHlWdjI2g9fMvkXoRijHvGZnCT4mG2jnLE5MPz1JzUlsR5e3hpJXITqOa/igJOEllaZ7PPzGC2/nyui2Y+lJgH5kbObnzg94D7Y8NMEpvA861UsuP5TxQyo36VNn/Hua5tTwQoTllfEbdJbwjZmAHbu6XQ+Rt7WFev3tnPD1n/iSPRn5BNPyFeoSZVsDBmECO/euGIc4tOrPe6cNaaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=agari.com; dmarc=pass action=none header.from=agari.com; dkim=pass header.d=agari.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ffecMmgGtA/KsJ1DJnFY0b+o7gEOHIJf9TZrxXjQcSs=; b=V+kIocZ9j5J6rdTDNAmjQFBQPReefArT4xzuniokld4KQDfD/yQZyWS2wxqF2t4Ym7CeUM5p/wOIkqx3qa5fIkWAK059z90IEHGR5YQhScpo1TVzcg6MbHLTyTjRfdZToVD8dEVjSzlVMkPe36Zt1O5IqTlYwuYWzBYWTVxOAqg= Received: from BY5PR13MB2999.namprd13.prod.outlook.com (2603:10b6:a03:191::27) by BYAPR13MB2744.namprd13.prod.outlook.com (2603:10b6:a03:fc::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.7; Fri, 7 Aug 2020 10:31:54 +0000 Received: from BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f]) by BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f%3]) with mapi id 15.20.3261.019; Fri, 7 Aug 2020 10:31:54 +0000 From: Autumn Tyr-Salvia To: Dotzero , Jesse Thompson CC: IETF DMARC WG Thread-Topic: [dmarc-ietf] non-mailing list use case for differing header domains Thread-Index: AQHWZKh8JcOQ838b0UOee1lvwkySbakcmlWAgAAZV4CABAtZAIAAJAYAgAMr0H6AAONBAIAAILYAgAAgwICAACkyAIAAAbIAgAA2jwCAAoyEgIAACMwAgAALnQCAAY3UgIAANr6AgAJ+BWs= Date: Fri, 7 Aug 2020 10:31:54 +0000 Message-ID: References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> <6053db20-b888-d597-476b-e76f47633fb3@tana.it> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=agari.com; x-originating-ip: [2600:1700:bd50:a670:203b:9ffe:c065:d0e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71e9e4b4-e20d-4699-d628-08d83abd1aa1 x-ms-traffictypediagnostic: BYAPR13MB2744: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2nPI1cdYpHSET+hWla3ecdSMKKMPwKufMHUQ/IbaafbSVnFqlkz1nrftJ4I1MK21/H3uSDrUSZ0gbRI0foS7+ZBc4ROcBALeE0RFk0RgwtFY+WwwN5FvYel6Q9Bb8JJ+Gq2O/ugQ5uftGz/RAMLpGjdOOTwP9j5M7s3GVuT4GoN2FPM/0WxN+S9ke9ZCKWTaHQfHYtDMwGILfS9DL4+yzD5/iBiUod6HYCM9ehW8N2g9otqp4H1PAhQ4Pw3eE8KhAY+l6K8IN40U42yDyuJzdKPOBAjvfCMmC2bEinn8BZ6z/nRlxZvq/ZFDCsloZGpTiYlsSjjUf29SjT5m3lekUODFZF1YNEH5K/DdNlPYBSnCXT6DG8ijgljKpdVjow31YUcWPFqPm4wh0wqAHweZ2JIbv4exp6OE7qpS2dXtNi/gPHtf/ELHZDB1Vfi/NIYK0jy9188rqYiOF+A1zB2mopAzlTSMi0VCh2Z4eCVbt+4r877Q38svIbX2B1FuUUbk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB2999.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(396003)(376002)(346002)(136003)(9686003)(5660300002)(55016002)(110136005)(966005)(478600001)(2906002)(76116006)(33656002)(52536014)(316002)(66476007)(66556008)(64756008)(66446008)(66946007)(6506007)(30864003)(53546011)(83080400001)(8676002)(83380400001)(66574015)(86362001)(186003)(166002)(4326008)(19627405001)(7696005)(8936002)(71200400001)(130980200001)(223123001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 5O0R4ZyyNkdJg07oL+CL2w+prJ18DZr1KUWR7+l3SrTCB9o3yrM5vg9UxxeiMeHY5rnGJweyLliavEvsb3ZsO7gnsrj32L/8DJEIY1eAhH9vs/JKDIoUyvl6t/0V6j8wIcqy51Kld534DK41fzyHVQOqOjLbfQzK1V2FFoiKokT5VIipEbloIwdJOGOmSOIskxSu0IyvTO2sAo+2WuHH3/+V52fXMVXFyTPgZWa+7wpCDtxk4rgHS662F8Ym2i7OsgHGQNCoh18c+yAWmlE9O+kBi1Q/vG05vs3E/yutZz4e80YtAt6sksHKgi7bHiDs8A4h6Fl3klvaG25tkYNmvh+Y1wdHysL11cxuTpKH68+plxXaZ2iHN4n23SsBY8JdjWkK/ZTz8xQjqqgDnXZHUG5MfszYciIHoT8U19h1OUKwkmujUrB6EsYWC9+mmpq3qJlORNvRFD6X5DkN+DqjaVQ1Ud9AbaTBZYgjW2MbfAUQq0XUIROdcuHVHzucCuNSqkgfpTCJZCdBqZUjPzzVJaWpH0KzgiknHca/DZQS8hNBb1zJdKFkfpIlR9hmnZEkNa2kS0gWao6wCqdRyWclR+IFxZUUMiG3Uz8bQxGx5BcemT3r4+t9oW13xr27V6+fpgDoXIzOfNQ8lZJMCQxiLWzV+0c/vwRfAyIF6rTWgAwNKai01oIAC0JREVbt6EcyAlQqO6ZjktkLC9nk0VSJyA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB2999AD95B4BD7C80971FDA4FD7490BY5PR13MB2999namp_" MIME-Version: 1.0 X-OriginatorOrg: agari.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB2999.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 71e9e4b4-e20d-4699-d628-08d83abd1aa1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 10:31:54.1709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05773123-385e-420d-844e-f01aee5e37ab X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BgjLUf3QxbJfwfQctwxKIXPARg6NwgfGAICTr43newyZD+OQU+RfctMTXAKEqCAoJ8KW+4u4du8XwreFvQuo1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2744 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 10:32:02 -0000 --_000_BY5PR13MB2999AD95B4BD7C80971FDA4FD7490BY5PR13MB2999namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What I find very interesting about this email from Jesse, and Mike's respon= se is that I hear these words coming from two very different experiences of= deploying DMARC. In my role doing onboarding at Agari, I have worked with many different org= anizations on their DMARC projects. I have worked with numerous corporate g= roups, as well as governmental organizations, nonprofits, and universities.= Universities operate with a somewhat different set of expectations than ot= her groups in ways that make DMARC additionally challenging. Here are a few things I have learned implementing DMARC for multiple univer= sities: * Universities have a significantly higher degree of user and use case = turnover than other organizations, by a lot. There are new students and sta= ff every term, and many more of them will use their email address to send o= ut email over various third party tools. In the corporate world, sure there= are employees coming and going all the time, and new projects, but there i= s a much greater degree of stability in terms of systems sending out email. * University IT has much less control over their users than corporate I= T. In corporate IT, it is not unusual for IT leadership to make decisions o= n what applications will and will not be supported, and to have general sup= port for this from the top. In higher education, IT teams seem to frequentl= y be told that they must support whatever their users request, and have ver= y little authority. * Most universities serve a greater breadth of use cases than most othe= r organizations. Consider an organization that is a fundraising nonprofit, = scientific research group in multiple disciplines, hospital, mental health = clinic, employer with HR tools, housing coordinator, childcare coordinator,= gym, sports arena, transportation system, provider of continuing education= to certified professionals, press agency, mailing list provider, forwarder= , etc. all in one. There are a lot of niche tools that can send email in ea= ch of these different use cases, but universities are the only place I see = so many of them all together. * Universities are highly decentralized. It seems like every major scho= ol inside a university (school of public health, school of humanities, etc.= ) has its own policies and culture, and sometimes its own IT staff. * Universities tend to have more legacy technology than other organizat= ions (except government). The reason I mention all this stuff is that I feel like some of what is bei= ng suggested here misses this reality. Mike said, "You need buy-in from senior management for any email authentica= tion efforts. When you add up the costs of customer support contacts for de= aling with fraudulent email claiming to be from your organization, reputati= on damage, etc., management becomes more willing to buy into a comprehensiv= e strategy." - in the higher education world, I don't see it working like t= his. IT staff can get enough buy-in to decide to work on DMARC as a project= , but the costs of support contacts are likely spread out over multiple gro= ups in a way that is very hard to quantify at a higher level, and even if t= hey were to consider that, they would still be more likely to say that a co= mprehensive strategy is good and all, but it still matters more to them tha= t good old Professor 1984 can still use his favorite application even thoug= h it doesn't conform to modern security standards. I feel like what is happening sometimes is that central university IT is tr= ying to drag their whole institutions into a more secure posture before any= body in a position to stop them fully understands what's going on lest they= be told to stop because it might make things a little inconvenient. Many u= niversities do not attempt DMARC at all, so I think any work we can do to m= ake it easier on them would encourage greater adoption. Thanks, Autumn Tyr-Salvia atyrsalvia@agari.com Agari Principal Customer Success Engineer ________________________________ From: dmarc on behalf of Dotzero Sent: Wednesday, August 5, 2020 12:52 PM To: Jesse Thompson Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson > wrote: On 8/4/20 11:52 AM, Alessandro Vesely wrote: > On 2020-08-04 6:10 p.m., Dotzero wrote: >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton > wrote: >>> On 8/2/20 5:43 PM, Douglas E. Foster wrote: >>>> As to the transparency question, it should be clear that there will be >>>> no simple solution to the ML problem. >>> >>> Actually, there is: If your domain has users that use mailing lists, >>> don't publish 'reject' or 'quarantine' policies. Generally this means t= o >>> just use those policies for domains used for transactional email. >>> >>> Unfortunately we seem to be focused on very complex technical solutions >>> to a misdeployment problem. I've never heard this misdeployment viewpoint in the context of M3AAWG, so = that might be a good audience to validate the viewpoint that users' domains= can't benefit from p=3Dquarantine|reject. Perhaps it should be included i= n a BCP? Maybe it is, and I'm misremembering? Granted, I've only been a m= ember for a few years. Maybe it was a common understanding years ago and n= o one talks about it anymore? Not a knock on M3AAWG but many of the members are more interested in delive= rability than anti-abuse. The Sender side of M3AAWG is dominated by ESPs ra= ther than Brand Senders. I say this as the Founder and Chair of Brand SIG f= or 10 years until I left my employer that was a member of M3AAWG. For example, when I was invited by the technical committee to present our s= trategy and challenges deploying DMARC for our institution, no one told me = we were misdeploying. The session was pretty well attended, and I don't th= ink I put everyone to sleep. Now I feel like my speech was counterproducti= ve because I may have encouraged others to misdeploy DMARC too. You were presenting what you did. It may or may not have been counterproduc= tive. >> There is another solution. Move users to a separate domain from the doma= in Long ago we put users on our org domain as a way to unify users (in a very = decentralized institution) under a single domain identity, and that brandin= g decision is not going to be undone, politically. Any project to move use= rs from one domain identity to another is a huge lift; it takes a lot of ti= me, effort, and never actually completes due to stragglers with very legiti= mate reasons to not give up sending from their old address. I implemented for an Enterprise with large ecommerce/social sites and 20k s= eats. The only people that were allowed to keep accounts on the primary dom= ains were people who directly supported the websites and they were not allo= wed to use those accounts for anything other than supporting the websites. = They had accounts at the other domain just as all the other users. I think that end-users would rather see their list mail be rewritten than b= e told to change their identity. I know that some people on this list thin= k that the domain in the from header isn't commonly visible anymore, but th= e domain is extremely important to users' sense of identity. Their identity at that organization is subject to the determinations of the= organization. It is amazing how quickly after a one time transition that u= sers get used to their new "identity". >> your transactional mails are sent from. You can also put users on a >> separate subdomain. To the idea of clean separation: We only encourage (without DMARC there is= no way to enforce) subdomains for transactional email despite "brand minde= d" people insisting on using the org domain (or just using it without askin= g). Despite everyone having an address in the org domain, we still have ma= ny users using legacy subdomains, and some of those subdomains are mixed-us= e. You need buy-in from senior management for any email authentication efforts= . When you add up the costs of customer support contacts for dealing with f= raudulent email claiming to be from your organization, reputation damage, e= tc., management becomes more willing to buy into a comprehensive strategy. DMARC is great for getting visibility on this "separation" problem. It's n= ot until we moved past p=3Dnone that we could get any sticks behind our car= rots. What I'm saying is that mixed-use domains are common and they proliferated = due to the lack of domain alignment enforcement prior to DMARC. Even when = there is intention by IT to separate the use cases, they need DMARC to get = both the visibility and the manageability/enforcement. If it is only IT pushing this, you are probably doomed to failure. I've observed other universities using their single org domain for everythi= ng, and they don't find out they have a problem until they try to implement= DMARC. It's easier for them to move the transactional email to subdomains= than to move users. That is, unless they just give up on the idea of DMAR= C altogether. Organizations make choices based on perceived benefits and costs. This might be a stretch, but I think the "DMARC is different for user vs tr= ansactional domains argument" dovetails with the need for sp to walk the do= main tree. If the assertion is that the domain with users is fundamentally= different than domains used for transactional email, and most institutions= use their org domain for their users, and subdomains are a mixed bag of va= rying use cases, then the org domain's DMARC policy isn't the best candidat= e for inheritance. The assumption was/is that the organizational domain most closely tracks th= e risk for abuse and is therefore the one that most needs protection. There= fore inheritance should be the rule rather than the exception. It also mean= s you don't have to walk the full tree. You only need to check the base dom= ain if the subdoain doesn't specify a policy. > Yet another solution would be to not use DMARC. The status quo ante. > > While p=3Dnone is a technically valid position, there seems to be a > demand of a mail infrastructure where spoofing is not allowed. Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/ I don't think DHS got the memo about misdeploying DMARC, either. I know th= at around 2018, the person maintaining the MLM for our astrophysics center = had to scramble to implement header munging because of all of the ..gov's p= ublishing p=3Dreject The .gov space has an interesting and long history with regard to email aut= hentication. In 2011, Pat Peterson (Agari) and I were asked by EOP (Executi= ve Office of The President) to create and give training on email authentica= tion for .gov that was turned into a virtual training environment that was = available for all government employees. The specific impetus were a series = of incidents that included fake malicious White House ecards purporting to = be online Christmas cards that were sent to government contractors and othe= rs. Required authentication for .gov domains moved forward in fits and star= ts up to the point of the DHS mandate. DHS approached the use of DMARC and = authentication as a blunt one size fits all instrument. The reality is that the devil is always in the details. Michael Hammer --_000_BY5PR13MB2999AD95B4BD7C80971FDA4FD7490BY5PR13MB2999namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What I find very interesting about this email from Jesse, and Mike's respon= se is that I hear these words coming from two very different experiences of= deploying DMARC. 

In my role doing onboarding at Agari, I have worked with many different org= anizations on their DMARC projects. I have worked with numerous corporate g= roups, as well as governmental organizations, nonprofits, and universities.= Universities operate with a somewhat different set of expectations than other groups in ways that make DMARC ad= ditionally challenging. 

Here are a few things I have learned implementing DMARC for multiple univer= sities: 
  • Universities have a significantly higher degree of user and use case tu= rnover than other organizations, by a lot. There are new students and staff= every term, and many more of them will use their email address to send out= email over various third party tools. In the corporate world, sure there are employees coming and going a= ll the time, and new projects, but there is a much greater degree of stabil= ity in terms of systems sending out email. 
  • University IT has = much less control over their users than corporate IT. In corporate IT, it i= s not unusual for IT leadership to make decisions on what applications will= and will not be supported, and to have general support for this from the t= op. In higher education, IT teams seem to frequently be told that they must support what= ever their users request, and have very little authority.
  • Most univ= ersities serve a greater breadth of use cases than most other organizations= . Consider an organization that is a fundraising nonprofit, scientific rese= arch group in multiple disciplines, hospital, mental health clinic, employe= r with HR tools, housing coordinator, childcare coordinator, gym, sports arena, transportation syst= em, provider of continuing education to certified professionals, press agen= cy, mailing list provider, forwarder, etc. all in one. There are a lot of n= iche tools that can send email in each of these different use cases, but universities are the only place I s= ee so many of them all together.
  • Universities are highly decentrali= zed. It seems like every major school inside a university (school of public= health, school of humanities, etc.) has its own policies and culture, and = sometimes its own IT staff. 
  • Universities tend to have more le= gacy technology than other organizations (except government). 
    • The reason I mention all this stuff is that I feel like some of what i= s being suggested here misses this reality. 

    Mike said, "= You need buy-in from senior management for any email authentication effor= ts. When you add up the costs of customer support contacts for dealing with= fraudulent email claiming to be from your organization, reputation da= mage, etc., management becomes more willing to buy into a comprehensive strategy." - in the higher education world, I don't see it working like this. IT staff c= an get enough buy-in to decide to work on DMARC as a project, but the costs= of support contacts are likely spread out over multiple groups in a way th= at is very hard to quantify at a higher level, and even if they were to consider that, they would still be = more likely to say that a comprehensive strategy is good and all, but it st= ill matters more to them that good old Professor 1984 can still use his fav= orite application even though it doesn't conform to modern security standards. 

    I feel like what is happening sometimes is that central university IT is try= ing to drag their whole institutions into a more secure posture before anyb= ody in a position to stop them fully understands what's going on lest they = be told to stop because it might make things a little inconvenient. Many universities do not attempt DMARC = at all, so I think any work we can do to make it easier on them would encou= rage greater adoption. 


    Thanks,

    Autumn Tyr-Salvia
    atyrsalvia@agari.com
    Agari Principal Customer Success Engineer


     
From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Dotzero <dotzero@gmail.com>
Sent: Wednesday, August 5, 2020 12:52 PM
To: Jesse Thompson <jesse.thompson=3D40wisc.edu@dmarc.ietf.org>= ;
Cc: IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing he= ader domains
 


On Wed, Aug 5, 2020 at 12:39 PM Jes= se Thompson <jesse.thompson=3D40wisc.edu@dmarc.ietf.org> wrote:
On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> On 2020-08-04 6:10 p.m., Dotzero wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton <fenton@bluepopcorn.net> wro= te:
>>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>>>> As to the transparency question, it should be clear that t= here will be
>>>> no simple solution to the ML problem.
>>>
>>> Actually, there is: If your domain has users that use mailing = lists,
>>> don't publish 'reject' or 'quarantine' policies. Generally thi= s means to
>>> just use those policies for domains used for transactional ema= il.
>>>
>>> Unfortunately we seem to be focused on very complex technical = solutions
>>> to a misdeployment problem.

I've never heard this misdeployment viewpoint in the context of M3AAWG, so = that might be a good audience to validate the viewpoint that users' domains= can't benefit from p=3Dquarantine|reject.  Perhaps it should be inclu= ded in a BCP?  Maybe it is, and I'm misremembering?  Granted, I've only been a member for a few years.  Maybe it was a com= mon understanding years ago and no one talks about it anymore?

Not a knock on M3AAWG but many of the members are more interested in d= eliverability than anti-abuse. The Sender side of M3AAWG is dominated by ES= Ps rather than Brand Senders. I say this as the Founder and Chair of Brand = SIG for 10 years until I left my employer that was a member of M3AAWG.

For example, when I was invited by the technical committee to present our s= trategy and challenges deploying DMARC for our institution, no one told me = we were misdeploying.  The session was pretty well attended, and I don= 't think I put everyone to sleep.  Now I feel like my speech was counterproductive because I may have encouraged = others to misdeploy DMARC too.

You were presenting what you did. It may or may not have been counterp= roductive.  


>> There is another solution. Move users to a separate domain from th= e domain

Long ago we put users on our org domain as a way to unify users (in a very = decentralized institution) under a single domain identity, and that brandin= g decision is not going to be undone, politically.  Any project to mov= e users from one domain identity to another is a huge lift; it takes a lot of time, effort, and never actually complet= es due to stragglers with very legitimate reasons to not give up sending fr= om their old address. 

I implemented for an Enterprise with large ecommerce/social sites and = 20k seats. The only people that were allowed to keep accounts on the primar= y domains were people who directly supported the websites and they were not= allowed to use those accounts for anything other than supporting the websites. They had accounts at the othe= r domain just as all the other users.

I think that end-users would rather see their list mail be rewritten than b= e told to change their identity.  I know that some people on this list= think that the domain in the from header isn't commonly visible anymore, b= ut the domain is extremely important to users' sense of identity. 

Their identity at that organization is subject to the determinations o= f the organization. It is amazing how quickly after a one time transition t= hat users get used to  their new "identity".


>> your transactional mails are sent from. You can also put users on = a
>> separate subdomain.

To the idea of clean separation:  We only encourage (without DMARC the= re is no way to enforce) subdomains for transactional email despite "b= rand minded" people insisting on using the org domain (or just using i= t without asking).  Despite everyone having an address in the org domain, we still have many users using legacy subdomain= s, and some of those subdomains are mixed-use. 

You need buy-in from senior management for any email authenticati= on efforts. When you add up the costs of customer support contacts for deal= ing with fraudulent email claiming to be from your organization, reput= ation damage, etc., management becomes more willing to buy into a comprehensive strategy.

DMARC is great for getting visibility on this "separation" proble= m.  It's not until we moved past p=3Dnone that we could get any sticks= behind our carrots. 

What I'm saying is that mixed-use domains are common and they proliferated = due to the lack of domain alignment enforcement prior to DMARC.  Even = when there is intention by IT to separate the use cases, they need DMARC to= get both the visibility and the manageability/enforcement.

If it is only IT pushing this, you are probably doomed to failure.
 

I've observed other universities using their single org domain for everythi= ng, and they don't find out they have a problem until they try to implement= DMARC.  It's easier for them to move the transactional email to subdo= mains than to move users.  That is, unless they just give up on the idea of DMARC altogether.

Organizations make choices based on perceived benefits and costs.=  

This might be a stretch, but I think the "DMARC is different for user = vs transactional domains argument" dovetails with the need for sp to w= alk the domain tree.  If the assertion is that the domain with users i= s fundamentally different than domains used for transactional email, and most institutions use their org domain for their = users, and subdomains are a mixed bag of varying use cases, then the org do= main's DMARC policy isn't the best candidate for inheritance. 

The assumption was/is that the organizational domain most closely= tracks the risk for abuse and is therefore the one that most needs protect= ion. Therefore inheritance should be the rule rather than the exception. It= also means you don't have to walk the full tree. You only need to check the base domain if the subdoain doe= sn't specify a policy.


> Yet another solution would be to not use DMARC.  The status quo a= nte.
>
> While p=3Dnone is a technically valid position, there seems to be a > demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/

I don't think DHS got the memo about misdeploying DMARC, either.  I kn= ow that around 2018, the person maintaining the MLM for our astrophysics ce= nter had to scramble to implement header munging because of all of the ..go= v's publishing p=3Dreject

The .gov space has an interesting and long history with regard to emai= l authentication. In 2011, Pat Peterson (Agari) and I were asked by EOP (Ex= ecutive Office of The President) to create and give training on email authe= ntication for .gov that was turned into a virtual training environment that was available for all government = employees. The specific impetus were a series of incidents that included fa= ke malicious White House ecards purporting to be online Christmas card= s that were sent to government contractors and others. Required authentication for .gov domains moved forward in fits= and starts up to the point of the DHS mandate. DHS approached the use of D= MARC and authentication as a blunt one size fits all instrument.

The reality is that the devil is always in the details.

Michael Hammer
--_000_BY5PR13MB2999AD95B4BD7C80971FDA4FD7490BY5PR13MB2999namp_-- From nobody Fri Aug 7 12:12:23 2020 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 927D73A0F62 for ; Fri, 7 Aug 2020 12:12:22 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=lfyLUQc1; dkim=pass (2048-bit key) header.d=taugh.com header.b=f7zgiNw2 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 MNddwQfH2HCR for ; Fri, 7 Aug 2020 12:12: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 75CA53A0DF1 for ; Fri, 7 Aug 2020 12:12:18 -0700 (PDT) Received: (qmail 29330 invoked from network); 7 Aug 2020 19:12:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7289.5f2da791.k2008; bh=agUfAqjpYzvGEbSha6L6els3qldwMXbpXCrSYF/qC+U=; b=lfyLUQc16eauzYSaD2+DXJMGoKXnfGJpW1ShJCO+hL7v7LNqiQH18iD7xcMS7Xjtxi8k0AcUbA50EvsyDeufZv6vrKhB3v5UW9xNNemXzHytdlrrwFyWxtKoJxqjiAFCFEii1FfRSZtaiwM+gY9l3MXYPNC1NO6bEV5btzuYa8extBR2FcYuKcKQu4ApFKvdETromXMxEuG3llwE9U4BssAJ1GJOywAV3Q11oTmYbAnDYOiQBrKkfE2g1QI5NZfDkNVz2gxje1iIQovMeqpTxbhyEtOm7PyI1fOu+NW/6U7/P5J3Dc2Vto6RVZfQdDR3J2V+DXaCqSof3wbPxa51Xw== 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=7289.5f2da791.k2008; bh=agUfAqjpYzvGEbSha6L6els3qldwMXbpXCrSYF/qC+U=; b=f7zgiNw204PgU8ryDthPEACHR14nVNZQuP8jy1BrZQvyi44wRQ27GskhvNA6UkR9Cb5msYcbcCR3rc43VozHP+6yU1Nl3QC4RBdT2MHJg25LVq4AYC5cO8anCwMCOydhCUU+0ukb5rTUPX0cy4j8HVEKFhWwlyxCgeqZZwasp3/8b/mKNZOEw+Mi4CPdG3tYYzTzfhsJGCtb5anpur5vg7M8ZYzujsqkg5RIcY8vCw09esI25WvlTUvvu8maIh7LwN7VtoHzZqMtPMlvKBFtaaJ8s2iI5pue3pKjDHmZMTP3kCP75FeJGykyxdNR4njm0t4Ag5Nxhb/p9OC0wtSgJw== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Aug 2020 19:12:16 -0000 Received: by ary.qy (Postfix, from userid 501) id 43E971E4014E; Fri, 7 Aug 2020 15:12:16 -0400 (EDT) Date: 7 Aug 2020 15:12:16 -0400 Message-Id: <20200807191216.43E971E4014E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: atyrsalvia@agari.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 19:12:23 -0000 In article you write: >I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a >more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to >stop because it might make things a little inconvenient. I was with you up until that sentence, since it trivializes the real problems that overly strict DMARC policies cause. Just yesterday I was sorting out a problem with people trying to finish editing a revised IETF standard about real-time web applications. Some of the authors' messages were disappearing, apparently at random. I saw what the problem was, one of the authors is at a big company whose IT department insists on p=reject (and has blown off complaints from fairly senior people about the problems it causes), the other uses an MIT alumni address that recently moved its hosting to Microsoft without telling anyone that the new host enforces DMARC policy while the old one didn't. My guess is that MIT figured Microsoft will host this for free, that's great, totally unaware that some of its users' mail would silently break. I told them as a workaround they needed to directly cc each other when they send anything to the group list, but the whole thing is a self-inflicted wound. R's, John From nobody Fri Aug 7 16:16:22 2020 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 512193A077E for ; Fri, 7 Aug 2020 16:16:20 -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, 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 M72qGRFYwU_O for ; Fri, 7 Aug 2020 16:16:18 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 F226C3A0768 for ; Fri, 7 Aug 2020 16:16:17 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id a21so1532575vsh.11 for ; Fri, 07 Aug 2020 16:16:17 -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=3pyHbBESCzWoSV0ihR2f09riJVgT+f8VAnhqPdh+J1U=; b=rJcTHwL609GmK5fk8xS8pTpr6FR/VCUuzs/edTsKJZ4IBU65gPR5mFq2KiSz6EnBpI yYtt4EMFgBKxtZ2Q42uMaSsigr+fznrjr7QFmIJli3E3HP2JjldwTlq4wH5IP+sTJyEk 394J8L7VvoYcufKFCQyjfHdSvLIokedwk+ngtkEwICzuwcMdR1+C9xfX6I3efO6S2RtE Iif/n+1eNXuotdsE9LEkynkY6NT8fQCQyYH+Y6PWktYOBBOLLroARCPc4dXWcemb41IN YrtYGhDV8Ci66+cTY+C3kt08fEGt22s0gU4MZr/8WXJQwIKHssarCRLnqvYn3yKFuKuJ lMzg== 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=3pyHbBESCzWoSV0ihR2f09riJVgT+f8VAnhqPdh+J1U=; b=tZkbsPvf886OXGHPctYlS0ZUMBPshMvMI3mfNg1nFQicVjzYqoSJxgp9wRjZnEsttJ gifFviyttMsQZsc6MEaa7xaMI2Y0Mje6CmIjjSbGXc52w5+/D+G61x7V2NRW3PO9K4Au iL2/SuRvtNezjN9dryfqvhacKpx0n6wKRH2mxQoEc0+u/P2XaidYd66Qc7M67cc5hTQj Smms5c5Yq/B5mZtYHYxYzPRRmKz9hrhp2+vJQZC0Gd81tzdQIcUqQzZtdts4yJqx6mqT vg0frLpV9U2Cq36s0+HTSFL2a//bUGya3Mlwar25n4b5g5ALtrQqMRH3dXsZwRo+lkJy LtHw== X-Gm-Message-State: AOAM533AbDqU3mwuwv8Q9ez8GBBURKHIRB1CHZsI8QVsw1dgyEWCJOin PoRQFzcfE9J81llY8QCjUUHUL5Bb68x6xwE3cDGavA== X-Google-Smtp-Source: ABdhPJzwoEKwxR55yJ0P1IecdaCV83SkIDmXvrppcOdE87uZlHuQVDon2dzwQaNcfj4Vs+lHdFNHTsAYWyY4NKYPCEU= X-Received: by 2002:a67:eb91:: with SMTP id e17mr12073789vso.7.1596842176775; Fri, 07 Aug 2020 16:16:16 -0700 (PDT) MIME-Version: 1.0 References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> In-Reply-To: <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Fri, 7 Aug 2020 16:16:02 -0700 Message-ID: To: Doug Foster Cc: Dave Crocker , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b58b4405ac51ca29" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 23:16:20 -0000 --000000000000b58b4405ac51ca29 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > Murray took server too literally. I have expressed before that a system > could do a sender authentication lookup on List-ID as easily as on From. > In this respect, it is similar to Dave's proposal, without the added > complexity of additional identifiers. So think "Registerd List-ID plus > DKIM signature (or SPF, but DKIM seems both sufficient and preferable.) > If we take "server" to mean a tuple made up of a List-ID value and a "d=" value from a validated DKIM signature, which I believe is what you're saying here, the first occurrence of this necessarily has no internal value (or history) attached to it. That means the operator has to develop meaning for it over time, which doesn't tell it how to handle the first N such messages. Err on the side of openness and you have a spam or attack vector; err on the side of defense and you irritate your users by denying them some list traffic until a reputation can develop. And it's probably actually a three-tuple, with the third part being the recipient. Otherwise, I could register (or trigger the auto-registration of) any two-tuple I want and thus intentionally let in my preferred list streams, good or bad, which affects every other user. Plus, you're trusting users to get this right. For a manual registration scheme, every time they get it wrong by entering the wrong data or failing to even do it at all, you've got a failure mode to deal with, usually in the form of user complaints which require other humans to resolve. That makes it relatively expensive. And finally, lists change once in a while, maybe to a new signing domain, maybe to a new name, maybe both. Every time that happens, the process has to start over. Naturally lists won't want to do this because of the sterling reputations they've developed, but the pain reappears whenever the process needs to be repeated for whatever reason. I'm not saying such a system can't or won't work. I'm also not saying I have a better idea. I am saying there's multi-faceted pain in every direction in this space, and this is no exception. Whatever path we choose to deploy here has to account for those choices and their side effects, and the ways they might be gamed. I am not sure what "Internet Scale" means to you. Most of the major > recipients have bulk mailer registration systems. It does not guarantee > whitelisting, but it tends to produce that effect. I have had occasion to > register with most of them. So "does not scale" is not obvious to me. > "Internet Scale" means millions or billions of users, like GMail or Yahoo or AOL or Microsoft have. Since they have the bulk of the inboxes, a solution needs to at least consider that size of use case, or explain why those cases don't need to be considered. I've never seen this manual registration process to which you refer. Where can I find it, for example, on GMail? Even more to the point, check out this link: > > https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto > > > Verizon appears to be offering a service (probably for extra cost) which > is based on: > (a) a well-defined mail stream from a known sender, and > (b) a mailbox user identifying that mail stream as subscribed, and > therefore desirable. > > It appears that the target senders are retailers who want to ensure that > their sale announcements are read before the sale is over. It is an > "Internet scale" application of the type of registration I was suggesting: > Well-identified senders, coupled with end-user endorsement, receive > preferred treatment. > Is there a technical description someplace of the mechanism behind what they're doing? As to the transparency question, it should be clear that there will be no > simple solution to the ML problem. > Indeed. [...] But the only way to establish an acceptable reputation is to either > register with the receiver directly, or register with the sender in a way > that the receiver will honor. > This needs to scale, from both ends: 1) If I as a new list operator want my list traffic to get accepted, how could I possibly go about registering with all (or even most) mailbox providers in a way they will trust? 2) If I as a mailbox provider want to give my users quality service and also spam filtering, what way can I offer list operators to identify themselves that can't be spoofed, and will only be exploited by good actors? Putting this burden on my users doesn't feel tenable. -MSK --000000000000b58b4405ac51ca29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 2, 2020 at 5:44 PM Douglas E.= Foster <fosterd@bayvie= wphysicians.com> wrote:
Murray took server too literally. =C2=A0 I have express= ed before that a system could do a sender authentication lookup on List-ID = as easily as on From. =C2=A0 In this respect, it is similar to Dave's p= roposal, without the added complexity of additional identifiers. =C2=A0 So = think "Registerd List-ID plus DKIM signature (or SPF, but DKIM seems b= oth sufficient and preferable.)

If we take "server" to mean a tuple made up of a List-ID value a= nd a "d=3D" value from a validated DKIM signature, which I believ= e is what you're saying here, the first occurrence of this necessarily = has no internal value (or history) attached to it.=C2=A0 That means the ope= rator has to develop meaning for it over time, which doesn't tell it ho= w to handle the first N such messages.=C2=A0 Err on the side of openness an= d you have a spam or attack vector; err on the side of defense and you irri= tate your users by denying them some list traffic until a reputation can de= velop.

And it's probably actually a three-= tuple, with the third part being the recipient.=C2=A0 Otherwise, I could re= gister (or trigger the auto-registration of) any two-tuple I want and thus = intentionally let in my preferred list streams, good or bad, which affects = every other user.

Plus, you'r= e trusting users to get this right.=C2=A0 For a manual registration scheme,= every time they get it wrong by entering the wrong data or failing to even= do it at all, you've got a failure mode to deal with, usually in the f= orm of user complaints which require other humans to resolve.=C2=A0 That ma= kes it relatively expensive.

And finally, lists change o= nce in a while, maybe to a new signing domain, maybe to a new name, maybe b= oth.=C2=A0 Every time that happens, the process has to start over.=C2=A0 Na= turally lists won't want to do this because of the sterling reputations= they've developed, but the pain reappears whenever the process needs t= o be repeated for whatever reason.

I'm not say= ing such a system can't or won't work.=C2=A0 I'm also not sayin= g I have a better idea.=C2=A0 I am saying there's multi-faceted pain in= every direction in this space, and this is no exception.=C2=A0 Whatever pa= th we choose to deploy here has to account for those choices and their side= effects, and the ways they might be gamed.

I am not sure what "Internet Scale" means to= you. =C2=A0 Most of the major recipients have bulk mailer registration sys= tems. =C2=A0 It does not guarantee whitelisting, but it tends to produce th= at effect. =C2=A0 I have had occasion to register with most of them. =C2=A0= So "does not scale" is not obvious to me.

"Internet Scale" means millions or billions= of users, like GMail or Yahoo or AOL or Microsoft have.=C2=A0 Since they h= ave the bulk of the inboxes, a solution needs to at least consider that siz= e of use case, or explain why those cases don't need to be considered.<= br>

I've never seen this manual registration p= rocess to which you refer.=C2=A0 Where can I find it, for example, on GMail= ?

Even more to the poi= nt, check out this link:
=

Verizon appears to be offering a service (probably for = extra cost) which is based on:
(a) a well-defined mail stream fro= m a known sender, and=C2=A0
(b) a mailbox user identifying that m= ail stream as subscribed, and therefore desirable.

It appears that the target senders are retailers who want to ensure that t= heir sale announcements are read before the sale is over. =C2=A0 It is an &= quot;Internet scale" application of the type of registration I was sug= gesting: =C2=A0 Well-identified senders, coupled with end-user endorsement,= receive preferred treatment.

I= s there a technical description someplace of the mechanism behind what they= 're doing?

As to the t= ransparency question, it should be clear that there will be no simple solut= ion to the ML problem.

Indeed.<= /div>
[...] But the only way to establish an= acceptable reputation is to either register with the receiver directly, or= register with the sender in a way that the receiver will honor.

This needs to scale, from both ends:

1) If I as a new list operator want my list = traffic to get accepted, how could I possibly go about registering with all= (or even most) mailbox providers in a way they will trust?

2) If I as a mailbox = provider want to give my users quality service and also spam filtering, wha= t way can I offer list operators to identify themselves that can't be s= poofed, and will only be exploited by good actors?=C2=A0 Putting this burde= n on my users doesn't feel tenable.

-MSK
--000000000000b58b4405ac51ca29-- From nobody Fri Aug 7 17:24:41 2020 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 7344A3A0A69 for ; Fri, 7 Aug 2020 17:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 WuxtgNAyZw7m for ; Fri, 7 Aug 2020 17:24:39 -0700 (PDT) Received: from wmauth1.doit.wisc.edu (wmauth1.doit.wisc.edu [144.92.197.141]) (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 05D313A07FB for ; Fri, 7 Aug 2020 17:24:38 -0700 (PDT) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08lp2174.outbound.protection.outlook.com [104.47.73.174]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QEP00ABVYH1SY30@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 07 Aug 2020 19:24:37 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-1, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.8.1518, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.73.174] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G7CC2h2XSN1EHrB5KEDREjDwKcH+PJxgW/H0NzvYTI2hHQHS5371RED/KUHmQJiJeIrRBfNQzKOj+jpthdgNpkkj6/6nygtTSVhglDqz0V6Y2spOd/uyk9Ric3Tm38PVxde/cJ/iMcj1pT1Re2lS+EpQ+qLKqs6GyqA8WxAAt4Mrzq3LXKnIcA2Am3+yu89wxYkBD9mXarZIeMo8DbmkNGepwpzlg2sYl5opqVCnbROMIr20de+PnlVplIM7hO4Hho+tcs+TuDf7+D9cbwo0kVmzHPKI7rLX8dV/3uYP9yZ66nnljsswe4PFaRKRHo0wiSyUU3gh0TykPnNgKlIvRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9VyYVayHZc/cGwTDpomq/kI8BkDmk4TgZ68XoOosdws=; b=QJwLcZhBrvkFOn03LUQCYtpCf8mz4aPzwkTr3++p20SvgH34Mwkor3favnb0loHmN/rW2ezfEoetleeuvPLZeiiyjDtuTbtTqt0zH2GHg8ZGpFo20dwPouPE9Sf3PEy4yNUb3XdLzHVQj8sleEDuWQN0yahb1yNL4nolKRRT+ycM5I3CQ6ulcMtYV1WorIqkRi7RAjE1R0lyhqIHpqHvkzmVyobehSoE3be+qEy9s5LFW7hNtxmuFfsGXMLmKozH4EZOZYi0Smb9LlShdDA+2ZG/26NDu+ROH/y/fhC+2LDgTGVkDOTKczuNEGdaWWfpNoXgUcIf7bdNm2lba1eWvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9VyYVayHZc/cGwTDpomq/kI8BkDmk4TgZ68XoOosdws=; b=N5ZjeTg3uXVI2n9ztvZ2Fg7lralY0JbKMP85FEzqiMYwDLZbkRHgJBX8fDX4jHHrEBWg3FQ+RV1IkaMu/yr1XAbvmmjecUCdoSjqp0K9/PLa5wVw+Ri7qmF5ePUnFB1BH9Eg3IDt9wqzfUwkZbqsDS4UG21uCLzWiHnhh9hzrf4= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB4396.namprd06.prod.outlook.com (2603:10b6:5:22::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.20; Sat, 8 Aug 2020 00:24:36 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::a92c:9a15:1bb0:4bfa%7]) with mapi id 15.20.3239.024; Sat, 8 Aug 2020 00:24:36 +0000 To: dmarc@ietf.org References: <20200807191216.43E971E4014E@ary.qy> From: Jesse Thompson Message-id: <78fd8b26-0bed-ac36-842d-a851ec04d8b5@wisc.edu> Date: Fri, 7 Aug 2020 19:24:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: <20200807191216.43E971E4014E@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR05CA0067.namprd05.prod.outlook.com (2603:10b6:610:38::44) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR05CA0067.namprd05.prod.outlook.com (2603:10b6:610:38::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.6 via Frontend Transport; Sat, 8 Aug 2020 00:24:35 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 4d686448-23f2-4b83-8a96-08d83b316e09 X-MS-TrafficTypeDiagnostic: DM6PR06MB4396: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JSJq/DOPRyHzaz30mAxmeE/IZwYUAJ/vd5pPgGr+XBfTxdimlDB9D1mcy1UWm4gC3qO+/R5Cl3LE05qaI/8ccXaRj48MBT1Q+qQbJFudVl/gJ/DJGsLUmxdwmdakQZsNSBlOyx6Q/TL0e56nhsVQooyEekOkR6o0z+WET7kzOJArxey8N+oGZ9s/LVdwzOKo1vPKHZoibPYd8kQHiyaTNG84MKib7Oh6XfEIvqxIeQ0cO7eWwEP1jxZEdAMOu1U2MwJHz9mXUboMDvxDTOUzrfpNa48VzuCqr9KK6K09coG1bQ5VIkKMYMWKC9Osza0qwDEl2PUmlIXn0YNu3OQ4/Wy51b8wlXktResj7HwJdzPRMXTo7mqfO0hChJk0+WL2aibCMKliK65rfoFBfJU01js4wVfTo4dIf5FA5OFWCrkBFHveWJsbv1u55lNKUXqiPZtQYL/01XI5yb/CQ809eP/6rcHACBcOBzj/Ow0goyE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(39860400002)(376002)(136003)(366004)(396003)(45080400002)(6486002)(2616005)(6706004)(75432002)(2906002)(5660300002)(31686004)(8676002)(186003)(16526019)(26005)(6916009)(53546011)(478600001)(66476007)(66946007)(44832011)(16576012)(956004)(86362001)(786003)(31696002)(316002)(8936002)(6666004)(36756003)(66556008)(83380400001)(3940600001)(43740500002)(130980200001)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Q1Zm7mmfkO+C3aiYNKRfvT88yfZoFsobfn6P0aD3rmdvPMq0KMd2YaMPP+DGIS0j8xD3YC1Rf05JjCdXpJc2xYAzYC2ffHdl7kLj37Sn/O0V2KBr8zwVllFoQWFPmUET3xWTIMMe6m6Q5wMN6qKSivBcBJ1qaHV9+PCPqp1e3tDY/iBt68gWqEXzVAF8SGRkl/q4KygvoIUBp/xginD2weGK+9VVFbShzZINO2AwEpcXpC5Ml3R0OkUhwCG7vDVSXcQpPHbf4bTq0Xd5YisLlRBYW8diUhvbBRnUlZdG8GnpNbQohtFBVMUJNO38A6zaiuptTkwGcfdATSRl1w4OtHue+mZg0TIZGgBozuw5lm866tQIqs0Qe2Q3VM0jrb6gqIDEkUGGYlHulwZVmCnlKD8DNuJw9OWKBhvmYLhhCbluwp3Rqvg9z/OKHeHs/0dlpDqwcd3+XhgySXpyzxHVeuvkAJQkmdIqSwJJHQ7K1new0HUIhQaM4IK/cMpyQ1PLKu7ivTpaH9oDAt7AVfh7iSz4kob52HHGYobaoxaVbsrfw0OY4DEpLERRgHEo4zy2B0tQAV3T24WGveudFMOHnFi8xeMP/1/N/f9fztP6tjcTVZKaER3e3647i+4e18tk8Wc9itPy4OxtXB5CUzvrYg== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 4d686448-23f2-4b83-8a96-08d83b316e09 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2020 00:24:35.9529 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: lov2WmgsPfTGatPwmOmR/enuXlAq0wgQj675QhwxWHIuVFHgW+rTWWMYimT/WungL3sB9mvEXJMgi5abSf+xKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4396 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 00:24:40 -0000 On 8/7/20 2:12 PM, John Levine wrote: > In article you write: >> I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a >> more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to >> stop because it might make things a little inconvenient. > > I was with you up until that sentence, since it trivializes the real > problems that overly strict DMARC policies cause. Maybe Autumn was reflecting the reality that the industry has already trivialized DMARC problems for these "misdeployments". > Just yesterday I was sorting out a problem with people trying to > finish editing a revised IETF standard about real-time web > applications. Some of the authors' messages were disappearing, > apparently at random. I saw what the problem was, one of the authors > is at a big company whose IT department insists on p=reject (and has > blown off complaints from fairly senior people about the problems it > causes), the other uses an MIT alumni address that recently moved its > hosting to Microsoft without telling anyone that the new host enforces > DMARC policy while the old one didn't. > > My guess is that MIT figured Microsoft will host this for free, that's > great, totally unaware that some of its users' mail would silently > break. Customers of Microsoft don't like to call things bundled in an expensive package "free". My peeve in recent years is that universities were essentially coerced (economically) into being the customers of Microsoft/Google and then the email admins are told to sit down and let the adults talk about what they think customers need from DMARC, ARC, etc. It's why I'm constantly sticking my foot in my mouth here and M3AAWG; trying to assert a voice. We need faculty/alumni/emeriti forwarding to work without being told that Microsoft can't do it without breaking DMARC. We need spoofing protection for all of our domains without being told we're misdeploying. We know that we need advanced local policy controls for DMARC enforcement and we don't want to be blamed when the vendor doesn't give us those controls (to your MIT example) > I told them as a workaround they needed to directly cc each other when > they send anything to the group list, but the whole thing is a > self-inflicted wound. Maybe it was inflicted by the domain owner onto the person maintaining the mailing list. (In my experience, this is where people realize that no one has been maintaining/patching the mailing list, unaware of DMARC, etc.) Again, I think MLM header munging is here to stay, and list recipients needs to get used to it (I'd like p=quarantine pct=0 be the default behavior so that domains choosing to misdeploy DMARC aren't second class). I'd like to see a way to un-munge mail from trusted intermediaries, but that sounds impractical. I think ARC has promise but it has some challenges that I hope can be overcome; notably a mechanism for the receiver to indicate trust to the intermediary (so that it knows it doesn't need to munge). At that point, I can start to figure out how to deal with the mailbox-level forwarded mail for faculty/alumni/emeriti... Jesse From nobody Fri Aug 7 18:36:41 2020 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 418423A07CC for ; Fri, 7 Aug 2020 18:36:40 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZU8t2f3ZJEv for ; Fri, 7 Aug 2020 18:36:38 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78BD3A07CA for ; Fri, 7 Aug 2020 18:36:37 -0700 (PDT) X-ASG-Debug-ID: 1596850595-11fa311da645720001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id lyAFVGWMKtC7555V (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 07 Aug 2020 21:36:35 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=IuGncsRG1u1HIQQ1Qe9DSREdoZq4E486JPnZFRWZ644=; b=Gw2+QXv4WkrAMDCedj+b3eighRdMT0uwlK+2zSH7ShbQUxFt9H3UgtcyjNL+uLiZO VYzXVDtmSeibuk0AgmtRsndXoWPof5G2x6QOeyjXj3Q05AgdEX35PGtSjj1+GSvNQ QMP6V+mXeQ2W+8foQYb1meulkdt4OUxFq83s4Wv4M= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 08 Aug 2020 01:36:27 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: <10c441a53dec4277a3153ed8d89d35d8@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=0b69153aec954dcaaad39e3297005b01 In-Reply-To: References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> X-Exim-Id: 10c441a53dec4277a3153ed8d89d35d8 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1596850595 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 17017 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83771 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 01:36:40 -0000 This is a multipart message in MIME format. --0b69153aec954dcaaad39e3297005b01 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Murray, I have most recently used this link at AOL/Yahoo: https://postmas= ter.verizonmedia.com/sender-request I have considered using the more complete "Complaint Feedback Loop", https:= //postmaster.verizonmedia.com/cfl-request but have never completed the pro= cess. Maybe they are the last to offer this type of feature. Or maybe my memory = is imagining things Now that you have pressed me, I cannot remember wheth= er I have had success with other services or not. My heart is not in prior registration either, but I was trying to lay out t= he next-best alternative for those who want an alternative to using the MLM= domain identity. The goal of DMARC is to end spoofing, which requires everyone to send using= their own domain, even when performing a favor for someone in another doma= in. A recipient domain owner has the right to define the rules for gettin= g into its network. Those who want into that network should play by the = rules of that network, whether the rules are liked or disliked. An incoming email is a take-it-or-leave-it proposition for most recipients.= My domain does not have the market power to alter sender behavior. Whe= n I receive a spoofed message that the recipient actually wants, I end up c= reating an exception to allow the spoof. Spoofing senders are counting on= their ability to force me to do that. However, Microsoft is powerful eno= ugh to engage in a standoff. Those who want to send to Microsoft destina= tions will need to not violate DMARC. I hope and expect that they will wi= n this battle. DMARC is not new. Products that have not become DMARC-aware are as obsole= te as WindowsXP. Unfortunately, that does include a lot of products. Over a year ago, I was about to recommend Proofpoint as our new email filte= ring vendor. But the next morning I realized that their secure email serv= ice will spoof the identity of non-clients when they respond to a message f= rom a client. I had a real problem with a vendor promoting their ability = to enforce DMARC on incoming mail, while also violating DMARC on their secu= re email service. Then I saw that Cisco Ironport did the same thing. I = raised CIRT issues with both vendors, but nothing has changed. Maybe Micr= osoft will be able to change their attitudes. DF ---------------------------------------- From: "Murray S. Kucherawy" Sent: 8/7/20 7:16 PM To: Doug Foster Cc: Dave Crocker , IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster wrote: Murray took server too literally. I have expressed before that a system c= ould do a sender authentication lookup on List-ID as easily as on From. I= n this respect, it is similar to Dave's proposal, without the added complex= ity of additional identifiers. So think "Registerd List-ID plus DKIM sign= ature (or SPF, but DKIM seems both sufficient and preferable.) If we take "server" to mean a tuple made up of a List-ID value and a "d=3D"= value from a validated DKIM signature, which I believe is what you're sayi= ng here, the first occurrence of this necessarily has no internal value (or= history) attached to it. That means the operator has to develop meaning f= or it over time, which doesn't tell it how to handle the first N such messa= ges. Err on the side of openness and you have a spam or attack vector; err= on the side of defense and you irritate your users by denying them some li= st traffic until a reputation can develop. And it's probably actually a three-tuple, with the third part being the rec= ipient. Otherwise, I could register (or trigger the auto-registration of) = any two-tuple I want and thus intentionally let in my preferred list stream= s, good or bad, which affects every other user. Plus, you're trusting users to get this right. For a manual registration s= cheme, every time they get it wrong by entering the wrong data or failing t= o even do it at all, you've got a failure mode to deal with, usually in the= form of user complaints which require other humans to resolve. That makes= it relatively expensive. And finally, lists change once in a while, maybe to a new signing domain, m= aybe to a new name, maybe both. Every time that happens, the process has t= o start over. Naturally lists won't want to do this because of the sterlin= g reputations they've developed, but the pain reappears whenever the proces= s needs to be repeated for whatever reason. I'm not saying such a system can't or won't work. I'm also not saying I ha= ve a better idea. I am saying there's multi-faceted pain in every directio= n in this space, and this is no exception. Whatever path we choose to depl= oy here has to account for those choices and their side effects, and the wa= ys they might be gamed. I am not sure what "Internet Scale" means to you. Most of the major recip= ients have bulk mailer registration systems. It does not guarantee whitel= isting, but it tends to produce that effect. I have had occasion to regis= ter with most of them. So "does not scale" is not obvious to me. "Internet Scale" means millions or billions of users, like GMail or Yahoo o= r AOL or Microsoft have. Since they have the bulk of the inboxes, a soluti= on needs to at least consider that size of use case, or explain why those c= ases don't need to be considered. I've never seen this manual registration process to which you refer. Where= can I find it, for example, on GMail? Even more to the point, check out this link: https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing= -relevance-performance-through-vto Verizon appears to be offering a service (probably for extra cost) which is= based on: (a) a well-defined mail stream from a known sender, and (b) a mailbox user identifying that mail stream as subscribed, and therefor= e desirable. It appears that the target senders are retailers who want to ensure that th= eir sale announcements are read before the sale is over. It is an "Intern= et scale" application of the type of registration I was suggesting: Well-= identified senders, coupled with end-user endorsement, receive preferred tr= eatment. Is there a technical description someplace of the mechanism behind what the= y're doing? As to the transparency question, it should be clear that there will be no s= imple solution to the ML problem. Indeed. [...] But the only way to establish an acceptable reputation is to either r= egister with the receiver directly, or register with the sender in a way th= at the receiver will honor. This needs to scale, from both ends: 1) If I as a new list operator want my list traffic to get accepted, how co= uld I possibly go about registering with all (or even most) mailbox provide= rs in a way they will trust? 2) If I as a mailbox provider want to give my users quality service and als= o spam filtering, what way can I offer list operators to identify themselve= s that can't be spoofed, and will only be exploited by good actors? Puttin= g this burden on my users doesn't feel tenable. -MSK --0b69153aec954dcaaad39e3297005b01 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Murray, I  ha= ve most recently used this link at AOL/Yahoo:  https://postmaste= r.verizonmedia.com/sender-request 

I have= considered using the more complete "Complaint Feedback Loop", https://p= ostmaster.verizonmedia.com/cfl-request  but have never completed t= he process.

Maybe they are the last to offer this = type of feature.  Or maybe my memory is imagining things   Now th= at you have pressed me, I cannot remember whether I have had success with o= ther services or not.

My heart is not in prior reg= istration either, but I was trying to lay out the next-best alternative for= those who want an alternative to using the MLM domain identity.   &nb= sp;

The goal of DMARC is to end spoofing, which re= quires everyone to send using their own domain, even when performing a favo= r for someone in another domain.   A recipient domain owner has the ri= ght to define the rules for getting into its network.    Those wh= o want into that network should play by the rules of that network, whether = the rules are liked or disliked. 

An incoming= email is a take-it-or-leave-it proposition for most recipients.   My = domain does not have the market power to alter sender behavior.   When= I receive a spoofed message that the recipient actually wants, I end up cr= eating an exception to allow the spoof.   Spoofing senders are countin= g on their ability to force me to do that.   However, Microsoft i= s powerful enough to engage in a standoff.    Those who want to s= end to Microsoft destinations will need to not violate DMARC.   I hope= and expect that they will win this battle.

DMARC = is not new.   Products that have not become DMARC-aware are as obsolet= e as WindowsXP.   Unfortunately, that does include a lot of products.<= /div>

Over a year ago, I was about to recommend Proofpoi= nt as our new email filtering vendor.   But the next morning I realize= d that their secure email service will spoof the identity of non-clients wh= en they respond to a message from a client.   I had a real problem wit= h a vendor promoting their ability to enforce DMARC on incoming mail, while= also violating DMARC on their secure email service.   Then I saw that= Cisco Ironport did the same thing.   I raised CIRT issues with both v= endors, but nothing has changed.   Maybe Microsoft will be able to cha= nge their attitudes.
DF


<= br>

Fro= m: "Murray S. Kucherawy" <superuser@gmail.com>
Se= nt: 8/7/20 7:16 PM
To: Doug Foster <fosterd= @bayviewphysicians.com>
Cc: Dave Crocker <dcrocke= r@bbiw.net>, IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header doma= ins
On Sun, Aug 2, 2020 at 5:= 44 PM Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:
Murray took server too = literally.   I have expressed before that a system could do a sender a= uthentication lookup on List-ID as easily as on From.   In this respec= t, it is similar to Dave's proposal, without the added complexity of additi= onal identifiers.   So think "Registerd List-ID plus DKIM signature (o= r SPF, but DKIM seems both sufficient and preferable.)

If we take "server" to mean a tuple made up of a Li= st-ID value and a "d=3D" value from a validated DKIM signature, which I bel= ieve is what you're saying here, the first occurrence of this necessarily h= as no internal value (or history) attached to it.  That means the oper= ator has to develop meaning for it over time, which doesn't tell it how to = handle the first N such messages.  Err on the side of openness and you= have a spam or attack vector; err on the side of defense and you irritate = your users by denying them some list traffic until a reputation can develop= .

And it's probably actually a three-tuple, with t= he third part being the recipient.  Otherwise, I could register (or tr= igger the auto-registration of) any two-tuple I want and thus intentionally= let in my preferred list streams, good or bad, which affects every other u= ser.

Plus, you're trusting users = to get this right.  For a manual registration scheme, every time they = get it wrong by entering the wrong data or failing to even do it at all, yo= u've got a failure mode to deal with, usually in the form of user complaint= s which require other humans to resolve.  That makes it relatively exp= ensive.

And finally, lists change once in a while, maybe= to a new signing domain, maybe to a new name, maybe both.  Every time= that happens, the process has to start over.  Naturally lists won't w= ant to do this because of the sterling reputations they've developed, but t= he pain reappears whenever the process needs to be repeated for whatever re= ason.

I'm not saying such a system can't or won't = work.  I'm also not saying I have a better idea.  I am saying the= re's multi-faceted pain in every direction in this space, and this is no ex= ception.  Whatever path we choose to deploy here has to account for th= ose choices and their side effects, and the ways they might be gamed.
=

I am not sure what "Internet S= cale" means to you.   Most of the major recipients have bulk mailer re= gistration systems.   It does not guarantee whitelisting, but it tends= to produce that effect.   I have had occasion to register with most o= f them.   So "does not scale" is not obvious to me.

"Internet Scale" means millions or billions of us= ers, like GMail or Yahoo or AOL or Microsoft have.  Since they have th= e bulk of the inboxes, a solution needs to at least consider that size of u= se case, or explain why those cases don't need to be considered.
=
I've never seen this manual registration process to which yo= u refer.  Where can I find it, for example, on GMail?

Even more to the point, check out this li= nk:

V= erizon appears to be offering a service (probably for extra cost) which is = based on:
(a) a well-defined mail stream from a known sender, and=  
(b) a mailbox user identifying that mail stream as subscri= bed, and therefore desirable.

It appears that the = target senders are retailers who want to ensure that their sale announcemen= ts are read before the sale is over.   It is an "Internet scale" appli= cation of the type of registration I was suggesting:   Well-identified= senders, coupled with end-user endorsement, receive preferred treatment.

Is there a technical description= someplace of the mechanism behind what they're doing?

=
As to the transparency question, it should be= clear that there will be no simple solution to the ML problem.
=

Indeed.

=
[...] But the only way to establish an acceptable reputation is to eit= her register with the receiver directly, or register with the sender in a w= ay that the receiver will honor.

Thi= s needs to scale, from both ends:

1= ) If I as a new list operator want my list traffic to get accepted, how cou= ld I possibly go about registering with all (or even most) mailbox provider= s in a way they will trust?

2) If I as a mailbox provider want to give my users q= uality service and also spam filtering, what way can I offer list operators= to identify themselves that can't be spoofed, and will only be exploited b= y good actors?  Putting this burden on my users doesn't feel tenable.<= /div>

-MSK
--0b69153aec954dcaaad39e3297005b01-- From nobody Fri Aug 7 19:27:48 2020 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 0E9F43A0B22 for ; Fri, 7 Aug 2020 19:27:47 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=vvpD3zZE; dkim=pass (2048-bit key) header.d=taugh.com header.b=X9y3N5Sk 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 BEIrVDnjq5Io for ; Fri, 7 Aug 2020 19:27:45 -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 44EC13A0B21 for ; Fri, 7 Aug 2020 19:27:44 -0700 (PDT) Received: (qmail 77768 invoked from network); 8 Aug 2020 02:27:44 -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=12fc5.5f2e0da0.k2008; bh=08AocNxjTQixfQ7hEQXpe15oEVuFyFoBclhDQdUxxME=; b=vvpD3zZEV5BgINGebSBFTY5IKy0tZz4BhyOZOGb6vwfeRbx1p/IJNATD+lndHXmF+fiiI5RZzsP4wYt0k19iHeIFtDw2jdxftG/HWiSK8elhDkrFBoYbu7XQ2k0mnPHuucaJx/6zUB80hPGvWxCLaeyAdW8z8W9V98Sm/JmWPtFms/Vt3xtUfNUjUKQqWZwSVFlW8ms13GBXJlLj591bThAKxCbEAEXb8mbFwFxp1nqBO1F9derKv6+Ng3IIpLRNKa1dWsFAssCeuiYumLMfNQKCWwuGytu0ZmuzLXyiryhw67+u8tbJXABBTVjmcWiIlo7T7vdJYgOS3bTP2jPUGQ== 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=12fc5.5f2e0da0.k2008; bh=08AocNxjTQixfQ7hEQXpe15oEVuFyFoBclhDQdUxxME=; b=X9y3N5SkgYFdghFLoJ9lYz/flEUaICV0Uo2VBqa1GNXOAAwCTZ2UgpZBMq2obT3JtWmpcGmFO1azJ0SpcTx6s/NQRmL5r7p526WZv+veueFZ2+g4UOtgXZXW6xWQY2UXXU6QlIvFJYquaoLsYvATfFPOUUNHsoKu7MPiyYseN22wlAvymXNvonEkb9UgRrQt8P4vkB8VGNJ7xleyTB3LgOhPaOPphDNIQ6cq/CIhAarZA2oi/G/O3bD/zyTosCgdk2EHB2ymoXGw9QwJZiBp73Z1UIc+wSXyaQe+v3Adtf8tfMtxoEcxqfeyEo2mBj4Dcd9zVWLAZqKo1+ZSkw7RrA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Aug 2020 02:27:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 216921E60BFF; Fri, 7 Aug 2020 22:27:43 -0400 (EDT) Date: 7 Aug 2020 22:27:43 -0400 Message-Id: <20200808022743.216921E60BFF@ary.qy> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <10c441a53dec4277a3153ed8d89d35d8@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 02:27:47 -0000 In article <10c441a53dec4277a3153ed8d89d35d8@bayviewphysicians.com> you write: >-=-=-=-=-=- > >Murray, I have most recently used this link at AOL/Yahoo: https://postmaster.verizonmedia.com/sender-request > >I have considered using the more complete "Complaint Feedback Loop", https://postmaster.verizonmedia.com/cfl-request >but have never completed the process. Complaint feedback loops just mean you say (perhaps with verification) that you're the contact for this range of IPs or domain names, and if a user presses the Junk button, the system can send you a copy of the report. It's not whitelisting, and it only covers about the first quarter inch of the long tail. Some years back people kept asking Spamhaus to set up a whitelist, so they hired me to do it. Technically it worked fine, but it soon became apparent that the only people who were interested weren't people who we'd want to whitelist. The good quality senders get their mail delivered already, the terrible ones didn't bother, and all we heard from were people who sometimes sent some spam along with the good mail but assured us they were nice people. (Many universities fall into this category.) I think you'll find that all of the existing whitelist like things are a sideshow to the company's real business of deliverability consulting. For DMARC, it would be nice if there were a shared list of credible forwarders, not to automatically accept their mail, but just to say they're good enough that you can believe what's in their ARC seals when you're doing the usual spam filtering. You can't just let people sign themselves up for a list like that, since every dodgy bulk mailer will figure this will get them an extra 2% delivery, and we've never gotten past a vague hope that we could canvass people we know to make a combined set of mailing lists hosts we know. R's, John From nobody Fri Aug 7 19:33:05 2020 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 066733A0B2C for ; Fri, 7 Aug 2020 19:33:03 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=eokVM2jd; dkim=pass (2048-bit key) header.d=taugh.com header.b=DipltzwT 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 RKbHkQTNR29Q for ; Fri, 7 Aug 2020 19:33:01 -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 5F0E33A0B26 for ; Fri, 7 Aug 2020 19:33:01 -0700 (PDT) Received: (qmail 79585 invoked from network); 8 Aug 2020 02:32:59 -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=136dd.5f2e0edb.k2008; bh=9GNbPpANwrJFxmuJZLprIeduD5VBM3ugAeo2OcOedEo=; b=eokVM2jdSgF9JXon88LPJ7njUpM8caeq0+S9GymL6N9IS9gpRbMIoA6mhWY71F0XCtBugQFDfE37KNViiIaEOotMa9PWk4D8WfXRERIRM2TY+CuLSElHj96z9N5oVhVFIcKiifLS+pC4WjzfJIH7maegdTvREcQLH9CwlztLDgcwXutk0qshZPkqTu+nht43v9eDwJCLjlrbfUc8MTFo+h4WTtiN3LmrPes3nUgTbIG34cKbttgOUik5opAkuszWXBThyDpmKDbXjBdM/BLad8cy/NOnPCSLPQu8DdgOoPbUZQb2JUfjiirpSAuh1o4urJ+GKqgzhkPtjuzBw+KvdQ== 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=136dd.5f2e0edb.k2008; bh=9GNbPpANwrJFxmuJZLprIeduD5VBM3ugAeo2OcOedEo=; b=DipltzwTRnXMr7eNzSxCqclvQJvIvcmIbM25fpx4dMtpI/1OUH51o78/3DcTHHZQP5exQDfGEq0WLkDjDcjsZVzNGz1Umsz/+2uOIPIxsTZ/v6cICwha3OQkjts0QeQNIJNxGOe/L8LldTE2YRLLV1JMbn/XLulGy8x7dguXTM7DE0KBvPVv0x8QfHVrX1Mvr00qbFUICMSgVQX8he6owM5HMIEONG+iIsa+Zi7Ib436XJwLmI3vzV7kbNlpWsER1CgfDhS/tbjIXH8VEWILAa1oIKUlGzxQ9BiLCG3RZCpzRjIsz5HcpU1fdXvaRE/DYeTT0AiE6t99njTrS2cWbg== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 08 Aug 2020 02:32:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 1D07F1E60C2D; Fri, 7 Aug 2020 22:32:59 -0400 (EDT) Date: 7 Aug 2020 22:32:59 -0400 Message-Id: <20200808023259.1D07F1E60C2D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu In-Reply-To: <78fd8b26-0bed-ac36-842d-a851ec04d8b5@wisc.edu> 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] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 02:33:03 -0000 In article <78fd8b26-0bed-ac36-842d-a851ec04d8b5@wisc.edu> you write: >On 8/7/20 2:12 PM, John Levine wrote: >> My guess is that MIT figured Microsoft will host this for free, that's >> great, totally unaware that some of its users' mail would silently >> break. > >Customers of Microsoft don't like to call things bundled in an expensive package "free". I have no idea what their pricing ie. My university uses Gmail for the alumni service and I believe that actually is free. >Maybe it was inflicted by the domain owner onto the person maintaining the mailing list. (In my experience, this is >where people realize that no one has been maintaining/patching the mailing list, unaware of DMARC, etc.) The IETF is entirely aware of DMARC, and their main mailing lists use a version of my dmarc.fail hack. This one's off in a corner, on the list of things to be cleaned up. >My peeve in recent years is that universities were essentially coerced (economically) into being the customers of >Microsoft/Google and then the email admins are told to sit down and let the adults talk about what they think customers >need from DMARC, ARC, etc. It's why I'm constantly sticking my foot in my mouth here and M3AAWG; trying to assert a >voice. If it's not obvious, we do appreciate it. Way too many of them say whew, we can blame the vendor and not worry about it. >We need faculty/alumni/emeriti forwarding to work without being told that Microsoft can't do it without breaking DMARC. Yup. >We need spoofing protection for all of our domains without being told we're misdeploying. I would be interested to better undertstand the meaning of "need" here. It is my impression that most people vastly overestimate how much of a phish target they are. Paypal and big banks certainly are, other places, a lot less so. R's, John From nobody Fri Aug 7 19:37:19 2020 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 2DDDA3A0B46 for ; Fri, 7 Aug 2020 19:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 rcnrcrmkbq4b for ; Fri, 7 Aug 2020 19:37:14 -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 4CB443A0B44 for ; Fri, 7 Aug 2020 19:37:14 -0700 (PDT) Received: from [192.168.43.69] ([172.58.30.214]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0782dsws004427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Aug 2020 19:39:55 -0700 To: John Levine Cc: dmarc@ietf.org References: <20200808023259.1D07F1E60C2D@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 7 Aug 2020 19:37:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200808023259.1D07F1E60C2D@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 02:37:17 -0000 On 8/7/2020 7:32 PM, John Levine wrote: > I would be interested to better undertstand the meaning of "need" > here. It is my impression that most people vastly overestimate how > much of a phish target they are. Paypal and big banks certainly are, > other places, a lot less so. I suspect the calculus is less in the pragmatic terms of asking how big this threat is and more in terms of wishing for some version of protection and thinking this helps to achieve it. The degree to which so many folk embrace does not appear to have that much empirical basis, but rather a sense of feeling a need to do something and at first blush this seems to be something. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 8 02:51:44 2020 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 67C393A0A65 for ; Sat, 8 Aug 2020 02:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 xIaaS7sft0Cy for ; Sat, 8 Aug 2020 02:51:40 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 4F53F3A0A3C for ; Sat, 8 Aug 2020 02:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1596880296; bh=9JV4F7ebl5C00MauNwtu6C2DxHOrhsX9H8XUCT2n/dY=; l=2348; h=To:References:From:Date:In-Reply-To; b=CvYgsU04mvbWrak6KtWko/Bg0XQVAqYuluHO9aqZQ3mir+Ktoa4ErfpMv790mGU/F FXPHzInuTjClNra3CLiGxMkQfl2hd8/gjD7d7ypKnCMl8CN0LM1AhMA6Xhqc+luzvx S2EdJx/k2wOfsNP+8YtBlKKZu3vPhBSgW0MDrvni+h9T5TyUUNvSfI8IkCQGQ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.36.171]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C6.000000005F2E75A7.00006717; Sat, 08 Aug 2020 11:51:35 +0200 To: dmarc@ietf.org References: <20200808022743.216921E60BFF@ary.qy> From: Alessandro Vesely Message-ID: Date: Sat, 8 Aug 2020 11:51:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200808022743.216921E60BFF@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 09:51:43 -0000 On 2020-08-08 4:27 a.m., John Levine wrote: > > Some years back people kept asking Spamhaus to set up a whitelist, so > they hired me to do it. Technically it worked fine, but it soon became > apparent that the only people who were interested weren't people who > we'd want to whitelist. The good quality senders get their mail > delivered already, the terrible ones didn't bother, and all we heard > from were people who sometimes sent some spam along with the good mail > but assured us they were nice people. I'm not clear why that failed. Personally, I was puzzled by the .com suffix, which somehow sounded like pay for being whitelisted. > I think you'll find that all of the existing whitelist like things > are a sideshow to the company's real business of deliverability > consulting. Of course whitelisting can easily become ESPs combat zone. > For DMARC, it would be nice if there were a shared list of credible > forwarders, not to automatically accept their mail, but just to say > they're good enough that you can believe what's in their ARC seals > when you're doing the usual spam filtering. Trusted-forwarder.org still exists...[*] Automatically accept is not the same as override DMARC policy. The latter can cure some of MLM and non-MLM problems. I proposed snd=rhswl.zone.example. The difference w.r.t. trusted-forwarder.org is that some sites can start building their own right hand side whitelists (RHSWL). Specifying the zone in the protocol makes it visible, so lazy admins can help themselves to quickly build their not-so-strict DMARC policy by using someone else's RHSWL. Combining lists could also become possible, once there is a decent amount of them. There is already An Architecture for Reputation Reporting, RFC 7070/3, which could support exchanging entries among similarly scoped RHSWLs. > You can't just let people sign themselves up for a list like that, > since every dodgy bulk mailer will figure this will get them an > extra 2% delivery, and we've never gotten past a vague hope that we > could canvass people we know to make a combined set of mailing > lists hosts we know. Seeking how to make that hope less vague should be a highly commended task. Best Ale -- [*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html From nobody Sat Aug 8 11:05:26 2020 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 945D03A0C3C for ; Sat, 8 Aug 2020 11:05:24 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQebsOZTJ951 for ; Sat, 8 Aug 2020 11:05:21 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCC73A0C3A for ; Sat, 8 Aug 2020 11:05:21 -0700 (PDT) X-ASG-Debug-ID: 1596909917-11fa311da649710001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id aYOR1lgM2q2sn1eC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 08 Aug 2020 14:05:17 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=sZqnAfqGDDGNJBdzsiYKkfqRpS5YgzXIVM1u9P1WYt8=; b=eC33wvryhDMJe8YKEZz9VLYbUFN1FeN/i5sXh91yUtWdBpBR0CLzYm9zHIyrnQyXO P0HCZPPtnhimRJguvFcgkXQ9OLoIylBtHSRValSh3lqQ7QJQnHEpMz6WjpaKLtXxc Qp7ohY3Ma1gMYaDY0SKFUYYevTvXNcy8YUV0cd1fk= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 08 Aug 2020 18:05:08 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: <0ad0a6b93ff74648b2620e81c7ddaa13@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=758c87a8c8a74e8e969489d62682140d In-Reply-To: References: <20200808022743.216921E60BFF@ary.qy> X-Exim-Id: 0ad0a6b93ff74648b2620e81c7ddaa13 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1596909917 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10839 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83780 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 18:05:25 -0000 This is a multipart message in MIME format. --758c87a8c8a74e8e969489d62682140d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The unifying principle is that we need a third-party authentication method,= a need which is not adequately satisfied with SPF and DKIM. The standard= can support multiple options, such as the following send3=3D"method=3DATPS,p=3Dreject,sp=3Dquarantine; method=3Dreputation,p= =3Dquarantine,dns=3Duri; method=3DRHSWL, sp=3Dreject" where: "method=3DATPS" means RFC 6541 third-party signatures, as suggested by Hect= or"method=3Dreputation" means a trust service like trusted-forwarders.org, = as suggested by John"method=3DRHSWL" means the whitelist system suggested b= y Alessandro Usage: If multiple methods are specified, the receiver checks all of the methods t= hat it is willing and able to use.If p=3D is missing, the third-party authe= ntication method is not supported for primary domains.If sp=3D is missing, = the third-party verification method is not supported for subdomainsIf any m= ethod passes, the message passes. No other checks need to be performed. = If all methods fail, the strictest policy is the recommendation action.If = any third-party authorization method is supported, the DMARC policies shoul= d be p=3Dnone and sp=3Dnone, to avoid false positives by entities that do n= ot know how to check the third-party method. A domain could optionally advertise which third-party methods it is willing= to check using a similar keyword structure: verify3=3D"method ATPS; method=3Dreputation; dns=3Duri; method=3DRHSWL". This would allow senders to limit third-party impersonation to those recipi= ents that will accept the impersonation as legitimate. It would be desirable for DMARC feedback reports to indicate which third-pa= rty methods were checked. Updating the reporting specification might be m= ore complex than specifying the verification method itself. Do we move forward with an approach like this? ---------------------------------------- From: Alessandro Vesely Sent: 8/8/20 5:52 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains On 2020-08-08 4:27 a.m., John Levine wrote: > > Some years back people kept asking Spamhaus to set up a whitelist, so > they hired me to do it. Technically it worked fine, but it soon became > apparent that the only people who were interested weren't people who > we'd want to whitelist. The good quality senders get their mail > delivered already, the terrible ones didn't bother, and all we heard > from were people who sometimes sent some spam along with the good mail > but assured us they were nice people. I'm not clear why that failed. Personally, I was puzzled by the .com suffix, which somehow sounded like pay for being whitelisted. > I think you'll find that all of the existing whitelist like things > are a sideshow to the company's real business of deliverability > consulting. Of course whitelisting can easily become ESPs combat zone. > For DMARC, it would be nice if there were a shared list of credible > forwarders, not to automatically accept their mail, but just to say > they're good enough that you can believe what's in their ARC seals > when you're doing the usual spam filtering. Trusted-forwarder.org still exists...[*] Automatically accept is not the same as override DMARC policy. The latter can cure some of MLM and non-MLM problems. I proposed snd=3Drhswl.zone.example. The difference w.r.t. trusted-forwarder.org is that some sites can start building their own right hand side whitelists (RHSWL). Specifying the zone in the protocol makes it visible, so lazy admins can help themselves to quickly build their not-so-strict DMARC policy by using someone else's RHSWL. Combining lists could also become possible, once there is a decent amount of them. There is already An Architecture for Reputation Reporting, RFC 7070/3, which could support exchanging entries among similarly scoped RHSWLs. > You can't just let people sign themselves up for a list like that, > since every dodgy bulk mailer will figure this will get them an > extra 2% delivery, and we've never gotten past a vague hope that we > could canvass people we know to make a combined set of mailing > lists hosts we know. Seeking how to make that hope less vague should be a highly commended task. Best Ale -- [*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --758c87a8c8a74e8e969489d62682140d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The= unifying principle is that we need a third-party authentication method, a = need which is not adequately satisfied with SPF and DKIM.   The standa= rd can support multiple options, such as the following

=
send3=3D"method=3DATPS,p=3Dreject,sp=3Dquarantine;  method=3Drepu= tation,p=3Dquarantine,dns=3Duri; method=3DRHSWL, sp=3Dreject"
where:
  • "method=3DATPS" means RFC 6541 third-party = signatures, as suggested by Hector
  • "method=3Dreputation" means a tr= ust service like tru= sted-forwarders.org, as suggested by John
  • "method=3DRHSWL"= means the whitelist system suggested by Alessandro
Usage:
  • If multiple methods are specified, the receiver checks all of th= e methods that it is willing and able to use.
  • If p=3D is missing, t= he third-party authentication method is not supported for primary domains.<= /li>
  • If sp=3D is missing, the third-party verification method is not sup= ported for subdomains
  • If any method passes, the message passes. &nb= sp; No other checks need to be performed.   
  • If all metho= ds fail, the strictest policy is the recommendation action.
  • If any = third-party authorization method is supported, the DMARC policies should be= p=3Dnone and sp=3Dnone, to avoid false positives by entities that do not k= now how to check the third-party method.
A domain could optio= nally advertise which third-party methods it is willing to check using a si= milar keyword structure:
verify3=3D"= method ATPS;  method=3Dreputation; dns=3Duri; method=3DRHSWL".  <= /div>
This would allow senders to limit third-party impersonation to th= ose recipients that will accept the impersonation as legitimate.
=
It would be desirable for DMARC feedback reports to indicate= which third-party methods were checked.   Updating the reporting spec= ification might be more complex than specifying the verification method its= elf.

Do we move forward with an approach like this?


F= rom: Alessandro Vesely <vesely@tana.it>
Sent: 8/8/20 5:52 AM
To: dmarc@ietf.org
Subj= ect: Re: [dmarc-ietf] non-mailing list use case for differing head= er domains
On 2020-08-08 4:27 a.m., John Levine wrote:
>
> Some years back people kept asking Spamhaus to s= et up a whitelist, so
> they hired me to do it. Technically it= worked fine, but it soon became
> apparent that the only peop= le who were interested weren't people who
> we'd want to white= list. The good quality senders get their mail
> delivered alre= ady, the terrible ones didn't bother, and all we heard
> from = were people who sometimes sent some spam along with the good mail
> but assured us they were nice people.


I'm not clear why that failed. Personally, I was puzzled by the .c= om
suffix, which somehow sounded like pay for being whitelisted.<= /div>


> I think you'll find that all o= f the existing whitelist like things
> are a sideshow to the c= ompany's real business of deliverability
> consulting.

Of course whitelisting can easily become ESPs combat zone= .


> For DMARC, it would be nice = if there were a shared list of credible
> forwarders, not to a= utomatically accept their mail, but just to say
> they're good= enough that you can believe what's in their ARC seals
> when = you're doing the usual spam filtering.


<= div>Trusted-forwarder.org still exists...[*]

Autom= atically accept is not the same as override DMARC policy. The
lat= ter can cure some of MLM and non-MLM problems.

I p= roposed snd=3Drhswl.zone.example. The difference w.r.t.
trusted-f= orwarder.org is that some sites can start building their own
righ= t hand side whitelists (RHSWL). Specifying the zone in the
protoc= ol makes it visible, so lazy admins can help themselves to
quickl= y build their not-so-strict DMARC policy by using someone else's
= RHSWL.

Combining lists could also become possible,= once there is a decent
amount of them. There is already An Archi= tecture for Reputation
Reporting, RFC 7070/3, which could support= exchanging entries among
similarly scoped RHSWLs.

=

> You can't just let people sign themselves up= for a list like that,
> since every dodgy bulk mailer will fi= gure this will get them an
> extra 2% delivery, and we've neve= r gotten past a vague hope that we
> could canvass people we k= now to make a combined set of mailing
> lists hosts we know.

Seeking how to make that hope less vague should be = a highly commended
task.


= Best
Ale
--

[*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html



























_______________________________________= ________
dmarc mailing list
dmarc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmarc

--758c87a8c8a74e8e969489d62682140d-- From nobody Sun Aug 9 03:28:59 2020 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 6CB713A0A51 for ; Sun, 9 Aug 2020 03:28:57 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=iki.fi 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 6NlD7onluwi7 for ; Sun, 9 Aug 2020 03:28:54 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14163A0A4D for ; Sun, 9 Aug 2020 03:28:53 -0700 (PDT) Received: from localhost (dyvyfyjk1qv6j67cj2pby-4.rev.dnainternet.fi [IPv6:2001:14bb:440:401d:156c:747d:6c47:b302]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: haa) by meesny.iki.fi (Postfix) with ESMTPSA id DEE68203F0; Sun, 9 Aug 2020 13:28:49 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596968930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K7etURLIXi2rwbfzUGw4Dotj+Wway681lMhTbMHn9LM=; b=H3ziOdamroWNE8bpGjPUBQkZQhdpvobQYPE1iMIaJVJ/uHdLh4+myaGZyHwPZgtBMF7maI TzaLhq5bmABwTWztUStuI5feagbgOp6QQJCJDh6kYhXIRPP/0heBPWQm9YWKGr1LQfto7O fUOZB1bDj7VzLRZjaT7Wohddf8rP3u0= Content-Type: multipart/alternative; boundary=Apple-Mail-F5D4C3AF-B45C-4D60-886E-60C2CF8DB45A Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Hannu Aronsson In-Reply-To: Date: Sun, 9 Aug 2020 13:28:49 +0300 Message-Id: References: To: dmarc@ietf.org X-Mailer: iPad Mail (18A5342e) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596968930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K7etURLIXi2rwbfzUGw4Dotj+Wway681lMhTbMHn9LM=; b=N660ZYtL0URyAN8Zs4zfcJ9CyN15UW5i8OKV8Gb+F+NNhggOrKWU/scvPnft/ZPqgAnxIb P1WAt1QvPsurR5PNZbjI+BVYNp2LdljPbzjhmoxa+gFPrCj9VxV9+den7y0r1ARFPirYIC HC5bfyitdXRmV6o9a/4Cy7tRlRpc9Uc= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1596968930; a=rsa-sha256; cv=none; b=kEZGoibUcrm2DgpiMDgJ1DcUA4BJg5z3KOhQE13qKxQJk5GykGyiOc1pFqQRH80vA7edRO 9DRwt0/gISKDW9InUJxN98aZKbUDZY6YqFwV9uMHetnsdeg2VvHC3nY9C1XxHf3tWz3v5s /YSMQT2/4i+xzmgyjNpsloS2vxwuE0U= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=haa smtp.mailfrom=haa@iki.fi Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 10:28:58 -0000 --Apple-Mail-F5D4C3AF-B45C-4D60-886E-60C2CF8DB45A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I have been lurking here around for a while and we have been working at M3AA= WG for some time as well. Today=E2=80=99s DMARC is breaking more and more email as it gets more widely= and often overly strictly deployed. I feel the major issue with DMARC is email forwarding in it=E2=80=99s many f= orms, in addition to mailing list issues. It would be preferable to try to d= o something that helps email survive as an open platform instead of bad work= arounds.=20 Transactional and person-to-person emails also should work reliably with DMA= RC (and similar things) when forwarded i.e. indirect delivery. In M3AAWG discussions, we have identified many stakeholders who are seeing m= ajor issues with DMARC and SPF when forwarding email for various valid reaso= ns, examples: a) ISPs hosting user domains and email from to addresses in those domains is= forwarded to external mailbox addresses. This is very common for smaller or= ganizations. b) Alumni and organization member addresses like alumni.harvard.edu, acm.org= , iki.fi and many others that provide a =E2=80=9Cpermanent=E2=80=9D email ad= dress and forward email to user-specified mailbox provider addresses. c) Users forwarding email themselves to another email address e.g. based on r= ules or forwarding to their mobile device address, or forwarding old ISP ema= il to new ISP, etc. d) Some mailing lists and smaller email distributions, too, which work just f= orward messages as they are to their members. e) and of course the many users using these services, and senders trying to s= end to them. So there may be many more stakeholders with DMARC issues than one might init= ially think about. DMARC is creating a lot of =E2=80=9Cthe message did not g= et thru=E2=80=9D issues for valid and real emails these days. To be worth pushing further, DMARC needs to be compatible with with email fo= rwarding i.e. indirect mail flows. To try to clarify my thinking around this, I tried to put some thoughts into= a practical proposal format so it would be easier to consider, comment and d= iscuss and think about the practicalities around it. Based on the discussion, it seems it might be more practical to try to make =E2= =80=9Csmall=E2=80=9D improvements into DMARC. If we can find some useful way= forward, we=E2=80=99re willing to work on an internet-draft for more formal= commenting. Background, in addition to the use cases above: Because SPF fails with forwarded/indirect emails, and as DMARC today depends= on SPF, it also fails in these use cases, especially when deployed overly s= trictly. Normal email forwarding does not break DKIM as the messages are not changed.= We have new tools available today that can help, specifically ARC. We should aim to make DMARC compatible with these forwarding use cases, with= out losing the anti-abuse aims if possible. Draft proposal for comments:=20 When a DMARC recipient MTA is processing an incoming message, 1) If DKIM is valid, SPF results should be ignored. DKIM already proves the m= essage is from the source it claims to be from, it doesn=E2=80=99t matter if= it arrived via an indirect path. 2) If DKIM is not used, but ARC is used, SPF processing should walk the ARC h= eader chain as long as they have acceptable reputation and if a matching IP a= ddress is found there, consider the SPF check successful. 3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as today,= or probably we should recommend always putting failing messages somewhere w= here the user can search for the =E2=80=9Clost messages=E2=80=9D when needed= , e.g. to the junk mailbox or quarantine. If something like this was in place, forwarders and others would be highly m= otivated to implement ARC, helping senders and recipients who want to deploy= DMARC or DMARC-like solutions. ARC reputation: ARC reputation has been discussed a lot and may be a major roadblock in goin= g this way. I think the situation has changed now as DMARC issues become lar= ger and affect more users, so people are more ready to do something about it= now. * Technically we should be able to simply use DNS-based IP allowlists to get= reputation information for the ARC signing intermediaries. * ARC allowlisting would allows MTA admins to choose suitable allowlists fro= m free and paid options from various sources and vendors, just like they use= blocklists today for email already.=20 * We could probably even re-use existing email RBL allow/blocklists for this= purpose, if you don=E2=80=99t trust some IP reputation as sender, you would= not trust it for ARC either. * Free options would be available so DMARC2 software and solutions could inc= lude default settings that already work out of the box for smaller organizat= ions. =20 * It seems possible to maintain semi-manual lists of =E2=80=9Cmajor trusted=E2= =80=9D forwarding services and have a suitable vetting process for that. At i= ki.fi we have looked at doing something like this, if it would help. * Additionally people would offer various automated lists based on other ana= lysis and methods. * ARC reputation could at this time have become an additional service for em= ail protection vendors to sell. Maybe before this was not viable earlier bec= ause ARC was not widely available yet, or the SPF/DMARC issue was not severe= enough before? * Mailbox service admins could add =E2=80=9Ctrusted forwarding IPs=E2=80=9D l= ocally to help specific users with forwarding related issues. Today there do= esn=E2=80=99t seem to be an easy options for mailbox service providers to he= lp their users who have SPF/DMARC issues. Yours, Hannu --=20 Hannu Aronsson haa@iki.fi > Dave Crocker wrote 8.8.2020 5.37: > I suspect the calculus is less in the pragmatic terms of asking how big th= is threat is and more in terms of wishing for some version of protection and= thinking this helps to achieve it. >=20 > The degree to which so many folk embrace does not appear to have that much= empirical basis, but rather a sense of feeling a need to do something and a= t first blush this seems to be something. --Apple-Mail-F5D4C3AF-B45C-4D60-886E-60C2CF8DB45A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello,


I have been lurking here around for a while and we have= been working at M3AAWG for some time as well.


Today=E2=80=99s DMARC is breaking more and more email as it get= s more widely and often overly strictly deployed.


I feel the major issue with DMARC is email forwarding in it=E2=80=99= s many forms, in addition to mailing list issues. It would be preferable to try to do somet= hing that helps email survive as an open platform instead of bad workarounds= . 


Transactional= and person-to-person emails also should work reliably with DMARC (and simil= ar things) when forwarded i.e. indirect delivery.



In M3AAWG discussions, we have identified many stakeholder= s who are seeing major issues with DMARC and SPF when forwarding email for v= arious valid reasons, examples:


a) ISPs hosting= user domains and email from to addresses in those domains is forwarded to e= xternal mailbox addresses. This is very common for smaller organizations.


b) Alumni and organization member addresses like a= lumni.harvard.edu, acm.org, iki.fi and many others that provide a =E2=80=9Cp= ermanent=E2=80=9D email address and forward email to user-specified mailbox p= rovider addresses.


<= span class=3D"s1" style=3D"font-size: 18.55px;">c) Users forwarding email th= emselves to another email address e.g. based on rules or forwarding to their= mobile device address, or forwarding old ISP email to new ISP, etc.<= /p>


d) Some mailing lists and smaller email distributions,= too, which work just forward messages as they are to their members.<= /p>


e) and of course the many u= sers using these services, and senders trying to send to them.


So there may be many more stakeholders with D= MARC issues than one might initially think about. DMARC is creating a lot of= =E2=80=9Cthe message did not get thru=E2=80=9D issues for valid and real em= ails these days.


= To be worth pushing further, DMARC needs to be compatible with with email fo= rwarding i.e. indirect mail flows.



<= /span>

To try to clarify my thinking= around this, I tried to put some thoughts into a practical proposal format s= o it would be easier to consider, comment and discuss and think about the pr= acticalities around it.


<= /span>

Based on the discussion, it s= eems it might be more practical to try to make =E2=80=9Csmall=E2=80=9D impro= vements into DMARC. If we can find some useful way forward, we=E2=80=99re wi= lling to work on an internet-draft for more formal commenting.


Background, in addition to the use cases above:


Because SPF fails with forwarded/indirect emails, and as DMAR= C today depends on SPF, it also fails in these use cases, especially when de= ployed overly strictly.


Normal email forwarding= does not break DKIM as the messages are not changed. We have new tools avai= lable today that can help, specifically ARC.


We= should aim to make DMARC compatible with these forwarding use cases, withou= t losing the anti-abuse aims if possible.


Draft p= roposal for comments: 


When a DMARC recipien= t MTA is processing an incoming message,


1) If D= KIM is valid, SPF results should be ignored. DKIM already proves the message= is from the source it claims to be from, it doesn=E2=80=99t matter if it ar= rived via an indirect path.


2) If DKIM is not use= d, but ARC is used, SPF processing should walk the ARC header chain as long a= s they have acceptable reputation and if a matching IP address is found ther= e, consider the SPF check successful.


3) If DKI= M and ARC are not used and SPF/DMARC fails, you could act as today, or proba= bly we should recommend always putting failing messages somewhere where the u= ser can search for the =E2=80=9Clost messages=E2=80=9D when needed, e.g. to t= he junk mailbox or quarantine.


If something lik= e this was in place, forwarders and others would be highly motivated to impl= ement ARC, helping senders and recipients who want to deploy DMARC or DMARC-= like solutions.

=

ARC reputation:


ARC re= putation has been discussed a= lot and may be a major roadblock in going this way. I think the situation h= as changed now as DMARC issues become larger and affect more users, so peopl= e are more ready to do something about it now.


* Tech= nically we should be able to simply use DNS-based IP allowlists to get reput= ation information for the ARC signing intermediaries.


* ARC allowli= sting would allows MTA admins to choose suitable allowlists from free and pa= id options from various sources and vendors, just like they use blocklists t= oday for email already. 


* We could probabl= y even re-use existing email RBL allow/blocklists for this purpose, if you d= on=E2=80=99t trust some IP reputation as sender, you would not trust it for A= RC either.


* Free options would be available so= DMARC2 software and solutions could include default settings that already w= ork out of the box for smaller organizations.  


* It seems pos= sible to maintain semi-manual lists of =E2=80=9Cmajor trusted=E2=80=9D forwa= rding services and have a suitable vetting process for that. At iki.fi we ha= ve looked at doing something like this, if it would help.


* A= dditionally people would offer various automated lists based on other analys= is and methods.

=

* ARC reputation could at this t= ime have become an additional service for email protection vendors to sell. M= aybe before this was not viable earlier because ARC was not widely available= yet, or the SPF/DMARC issue was not severe enough before?


* Mailbox= service admins could add =E2=80=9Ctrusted forwarding IPs=E2=80=9D locally t= o help specific users with forwarding related issues. Today there doesn=E2=80= =99t seem to be an easy options for mailbox service providers to help their u= sers who have SPF/DMARC issues.


Yours,

 = ; Hannu

-- =

Hannu Aronsson
haa@iki.fi
Dave Crocker <dhc@dcrocker.ne= t> wrote 8.8.2020 5.37:

I suspect the calculus is less in the pragmatic te= rms of asking how big this threat is and more in terms of wishing for some v= ersion of protection and thinking this helps to achieve it.
=
The degree to which so many folk embrace does not appear to= have that much empirical basis, but rather a sense of feeling a need to do s= omething and at first blush this seems to be something.
= --Apple-Mail-F5D4C3AF-B45C-4D60-886E-60C2CF8DB45A-- From nobody Sun Aug 9 08:11:41 2020 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 8DF3F3A098B for ; Sun, 9 Aug 2020 08:11:39 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iki.fi 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 MN9S-R9M11fq for ; Sun, 9 Aug 2020 08:11:36 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4E43A0985 for ; Sun, 9 Aug 2020 08:11:33 -0700 (PDT) Received: from [172.20.10.5] (213-216-249-231.bb.dnainternet.fi [213.216.249.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: haa) by meesny.iki.fi (Postfix) with ESMTPSA id 2FA02202B0 for ; Sun, 9 Aug 2020 18:11:27 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596985889; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WOmAt8vKN3nECYgHXfndYpl5VDd8KXjfxpKMqoiM+z0=; b=GnqJUnLZbbccHuJxXQnMJ1DiMRpINTYnsWddpDqW4UZCV51DfYGHXGZ72O5c88fDynpUNh kKq7+LP6MjitZcSJDFSDxASh+MVkWmBSfe3UdqV2woslEUUuN+Im8EbL1FaOEpYevf0qAU h7QvQkjaWk5CZoKOgCbC6LZJ0b2WiBk= From: Hannu Aronsson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sun, 9 Aug 2020 18:11:16 +0300 References: To: dmarc@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596985889; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WOmAt8vKN3nECYgHXfndYpl5VDd8KXjfxpKMqoiM+z0=; b=Lc0XXUwy9ey1rGjP1f98NkoDnGrpTWG+dnXl+9lOleHSajUvZrayrSP9/jnWa2Fy027ct1 ZUJqaL5n3HuNnuNBOESihF9f7Nqvb5f3PMgeeuyPZFZkeTX3w/x0BQ0kZyaO8Nxi1LBFTf ArR+9zpcJpJl/aeqr/1oF4T3ge0XHP4= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1596985889; a=rsa-sha256; cv=none; b=C++Ul/dYz8ZC0uAd0TRjSaac78pupe76ibvaT5n1zWEc7JKv4a035IMrxE5dd/VQLi7ZjJ 8y4vUtGFXypadc5Z7rT/cSmeg9Fnh/MvbHOjz+mGlYFEUy0MA28hYTnOXNMcYY6mDcjYKL SF8xkvfxU/X6v0l0CX5zQVzXJAvpd44= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=haa smtp.mailfrom=haa@iki.fi Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 15:11:40 -0000 Hello, Quick correction: As DMARC requires only either DKIM or SPF which I had = confused, this removes the need for the proposal point 1). Thanks for = the off-list help received. This seems to be mostly an SPF issue, but still remains when - SPF used used alone without DMARC (not sure if relevant for this = discussion, but it is a real-world problem) and=20 - DMARC when DKIM is not used and it falls back to SPF causing indirect emails to fail, especially with p=3Dreject or -all = settings or overly strict receiver deployments.=20 For fixing the SPF issue a solution using ARC would be much preferable = to the SRS (Sender Rewriting Scheme) workaround, because e.g. the = messages would be unchanged, avoid problems with long email addresses or = requiring databases, and DMARC strict =46rom alignment issues, etc. The other topics in the email,=20 - forwarding use cases from M3AAWG discussions and=20 - figuring out how we could get ARC reputation solution in place are hopefully still interesting for this discussion. Yours, Hannu > On 9.8.2020, at 13:28+0300, Hannu Aronsson wrote: >=20 > Hello, >=20 > I have been lurking here around for a while and we have been working = at M3AAWG for some time as well. >=20 > Today=E2=80=99s DMARC is breaking more and more email as it gets more = widely and often overly strictly deployed. >=20 > I feel the major issue with DMARC is email forwarding in it=E2=80=99s = many forms, in addition to mailing list issues. It would be preferable = to try to do something that helps email survive as an open platform = instead of bad workarounds.=20 >=20 > Transactional and person-to-person emails also should work reliably = with DMARC (and similar things) when forwarded i.e. indirect delivery. >=20 >=20 > In M3AAWG discussions, we have identified many stakeholders who are = seeing major issues with DMARC and SPF when forwarding email for various = valid reasons, examples: >=20 > a) ISPs hosting user domains and email from to addresses in those = domains is forwarded to external mailbox addresses. This is very common = for smaller organizations. >=20 > b) Alumni and organization member addresses like alumni.harvard.edu, = acm.org, iki.fi and many others that provide a =E2=80=9Cpermanent=E2=80=9D= email address and forward email to user-specified mailbox provider = addresses. >=20 > c) Users forwarding email themselves to another email address e.g. = based on rules or forwarding to their mobile device address, or = forwarding old ISP email to new ISP, etc. >=20 > d) Some mailing lists and smaller email distributions, too, which work = just forward messages as they are to their members. >=20 > e) and of course the many users using these services, and senders = trying to send to them. >=20 > So there may be many more stakeholders with DMARC issues than one = might initially think about. DMARC is creating a lot of =E2=80=9Cthe = message did not get thru=E2=80=9D issues for valid and real emails these = days. >=20 > To be worth pushing further, DMARC needs to be compatible with with = email forwarding i.e. indirect mail flows. >=20 >=20 > To try to clarify my thinking around this, I tried to put some = thoughts into a practical proposal format so it would be easier to = consider, comment and discuss and think about the practicalities around = it. >=20 > Based on the discussion, it seems it might be more practical to try to = make =E2=80=9Csmall=E2=80=9D improvements into DMARC. If we can find = some useful way forward, we=E2=80=99re willing to work on an = internet-draft for more formal commenting. >=20 > Background, in addition to the use cases above: >=20 > Because SPF fails with forwarded/indirect emails, and as DMARC today = depends on SPF, it also fails in these use cases, especially when = deployed overly strictly. >=20 > Normal email forwarding does not break DKIM as the messages are not = changed. We have new tools available today that can help, specifically = ARC. >=20 > We should aim to make DMARC compatible with these forwarding use = cases, without losing the anti-abuse aims if possible. >=20 > Draft proposal for comments:=20 >=20 > When a DMARC recipient MTA is processing an incoming message, >=20 > 1) If DKIM is valid, SPF results should be ignored. DKIM already = proves the message is from the source it claims to be from, it doesn=E2=80= =99t matter if it arrived via an indirect path. >=20 > 2) If DKIM is not used, but ARC is used, SPF processing should walk = the ARC header chain as long as they have acceptable reputation and if a = matching IP address is found there, consider the SPF check successful. >=20 > 3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as = today, or probably we should recommend always putting failing messages = somewhere where the user can search for the =E2=80=9Clost messages=E2=80=9D= when needed, e.g. to the junk mailbox or quarantine. >=20 > If something like this was in place, forwarders and others would be = highly motivated to implement ARC, helping senders and recipients who = want to deploy DMARC or DMARC-like solutions. >=20 > ARC reputation: >=20 > ARC reputation has been discussed a lot and may be a major roadblock = in going this way. I think the situation has changed now as DMARC issues = become larger and affect more users, so people are more ready to do = something about it now. >=20 > * Technically we should be able to simply use DNS-based IP allowlists = to get reputation information for the ARC signing intermediaries. >=20 > * ARC allowlisting would allows MTA admins to choose suitable = allowlists from free and paid options from various sources and vendors, = just like they use blocklists today for email already.=20 >=20 > * We could probably even re-use existing email RBL allow/blocklists = for this purpose, if you don=E2=80=99t trust some IP reputation as = sender, you would not trust it for ARC either. >=20 > * Free options would be available so DMARC2 software and solutions = could include default settings that already work out of the box for = smaller organizations. =20 >=20 > * It seems possible to maintain semi-manual lists of =E2=80=9Cmajor = trusted=E2=80=9D forwarding services and have a suitable vetting process = for that. At iki.fi we have looked at doing something like this, if it = would help. >=20 > * Additionally people would offer various automated lists based on = other analysis and methods. >=20 > * ARC reputation could at this time have become an additional service = for email protection vendors to sell. Maybe before this was not viable = earlier because ARC was not widely available yet, or the SPF/DMARC issue = was not severe enough before? >=20 > * Mailbox service admins could add =E2=80=9Ctrusted forwarding IPs=E2=80= =9D locally to help specific users with forwarding related issues. Today = there doesn=E2=80=99t seem to be an easy options for mailbox service = providers to help their users who have SPF/DMARC issues. >=20 > Yours, > Hannu > --=20 > Hannu Aronsson > haa@iki.fi >=20 >> Dave Crocker wrote 8.8.2020 5.37: >>=20 >> I suspect the calculus is less in the pragmatic terms of asking how = big this threat is and more in terms of wishing for some version of = protection and thinking this helps to achieve it. >>=20 >> The degree to which so many folk embrace does not appear to have that = much empirical basis, but rather a sense of feeling a need to do = something and at first blush this seems to be something. -- haa@iki.fi https://www.haa.iki.fi From nobody Sun Aug 9 09:54:37 2020 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 C9C463A08B3 for ; Sun, 9 Aug 2020 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=cert.ee header.b=JgofH5RU; dkim=pass (2048-bit key) header.d=cert.ee header.b=Bd/54MQb 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 ZuEPfWO_7TGx for ; Sun, 9 Aug 2020 09:54:32 -0700 (PDT) Received: from smtp-out.cert.ee (smtp-out.cert.ee [46.226.143.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC593A090E for ; Sun, 9 Aug 2020 09:54:30 -0700 (PDT) Received: from mail.cert.ee (mail.cert.ee [46.226.143.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by smtp-out.cert.ee (Postfix) with ESMTPS id 6FFE93F8F3 for ; Sun, 9 Aug 2020 19:54:28 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.ee; s=mail; t=1596992068; bh=WqYTU/cebzE68I2u2R8uR6M72W6tzYLw4MPI3qPuOLI=; h=To:References:From:Date:In-Reply-To; b=JgofH5RUTKD1O/pLqD098oERigbuu1Nl5tRFwIlACvSKhW8PWAycQxTC7ecZKUjE3 vvIPDJtCSflSd1SLCPJYiGYOy6FHeYAp6F/xkmzMFf1moI9jG/aEcIug1DvTqHJiLp JnT7qMlw589Pw8Nc8O9V3Fpx9heu0bRf/FbVjXVhHsGZLu3KGGefc5UjfUq2GS19V9 t7VyQWHympBW1vFBlWZ40PCd+hFYtjpy0Ams29g4TQYlAcl2bXOZzq/sO7L+uFewyv 5hUVj6eSbKYb/HMiEYn9RFCl7n9E4jsqnP4Y2KjCkX0Ozg7Mm19goPTCzzb94apP8j ySjItOrxOtQCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.ee; s=mailcertee; t=1596992068; bh=WqYTU/cebzE68I2u2R8uR6M72W6tzYLw4MPI3qPuOLI=; h=To:References:From:Date:In-Reply-To; b=Bd/54MQbEI5/x3iumGm2gG49vPtRytzfw8Ir0FaUZtGd6X76FPMX8pZ2q1MoBBxpb 0BKG9kt6hDzc4GJriTW89fQlnmc6PreqVWHAPYZaqrNIBgDXN/SfTVLlQhHMonDHSW dmcp0myfo+l6cAAO0qQDi/JRpbZIonv3FoUPTcn2++GYricHjcv2t9JVHpnigG2Vu3 w6aOBdGMLOpV+hLarkc6aWoFSVzCwhzi5jX2a8WqckedCiqje9meCYvrFCft1cNgEy 4V2FpLagPCUBWnGcqgAy8CIvXC6g+H9vQDB9WHXtUkTF7EC+YJqOcWP76dmD3Ld0zE etJZsZMQUBtTQ== To: dmarc@ietf.org References: From: =?UTF-8?Q?T=c3=b5nu_Tammer?= Autocrypt: addr=tonu@cert.ee; keydata= mQINBFsX3wABEADx8PMtzm0dHjVdKRZgJDV4By1jS5f5awn7znEh0YM+crfm4zyEmQlZWfbo avIEJQDwGlUrA/FHdqdYdXI42fuPgmVkdSAynXZu5Upze/israDjKxBcQUIZ3eLr2BpJYNkq CaBdnueT5dmyRGwV0X9z8HFtvfQiompKewIC37NBlCxSBvC0ZHVQFQwV/6fR1PR6AeSqnHw9 QVj5AHxK1LebVyrzTRF4BGJRIjcd5tYdUVrCpeZ2/vXZpsG5buvDoD/HFelM8JvghRu2zsPn 8flsca4pMSMWrMxXe0gRtmxzOuI7IRw+fzaz2+BG/ja4ytt4aKBQ793PPy++BI6+wCsJ92St pFKfj85Bp2v0f94GHnQrAgrqXqpYd5btvwZZVjY+oaTGardLf5YlKBChoRDF0FdMfCTpfTDV /VFVVZGl1VS/mzabypVdSYJjU1lIw0X3PBcN+35Ta7rcEUFAwJW575MMS7EASlVN8Co5tz1y YMhjNtUDMnK+Rld/oIiqVLYNsQKavLyn/WvCwL+V01Uy9/u6pXbiVwR+bNGMHWJZoz9Lf35k ULVmyjhpSo/1LN2aqJy2kpV9qOM/EzkPDubBHgsvTpO92cQO+mFHGAoVextMSh36nsX+u3rN Kqqk1MSQWZmxMENNu0e5lLDVsCtEwuPhmLnu6mE81v/poYEQGQARAQABtBtUw7VudSBUYW1t ZXIgPHRvbnVAY2VydC5lZT6JAlQEEwEIAD4WIQSUd2uGah6Em8RWRtacqJ5Bd6iZewUCWxff AAIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCcqJ5Bd6iZe82WD/9+zAIf AwGB7gVHFFyMhNWnYftfdnM0loIfcVUgSpQhE62N/P1Ox64ams7R2jAXMEh/kvq+OWSYWcD1 rY7AC1mo2ViOLN62tx04bkWvrFRu883H1M+cEPc1JPM9br4ocWZB3XCbt3r4vm47ZYB2UmyL K+YGlJS2nbyRQ7THIrTbI4KkekgFr16YG3qR3v46VekYfpEpJ1m3JlkqZO5jV8fpsbi37W58 aVfeH4at/65Qa7uO59bFhWeWPnDMW9IQHMkg9IBQUzBmGjWX9rNonCTV7dkfrcLPK1by0eZd U71sRMVUG6TNxUFshoTDinBJOW99JCEpzkwhlFRF/sm8osNRPNXSFV/OG7xF0OE9vdlYHi4J g2aQNrTkmHFYybQgBP58QPoKj1EE5VvIsEvlpvfbsb3wu34RmjQTbqhIpSJ6cA5e9fwW2cCd NmVzsNhULQrGF6i+wV+b+b7MHQJ+C53LdH//xkfWB2RYaWgAbbcowVSSWoCTkfOF2D31Skct YIXJpVLiNzG60sTtiiinw5OdnV8P7EwR65mwJsC/uugY3YTzQbx/G2z4IvE/qAPoKnLOPMb2 Ec1rLIEs8Dfa7cM5C6/D+PS8SlE4JVPIXgyFGimlJeJaaldADCAQ567f17gmj5ZEL6uvLFEY FmB7SSJjOLqnFabr13zV94el7sOZt7kCDQRbF98AARAAnRG/CV2sJXh6hM9JYx4KnFs6ZUC0 kFq8lj72raBTx/rEggecwsj9r5hxJi0EyRD4Apid1K3vybiKZLEXE1VTZOZq0gxNw74IUOPy G1UCx3AGMZXKMVoCP+zYvNchlP4Xcsmpn7bLmklZy4xFM1jJTbBWP5znEIBRq9weVrcVQASz BTk3qC6/i4IfL3sAVvKrW2wNJ5jaaSifpn5t9SP8/hvinUeDk7VsCUQyyXaGDKGnf+2NixXd kYdJE/WQ+jOhNT5ujgC9mdCCPYwzC27+9eKzMcC3n4NdrBS+VUmfsM87hpER1dL+33WO8gUa H4KMNhOJ517v4Z/EXyWFez9a4oo9A4IPWXz1Z95NYd8x7KLb2XTr5qdKKSSD5TCCgzaXPR5W 2ivxWnQkxhfCwnT1tzZDAyvNbhwTUb0ggf5Tr478RLpofuMnluxe30/gcqFkE/4dFjo8sEks yBjTaXVJXFi39d0SGjjsHxsEUAu3YCQMBB+436uDdc8yb4yzKpiPja1jYGnfKKpcw1p33WaN VN6QnWzx3+dY9M7xouS8LKcITUB0VgsD/hwJdZcsjIT3BUZob7jbgaZAamuL0C8qvHuvNfwH f2o0ca7jZDNKm2qyZ8f4Oe9/XkqmOY3x6+zgIlpdH1Docdvh1RGv52eZx0tMd/OIMJHVLc6C OcQmdZEAEQEAAYkCPAQYAQgAJhYhBJR3a4ZqHoSbxFZG1pyonkF3qJl7BQJbF98AAhsMBQkJ ZgGAAAoJEJyonkF3qJl72YUP/j5PBqco2JYNpw/DGf9yqlmnPsPxBenv7Uz/MBNffIEZAh9h BlJ8oEfqzW+gCB+hyrPv/50pAp3Gn0QlYNAofk2djyXcK6g3LjC5MLWWpO0NZWum82UE/edq 25CJwaOcxvWMewMyrzNr8UVTeJfxaZ8khVaOB9H1NfUscIc0UvjMxCAQA6YuXA+DSheiQc6E Lm4lKA6cQIlKSMHvt72Cg7kknC+exVxKr14DWYQptfptP9LRaYq9I4FUucJfj7K7ZbN04+di jyYmk0AU0J9tpmTUTQcczqZwoOqhYWBAnWqqN0mGgiEU/AusTfgRb9DYFkogiCzthXPvKmmz RqiLmJkfxrQaV5uSOf7Bl4W1uATVHbLWlVhf4KnJWRGkE5u/HSoy7A2N/Spl1aT8bgsByqAT jXa9iYf3KcfNh4V45MzowvvaBjRXvAOZJl99dXtBKL0AFxCOKOp+k+FAPK4W+RvoDwP0tGPU YzReevXdM5maWRdJfBl7zi6PS5fQQFg3qJnmCoCY74GTIQJEKltj+HpcJbPt5dC3ifTCTXhP RX2CE9tRHkcMJWHlm8mpWZ+cKgoxUqu4+K5VfVsCPxx2sDKIk1MuEecVVlzpoNiaWqYpTMmQ or0hIzBhl+AFR27KMxG+9OK/tb5tVCMjcwdUuJJvQ7afI+JPmI/5/SwVcACg Message-ID: Date: Sun, 9 Aug 2020 19:54:27 +0300 BIMI-Selector: v=BIMI1; s=default; MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 16:54:36 -0000 Hi! I keep reading the discussion and I am surprised how people express views that current DMARC standard does not work. I am surprised that technical people here express this view. DMARC relies on SPF and DKIM. The latter is particularly important for the mailing lists to ensure that DMARC works. And when I read the cases it is clear that the issue is not of DMARC but of DKIM. RFC for DKIM says very clearly in the introductory part that and I quote "Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature." If this is not the case, the relay is actually violating DKIM standard. The lists we manage, we have made sure they follow the RFC and there is no issue of DKIM preservation. Some lists, however, have taken a different approach and to make sure we have delivery there also, we've looked at the elements which are used for DKIM calculation. We realise that not including the content into hash calculation can have a drawback but given that non-DKIM compliant lists do with content what they wish anyway, it's not much of a drawback. At the same time, prevention against spoofing and misuse is retained, which is the key for DMARC. Tonu tonu@cert.ee On 09.08.2020 18:11, Hannu Aronsson wrote: > Hello, > > Quick correction: As DMARC requires only either DKIM or SPF which I had= confused, this removes the need for the proposal point 1). Thanks for th= e off-list help received. > > This seems to be mostly an SPF issue, but still remains when > - SPF used used alone without DMARC (not sure if relevant for this disc= ussion, but it is a real-world problem) and=20 > - DMARC when DKIM is not used and it falls back to SPF > causing indirect emails to fail, especially with p=3Dreject or -all set= tings or overly strict receiver deployments.=20 > > For fixing the SPF issue a solution using ARC would be much preferable = to the SRS (Sender Rewriting Scheme) workaround, because e.g. the message= s would be unchanged, avoid problems with long email addresses or requiri= ng databases, and DMARC strict From alignment issues, etc. > > The other topics in the email,=20 > - forwarding use cases from M3AAWG discussions and=20 > - figuring out how we could get ARC reputation solution in place > are hopefully still interesting for this discussion. > > Yours, > Hannu > >> On 9.8.2020, at 13:28+0300, Hannu Aronsson wrote: >> >> Hello, >> >> I have been lurking here around for a while and we have been working a= t M3AAWG for some time as well. >> >> Today=E2=80=99s DMARC is breaking more and more email as it gets more = widely and often overly strictly deployed. >> >> I feel the major issue with DMARC is email forwarding in it=E2=80=99s = many forms, in addition to mailing list issues. It would be preferable to= try to do something that helps email survive as an open platform instead= of bad workarounds.=20 >> >> Transactional and person-to-person emails also should work reliably wi= th DMARC (and similar things) when forwarded i.e. indirect delivery. >> >> >> In M3AAWG discussions, we have identified many stakeholders who are se= eing major issues with DMARC and SPF when forwarding email for various va= lid reasons, examples: >> >> a) ISPs hosting user domains and email from to addresses in those doma= ins is forwarded to external mailbox addresses. This is very common for s= maller organizations. >> >> b) Alumni and organization member addresses like alumni.harvard.edu, a= cm.org, iki.fi and many others that provide a =E2=80=9Cpermanent=E2=80=9D= email address and forward email to user-specified mailbox provider addre= sses. >> >> c) Users forwarding email themselves to another email address e.g. bas= ed on rules or forwarding to their mobile device address, or forwarding o= ld ISP email to new ISP, etc. >> >> d) Some mailing lists and smaller email distributions, too, which work= just forward messages as they are to their members. >> >> e) and of course the many users using these services, and senders tryi= ng to send to them. >> >> So there may be many more stakeholders with DMARC issues than one migh= t initially think about. DMARC is creating a lot of =E2=80=9Cthe message = did not get thru=E2=80=9D issues for valid and real emails these days. >> >> To be worth pushing further, DMARC needs to be compatible with with em= ail forwarding i.e. indirect mail flows. >> >> >> To try to clarify my thinking around this, I tried to put some thought= s into a practical proposal format so it would be easier to consider, com= ment and discuss and think about the practicalities around it. >> >> Based on the discussion, it seems it might be more practical to try to= make =E2=80=9Csmall=E2=80=9D improvements into DMARC. If we can find som= e useful way forward, we=E2=80=99re willing to work on an internet-draft = for more formal commenting. >> >> Background, in addition to the use cases above: >> >> Because SPF fails with forwarded/indirect emails, and as DMARC today d= epends on SPF, it also fails in these use cases, especially when deployed= overly strictly. >> >> Normal email forwarding does not break DKIM as the messages are not ch= anged. We have new tools available today that can help, specifically ARC.= >> >> We should aim to make DMARC compatible with these forwarding use cases= , without losing the anti-abuse aims if possible. >> >> Draft proposal for comments:=20 >> >> When a DMARC recipient MTA is processing an incoming message, >> >> 1) If DKIM is valid, SPF results should be ignored. DKIM already prove= s the message is from the source it claims to be from, it doesn=E2=80=99t= matter if it arrived via an indirect path. >> >> 2) If DKIM is not used, but ARC is used, SPF processing should walk th= e ARC header chain as long as they have acceptable reputation and if a ma= tching IP address is found there, consider the SPF check successful. >> >> 3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as = today, or probably we should recommend always putting failing messages so= mewhere where the user can search for the =E2=80=9Clost messages=E2=80=9D= when needed, e.g. to the junk mailbox or quarantine. >> >> If something like this was in place, forwarders and others would be hi= ghly motivated to implement ARC, helping senders and recipients who want = to deploy DMARC or DMARC-like solutions. >> >> ARC reputation: >> >> ARC reputation has been discussed a lot and may be a major roadblock i= n going this way. I think the situation has changed now as DMARC issues b= ecome larger and affect more users, so people are more ready to do someth= ing about it now. >> >> * Technically we should be able to simply use DNS-based IP allowlists = to get reputation information for the ARC signing intermediaries. >> >> * ARC allowlisting would allows MTA admins to choose suitable allowlis= ts from free and paid options from various sources and vendors, just like= they use blocklists today for email already.=20 >> >> * We could probably even re-use existing email RBL allow/blocklists fo= r this purpose, if you don=E2=80=99t trust some IP reputation as sender, = you would not trust it for ARC either. >> >> * Free options would be available so DMARC2 software and solutions cou= ld include default settings that already work out of the box for smaller = organizations. =20 >> >> * It seems possible to maintain semi-manual lists of =E2=80=9Cmajor tr= usted=E2=80=9D forwarding services and have a suitable vetting process fo= r that. At iki.fi we have looked at doing something like this, if it woul= d help. >> >> * Additionally people would offer various automated lists based on oth= er analysis and methods. >> >> * ARC reputation could at this time have become an additional service = for email protection vendors to sell. Maybe before this was not viable ea= rlier because ARC was not widely available yet, or the SPF/DMARC issue wa= s not severe enough before? >> >> * Mailbox service admins could add =E2=80=9Ctrusted forwarding IPs=E2=80= =9D locally to help specific users with forwarding related issues. Today = there doesn=E2=80=99t seem to be an easy options for mailbox service prov= iders to help their users who have SPF/DMARC issues. >> >> Yours, >> Hannu >> --=20 >> Hannu Aronsson >> haa@iki.fi >> >>> Dave Crocker wrote 8.8.2020 5.37: >>> >>> I suspect the calculus is less in the pragmatic terms of asking how b= ig this threat is and more in terms of wishing for some version of protec= tion and thinking this helps to achieve it. >>> >>> The degree to which so many folk embrace does not appear to have that= much empirical basis, but rather a sense of feeling a need to do somethi= ng and at first blush this seems to be something. > > -- > haa@iki.fi https://www.haa.iki.fi > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Aug 9 09:58:56 2020 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 657773A0A73; Sun, 9 Aug 2020 09:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 Y33E2RyC_m5I; Sun, 9 Aug 2020 09:58:53 -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 6DC733A0A66; Sun, 9 Aug 2020 09:58:50 -0700 (PDT) Received: from [192.168.43.69] ([172.58.75.214]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 079H1VV1013202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 9 Aug 2020 10:01:31 -0700 To: =?UTF-8?Q?T=c3=b5nu_Tammer?= , dmarc@ietf.org References: Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 9 Aug 2020 09:58:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 16:58:55 -0000 On 8/9/2020 9:54 AM, Tõnu Tammer wrote: > "Message > transit from author to recipient is through relays that typically make > no substantive change to the message content and thus preserve the DKIM > signature." If this is not the case, the relay is actually violating > DKIM standard. However, a mailing list is not a 'relay'.  The term relay is meant to refer to an MTA. Reviewing RFC 5598 might help. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 9 21:48:30 2020 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 E7C6B3A13C9 for ; Sun, 9 Aug 2020 21:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 U4jOiVV9HMbp for ; Sun, 9 Aug 2020 21:48:27 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 C733C3A07D7 for ; Sun, 9 Aug 2020 21:48:27 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:b42c:231c:10db:4ad9]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07A4mQ4h012294 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sun, 9 Aug 2020 21:48:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1597034907; bh=yZR1Gp/seqT/Si4FI6Ze0cxItGjVwUIyd7CY4UsDMe4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dk/RUq9zllVQhVhWuZIsLjcj6m8Q6yTWgF1oVhBh+Up4ZMBB5VKj6R9FRu/x4dwec 9XO3HSoax3kiIBlmWVfZPaptZ2RQVU4IsgsgcBCozY/TauDFY8diBAcO3DgnDmXC13 cwR3Flre9gCsN2hau1Swa3aKLZPkNecYpQ8qeuKE= To: dmarc@ietf.org References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com> <6053db20-b888-d597-476b-e76f47633fb3@tana.it> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Sun, 9 Aug 2020 21:48:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 04:48:29 -0000 On 8/5/20 9:36 AM, Jesse Thompson wrote: > On 8/4/20 11:52 AM, Alessandro Vesely wrote: >> On 2020-08-04 6:10 p.m., Dotzero wrote: >>> There is another solution. Move users to a separate domain from the domain > Long ago we put users on our org domain as a way to unify users (in a very decentralized institution) under a single domain identity, and that branding decision is not going to be undone, politically. Any project to move users from one domain identity to another is a huge lift; it takes a lot of time, effort, and never actually completes due to stragglers with very legitimate reasons to not give up sending from their old address. > > I think that end-users would rather see their list mail be rewritten than be told to change their identity. I know that some people on this list think that the domain in the from header isn't commonly visible anymore, but the domain is extremely important to users' sense of identity. >>> your transactional mails are sent from. You can also put users on a >>> separate subdomain. You really don't want to move users; they would need to notify all of their correspondents. Instead, leave the users where they are and move the transactional mail to a different domain (or to a subdomain) and put the restrictive policy there. -Jim From nobody Mon Aug 10 01:41:31 2020 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 6A49E3A1546 for ; Mon, 10 Aug 2020 01:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 MGCbDVPlOduv for ; Mon, 10 Aug 2020 01:41:29 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 C5BE73A14AC for ; Mon, 10 Aug 2020 01:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597048873; bh=eEtkGOQQLSRU1Xb7t5pDa4lPMcJ0ap1e7TgNtrJ20mE=; l=2953; h=To:References:From:Date:In-Reply-To; b=DZ0w5YVaDZMF2mbsRyvISTvBaGkPEfK71ZczpQqEBa3S93J3Yd1vba+EDc+D3dpun 5tq29WuaxA7sxU7pKhfIvnzQc6VsrF+9O/sCwsI+9JVDAKgXIlC1dpNHTEomsNtn3i 5nJh0FBy34Wd69Bi3O209lSAIa5jzx778a12qBVrah1LVQ72QxnoikMvm5XQI Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.36.35]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC013.000000005F310828.000039C6; Mon, 10 Aug 2020 10:41:12 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Mon, 10 Aug 2020 10:41:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:41:31 -0000 On 2020-08-09 6:54 p.m., Tõnu Tammer wrote: > > DMARC relies on SPF and DKIM. The latter is particularly important for > the mailing lists to ensure that DMARC works. And when I read the cases > it is clear that the issue is not of DMARC but of DKIM. Indeed, one of the proposed workarounds, Recognized Transformations of Messages, addresses DKIM verification algorithm. Yet, it is being discussed on this list rather than ietf-dkim. I hope it becomes a WG draft soon. > RFC for DKIM says very clearly in the introductory part that and I > quote "Message transit from author to recipient is through relays > that typically make no substantive change to the message content > and thus preserve the DKIM signature." If this is not the case, the > relay is actually violating DKIM standard. As Dave said, MLMs may need to carry out some transformations while usual relays don't —except those which add **SPAM** subject tags or antivirus footers. The l= tag is one of the early envisaged provisions to address footer additions. It was deprecated because of the possibility to add malicious footers. Of course, adding a footer /is/ a substantive change. However tight we define recognized transformations, they have to allow the addition of a few lines and a URL. Hence, they can be malicious. Therefore, we need to differentiate two classes of domain owners, those who can afford such risk and those who want top strictness. > The lists we manage, we have made sure they follow the RFC and there is > no issue of DKIM preservation. https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Turn_off_all_message_modifications > Some lists, however, have taken a different approach and to make > sure we have delivery there also, we've looked at the elements > which are used for DKIM calculation. We realise that not including > the content into hash calculation can have a drawback but given > that non-DKIM compliant lists do with content what they wish > anyway, it's not much of a drawback. At the same time, prevention > against spoofing and misuse is retained, which is the key for > DMARC. That only works if you trust the MLM. We cannot rely on trust, because there is no widespread common reputation system. DMARC does provide for "trusted_forwarder" and "mailing_list" policy override types: However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner's policy. For example, if the Mail Receiver knows that this particular email came from a known and trusted forwarder (that happens to break both SPF and DKIM), then the Mail Receiver may choose to ignore the Domain Owner's policy. However, that kind of hush hush is not deterministic, since the protocol does not define the "external information". Providing for a URL pointing to such external source might help. Best Ale -- From nobody Mon Aug 10 03:57:54 2020 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 042333A14DA for ; Mon, 10 Aug 2020 03:57:53 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovxwq59bZaPX for ; Mon, 10 Aug 2020 03:57:51 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B122F3A14D5 for ; Mon, 10 Aug 2020 03:57:51 -0700 (PDT) X-ASG-Debug-ID: 1597057069-11fa311da652430001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id vxnsH10xm79oLcE4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 10 Aug 2020 06:57:49 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=0zRRSGBtJyqrRBCIgLoTgY8Vymy2NuQLqji00RWhwUU=; b=O5szMll9+KFWfJK5gLbJxJtBvQ3PPb/W2MwRdnHR9tHB0wPMzjQJuk7PBiyb+FKuG KlYgwJhLJQ/zPSr55TNkoL6gwSCndjvIhKyxb79A4bJfyHn19hcyltF2411IArfB+ X9ONshIM7qWTYi/1t7jX9JZxE00q0LCB9uHHb2PqY= From: "Douglas E. Foster" To: "Alessandro Vesely" , Date: Mon, 10 Aug 2020 10:57:40 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] non-mailing list use case for differing header domains Reply-To: fosterd@bayviewphysicians.com Message-ID: <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=b073e2f02e704cfd920e450418d3b346 In-Reply-To: References: X-Exim-Id: 2ef8e773e7bf467481a05ab3fc4d937f X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597057069 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2639 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83815 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 10:57:53 -0000 This is a multipart message in MIME format. --b073e2f02e704cfd920e450418d3b346 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alessandro observed: >> However, that kind of hush hush is not deterministic, since the >> protocol does not define the "external information". Providing for a >> URL pointing to such external source might help. Even an external reputation system requires recipient participation. That= is why I suggested both a send3=3D"parameters" clause to indicate sender s= upport for third-party authorization and a verify3=3D"parameters" clause to= indicate recipient support for third-party authentication. When both ar= e visible to the non-domain message source, that source can have confidence= that the message will be handled as authorized. We have a very complete specification for ATSP signature delegation. Do we have a similar document for your RHSWL approach? Do we have a similar document for lookup into a trusted-forwarders list, as= suming a service like that can be revived? If ATSP and RHSWL solve essentially the same problem, we need to do an anal= ysis of which is more likely to succeed, and proceed with that winner. Third-party lookup is a very different approach than ATSP, so they can supp= lement each other. DF --b073e2f02e704cfd920e450418d3b346 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Alessandro observe= d:
>>  However, that kind of hush hush is not determin= istic, since the
>> protocol does not define the "external = information". Providing for a
>> URL pointing to such exter= nal source might help.

Even an external reputation= system requires recipient participation.   That is why I suggested bo= th a send3=3D"parameters" clause to indicate sender support for third-party= authorization and a verify3=3D"parameters" clause to indicate recipient su= pport for third-party authentication.    When both are visible to= the non-domain message source, that source can have confidence that the me= ssage will be handled as authorized.

We have a ver= y complete specification for ATSP signature delegation.   
<= div>Do we have a similar document for your RHSWL approach?
Do we = have a similar document for lookup into a trusted-forwarders list, assuming= a service like that can be revived?

If ATSP and R= HSWL solve essentially the same problem, we need to do an analysis of which= is more likely to succeed, and proceed with that winner.

Third-party lookup is a very different approach than ATSP, so they = can supplement each other.

DF

=

--b073e2f02e704cfd920e450418d3b346-- From nobody Mon Aug 10 10:24:20 2020 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 E91553A0B97 for ; Mon, 10 Aug 2020 10:24: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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=FKhlCiYX; dkim=pass (2048-bit key) header.d=taugh.com header.b=fuwr9llM 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 8kRnLYzjUwB2 for ; Mon, 10 Aug 2020 10:24:17 -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 46FDB3A0B8E for ; Mon, 10 Aug 2020 10:24:16 -0700 (PDT) Received: (qmail 37859 invoked from network); 10 Aug 2020 17:24:12 -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=93e0.5f3182bc.k2008; bh=fvyUBaR5xBk/LA9++t8uzWWRbJ1iAnzqnIU21Bq6EvQ=; b=FKhlCiYXJHEGG5pLnMOGAcy1B/kBXf+tANgK/ZCDBNqzw2vcUL5JoaOYWgBqZmyuqjHEya1IfNRrkL+itESVX/heBMLFNQYamVKnHvleoRFXVYcR7tKrbl++9IBHRlPn0hyOuTIgLqITe9FOj9td26ERx76F607h/9Q57kxJdyXcc1T5KSgd2VaJq0Hx5N7TPgkOhgXqU3U6N84sgiv1V4rAVuv1zrmigH5PCBdYnZesAEZFR+AH3hPa2f9piZnkMR0TVOAKZ9ri31LPOjn28kqiZDCaHuI9ghJKpfPcKMt5fv3YU5HA9MFacwO6rX1c91GSEIVPl60FddWHzgavRw== 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=93e0.5f3182bc.k2008; bh=fvyUBaR5xBk/LA9++t8uzWWRbJ1iAnzqnIU21Bq6EvQ=; b=fuwr9llM2GtJG+abfe8uwXuxKs28tktpaSqI8z5vkL9J7he8ZxCpnJnTMtMK4/0QsqSuThbrlLZQlrDY7gBVKOYtOt0SnN4JfpZ09Diz8aScAJkX+YYZ3z7OwAnuitzNLnroVu0iM3/5UoDUO4ML2KdtmsmGzkkjk4eqrVXzDcHDfWLpUgIkrJZdaPlZyaLqCGb7xEFgZxHd+OnmJoiqgqU0F4P1AIy7q3w9tfnXLo1ruM7+fAUY7oEmQK7Th0+HPPaKmRKa8gvfuqPADJMSihBTdbmdr6sHFh52s7VU54GXG6lDbjmRPDSeOvP2GXC1VdUcMdf7TYwuGqPqHtSN5g== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 10 Aug 2020 17:24:12 -0000 Received: by ary.local (Postfix, from userid 501) id A13681E7CD8B; Mon, 10 Aug 2020 13:24:11 -0400 (EDT) Date: 10 Aug 2020 13:24:11 -0400 Message-Id: <20200810172411.A13681E7CD8B@ary.local> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 17:24:19 -0000 In article <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> you write: >>Even an external reputation system requires recipient participation. That is why I suggested both a send3="parameters" clause to >indicate sender support for third-party authorization and a verify3="parameters" clause to indicate recipient support for third-party >authentication. When both are visible to the non-domain message source, that source can have confidence that the message will be >handled as authorized. We have had a lot of attempts at third-party authorization schemes going back at least to vouch-by-reference in 2009 and ATPS in 2012, and the Spamhaus Whitelist in 2010. Every single one of them failed, not due to technical problems, but because nobody was interested. The only third party reputation systems that anyone uses are DNSBLs like Spamhaus that publish negative reputations, and even there you can count the ones with non-trivial use on the fingers of one hand. With this in mind, I cannot see any point in designing yet another vouching or authorization scheme unless we have evidence that an interesting fraction of the world's mail systems want to use it. I don't see that, and honestly see no chance that we ever will. R's, John From nobody Mon Aug 10 10:26:56 2020 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 990B23A0B9D for ; Mon, 10 Aug 2020 10:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 VlXA25BGVSCl for ; Mon, 10 Aug 2020 10:26:52 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DA13A0B58 for ; Mon, 10 Aug 2020 10:26:50 -0700 (PDT) Received: from [192.168.43.69] ([172.58.19.36]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07AHTWVJ002706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 10 Aug 2020 10:29:32 -0700 To: dmarc@ietf.org References: <20200810172411.A13681E7CD8B@ary.local> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> Date: Mon, 10 Aug 2020 10:26:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200810172411.A13681E7CD8B@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 17:26:56 -0000 > We have had a lot of attempts at third-party authorization schemes ... > With this in mind, I cannot see any point in designing yet another > vouching or authorization scheme unless we have evidence that an > interesting fraction of the world's mail systems want to use it. I > don't see that, and honestly see no chance that we ever will. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 10 10:30:15 2020 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 3A9BD3A0BCA for ; Mon, 10 Aug 2020 10:30:14 -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, 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 xtCc6zQ2AzBa for ; Mon, 10 Aug 2020 10:30:13 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4AF3A0BC2 for ; Mon, 10 Aug 2020 10:30:12 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id c15so8937676wrs.11 for ; Mon, 10 Aug 2020 10:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7iZvTM+/CWHRFzdBXyRyQX8rLbVr23QIpDDMpRpM0NA=; b=nTDP1utbSuI/WF3zEwzBmwOTd75LaSUrqq2XiM1jQJyR6EQeofXBuqiwmdnwkSLxCM rhqkylpToki//HHpvRYXRNRxgyh1CqthPCKJGHxytupIvwDOe9drn7dq79khDnJ7ZC9T gh8uv9ac/ACd7onDYXFXzzROjIKPU0AFCShSOVpmkefBEyWCE3XdrvSibYe0uBk18rIt DWzuBH7K9fLB08vIVGijdg9wRKlmUbUPkkgTRGUQdiIL8tN9zARquZjkcZTpkhylOTQY PzYDml5Z4yyI2jHRbMJWiQw6tMBmMOYSx4vMRPIkVzYMaKOI9utzJVBykfLYH4rsW1Qf VABQ== 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=7iZvTM+/CWHRFzdBXyRyQX8rLbVr23QIpDDMpRpM0NA=; b=pjwWjhbHTdHOuCfKlEZDtXJW8g+69lqzC5QVkhN9b+ZCyCuepp4mN6WC3rpqywLqXs IyJx2+PQK8MuC+oww7AdVp4B3bry8ka7TlmYekRtheOKqedMzGreKNKZaNVbPdFz4GuT 6ZkULEaL0riYv47WgSPDYJ2gWmMJXkb3x80LBCR6LDEQ0wrIFWeuSYDgLPkhPw9AYbEh pV5K3KvyxsAGAr/e6exOAiklxTHJqABoHu1JAaHWLF3UyxGppb+DPDAzgy23xbWhPByv Bd2pN1CRG85SBVmuF1EHul9YrUYKOteZtyJXrYF4izkrNOWd6aJAjXkGh7b5ODG0PfpA fsCQ== X-Gm-Message-State: AOAM532sih2KT5bEdMipgaOuJawZNAhXucBhKCxAeb8Ae1cisoKed/kZ KeK37vlPV1YujOGOpQLZ6astfgEz4XCiopI1MnOeBg== X-Google-Smtp-Source: ABdhPJyAX4xPASDBYAjeXR9uYcsDXakvZNcn/K9Qy176cnVURKH+bC/PWcydY/BPIy2cL+cL+mLvH782jxP3Kz1gwvE= X-Received: by 2002:a5d:4ecf:: with SMTP id s15mr2445312wrv.202.1597080611372; Mon, 10 Aug 2020 10:30:11 -0700 (PDT) MIME-Version: 1.0 References: <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> <20200810172411.A13681E7CD8B@ary.local> In-Reply-To: <20200810172411.A13681E7CD8B@ary.local> From: Dotzero Date: Mon, 10 Aug 2020 13:30:00 -0400 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000084c34a05ac894eac" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 17:30:14 -0000 --00000000000084c34a05ac894eac Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 1:24 PM John Levine wrote: > In article <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> you > write: > >>Even an external reputation system requires recipient participation. > That is why I suggested both a send3="parameters" clause to > >indicate sender support for third-party authorization and a > verify3="parameters" clause to indicate recipient support for third-party > >authentication. When both are visible to the non-domain message > source, that source can have confidence that the message will be > >handled as authorized. > > We have had a lot of attempts at third-party authorization schemes > going back at least to vouch-by-reference in 2009 and ATPS in 2012, > and the Spamhaus Whitelist in 2010. Every single one of them failed, > not due to technical problems, but because nobody was interested. > > The only third party reputation systems that anyone uses are DNSBLs > like Spamhaus that publish negative reputations, and even there you > can count the ones with non-trivial use on the fingers of one hand. > > With this in mind, I cannot see any point in designing yet another > vouching or authorization scheme unless we have evidence that an > interesting fraction of the world's mail systems want to use it. I > don't see that, and honestly see no chance that we ever will. > > R's, > John > > +1 Michael Hammer --00000000000084c34a05ac894eac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 10, 2020 at 1:24 PM John = Levine <johnl@taugh.com> wrote= :
In article <= ;2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> you write:
>>Even an external reputation system requires recipient participation= .=C2=A0 =C2=A0That is why I suggested both a send3=3D"parameters"= clause to
>indicate sender support for third-party authorization and a verify3=3D&= quot;parameters" clause to indicate recipient support for third-party<= br> >authentication.=C2=A0 =C2=A0 When both are visible to the non-domain me= ssage source, that source can have confidence that the message will be
>handled as authorized.

We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.=C2=A0 Every single one of them failed,<= br> not due to technical problems, but because nobody was interested.

The only third party reputation systems that anyone uses are DNSBLs
like Spamhaus that publish negative reputations, and even there you
can count the ones with non-trivial use on the fingers of one hand.

With this in mind, I cannot see any point in designing yet another
vouching or authorization scheme unless we have evidence that an
interesting fraction of the world's mail systems want to use it. I
don't see that, and honestly see no chance that we ever will.

R's,
John



--00000000000084c34a05ac894eac-- From nobody Mon Aug 10 12:05:01 2020 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 38F093A0B23; Mon, 10 Aug 2020 12:04:59 -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, 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 t60UsTVPofqo; Mon, 10 Aug 2020 12:04:57 -0700 (PDT) Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 D21193A0A97; Mon, 10 Aug 2020 12:04:57 -0700 (PDT) Received: by mail-oo1-xc2d.google.com with SMTP id z11so2113621oon.5; Mon, 10 Aug 2020 12:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=nDanMwa6IpMtIypOgc3s7wshTITi+0n8F+uY4c+PPr0=; b=XSpTZhX/G2p7Ca4cuxCA0eEkPDSeiC/qL0i+LDD/jl4R/9lHmIZM8dpjbTNCpC6poI q9tfhEQBq8a6YMwTshvjjTtcXjWH0mFdF4e0IGsyxRwKt1V6/ciLoi5wGlJATbUVXgpC qpFTNlcaelvlGcYUEolq406KSVCBTQ+bWRdmku4d7h+XAxyVLmXFP6eQ8k3ID7fssB6T 2pveso0txvE+Mc5qC2sP5ZzofIPS4/CtAOnZWDmbjxHuQiA6o196nsZwq86GEUbh8nIr efbDRpUklvEhCK6I5uE/v5wak06tQ4KlokhcnljVp2/46Z8zND9OXMKicJmF8ukhTOXE vB0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=nDanMwa6IpMtIypOgc3s7wshTITi+0n8F+uY4c+PPr0=; b=O6KwAIKsZfwFiN7NScwEDTelikjbbwquWIU3MH5OCIwdhlWn8yqJj3k59i3o13tyNP HYAwwZ3oTHDQ/GYI7J4rvVH2gxVTD+4WaNYFU3byGvOn4PI/b9DOWr+VqReGQXxYsyZB 4+5nRXxQRrIZErq1j4flNsI3fNL4FpECFngcYe1UXBPYsOKfPmc7pqA+Mf585TwWTqV9 l/XSZSve/6UkO0Cwvb2dsEUs3BRcXHHacDi0WJb9VWuEiu45z9u1LX9bE5G+PhCcmSpO BWhm+St3Cp4Mrb2rKYHfk9M33WZU7eYIc05vs7nzdkkQ4VTE17lWTP0fKlUzNKbRQ+Eo 6+Aw== X-Gm-Message-State: AOAM5338+2dLVaIS0HquUvy4+iPnhHmxGoNpIPF4MRC3GgEm2Aay0KA1 c2OqYACz3cizwXMIytuAnFysz9hDJhZpycUhmYgoc3Re X-Google-Smtp-Source: ABdhPJz1Z1IIdwkR9NM4HAX+CeVVoFxSlb+e2lG7Hk1JhFKKehfwRS1B3oDjWWScH/osi1/oVJEzW3g62/RpLtCJ1ew= X-Received: by 2002:a4a:ab85:: with SMTP id m5mr1977010oon.66.1597086296861; Mon, 10 Aug 2020 12:04:56 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Mon, 10 Aug 2020 15:04:46 -0400 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000666f8a05ac8aa14b" Archived-At: Subject: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:04:59 -0000 --000000000000666f8a05ac8aa14b Content-Type: text/plain; charset="UTF-8" During IETF 108, the chairs realized that there was interest in Dave's RFC5322.Sender draft. This starts a Call for Adoption for draft-crocker-dmarc-sender The draft is available here: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ Currently, the draft is marked as "Standards Track". The chairs feel if the working group does adopt this, it should begin as "Experimental". If we start to see adoption of this work, this can be changed back to "Standards Track" before Working Group Last Call. Of course, we welcome input from the working group on this. Please review this draft to see if you think it is suitable for adoption, and send any comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 24 August 2020 Thanks, tim wicinski --000000000000666f8a05ac8aa14b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

During IETF 108, the chairs realized that there was interest in Dave= 's
RFC5322.Sender draft. =C2=A0

This starts a Call for Adopt= ion for draft-crocker-dmarc-sender

The draft is available here: https:= //datatracker.ietf.org/doc/draft-crocker-dmarc-sender/

Currently= , the draft is marked as "Standards Track".=C2=A0 The chairs feel= if the
working group does adopt this, it should begin as "Experime= ntal".=C2=A0 If we start
to see adoption of this work, this can be= changed back to "Standards Track" before
Working Group Last C= all.=C2=A0 Of course, we welcome input from the working group on this.
<= br>Please review this draft to see if you think it is suitable for adoption= , and
send any comments to the list, clearly stating your view.

= Please also indicate if you are willing to contribute text, review, etc.
This call for adoption ends: 24 August 2020

Thanks,
tim wici= nski
--000000000000666f8a05ac8aa14b-- From nobody Mon Aug 10 12:05:14 2020 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 B30783A0C40; Mon, 10 Aug 2020 12:05:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159708630567.25939.3916026035849808234@ietfa.amsl.com> Date: Mon, 10 Aug 2020 12:05:05 -0700 Archived-At: Subject: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:05:13 -0000 The DMARC WG has placed draft-crocker-dmarc-sender in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ From nobody Mon Aug 10 12:09:21 2020 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 EA0053A0C43 for ; Mon, 10 Aug 2020 12:09:18 -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=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 n07Pjsg8smLZ for ; Mon, 10 Aug 2020 12:09:17 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C04FF3A0E8A for ; Mon, 10 Aug 2020 12:08:41 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id i15so7794479ils.9 for ; Mon, 10 Aug 2020 12:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QRBfSlmzy0JRGYpIIO0Hq1wGyeJ4Cp+yO/WmMfuepPI=; b=C3RIh2fbFX2qrAptd5MEYViiowtaitkz/D7UoDgElQzot8HibGStTPoZug629t9nMO +8pkNxtNsqj4H9nCEpiKx3ZwEwMz3yIQvTQnNXJaXBtqIpvB2pbtgQd69+FI/cYBCHWg R2B4YbJzC5NDZAOgZFRD3pATmGQ+1KcOtVXVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QRBfSlmzy0JRGYpIIO0Hq1wGyeJ4Cp+yO/WmMfuepPI=; b=OkWt/MAIXlkQq9hRqjPVzk3ncf5Si2EKB5Kd3pMpOZndMks6+7dMznrnXax8FhNdIZ DB2B4YKOf0RAD/R6r+L/ygEqRaoNxzKLt4/0vZ1HxHFR0qYbhW6Qrv9rfgsoTqeW/K8S ru6AP0/ZEznsr1yB+Fqu71MjYYG3X5BgF9Beymi7vArFZZz2n+kCnObJ1jWXj1+Gllwz ZPzLxs0kT8MTQXRfGdDhoDzkcXT1bzdjdkWuOERgjr7Ats9LH9PqsjczhUKWkU83oI3o HKvu7beVD2ineSnfWHkIIrXSQx639yhUBk0W4E4f8BJ49+ceptjx1G3ggXJ1c/C27lBH Yq3g== X-Gm-Message-State: AOAM530Mp90TcBFiqFRtgTmqwxjLdMuYQqork5yqtuf3A/ghCqP9FpXg YsZkc8dJnzYG96IEHHBdhC4alYPufN9Mct2K0yx711YQFIs= X-Google-Smtp-Source: ABdhPJxVkH7AccgOps1VvwAMbCehMt9MMDw2yxkpPvnsPk/NVrr1aPs5wKPz04kNvje0n9ptTU7hHw4+HJ6S2w1AzmU= X-Received: by 2002:a92:d611:: with SMTP id w17mr19220554ilm.103.1597086520454; Mon, 10 Aug 2020 12:08:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 10 Aug 2020 12:08:08 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ba4bed05ac8aaef2" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:09:19 -0000 --000000000000ba4bed05ac8aaef2 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. > > This starts a Call for Adoption for draft-crocker-dmarc-sender > +1 for adopting the document into the WG for continued discussion. --Kurt --000000000000ba4bed05ac8aaef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 12:05 PM Tim Wici= nski <tjw.ietf@gmail.com> w= rote:

= During IETF 108, the chairs realized that there was interest in Dave's =
RFC5322.Sender draft. =C2=A0

This starts a Call for Adoption for= draft-crocker-dmarc-sender

+1 for adopting the document into the WG for continued discussion.

--Kurt
--000000000000ba4bed05ac8aaef2-- From nobody Mon Aug 10 12:10:53 2020 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 3E0FE3A0B4A for ; Mon, 10 Aug 2020 12:10:52 -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, 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 5wsIaf79C-4k for ; Mon, 10 Aug 2020 12:10:50 -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 B16013A0A97 for ; Mon, 10 Aug 2020 12:10:50 -0700 (PDT) Received: from [192.168.43.69] ([172.58.19.36]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07AJDKZa011740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 10 Aug 2020 12:13:30 -0700 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 10 Aug 2020 12:10:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:10:52 -0000 Folks, I was quite surprised -- at the level of astonished -- to see the pushback on the Author header-field proposal, since it is such a simple and straightforward mechanism. I'd like to ask for clarity from the group on both concerns about it and desires for it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 10 20:47:48 2020 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 E75E03A094F for ; Mon, 10 Aug 2020 20:47:45 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=qiBo+wr7; dkim=pass (2048-bit key) header.d=taugh.com header.b=Q4N9ulMF 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 tDpscvdySuGh for ; Mon, 10 Aug 2020 20:47:44 -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 6B3523A0943 for ; Mon, 10 Aug 2020 20:47:44 -0700 (PDT) Received: (qmail 71865 invoked from network); 11 Aug 2020 03:47:41 -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=118b7.5f3214dd.k2008; bh=Yd6zFPxGrJt6r9TsSS5ZEuh8/E3dUq3+7B3G7uFlQlk=; b=qiBo+wr7oRBaRFS863VpH4yTpYQawEMgE/ZzTm6WwGwsHolQC4OVH9k7lJ0tr44Kyx2aB0dRQTiky/DSdjZOO8YzakcxpxombWTw8DYKhPPWQuxR5AW1QsLgolRkxJNAs9kV55kpPZIKis/HGaN3Yz5G1ECe7xSM6f24xueapHzSmRyxbhDS9eYA7aFIqj/bUxxCQazaFiYd5llsuTuRlzqqj29OTsjZLsaIQHWQNoFjHWAQx0zuOZvoXAGqDKsfD3MAkpPord0V96ztAgwccA/xzx38XQ15gkaQanMKFhXWQsYUsnyHOMq/PF89Sfu8TehI7cahhHEr1yhgrX1+xQ== 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=118b7.5f3214dd.k2008; bh=Yd6zFPxGrJt6r9TsSS5ZEuh8/E3dUq3+7B3G7uFlQlk=; b=Q4N9ulMF+tUkarHA2KWKP48pAqPpDkuLxTtKp9fTBm2NdkyxW6xkaV+8+ZChZqf8zurv5NX91/edQyb03C9HQjzL1zLSUW7SWcXGrOrRUhy+LETTAcSZSP4Rd3vWq/Uvo8fvvNXD7XtcLiel+cTV55C0EVzrN35RFhFEGCoAeGJKr58pKhP8Y6u99Ub7Ma5CuM44y6liGRGeQ5iV9wpzGpb/5hFbMYG3+A8JXDZFl5/6kNx+6FupzqKgV3wySO+egXHnkIMV99yCtff8dMdvWLGme0qQyhgPAIkjBB1l5vhOeNylgvz8pB+acAQlbQT81A3/1Yxpm1rM4R27saBniw== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 11 Aug 2020 03:47:41 -0000 Received: by ary.local (Postfix, from userid 501) id BA1831E7FDBF; Mon, 10 Aug 2020 23:47:40 -0400 (EDT) Date: 10 Aug 2020 23:47:40 -0400 Message-Id: <20200811034740.BA1831E7FDBF@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net 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] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 03:47:46 -0000 In article you write: >Folks, > >I was quite surprised -- at the level of astonished -- to see the >pushback on the Author header-field proposal, since it is such a simple >and straightforward mechanism. The different bits in the message are simple enough. The problem is that it might as well be called Really-From, and then when enough systems do mutant DMARC to cause the same problems with Really-From that we have with From, the step after that is Really-Really-From, so on ad nauseam. While that happens (or maybe doesn't) we have no idea whether MUAs will display it or let you enter it or automatically make it the same as From or maybe something else, likely making it a disaster for interoperability. I think the DMARC sender draft is a lot more promising. R's, John From nobody Tue Aug 11 20:32:33 2020 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 081FA3A0EBC for ; Tue, 11 Aug 2020 20:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 eiNN3j0QTi73 for ; Tue, 11 Aug 2020 20:32:30 -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 F14E83A0EBF for ; Tue, 11 Aug 2020 20:32:29 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07C3ZCVv021405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 11 Aug 2020 20:35:13 -0700 To: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> From: Dave Crocker Organization: Brandenburg InternetWorking Reply-To: dcrocker@bbiw.net Message-ID: <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> Date: Tue, 11 Aug 2020 20:32:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200811034740.BA1831E7FDBF@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 03:32:32 -0000 >> I was quite surprised -- at the level of astonished -- to see the >> pushback on the Author header-field proposal, since it is such a simple >> and straightforward mechanism. > > The different bits in the message are simple enough. > > The problem is that it might as well be called Really-From, and then Your opening item is that you don't like the name of the field? In any event, I suggested "Author" because it is simple and accurate. Something like what you suggest - on the off-chance you are serious -- offers distracting tone and baggage. > when enough systems do mutant DMARC to cause the same problems with > Really-From that we have with From, That's a premise with no foundation and arguably no validity. At the least, if you are going to use this as the substance of your concern, perhaps you could explain with some care why you are so certain this will happen. Here's why I think it won't: They already have From:. The real value in DMARC is not what is displayed to the end-user but in having a required field that cites the originating domain name. That doesn't change if there are additional fields that might or might not mention the originating domain. > the step after that is > Really-Really-From, so on ad nauseam. While that happens (or maybe > doesn't) we have no idea whether MUAs will display it or let you enter The question of whether any MUAs will implement this is the same concern for any proposal. So on its own, that would mean we never do anything unless implementers and operators promise to use it. Absent an IETF formal policy to that end... > it or automatically make it the same as From or maybe something else, > likely making it a disaster for interoperability. > > I think the DMARC sender draft is a lot more promising. It has it's own problems. There's no perfection here, since the task is retro-fitting work-arounds to an established mechanism that has been altered. As I've noted, realistically, DMARC makes the From: field be the Sender: field. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 12 04:46:00 2020 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 EE4C73A0F80 for ; Wed, 12 Aug 2020 04:45:57 -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 1ZpZHK1ryl46 for ; Wed, 12 Aug 2020 04:45:53 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 2074C3A0F9C for ; Wed, 12 Aug 2020 04:45:53 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id c6so1288208ilo.13 for ; Wed, 12 Aug 2020 04:45:52 -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=QY7SNOsCFauWP8iUwvd8KWWl+elI0bkTitW5IceLTSA=; b=F+tE9SVLqTvGRliZRay/U3eXJnYu2vmxpgpt7Gq1OGvRDYrfWgIRp2WrFg5+GH4KBM 01fgWZACubZJMrLfT6kB+8MRtr78N3G+Z5zFV/aDR8vc9VxWi+nTQ8xXyAmhjTMErlAp qh0QLg01jsBLUlDo74INocJ/7Yrvc1Spp6Wbo= 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=QY7SNOsCFauWP8iUwvd8KWWl+elI0bkTitW5IceLTSA=; b=ZE2QSvz7hBfRE1sHDg9TCo1clrxi6UGkYdbzOx7e/GRtENIcA4fXs1r12b7eVebwxW I24xYffdkYQtQzZbKytCOKksdNYiZ1osnORKMtIMOdTs8TWL0sLtdKj5YVBNJdoGhWcI L/FY/+wZoU8WJxVkJoG0VmMSxlQZpsZ/58bPtJOjWcDAWwtLbnBY5zScju+1gEiyVqpb Dvp1dCxqLmHqWsKHmtHbzUCQF7NI+XggLeqB+EqGLZ/RdhfRIG6Y35T/iKdYKT2DbTa/ 8wdpk0Powe9lz0RZ5PnzZbc11Go9JW8ncprC2n9Bauf6x4mMgBrEjWv6PZh9Gx/xwc9E AbqA== X-Gm-Message-State: AOAM532X1LamVi7CcXwRJ+a2II3eJ+GeTowAfD8QOYj8BD6jm4P+ZW8p Pe/2G6HhsHK7RT+DF+lEH9Ts/GV/w1jKYavUnUD+97LuXNA= X-Google-Smtp-Source: ABdhPJxmX8utAOgYSjBwWrzIClAUVp3ZdkkOPdloN7lsC/QbE8IQFP/1nce1H8oeab1RT90FRtEm2h90wsCwba2zTPs= X-Received: by 2002:a92:d4cc:: with SMTP id o12mr479947ilm.90.1597232752148; Wed, 12 Aug 2020 04:45:52 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> In-Reply-To: <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> From: Neil Anuskiewicz Date: Wed, 12 Aug 2020 04:45:16 -0700 Message-ID: To: dcrocker@bbiw.net Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000d0debe05acacba80" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 11:45:58 -0000 --000000000000d0debe05acacba80 Content-Type: text/plain; charset="UTF-8" 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. On Tue, Aug 11, 2020 at 8:32 PM Dave Crocker wrote: > > >> I was quite surprised -- at the level of astonished -- to see the > >> pushback on the Author header-field proposal, since it is such a simple > >> and straightforward mechanism. > > > > The different bits in the message are simple enough. > > > > The problem is that it might as well be called Really-From, and then > > Your opening item is that you don't like the name of the field? > > In any event, I suggested "Author" because it is simple and accurate. > Something like what you suggest - on the off-chance you are serious -- > offers distracting tone and baggage. > > > > when enough systems do mutant DMARC to cause the same problems with > > Really-From that we have with From, > > That's a premise with no foundation and arguably no validity. > > At the least, if you are going to use this as the substance of your > concern, perhaps you could explain with some care why you are so certain > this will happen. > > Here's why I think it won't: They already have From:. > > The real value in DMARC is not what is displayed to the end-user but in > having a required field that cites the originating domain name. That > doesn't change if there are additional fields that might or might not > mention the originating domain. > > > > the step after that is > > Really-Really-From, so on ad nauseam. While that happens (or maybe > > doesn't) we have no idea whether MUAs will display it or let you enter > > The question of whether any MUAs will implement this is the same concern > for any proposal. So on its own, that would mean we never do anything > unless implementers and operators promise to use it. Absent an IETF > formal policy to that end... > > > > it or automatically make it the same as From or maybe something else, > > likely making it a disaster for interoperability. > > > > I think the DMARC sender draft is a lot more promising. > > It has it's own problems. > > There's no perfection here, since the task is retro-fitting work-arounds > to an established mechanism that has been altered. As I've noted, > realistically, DMARC makes the From: field be the Sender: field. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d0debe05acacba80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mr. Crocker, is there a document that describes some of th= ese proposals and perhaps the best arguments for an against=C2=A0somewhere?= The firehose of learning would a bit easier if there were a FAQ. I think i= t 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.

<= div class=3D"gmail_quote">
On Tue, Aug= 11, 2020 at 8:32 PM Dave Crocker <d= hc@dcrocker.net> wrote:

>> I was quite surprised -- at the level of astonished -- to see the<= br> >> pushback on the Author header-field proposal, since it is such a s= imple
>> and straightforward mechanism.
>
> The different bits in the message are simple enough.
>
> The problem is that it might as well be called Really-From, and then
Your opening item is that you don't like the name of the field?

In any event, I suggested "Author" because it is simple and accur= ate.
Something like what you suggest - on the off-chance you are serious --
offers distracting tone and baggage.


> when enough systems do mutant DMARC to cause the same problems with > Really-From that we have with From,

That's a premise with no foundation and arguably no validity.

At the least, if you are going to use this as the substance of your
concern, perhaps you could explain with some care why you are so certain this will happen.

Here's why I think it won't:=C2=A0 They already have From:.

The real value in DMARC is not what is displayed to the end-user but in having a required field that cites the originating domain name.=C2=A0 That =
doesn't change if there are additional fields that might or might not <= br> mention the originating domain.


> the step after that is
> Really-Really-From, so on ad nauseam. While that happens (or maybe
> doesn't) we have no idea whether MUAs will display it or let you e= nter

The question of whether any MUAs will implement this is the same concern for any proposal.=C2=A0 So on its own, that would mean we never do anything=
unless implementers and operators promise to use it.=C2=A0 Absent an IETF <= br> formal policy to that end...


> it or automatically make it the same as From or maybe something else,<= br> > likely making it a disaster for interoperability.
>
> I think the DMARC sender draft is a lot more promising.

It has it's own problems.

There's no perfection here, since the task is retro-fitting work-around= s
to an established mechanism that has been altered.=C2=A0 As I've noted,=
realistically, DMARC makes the From: field be the Sender: field.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d0debe05acacba80-- From nobody Wed Aug 12 05:13:21 2020 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 CF9163A1243 for ; Wed, 12 Aug 2020 05:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 uUCysYCvfh1y for ; Wed, 12 Aug 2020 05:13:16 -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 517E33A1242 for ; Wed, 12 Aug 2020 05:13:16 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07CCFxkr004765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2020 05:15:59 -0700 To: Neil Anuskiewicz Cc: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> Date: Wed, 12 Aug 2020 05:13:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 12:13:20 -0000 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. There is a small number of Internet Drafts. Each of them explains themselves, well or poorly. This kind of work is early-stage development and requires participants to be actively engaged in that development. FAQs, for example, come later, for wider consumption. If you have particular questions, ask them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 12 05:55:43 2020 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 82D1D3A0C9A for ; Wed, 12 Aug 2020 05:55:42 -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 ADDQ0mm7L9DW for ; Wed, 12 Aug 2020 05:55:40 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE473A1279 for ; Wed, 12 Aug 2020 05:55:40 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id t4so1507085iln.1 for ; Wed, 12 Aug 2020 05:55:40 -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=wf7sDGc7y/45xXKXIr+nIPEyubyWWZ7CDREvpMTy0U4=; b=OtjWxUxgtUZZGo8NjO2DlDiLkLImAD4Sk7bh7xkbGz4ysULux8Q0kfOb603W4yeSks FmoNhHsXyCxVPKtp2oL+L+XxS09HOfJovZ0R8ArZTAybUBemW2+SdOjACxzN6A7DXmPY Z4lU2tiMSi9bokoRrekFkJx5HL4iubR/m5gmY= 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=wf7sDGc7y/45xXKXIr+nIPEyubyWWZ7CDREvpMTy0U4=; b=TJ4M2a9pLppA1Wuzyt5eNjSc+RMuo6G05cfFAYEllYqRF8yFphatOCgPGi4dx/9ZXZ ubBeztlGrzb0z0vmeV+G1CBdnLhL3cHrtHlN83MZefMRyvOUy8ouzfkeKsE7SEgMPjrN R8CZ4RKLvOIDUBztYSgKsCLtfrn6oMJFnU+N3zpzfJpSkP0V6H01YULveS0rBaJy81ow OBhtDACWe1PoiIQJzOou2tutfJn+AXtJ3vvtzqI73sQCYZWNeXlLSDrtuZQS1WqSHbhs cei7Jb4pIBxD2DZt/0804DXDOP6b3Z+6KFt+3xJPhFgYd2hfnxLwbfqvr8V337dr3BxM HzuA== X-Gm-Message-State: AOAM530BYc09wNh0TAFqt+oVOSv4OBLOFWpw+XUWnEbhUHRLSRbrtnjU 6KfjoWUP+mVfcH9RFJa9x70EcoriWu1E+8eHNU/Ox/DIiyK06g== X-Google-Smtp-Source: ABdhPJyfbiDtEtTOMFZLk/abypFyzFk8OfQc0n+RZbb08gckjAKUq4+6aASCADQmbTyEBmwLBIqmkBdVRen4/7nifFE= X-Received: by 2002:a92:660e:: with SMTP id a14mr28251568ilc.262.1597236939795; Wed, 12 Aug 2020 05:55:39 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> In-Reply-To: <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> From: Neil Anuskiewicz Date: Wed, 12 Aug 2020 05:55:03 -0700 Message-ID: To: dcrocker@bbiw.net Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000006b49e905acadb422" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 12:55:43 -0000 --0000000000006b49e905acadb422 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker 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 problem being addressed is the munging of headers by mailing lists and other forwarders, breaking things like DKIM. 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. :-) > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --0000000000006b49e905acadb422 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 12, 2020 at 5:13 AM Dave = Crocker <dhc@dcrocker.net> wr= ote:
On 8/12/202= 0 4:45 AM, Neil Anuskiewicz wrote:
> Mr. Crocker, is there a document that describes some of these proposal= s
> and perhaps the best arguments for an against=C2=A0somewhere? The fire= hose 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= 9;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 discussio= n about semantics. What to call a proposed=C2=A0RFC5322.Sender field.
=

The problem being addressed is the munging of headers b= y mailing lists and other forwarders, breaking things like DKIM.
=
I've not been lurking long enough to grok what's goi= ng on but I'll continue to lurk and learn, eventually=C2=A0finding a sm= all way to contribute to this effort even if it's just to sweep out the= IETF Ashram. :-)
bbiw.net
--0000000000006b49e905acadb422-- From nobody Wed Aug 12 06:04:11 2020 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 75FFD3A1284 for ; Wed, 12 Aug 2020 06:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 hhNmuS_L_PCr for ; Wed, 12 Aug 2020 06:04:06 -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 6989F3A1283 for ; Wed, 12 Aug 2020 06:04:06 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07CD6nN8009503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2020 06:06:49 -0700 To: Neil Anuskiewicz Cc: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 12 Aug 2020 06:03:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:04:10 -0000 On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > 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. > 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 From nobody Wed Aug 12 06:23:10 2020 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 06D943A1285 for ; 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 ; 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 ; Wed, 12 Aug 2020 06:23:07 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id j8so2435898ioe.9 for ; 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> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> In-Reply-To: From: Neil Anuskiewicz Date: Wed, 12 Aug 2020 06:22:30 -0700 Message-ID: To: dcrocker@bbiw.net Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000008d6c6a05acae161b" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:23:09 -0000 --0000000000008d6c6a05acae161b Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker wrote: > On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > > 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 > --0000000000008d6c6a05acae161b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 12, 2020 at 6:04 AM Dave = Crocker <dhc@dcrocker.net> wr= ote:
On 8/12/202= 0 5:55 AM, Neil Anuskiewicz wrote:
>
>
> On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker <dhc@dcrocker.net
> <mailto:dhc@d= crocker.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
>=C2=A0 =C2=A0 =C2=A0 > Mr. Crocker, is there a document that describ= es some of these
>=C2=A0 =C2=A0 =C2=A0proposals
>=C2=A0 =C2=A0 =C2=A0 > and perhaps the best arguments for an against= =C2=A0somewhere? The
>=C2=A0 =C2=A0 =C2=A0firehose of
>=C2=A0 =C2=A0 =C2=A0 > learning would a bit easier if there were a F= AQ. I think it might
>=C2=A0 =C2=A0 =C2=A0even
>=C2=A0 =C2=A0 =C2=A0 > help the participants if this was all documen= ted. Yes, I know
>=C2=A0 =C2=A0 =C2=A0there's
>=C2=A0 =C2=A0 =C2=A0 > the archived but I mean an organized and line= ar doc.
>
>
>
>=C2=A0 =C2=A0 =C2=A0If you have particular questions, ask them.
>
>
> I've just recently started lurking but I think this is a discussio= n
> about semantics. What to call a proposed=C2=A0RFC5322.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 alignme= nt:=C2=A0RFC5322.Send= er =3D=3D RFC5= 322.From so if tag is present permitting this alternative means of alignmen= t. 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 wo= rk mostly with small businesses that don't have zillions of mail stream= s and moving parts. But DMARC sometimes finds rogue senders within the orga= nization (The Toledo office decided to do their own marketing or Bob in sal= es is gonna make everything happen), legit senders who aren't authentic= ated, mail streams everyone forgot about, and, occasionally spoofers.

E= ven with a small business, turning the policy knob above none is unnerving,= especially if there's less than perfecto authentication across the boa= rd 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.=C2=A0 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=C2=A0finding a small way to con= tribute
> to this effort even if it's just to sweep out the IETF Ashram. :-)=


Welcome aboard.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--0000000000008d6c6a05acae161b-- From nobody Wed Aug 12 06:24:42 2020 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 1E4FC3A12D0 for ; Wed, 12 Aug 2020 06:24:34 -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 A4Z1y6VVXJsv for ; Wed, 12 Aug 2020 06:24:32 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DC03A12D2 for ; Wed, 12 Aug 2020 06:24:32 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id y18so1545174ilp.10 for ; Wed, 12 Aug 2020 06:24:32 -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=nuZTP/KWHBe8gcaLR1G4L2N5c4xfbOT26T+6JIU9jD4=; b=RJDV46M2+CIpZPJ9PQUEgJRVllVHQxu11eRxjTSlrSywmzHfJ+fjHFyajGFKeOMmOa 6PfyqQjKJ73h+GWwsbHznyidriASc4Od1Ml4bVW9PDIzk9wY9Xju8jSAUvkRfY/HO9D7 fvOSZsKGA0iCiVTOGqhN/REy1Kw/4BByg2Alw= 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=nuZTP/KWHBe8gcaLR1G4L2N5c4xfbOT26T+6JIU9jD4=; b=HHTg/UgfxSiTN2tGFbdvnOuv2OIlFydddu6ftkUGGVJ+5qMWgmmp4jeDnITJaxEQTa xemMUc9Jl4WAfsxvlQ09tTKNjMInNVxbBESqHOFCDAnmh6se6xMX7PN9pnD445qrQGRu p/jocwY12yyA1bMz3O1RFv3nEg2w0XwJK6RuaYyT7YelFyCQ1k94WdpE3I/JZTRsqvGc Fdlfxd0f0PiBCyKxioG1UN2a8AX3/Qhg4Okbj90ax2XD0hxChz1AppKZp1dvL7YjtONK WareajMax+GacqforwtD7Rqa4/uTMMbHgYecyKXXzNMpb0N9Rg4UKZQ5j7j6ooKYQIgw Y1oQ== X-Gm-Message-State: AOAM533VD++Z/GgiD7NwYZh1rNlQB/LuAM8DBi8f97/0rbSqkkSdk3Fp 1FHy/SMp/mTYIaCyPgDmzzG9pnH6EV/yOnwNEaiXDw== X-Google-Smtp-Source: ABdhPJxruxi7Y9PSKsVYxk9PfnAVuN/BN1Uqgs2qulXpJaohIEi49UaE/Q4SlY89MscWCVSf01wO1RDGcQ6W3EEw0jA= X-Received: by 2002:a92:85c8:: with SMTP id f191mr28783444ilh.242.1597238671556; Wed, 12 Aug 2020 06:24:31 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> In-Reply-To: From: Neil Anuskiewicz Date: Wed, 12 Aug 2020 06:23:55 -0700 Message-ID: To: dcrocker@bbiw.net Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000a3d9dd05acae1ba6" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:24:41 -0000 --000000000000a3d9dd05acae1ba6 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker wrote: > On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > > 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. > > > > 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. > > Thank you. That was a warm welcome. The guy who recommended this list to me suggested I lurk for like a year or get eaten alive. IETF are more relaxed than I expected. > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --000000000000a3d9dd05acae1ba6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 12, 2020 at 6:04 AM Dave = Crocker <dhc@dcrocker.net> wr= ote:
On 8/12/202= 0 5:55 AM, Neil Anuskiewicz wrote:
>
>
> On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker <dhc@dcrocker.net
> <mailto:dhc@d= crocker.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
>=C2=A0 =C2=A0 =C2=A0 > Mr. Crocker, is there a document that describ= es some of these
>=C2=A0 =C2=A0 =C2=A0proposals
>=C2=A0 =C2=A0 =C2=A0 > and perhaps the best arguments for an against= =C2=A0somewhere? The
>=C2=A0 =C2=A0 =C2=A0firehose of
>=C2=A0 =C2=A0 =C2=A0 > learning would a bit easier if there were a F= AQ. I think it might
>=C2=A0 =C2=A0 =C2=A0even
>=C2=A0 =C2=A0 =C2=A0 > help the participants if this was all documen= ted. Yes, I know
>=C2=A0 =C2=A0 =C2=A0there's
>=C2=A0 =C2=A0 =C2=A0 > the archived but I mean an organized and line= ar doc.
>
>
>
>=C2=A0 =C2=A0 =C2=A0If you have particular questions, ask them.
>
>
> I've just recently started lurking but I think this is a discussio= n
> about semantics. What to call a proposed=C2=A0RFC5322.Sender field.
The reference to field name was for an alternative to the rfc5322.From
field, not sender.


> 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.=C2=A0 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=C2=A0finding a small way to con= tribute
> to this effort even if it's just to sweep out the IETF Ashram. :-)=


Welcome aboard.

Thank you. That was a warm welcome. The guy who recom= mended this list to me suggested I lurk for like a year or get eaten alive.= IETF are more relaxed than I expected.
=C2=A0
d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--000000000000a3d9dd05acae1ba6-- From nobody Wed Aug 12 06:32:47 2020 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 82CC43A12A6 for ; Wed, 12 Aug 2020 06:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=bbiw.net header.b=GtVTIpow; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uglDM8z5 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 1oMnHIn7mf7b for ; Wed, 12 Aug 2020 06:32:37 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2AC3A12C4 for ; Wed, 12 Aug 2020 06:32:37 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 86AE792C; Wed, 12 Aug 2020 09:32:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 12 Aug 2020 09:32:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=2 I5VGS2IfiEhOLAzATv86AoAJ5zh9y0pSCJYnOZl/AA=; b=GtVTIpow2XeVx9QRz YUmOYeu1moGEH2UFCP9q5eOdnrrdxxcgm4xxj1DZSMuNj7eAxHrWI3llLX9YarVu LAOudhQGmk9RWXasHK5+mIHJcdS3WxtvDQjbTKnii5bd7ZSEFoTvcjCLe30fQBFB a8Ep+zkXqp/KEeCNJq4kM/H2xlTLCwhgMLl+fIpzZ5xbuBb+hsKz2Kakgt4oDDg/ CKQOHHOgFdwVMi3RxDlw+WlhSzsDKouDMxE6VlZ9jWhGhlYbyTZTW2EawCvw4hyl yS05IHvPt15ulb+E+v8roaBbukvppufX6mEPsBRJg3fmiNgA4Nbv9Wf2HUMWGjr+ XsWoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=2I5VGS2IfiEhOLAzATv86AoAJ5zh9y0pSCJYnOZl/ AA=; b=uglDM8z5D+0wi+81jntfJzvnsSjazAj6lSIiuz52F8qymeEYbCeikU3bZ G5rp8KVKtTFElSfI9pHuHbb4z+8cucOqt9bUeSYeoUYRSvE+U4j1CEdyetZedQYg UxWCAmlMDqb5nONEJzsCvcfJyhjRhGg3Qvq7u4EdSFSub8g3pcOrv39jvJIv6VED 2lIbes7XVlNSR56CKME+/XLMMctEp3Eh7HqqoKVQaTS3dJCAfsKG/u+q0KV6ERqA FhRnpa6ANiDoT+g8XhC9ERE0bsv4BSjGHUU/ZIX5juKHcJwrnrZ4A+E4ud8GrHMX s1szBiy4LVw7Z85g2DicCd1XerMSw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrledvgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomhepffgrvhgv ucevrhhotghkvghruceouggtrhhotghkvghrsegssghifidrnhgvtheqnecuggftrfgrth htvghrnhepiefhvdeugfejkefftdfhleevleetveefgeetfeegteejjedujeeugeehfeeh gfeinecuffhomhgrihhnpegssghifidrnhgvthenucfkphepuddtkedrvddviedrudeivd drieefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep uggtrhhotghkvghrsegssghifidrnhgvth X-ME-Proxy: Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id A2C4C3280069; Wed, 12 Aug 2020 09:32:35 -0400 (EDT) To: Neil Anuskiewicz Cc: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8cd5cb19-4934-fe8f-1b99-0aa11ffc1dca@bbiw.net> Date: Wed, 12 Aug 2020 06:32:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.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] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:32:46 -0000 On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote: > IETF are more relaxed than I expected. Don't believe it. The advice was warranted. d/; -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 12 07:03:39 2020 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 BAB903A12A4 for ; Wed, 12 Aug 2020 07:03:37 -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 jMVyeVGD9jbC for ; Wed, 12 Aug 2020 07:03:36 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 5EB033A129F for ; Wed, 12 Aug 2020 07:03:36 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id g14so2727229iom.0 for ; Wed, 12 Aug 2020 07:03:36 -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=wJpDVZOf7iQuDAX8p062iI92Q6YILLzCuGif5ZbDGHs=; b=hr1Pq7RK/Xp9HxIzCMKo4KnHPU4Zfx43eF1coM4WslQCZLsgBgnaqEBdPn+GGv3nY5 h20pL8JYOQdYynJS82Y1bbkAv+3R1GwHLtcoP73fg7Z+IGxbEYjK4sD2nyKIL/s4u6JX bcx6ccBOBFNHsPbbLlkGwjqpfsag53lcmVyuI= 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=wJpDVZOf7iQuDAX8p062iI92Q6YILLzCuGif5ZbDGHs=; b=It15jzSuy9olr+Xc/nrHFaUvPOpAFzG/+TwYzhOMJJFumS6CM3HML0u/Cegr7dRk8g iKSrku44Ip8GmJJS5WIshVIujwj+5wkO1mmJwJT8JuuOGDppCqxX65HqnpclSky28+xb ejU8wg9Jm7NwTggTRU4s9BYF/4eJndCS08GrNuDi4FnUaCDCOe7qmbPv6OImmL3pSqkb AbBW5AZORadQkrjkwtOgJauK2sKP7eZAoDxO4ZGBs4K7a14qpPpzfR5DtxI9kPfnd6r6 cOUC5LA7LYzY4l0Q+U3AFZOkVm8pXhyVd5e1TNj8gH9PJEQrWch2n17ZiYHCl/88KZ2o qqXA== X-Gm-Message-State: AOAM532vtLl1gsai1Zt2lLxELj7uV6UH4Zcb2N/iCHEA+/Y1yZoDaBdg rLz1aAdyNjxEHuaHmeDYoclYGIrYKxq6WiNu64b1PYoXaVc= X-Google-Smtp-Source: ABdhPJzKWZwdMNggwQem+SACfvhQ6XNPFlW2N69kUG7+bM3egwwpl/2t74/2ZaVdfBuvnDddlMmgjMghNYDtSGMJhO8= X-Received: by 2002:a05:6638:1129:: with SMTP id f9mr30962414jar.35.1597241015538; Wed, 12 Aug 2020 07:03:35 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <2d407924-835c-38ae-b54b-d9b6cf3aadcb@dcrocker.net> <8cd5cb19-4934-fe8f-1b99-0aa11ffc1dca@bbiw.net> In-Reply-To: <8cd5cb19-4934-fe8f-1b99-0aa11ffc1dca@bbiw.net> From: Neil Anuskiewicz Date: Wed, 12 Aug 2020 07:02:59 -0700 Message-ID: To: Dave Crocker Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a350f05acaea7ef" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 14:03:38 -0000 --0000000000005a350f05acaea7ef Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 6:32 AM Dave Crocker wrote: > On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote: > > IETF are more relaxed than I expected. > > Don't believe it. The advice was warranted. > > Well, it's good to mostly lurk for a while as a courtesy unless and until I have something useful to contribute. I will say if there's help needed with writing an FAQ, a RFP, or something else entirely that would be useful, I'm willing to help. My experience with DMARC has been hands-on implementation so thinking about the protocol and how to make it better is new ground. I have idea if I'll have any insight. I'll try to learn enough to contribute through lurking. > d/; > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --0000000000005a350f05acaea7ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 12, 2020 at 6:32 AM Dave = Crocker <dcrocker@bbiw.net> = wrote:
On 8/12/2= 020 6:23 AM, Neil Anuskiewicz wrote:
> IETF are more relaxed than I expected.

Don't believe it.=C2=A0 The advice was warranted.

Well, it's good to mostly lurk for a while as a c= ourtesy unless and until I have=C2=A0something useful to contribute. I will= say if there's help needed with writing an FAQ, a RFP, or something el= se entirely that would be useful, I'm willing to help.

My experience with DMARC has been hands-on implementation so think= ing about the protocol and how to make it better is new ground. I have idea= if I'll have any insight. I'll try to learn enough to contribute t= hrough lurking.
=C2=A0
d/;

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--0000000000005a350f05acaea7ef-- From nobody Wed Aug 12 08:16:44 2020 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 7FABF3A1356 for ; Wed, 12 Aug 2020 08:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=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 gbOP8jLOyZMN for ; Wed, 12 Aug 2020 08:16:42 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9E43A131C for ; Wed, 12 Aug 2020 08:16:42 -0700 (PDT) Received: from [192.168.0.206] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 4578D9F1F7 for ; Wed, 12 Aug 2020 08:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597245401; bh=41Wj/FmK3yG7byNdLFKIK0pW08vY4sZVnVzc6vMGhtk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BxVnQW20D3qo9GWiuvSUO4GlyfZkocZd3LSXF7l+IC2cCDvdMY4NiiCH2HZnw1gih Udc+t5NXpDYKTwSkJa1o9aUTkb1aJ7SiA4DrlVAe2sEhK0vJt3q9t9cckagYVl05MM RmDuREasGYu8eHRCRyZpY7hok7C3TaiCCA3JVWK4= To: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> From: Steve Atkins Message-ID: <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> Date: Wed, 12 Aug 2020 16:16:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 15:16:44 -0000 On 12/08/2020 04:32, Dave Crocker wrote: > > Here's why I think it won't:  They already have From:. > > The real value in DMARC is not what is displayed to the end-user but > in having a required field that cites the originating domain name.  > That doesn't change if there are additional fields that might or might > not mention the originating domain. I think we disagree on the goal of DMARC. The entire point of DMARC is brand protection. Control over what is displayed to the user, not what's in any particular header. You could use it for other things, but that's what informed publishers of DMARC say they're using it for (sometimes phrased as "protection against phishing" but that too is all about what's displayed to the recipient). If you display the contents of Author to the user, then DMARC publishers will want to control that. If MUAs will display the contents of the Author: header where the From: header is now then draft-crocker-dmarc-author-00 effectively moves what used to be Sender: header to the From: header and what used to be the From: header to the Author: header. You could achieve exactly the same result, with much less deployment effort, by updating DMARC to enforce the Sender header and leaving MUAs displaying the From: header. That wouldn't be acceptable to anyone who wants to publish DMARC, so the Author: proposal won't be either. Cheers,   Steve From nobody Wed Aug 12 13:09:13 2020 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 140DC3A0AC6 for ; Wed, 12 Aug 2020 13:09:11 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=wysKK5gH; dkim=pass (2048-bit key) header.d=taugh.com header.b=Iq72i3IX 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 iHf0BIvd2eBy for ; Wed, 12 Aug 2020 13:09:09 -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 925383A0A84 for ; Wed, 12 Aug 2020 13:09:09 -0700 (PDT) Received: (qmail 68499 invoked from network); 12 Aug 2020 20:09:07 -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=10b8f.5f344c63.k2008; bh=8YeHQd3KR8DpL69lnk+kw8efMuG1XSMAIejlgC28+k0=; b=wysKK5gHT5xWWbTqqP0BP/XlX7H9TQnMZKj0PaHf5z55oEiaJAe1BBhJh+ua7anpyOzc2jpWnyA4rcC0k6voe2Um3/kQuu3Ph2GH3GLmDko0jVlVpckgwxHFCsS7IrbTjuAt/janOIr1y6Je2BfVKu2SxFCfvEStylUqPklm8/9iAmONV+/nM/Bg47On188oSqRIJHzS9LTorl65pctHYEc69fmM+L5kbvRku8le02DhbnY9LAwU1WBlrolJesgATarlqvbiD2XVFZMziQE121wi7WAXgwf0vYtafeN08m09/sTocnSVpejIYKXPqvqMf8Hmqc+MbZJ7v9/g/Sd4IQ== 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=10b8f.5f344c63.k2008; bh=8YeHQd3KR8DpL69lnk+kw8efMuG1XSMAIejlgC28+k0=; b=Iq72i3IXb7w32798wIMcxU9WGf9JO8ZqXz92xojX4xhATnoDIviNDRBK+9mVYEQd6tb4v/vWsIOoAfv5zfQcgxodhy/3bFPsWoJBv/xjipZfq+B97X4q4CoeO+DQHFj3I4+gGxFZ0k2UipllbY7UD9VUkyXUMm+qYtKvmr+PHg9LgccR7ec3wDIOoHsG798qlcKl2hXREg/UlabswW4dzQuKdd1UIzJkYD8x4H4h/PVkFPz9BLB9ieIaQ4oUyfkcuQ/WNDTEIOfRgo6ce52+sBF/1996jibwFyuVj49SdJmUfQCx0jM3o3qEwTHlo7dgAQoeBzOkowrlJUrlkrWZ6Q== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 12 Aug 2020 20:09:07 -0000 Received: by ary.local (Postfix, from userid 501) id 5D09F1E896D8; Wed, 12 Aug 2020 16:09:07 -0400 (EDT) Date: 12 Aug 2020 16:09:07 -0400 Message-Id: <20200812200907.5D09F1E896D8@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 20:09:11 -0000 In article <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> you write: >Here's why I think it won't: They already have From:. I was going to answer but Steve Atkins said it better. Let's work on your Sender draft which doesn't try to change what MUAs display. R's, John From nobody Wed Aug 12 14:37:31 2020 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 664CF3A0BEB for ; Wed, 12 Aug 2020 14:37:29 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROI63PKXPdNN for ; Wed, 12 Aug 2020 14:37:27 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB24F3A0BEA for ; Wed, 12 Aug 2020 14:37:27 -0700 (PDT) X-ASG-Debug-ID: 1597267443-11fa311da69cf90001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id woDoHDmQA8n71E1P (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 12 Aug 2020 17:24:03 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=xMaBp9XF/s8Xcqn3DfWhCTHkVvv2BJs/KYa4Ta7mI+o=; b=WJBQDyeW5fJOukkyhqyeWKr8Zj4LZ6oqgRwliAKF/pZ+AAhfxrIdPvsJqHsCeZcoX Unhhhf3gqVTyQ33NW8Zfba7G/Sns44k8UDonc4m5UUC2BwgVySTx1pjjVYI5+6h1v mwrb34sJ+g58Try08xx/yopN8jwMz00yk5tLqPkdE= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 12 Aug 2020 17:23:57 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF Secretariat'" , , , References: <159708630567.25939.3916026035849808234@ietfa.amsl.com> In-Reply-To: <159708630567.25939.3916026035849808234@ietfa.amsl.com> Date: Wed, 12 Aug 2020 17:23:57 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued" Message-ID: <000001d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLoc8w3YCX9iOF58uRWoNGn4EyX7acQ89gw Content-Language: en-us X-Exim-Id: 000001d670ee$e38f8750$aaae95f0$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597267443 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 9972 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83863 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 21:37:29 -0000 -1 A vote against the proposal in the strongest possible terms. About the Analysis: Quote Internet mail defines the RFC5322.From field to indicate the author of the message's content and the RFC5322.Sender field to indicate who initially handled the message... This was not a problem, until development of stringent protections on use of the RFC5322.From field. It has prompted Mediators, such as mailing lists, to modify the RFC5322.From field, to circumvent mail rejection caused by those protections. Comment The author fails to recognize that we have a single-author email architecture. Consequently, the last entity to alter the message IS the author. An altered message can be compared to a Hollywood movie that is "inspired by real events." The delivered message probably has a connection to what the originator wrote, but the nature of that connection is unknown to the recipient. DMARC forces the true author (the mailing list) to take ownership of its work by using a From address in its own domain. Quote This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the RFC5322.From field has become dominated by its role as a handling identifier. Comment This is factually wrong. The path that a message follows has always been of interest, because the reputation of each handler is relevant to the risk associated with the received document. DKIM signatures provided a technology to address this problem. If and only if a DKIM signature can be verified, then the receiver can conclude that the path is irrelevant to message risk. For the problem at hand, messages are assumed to originate with a valid signature, so path would not matter if the document was not altered. It is the mailing list action to alter the message which alters the risk profile of the message, not the path followed. Document alteration is an inherently untrusted activity. The ability to make constructive changes is also the ability to make malicious changes. The ability to make changes is also the ability to create entirely new messages, because a new message could be fabricated to look like a forwarded message if it was advantageous to an attacker to do so. Mailing lists want recipient systems to conclude that the mailing list will only make constructive changes. This is an administrative decision which cannot be obtained from the document itself. It must be obtained using an out-of-band process, and it must be obtained from each recipient, or from the originator domain using a process that each recipient domain will trust. This document proposes a way for recipient domains to authorize exactly what mailing lists wish to do. The proposed protocol would grant that trust if both originating and sending domains choose to participate. But the stated path sensitivity is a misrepresentation of the situation. Quote The current specification augments use of the RFC5322.From field, by enhancing DMARC to also use the RFC5322.Sender field. This preserves the utility of RFC5322.From field while also preserving the utility of DMARC. Comment As we shall see, this proposal has the effect of rolling back DMARC, not preserving it, for any domains that choose to enroll in it. Quote Because the current email protection behavior involves the RFC5322.From field, and pertain to the human author, it is common to think that the issue, in protecting the field's content, is behavior of the human recipient. However there is no indication that the enforced values in the RFC5322.From field alter end-user behavior. In fact there is a long train of indication that it does not. Rather, the meaningful protections actually operate at the level of the receiving system's mail filtering engine, which decides on the disposition of received mail. Comment This assertion is based on the author's inability or unwillingness to distinguish between an author identifier and a trust indicator about authorship identifier. The From address is an identifier which indicates the entity which is supposedly responsible for the content. The reliability of that assertion is affected by whether the connection between the author and the document can be verified by a mechanism such as DMARC. A trust indicator is a symbol or text phrase which indicates whether verification has been successful or not. As discussed in the WG, trust indicators have some effect on user behavior, but not the dramatic effect one might hope would occur. This means that the user tends to believe that the From address is valid, whether the trust indicator is present or not. It does not mean that the From address has no relevance to the user. In general, the user expects that the From address will be the Reply-To recipient. A user would be surprised and alarmed to reply to a message using the From address, and then learn that the reply made no sense because the original did not originate from the stated From address. Just as importantly, the assertion is hypocritical. The end-goal of this proposal is to allow a mailing list to set the From address to a particular value of its choosing, because the value of the From address is perceived as very important to their user base. Therefore, the reader is requested to believe that the From address is, and should be, very important to mailing list subscribers, while it is not, and should not be, important to anyone else. About the Proposed Protocol: The proposal implements an unrestricted third-party signature delegation mechanism. The proposal language obscures the fact that the original document's DMARC validation occurs against the originator's domain, while the enhanced DMARC validates only against the resender domain. This change of reference is necessary to achieve the intended goal for mailing lists, because the list-altered message can only be authenticated using the mailing list domain. Since this arrangement is contrary to the design of DMARC or the intent of the participating domain owner, it is not preserving the benefits of DMARC at all. Once a domain owner agrees to participate in this "enhanced" DMARC, anyone can send messages "From" that domain, as long as the sender authenticates itself using the Sender field and a corresponding DKIM signature. These requirements are trivial, and can be satisfied with minimal effort by any sender, whether legitimate or malicious. The combination of this protocol, along with the enabling DNS entry, provides a guidebook to spammers about how to successfully spoof the participating domain. Consequently, this configuration produces a result which is inferior to operating with DMARC disabled. Without DMARC, the receiving system observes an "Not Verified" result, which tends to encourage a rigorous risk assessment. With this "enhanced" DMARC, the receiving system receives an "Authorized" result, which tends to encourage a less skeptical risk assessment. In reality, an authorization which is available for us by everyone is of no value to anyone at all. Given that the "enhanced" DMARC removes the benefit that DMARC is designed to provide, there is no reason for a domain owner to enroll in the enhanced process, and no reason for a message recipient to accept the recommendations produced by the enhanced process, since the enhanced process is inferior to no process. In the working group, participants indicated that prior attempts to implement controlled third-party signature delegation have been ignored or rejected by domain owners. If domain owners are uninterested in controlled third-party signature delegation, why would they be interested in one that has no controls? About the Intended Benefits to the Mailing List As if all of this were not enough, this proposal will not solve the Mailing List problem even if it is implemented widely. The proposal does not provide a way for mailing lists to know if the recipient system has embraced the "enhanced" DMARC or not. As long as the implementation question is in doubt, the mailing list would have to proceed on the defensive assumption that DMARCv1 is still enforced. This might produce the worst of all possible results: malicious sources use brute-force techniques to find and attack those domains which accept the enhanced DMARC, while mailing lists remain afraid to utilize the new scheme which they hoped would solve their problem. About Defending the Mailing List Identity Mailing List Domains SHOULD implement DMARC to protect their subscribers. Mailing lists such as the present one are easily spoofed, since the list is only identified to the user by the list footer and the subject tag, both of which are easily duplicated. Any malicious source which has this formatting information can produce a fake posting, apply a non-DMARC value in the From address, and send it to any known subscribers. The subscriber will have no visible clues to indicate that it is not a legitimate post, and the incoming email gateway would have no discernible reason to require that the message come from an IETF server. The spoof would succeed as long as the malicious message was not blocked by a blacklist rule in the incoming email gateway. If Mailing List domains implement DMARC, replacing spoofed From addresses with a list domain address, all submissions would become DMARC-verifiable upon delivery, whether submitted by a DMARC-participating domain or not. There are several options for identifying the originator despite using the list domain in the From address. Some of these have been discussed in the Working Group. Summary The proposal is without merit. Doug Foster From nobody Wed Aug 12 15:17:22 2020 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 94D083A0C1B for ; Wed, 12 Aug 2020 15:17:20 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 sa7yxY--6PcV for ; Wed, 12 Aug 2020 15:17:19 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 2E5AE3A0C0C for ; Wed, 12 Aug 2020 15:17:19 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id mw10so1817897pjb.2 for ; Wed, 12 Aug 2020 15:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=LOr2rOBLCr6nX8TFKwYRZAS4fKFdC+tPEwiQBf8pwqA=; b=VlFwQNi8JOcLUuTBtamR8tqGjkLd+f2z2K07gVl3hECog39hzun3toQ0xBkGFdyHQ5 EQbgRA4EKxwxuVdKYG5FWBoGwcQWJ7xb3DvBk0E+Gr0hsCX+KyTEOIy37ahgSF4iSuYi +DsV+Qaf5+Yz7hcVlzpRZFpDl4UZ+PMj26XgY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=LOr2rOBLCr6nX8TFKwYRZAS4fKFdC+tPEwiQBf8pwqA=; b=hymDGS4y/ZRJ15YEs5mgNPEWhM6USyvRSMfC3bZxezf36DU7R8wzcrsifHIsQlOaKU mlw1EXo/2VgQ3ANIwBPhfwkflN9Rc6O0iTtPkQIgyueOZPnPilCGh6qfvpWgTDQ26qky K48CuwjM7OP9T6jp5vdxxe8bWatRc8GlazyTSJyDa8CtddHqJAXaGL4l86aEKl+a7R1M MhcqKim1Conz7iPDu8Z62TQOupH/8ChnmHUT5lP9mGLGCfMGAWleWAxXNg493A2ECMzy LX93dNsUJQYqzPz+vInlhGq0q0epnsTBfmQR3wYyCOQMzL3AUvBLCohizFVPBA3YN1Dt g26Q== X-Gm-Message-State: AOAM530G742u2ND8JNctUH0VxjkHcuFfrRu/KTde8RERSjngcGhe7lV9 DHf9NiDm3sNyj5g0C9NFjCyiUg== X-Google-Smtp-Source: ABdhPJyyCvxFNN+0WlTWJUvzjOyhdyKz61jojCza+CccR1boYxKH+o4n6KsM76gbihdBjMkP4jklXQ== X-Received: by 2002:a17:90a:fc90:: with SMTP id ci16mr2068756pjb.229.1597270638266; Wed, 12 Aug 2020 15:17:18 -0700 (PDT) Received: from ?IPv6:2601:1c0:cb00:7680:85c4:bfe1:ff19:12f1? ([2601:1c0:cb00:7680:85c4:bfe1:ff19:12f1]) by smtp.gmail.com with ESMTPSA id b20sm3437639pfo.88.2020.08.12.15.17.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2020 15:17:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Neil Anuskiewicz Mime-Version: 1.0 (1.0) Date: Wed, 12 Aug 2020 15:17:17 -0700 Message-Id: References: <20200807191216.43E971E4014E@ary.qy> Cc: dmarc@ietf.org, atyrsalvia@agari.com In-Reply-To: <20200807191216.43E971E4014E@ary.qy> To: John Levine X-Mailer: iPad Mail (17G68) Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 22:17:21 -0000 > On Aug 7, 2020, at 12:12 PM, John Levine wrote: >=20 > =EF=BB=BFIn article you write: >> I feel like what is happening sometimes is that central university IT is t= rying to drag their whole institutions into a >> more secure posture before anybody in a position to stop them fully under= stands what's going on lest they be told to >> stop because it might make things a little inconvenient. >=20 > I was with you up until that sentence, since it trivializes the real > problems that overly strict DMARC policies cause. >=20 > Just yesterday I was sorting out a problem with people trying to > finish editing a revised IETF standard about real-time web > applications. Some of the authors' messages were disappearing, > apparently at random. I saw what the problem was, one of the authors > is at a big company whose IT department insists on p=3Dreject (and has > blown off complaints from fairly senior people about the problems it > causes), the other uses an MIT alumni address that recently moved its > hosting to Microsoft without telling anyone that the new host enforces > DMARC policy while the old one didn't. >=20 > My guess is that MIT figured Microsoft will host this for free, that's > great, totally unaware that some of its users' mail would silently > break. >=20 > I told them as a workaround they needed to directly cc each other when > they send anything to the group list, but the whole thing is a > self-inflicted wound. >=20 > R's, > John >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc When mail breaks it=E2=80=99s more than an inconvenience. In business it can= materially affect people=E2=80=99s livelihoods. I do think that sometimes people don=E2=80=99t take p=3Dreject seriously en= ough, and don=E2=80=99t realize how much time and monitoring and prep it tak= es. I mostly work with smaller entities but I advise staying at p=3Dnone of= the time unless there=E2=80=99s spoofing. Otherwise, it=E2=80=99s reporting= only, watch the reports, and take action if and only if there=E2=80=99s a p= roblem.=20 I do get the instinct to be proactive but if you=E2=80=99re going to be proa= ctive, get ready to take the time and, if outside help needed, the money to d= o it without breaking legit mail.=20= From nobody Wed Aug 12 15:21:14 2020 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 C40433A0C0C for ; Wed, 12 Aug 2020 15:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=DEPbkjJ2; dkim=pass (2048-bit key) header.d=taugh.com header.b=e4bDcJkG 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 I5f125fzsbZ5 for ; Wed, 12 Aug 2020 15:21:11 -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 242C73A0C09 for ; Wed, 12 Aug 2020 15:21:10 -0700 (PDT) Received: (qmail 95222 invoked from network); 12 Aug 2020 22:21:09 -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:content-id; s=173f3.5f346b55.k2008; i=johnl-iecc.com@submit.iecc.com; bh=d+Hisr9PZWQXJt2EzvbiVQoW/n7rIG6OjohajsEX4zM=; b=DEPbkjJ2LJQH6UjXAYKZhVgIgAkBokN9bRQA2fVDLH+TLVWimbi7iRLjOqrKB8ZEEOhxTQL7jimF/lIf4heaILsP69n480QDoxypF+frM+zkmyJibgP+43iprI5kUCJ1prZL8muaoUQ514W72Q5x7BMaxTsDUkjQBBowkLwxxZ1PBbvGsmt6wrGcPK7HCzhAL5jBSyoPsbQeN/ofj2ToRMDZkX3k3ZRM9mpo2RdBXVdfGhPi8zunwKohNu0ZV77aGzuNJnP98tGO8r+J2cSt/8quCnvy/4WQPf9hlG77xqDPWIggVsNeBB4QpqPBjOPV7HTlDEzU2UL/PVc9uxtwaQ== 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:content-id; s=173f3.5f346b55.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=d+Hisr9PZWQXJt2EzvbiVQoW/n7rIG6OjohajsEX4zM=; b=e4bDcJkGfOmSf4QVDzmgOs+C6cdu/10RbwxqbW8I97CTJDV1jYjV9AnviCtzH1rICLx2Rtzsslh8JjHFtfo4Plabc+v7t09iDdtiBPLjxFiVggJdD0y3NYVDdl74jigaAjkI1wtjueWk51u2QnFWot7JBAIEIULNt6eSYWxAEHGCG83pSm+q82qI0KaIV/tDDo/YRueq6188u1t9qFrs0yUt/0XL6VeGAO2/cNN5BpZ/QHlr/PpsubDnyRTFvN9iJGEViY9Mx1a0Kj0b89Z8/G+uymfo/5FFgEe/ovEAQ8OpRdj2r8zch3kYC329efgMW8Z2BGvXPxtcrNOKvbyF9g== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 12 Aug 2020 22:21:08 -0000 Date: 12 Aug 2020 18:21:09 -0400 Message-ID: <767c6a11-34c5-b4e6-a8ad-5925e7c01bf2@taugh.com> From: "John R Levine" To: "Neil Anuskiewicz" Cc: dmarc@ietf.org In-Reply-To: References: <20200807191216.43E971E4014E@ary.qy> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-490910435-1597270785=:55984" Content-ID: <3c8cbdb0-f75b-b22-1559-7d2e8ebb699b@iecc.com> Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 22:21:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-490910435-1597270785=:55984 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <9e5b2bba-4d5b-1935-3e3b-c423315d6dd@iecc.com> > I do think that sometimes people don’t take p=reject seriously enough, and don’t realize how much time and monitoring and prep it takes. I mostly work with smaller entities but I advise staying at p=none of the time unless there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take action if and only if there’s a problem. Completely agree. I have 240,000 aggregate and 80,000 failure reports in my database and I'm still publishing p=none for all my domains that actually send mail. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-490910435-1597270785=:55984-- From nobody Wed Aug 12 16:59:41 2020 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 EB0D73A0DD9 for ; Wed, 12 Aug 2020 16:59:37 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=CtjCGmRi; dkim=pass (2048-bit key) header.d=taugh.com header.b=JGGOqoBp 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 DQ9F-Cd4D2HT for ; Wed, 12 Aug 2020 16:59:36 -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 793E83A0DD1 for ; Wed, 12 Aug 2020 16:59:36 -0700 (PDT) Received: (qmail 12257 invoked from network); 12 Aug 2020 23:59:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2fde.5f348266.k2008; bh=FEa4waIfCuAJZhRcqD1fNuIu7eyVZVI84vE04AG1iVQ=; b=CtjCGmRi0HFn8T+iWSbIb6PLrdj8M+SvZq4LL0W5gmC6LwyDQM3qGeW4WXdQQhpSk402OevFRoime5+rGG4nXwC2bbjUsnG/iGrpwEm9SMOUKBlBsIsPmU2ieWXRsdyVGCe9h8dW+NpNqnDK11rPQPAvLwnTcbCXe/3UlZK1vCiK7caJUEX+JNHomXciuKfkWTxYTLFN0NsQTYAZW0Y+D03W8Xl8f+I1LOhgEg/BHq6OqB7a3IyXFfvnwnRuFo+GMeGiSxvKSROmk4CrRSV5+dipoptAdlYzH9qFoCgc6fFNxUM/4+bk0xsnTrtlgkxafPvIS4VyGn1lvlJFFBRNKA== 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=2fde.5f348266.k2008; bh=FEa4waIfCuAJZhRcqD1fNuIu7eyVZVI84vE04AG1iVQ=; b=JGGOqoBpOKC5ujnj92knWxWNfwFqFvkRHzMuXZ3ThXYq3+CyjaBS8blKlS2pbYtj2A8zPz/uyHbjbGV/Gtikdhr8H24d5fErc8194MQfKIzRqXCm97c7biiWZj8axpBlrZbpOEgWQf/SHeW1UTl3TV1Kco52AARN7sYWLDFbXCrK09V2Qen8sjLLg3bBkkCxymO0jJ6xUBk8hpDDRM4rHx8Sh8BLSocWzsT9sv+L+Aqho8O8NVIcGpFkM9FRtYu9sMtlsOzJN9BG9kecMjrwqG+Z/TW4Xra68ZL0j9RNmctWd2yvw05FpVGzrxu1fp/8RmujNRVpWRfOReLjksc+qQ== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 12 Aug 2020 23:59:33 -0000 Received: by ary.local (Postfix, from userid 501) id F11011E8A8CB; Wed, 12 Aug 2020 19:59:33 -0400 (EDT) Date: 12 Aug 2020 19:59:33 -0400 Message-Id: <20200812235933.F11011E8A8CB@ary.local> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <000001d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 23:59:38 -0000 In article <000001d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> you write: >The author fails to recognize that we have a single-author email >architecture. Consequently, the last entity to alter the message IS the >author. Sorry, but no. The structure of Internet mail is quite clear, and that's not it. I can belive there are people who wish it were like that, but no. R's, John From nobody Thu Aug 13 01:11:21 2020 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 512F73A088C for ; Thu, 13 Aug 2020 01:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 AqS7wuZOXa4Q for ; Thu, 13 Aug 2020 01:11:18 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 3C3143A0885 for ; Thu, 13 Aug 2020 01:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597306275; bh=+Bs52rwDC1DEX9LptsUcTMYQEXl6rcPceqlng2CaqUY=; l=304; h=To:References:From:Date:In-Reply-To; b=A+jjavlN75HdiJaj9v6K0NK/4ZbYzmqYJsf0yQq4lRRrsCuhlYVYcxRYs0Yi1D8mV nZhx4C0qNLDp28LHypAGx7hlAhraq7/0YBydsVb0VDcRotuR5GJL7bwtBNuCzC6YA0 sK/QpLjdPpZgBluvPT8LosJMcgLexgPsNEmcqBWHMcvFk4o0lgzKgPyrC9tCV Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.37.104]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F34F5A2.00006FB2; Thu, 13 Aug 2020 10:11:14 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <577cdd0b-e71e-f5aa-d57e-cbf42d97afda@tana.it> Date: Thu, 13 Aug 2020 10:11:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 08:11:19 -0000 On 2020-08-10 9:04 p.m., Tim Wicinski wrote: > > This starts a Call for Adoption for draft-crocker-dmarc-sender +1, the I-D needs work and coordination with other I-Ds by the WG. > Please also indicate if you are willing to contribute text, review, etc. Yes, I will. Best Ale -- From nobody Thu Aug 13 01:57:20 2020 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 77A2F3A0995 for ; Thu, 13 Aug 2020 01:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Lneh_BLXlPxr for ; Thu, 13 Aug 2020 01:57:17 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 14AF83A0992 for ; Thu, 13 Aug 2020 01:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597309033; bh=ZC8Ewr1q64LC4zmZDFjgTigwipaOQ6qr+BSeClVGuFs=; l=2871; h=To:References:From:Date:In-Reply-To; b=DXuBzAcYCUqY38Zz447FBjrNBLL9bG41s9Psb+6YSqfJS4FzM29rl5p6wVT71UdCZ Aa0oIAEB/9StcI5zI+WLLjCwBkzaGiEKSD9CEkOatWckw+SOlJB9mcDo12mN0iFFmx nSYUhbmRWt+werFbLsSqWJEL6Yjjm17jEg2hyTcttmFmnZa9cwVi3XL5p6K4b Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.37.104]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC026.000000005F350069.00007469; Thu, 13 Aug 2020 10:57:13 +0200 To: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> From: Alessandro Vesely Message-ID: <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> Date: Thu, 13 Aug 2020 10:57:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 08:57:18 -0000 On 2020-08-12 5:16 p.m., Steve Atkins wrote: > On 12/08/2020 04:32, Dave Crocker wrote: >> >> Here's why I think it won't:  They already have From:. >> >> The real value in DMARC is not what is displayed to the end-user but >> in having a required field that cites the originating domain name. >> That doesn't change if there are additional fields that might or >> might not mention the originating domain. > > I think we disagree on the goal of DMARC. The entire point of DMARC is > brand protection. Control over what is displayed to the user, not > what's in any particular header. You could use it for other things, > but that's what informed publishers of DMARC say they're using it for > (sometimes phrased as "protection against phishing" but that too is > all about what's displayed to the recipient). Both MX filtering and MUA displaying are relevant, possibly more or less relevant according to users and organizations. > If you display the contents of Author to the user, then DMARC > publishers will want to control that. > > If MUAs will display the contents of the Author: header where the > From: header is now then draft-crocker-dmarc-author-00 effectively > moves what used to be Sender: header to the From: header and what used > to be the From: header to the Author: header. I'd bet we have a good deal of time before MUAs react to the addition of Author:. MX filters will react before them. MLM software will hopefully react even faster. In fact, MUAs reaction will be based rather on how the field usage will have been shaped by MXes and MLMs than on Dave's I-D directly. IMHO, Author: is a necessary complement to DKIM transformations. One transformation being "From: was rewritten, original value was saved in Author:". Based on that tag, a DKIM verifier can produce a canonicalization where the value of From: is put back in place, along with undoing other transformations, so as to verify the original signature. > You could achieve exactly the same result, with much less deployment > effort, by updating DMARC to enforce the Sender header and leaving > MUAs displaying the From: header. Sender: and Author: are not mutually exclusive. While it's true that they aim at the same result, they are /not exactly/ like each other. MLMs already set Sender:, and can easily begin to set Author:, but won't stop to rewrite From: until they know MXes have upgraded. We should conceive a standard that allows such dynamics. > That wouldn't be acceptable to anyone who wants to publish DMARC, > so the Author: proposal won't be either. Both these workarounds presume that domains hosting users' mailboxes may want to publish a somewhat relaxed policy, yet stricter than p=none. That seems plausible, especially if the class of acceptable senders is tunable. Best Ale -- From nobody Thu Aug 13 01:59:07 2020 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 4C6433A09A6 for ; Thu, 13 Aug 2020 01:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.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 dJoi7-3d5F0b for ; Thu, 13 Aug 2020 01:59:03 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2113.outbound.protection.outlook.com [40.107.237.113]) (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 DF23C3A09A4 for ; Thu, 13 Aug 2020 01:59:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bVwqzWgPMKXgRomY6JG119aRgXeJDbrGObX4qK4mZWwfGyI2/Ku9xiWLt4FxuXnfdpYvEXON0wUgGiVVjZluSImuygr5f9jGqcOU93+sS1dAE/x8VuAJqvbwaj+CIWhucyKiNR4F7YwODRPh2dYKvJvHsC5tuF6uGspkVHgFGekyrSjolR9oirrtnlBYTw9JCFPW81ImAujuDsD36YMV3Y4UI7AjO/1Q6pMSiWr/l3IOwVAh/aylFgV8bOs2drjjDKi30rPw4vWOaYg3zepUHM1PiFFOOSij4SQwu2uWNGSvdiUIUqCwsLmIkGVXyIcdill6VnF9S0aH96QlAq/mjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kITJ/Hw3inOqqZK9fVbodP7SmBUJV7ToDkeCz9jjF10=; b=emKlRH2DUyK1PcmLX1u9Js+zAALyijof5nZvqePTUlerb2xkhnPTEiM1w+dlYxVcON7ICGtnNuVC2hmhRIaqx8mXh2XPIV5VSoH0Ht++PpIpTM1zbZyV1ARcuxfhMeKSAcMMMmzRO/mIgUezNTOg8YSxxNlrjcnyxkLo0i6b0Npl6YB1o72NlGB90OJ06jZQ56LQUzcUJtt7u1P+9ELiugRGeOplqA1r+YwuOGQ/a/sGYxd/qzY9mi4cuNVXZ9c0Ko3r4q0x3Pl50czCeujsRhZtvfPYGkS05T3BaM0whMOCZHWyfmpi01phpTS7Pcn5nfso/GiUUE0sViTgi99M2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=agari.com; dmarc=pass action=none header.from=agari.com; dkim=pass header.d=agari.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kITJ/Hw3inOqqZK9fVbodP7SmBUJV7ToDkeCz9jjF10=; b=Fc90grDbJg0XLDhEUge1gEYmk5/Ev8NFncE9l3zfydC69xoFJRIfGTGNhrhxNutHhLACjuNiuwi5/VedzbGAHQf8SJVyJ2pWUP+kOpv4WFGVd/UnXKeSpb3KyLVh3WMckHtb0pgbwM4ueAkHWDN7LOcRRX9AYjPxKreNllBrTbQ= Received: from BY5PR13MB2999.namprd13.prod.outlook.com (2603:10b6:a03:191::27) by BY5PR13MB3427.namprd13.prod.outlook.com (2603:10b6:a03:1a9::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.15; Thu, 13 Aug 2020 08:58:54 +0000 Received: from BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f]) by BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f%3]) with mapi id 15.20.3283.014; Thu, 13 Aug 2020 08:58:54 +0000 From: Autumn Tyr-Salvia To: Neil Anuskiewicz , John Levine CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] non-mailing list use case for differing header domains Thread-Index: AQHWZKh8JcOQ838b0UOee1lvwkySbakcmlWAgAAZV4CABAtZAIAAJAYAgAMr0H6AAONBAIAAILYAgAAgwICAACkyAIAAAbIAgAA2jwCAAoyEgIAACMwAgAALnQCAAY3UgIAANr6AgAJ+BWuAAJt5AIAID1qAgACxZwQ= Date: Thu, 13 Aug 2020 08:58:54 +0000 Message-ID: References: <20200807191216.43E971E4014E@ary.qy>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: marmot-tech.com; dkim=none (message not signed) header.d=none;marmot-tech.com; dmarc=none action=none header.from=agari.com; x-originating-ip: [2600:1700:bd50:a670:1d22:fb0f:4375:8a21] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1bdbc046-0efb-4ade-a653-08d83f671b60 x-ms-traffictypediagnostic: BY5PR13MB3427: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tLkyBXclruSsSL2Z0wKzon/qGVUjRRd+5rb0ZV1xImN5761a/+64QMk1ZQp6B4UPRYqMLbTXgeZNrUd3GLOHgZfGyEz7c6v6R5RREPdOmMciJhgOHNYuNPNZHid6pCmA2UC+F4Q+nuzksuiqvEHV6Sm1VxMILVvQlESdL9c+uRYYoYlvnzfYpUMyMtfzFpEBI/9bGvJIBnl38Wmykx9G7Z+GR8YzmTnyndPAwMtLFuCnQ8z39ROyG25OqMxq6X9I+/rANxDYgMi50nc6hbA4X5Cpn8QapI4DAOGaDQd/ITqYlXrMI0al7O1JDPf57DS22LtFCpPcykgiggJvZnKvW5qqR7qLIHVnv6mhbv1Gr+Nxrt8qmr4bdPDNuJdi0dfzemfXffMW9yR60LpnU+2ifmQTeFpSPiZCNMSc4y4rwodAqdYIPh893KbQw7GsrmAavf8knMrgROFmfhn+R0r/nbtSwGQJgxXu8FmXGlJqUgA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB2999.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(376002)(396003)(366004)(136003)(7696005)(83380400001)(6506007)(53546011)(33656002)(19627405001)(966005)(4326008)(478600001)(66946007)(66476007)(71200400001)(166002)(86362001)(66446008)(64756008)(2906002)(66556008)(76116006)(8676002)(55016002)(316002)(8936002)(5660300002)(110136005)(9686003)(186003)(52536014)(45080400002)(223123001)(130980200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /NqoQ/a/QaSSSauJ78cZsDmAX6wbhoX1oyEEqZpVHntGfhNtmXPfY4aX7SRYWz6g8/73OCAiRPRswnzfX/jmb0vKpMCWrxobRxydNL0G4KncJ78DzCDGxl8ccUsldLLUF7yUvCR8PXE8+ODJ27zKbb8Nnf4MlDFrGdTnRgX0wF+C5DQSZB4JLr+LHaxr4COKrsdL3rHFWqbeMJAvTTyyXlTk8Zy2we8Glk6V5Q21gRieErgTU1+uYfXCK5VcR2MWNiVRu3Mz8gP4AkbEnIljkIJgXoG7S4U9fqAfMxdPqTPYQ5z8u9v9XvKli+Z7cduUqeuklIJg9JzJ56sOI5+NjOLw04fQZTbvvsjtDHyYdbyAonJsIiOdAT8YG0KB0lMkiYdWZkbRL8GivV25AklZOqDDhNnMVlNVjnf26drHj16VcYM+l11TO0mZ1bGZQleJhguhzJ1KWq3ufZpSzb8wFprKHKC80mC04Hh4E02KlM1s4mzX4x7w1A3VNvl2W9I09SjkzIzMKJBYGDhHE2aCHDMFKKq3KjZgIe13TNwPT/iv7Z0eWHch9DE0+6QNzK8igZLDM3DMWpx1jS4ym2ptXAF6nzUCa5I+f5hUnJy00jnm9ysw91u3bv/Ri+qMD2pL9KZcjVRc5spItBUbLHtHMWEgdv9OTZ2JYoV4E+c1V1H20usMMvxMWv3NyrW6m6mLKHJ82iYrMCX8LYfS3tAfgw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB299920E15CC75E9D72F67170D7430BY5PR13MB2999namp_" MIME-Version: 1.0 X-OriginatorOrg: agari.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB2999.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1bdbc046-0efb-4ade-a653-08d83f671b60 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 08:58:54.4216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05773123-385e-420d-844e-f01aee5e37ab X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K/3y/GUIBhdgjW4x8z0AvufeMgRUpGMXbnZTGcI+PxoQpKHJBkpBfsCHsZ+IzkHxhpNz/kFilV3MvdnqUbmYyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3427 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 08:59:05 -0000 --_000_BY5PR13MB299920E15CC75E9D72F67170D7430BY5PR13MB2999namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IkkgZG8gZ2V0IHRoZSBpbnN0aW5jdCB0byBiZSBwcm9hY3RpdmUgYnV0IGlmIHlvdeKAmXJlIGdv aW5nIHRvIGJlIHByb2FjdGl2ZSwgZ2V0IHJlYWR5IHRvIHRha2UgdGhlIHRpbWUgYW5kLCBpZiBv dXRzaWRlIGhlbHAgbmVlZGVkLCB0aGUgbW9uZXkgdG8gZG8gaXQgd2l0aG91dCBicmVha2luZyBs ZWdpdCBtYWlsLiINCg0KLUFkbWl0dGVkbHksIHRoYXQncyB3aGVyZSBteSBiaWFzIGNvbWVzIGlu LiBNeSBqb2IgaXMgd29ya2luZyB3aXRoIG9yZ2FuaXphdGlvbnMgdGhhdCBoYXZlIHBhaWQgbXkg ZW1wbG95ZXIgZm9yIG1lIHRvIGJlIHRoYXQgb3V0c2lkZSBoZWxwLCBzbyBpdCdzIHJhcmUgZm9y IG1lIHRvIHNlZSBob3cgYmFkbHkgaXQgY2FuIGJlIGRvbmUgYnkgcGVvcGxlIHNldHRpbmcgcmVz dHJpY3RpdmUgRE1BUkMgcG9saWNpZXMgd2l0aG91dCBrbm93aW5nIHdoYXQgdGhleSdyZSBkb2lu Zy4NCg0KDQpCZXN0LA0KDQpBdXR1bW4gVHlyLVNhbHZpYQ0KYXR5cnNhbHZpYUBhZ2FyaS5jb20N CkFnYXJpIFByaW5jaXBhbCBDdXN0b21lciBTdWNjZXNzIEVuZ2luZWVyDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IE5laWwgQW51c2tpZXdpY3ogPG5laWxAbWFy bW90LXRlY2guY29tPg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTIsIDIwMjAgMzoxNyBQTQ0K VG86IEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb20+DQpDYzogZG1hcmNAaWV0Zi5vcmcgPGRt YXJjQGlldGYub3JnPjsgQXV0dW1uIFR5ci1TYWx2aWEgPGF0eXJzYWx2aWFAYWdhcmkuY29tPg0K U3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBub24tbWFpbGluZyBsaXN0IHVzZSBjYXNlIGZvciBk aWZmZXJpbmcgaGVhZGVyIGRvbWFpbnMNCg0KDQoNCj4gT24gQXVnIDcsIDIwMjAsIGF0IDEyOjEy IFBNLCBKb2huIExldmluZSA8am9obmxAdGF1Z2guY29tPiB3cm90ZToNCj4NCj4g77u/SW4gYXJ0 aWNsZSA8Qlk1UFIxM01CMjk5OUFEOTVCNEJEN0M4MDk3MUZEQTRGRDc0OTBAQlk1UFIxM01CMjk5 OS5uYW1wcmQxMy5wcm9kLm91dGxvb2suY29tPiB5b3Ugd3JpdGU6DQo+PiBJIGZlZWwgbGlrZSB3 aGF0IGlzIGhhcHBlbmluZyBzb21ldGltZXMgaXMgdGhhdCBjZW50cmFsIHVuaXZlcnNpdHkgSVQg aXMgdHJ5aW5nIHRvIGRyYWcgdGhlaXIgd2hvbGUgaW5zdGl0dXRpb25zIGludG8gYQ0KPj4gbW9y ZSBzZWN1cmUgcG9zdHVyZSBiZWZvcmUgYW55Ym9keSBpbiBhIHBvc2l0aW9uIHRvIHN0b3AgdGhl bSBmdWxseSB1bmRlcnN0YW5kcyB3aGF0J3MgZ29pbmcgb24gbGVzdCB0aGV5IGJlIHRvbGQgdG8N Cj4+IHN0b3AgYmVjYXVzZSBpdCBtaWdodCBtYWtlIHRoaW5ncyBhIGxpdHRsZSBpbmNvbnZlbmll bnQuDQo+DQo+IEkgd2FzIHdpdGggeW91IHVwIHVudGlsIHRoYXQgc2VudGVuY2UsIHNpbmNlIGl0 IHRyaXZpYWxpemVzIHRoZSByZWFsDQo+IHByb2JsZW1zIHRoYXQgb3Zlcmx5IHN0cmljdCBETUFS QyBwb2xpY2llcyBjYXVzZS4NCj4NCj4gSnVzdCB5ZXN0ZXJkYXkgSSB3YXMgc29ydGluZyBvdXQg YSBwcm9ibGVtIHdpdGggcGVvcGxlIHRyeWluZyB0bw0KPiBmaW5pc2ggZWRpdGluZyBhIHJldmlz ZWQgSUVURiBzdGFuZGFyZCBhYm91dCByZWFsLXRpbWUgd2ViDQo+IGFwcGxpY2F0aW9ucy4gU29t ZSBvZiB0aGUgYXV0aG9ycycgbWVzc2FnZXMgd2VyZSBkaXNhcHBlYXJpbmcsDQo+IGFwcGFyZW50 bHkgYXQgcmFuZG9tLiBJIHNhdyB3aGF0IHRoZSBwcm9ibGVtIHdhcywgb25lIG9mIHRoZSBhdXRo b3JzDQo+IGlzIGF0IGEgYmlnIGNvbXBhbnkgd2hvc2UgSVQgZGVwYXJ0bWVudCBpbnNpc3RzIG9u IHA9cmVqZWN0IChhbmQgaGFzDQo+IGJsb3duIG9mZiBjb21wbGFpbnRzIGZyb20gZmFpcmx5IHNl bmlvciBwZW9wbGUgYWJvdXQgdGhlIHByb2JsZW1zIGl0DQo+IGNhdXNlcyksIHRoZSBvdGhlciB1 c2VzIGFuIE1JVCBhbHVtbmkgYWRkcmVzcyB0aGF0IHJlY2VudGx5IG1vdmVkIGl0cw0KPiBob3N0 aW5nIHRvIE1pY3Jvc29mdCB3aXRob3V0IHRlbGxpbmcgYW55b25lIHRoYXQgdGhlIG5ldyBob3N0 IGVuZm9yY2VzDQo+IERNQVJDIHBvbGljeSB3aGlsZSB0aGUgb2xkIG9uZSBkaWRuJ3QuDQo+DQo+ IE15IGd1ZXNzIGlzIHRoYXQgTUlUIGZpZ3VyZWQgTWljcm9zb2Z0IHdpbGwgaG9zdCB0aGlzIGZv ciBmcmVlLCB0aGF0J3MNCj4gZ3JlYXQsIHRvdGFsbHkgdW5hd2FyZSB0aGF0IHNvbWUgb2YgaXRz IHVzZXJzJyBtYWlsIHdvdWxkIHNpbGVudGx5DQo+IGJyZWFrLg0KPg0KPiBJIHRvbGQgdGhlbSBh cyBhIHdvcmthcm91bmQgdGhleSBuZWVkZWQgdG8gZGlyZWN0bHkgY2MgZWFjaCBvdGhlciB3aGVu DQo+IHRoZXkgc2VuZCBhbnl0aGluZyB0byB0aGUgZ3JvdXAgbGlzdCwgYnV0IHRoZSB3aG9sZSB0 aGluZyBpcyBhDQo+IHNlbGYtaW5mbGljdGVkIHdvdW5kLg0KPg0KPiBSJ3MsDQo+IEpvaG4NCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG1h cmMgbWFpbGluZyBsaXN0DQo+IGRtYXJjQGlldGYub3JnDQo+IGh0dHBzOi8vbmFtMTIuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmRtYXJjJmFtcDtkYXRhPTAyJTdDMDElN0NhdHlyc2Fs dmlhJTQwYWdhcmkuY29tJTdDMjM4OGM0NjkzZjlhNDFkODRkNDMwOGQ4M2YwZDdhYjQlN0MwNTc3 MzEyMzM4NWU0MjBkODQ0ZWYwMWFlZTVlMzdhYiU3QzAlN0MwJTdDNjM3MzI4Njc0NDIwMDA2MTg0 JmFtcDtzZGF0YT11MnhwN1VNUzdPSHpra3l6SGVvS2E5Umkzdzh2N3NqSld2VyUyQlh1ZXBtajQl M0QmYW1wO3Jlc2VydmVkPTANCg0KV2hlbiBtYWlsIGJyZWFrcyBpdOKAmXMgbW9yZSB0aGFuIGFu IGluY29udmVuaWVuY2UuIEluIGJ1c2luZXNzIGl0IGNhbiBtYXRlcmlhbGx5IGFmZmVjdCBwZW9w bGXigJlzIGxpdmVsaWhvb2RzLg0KDQogSSBkbyB0aGluayB0aGF0IHNvbWV0aW1lcyBwZW9wbGUg ZG9u4oCZdCB0YWtlIHA9cmVqZWN0IHNlcmlvdXNseSBlbm91Z2gsIGFuZCBkb27igJl0IHJlYWxp emUgaG93IG11Y2ggdGltZSBhbmQgbW9uaXRvcmluZyBhbmQgcHJlcCBpdCB0YWtlcy4gSSBtb3N0 bHkgd29yayB3aXRoIHNtYWxsZXIgZW50aXRpZXMgYnV0IEkgYWR2aXNlIHN0YXlpbmcgYXQgIHA9 bm9uZSBvZiB0aGUgdGltZSB1bmxlc3MgdGhlcmXigJlzIHNwb29maW5nLiBPdGhlcndpc2UsIGl0 4oCZcyByZXBvcnRpbmcgb25seSwgd2F0Y2ggdGhlIHJlcG9ydHMsIGFuZCB0YWtlIGFjdGlvbiBp ZiBhbmQgb25seSBpZiB0aGVyZeKAmXMgYSBwcm9ibGVtLg0KDQpJIGRvIGdldCB0aGUgaW5zdGlu Y3QgdG8gYmUgcHJvYWN0aXZlIGJ1dCBpZiB5b3XigJlyZSBnb2luZyB0byBiZSBwcm9hY3RpdmUs IGdldCByZWFkeSB0byB0YWtlIHRoZSB0aW1lIGFuZCwgaWYgb3V0c2lkZSBoZWxwIG5lZWRlZCwg dGhlIG1vbmV5IHRvIGRvIGl0IHdpdGhvdXQgYnJlYWtpbmcgbGVnaXQgbWFpbC4NCg== --_000_BY5PR13MB299920E15CC75E9D72F67170D7430BY5PR13MB2999namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCiZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUwLCA0 OSwgNDgpOyBmb250LWZhbWlseTogJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O1NlZ29lIFVJ IFdlYiAoV2VzdCBFdXJvcGVhbikmcXVvdDssICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAtYXBwbGUt c3lzdGVtLCBzeXN0ZW0tdWksIFJvYm90bywgJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTQuNjY2N3B4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50Ij5JDQogZG8gZ2V0IHRoZSBp bnN0aW5jdCB0byBiZSBwcm9hY3RpdmUgYnV0IGlmIHlvdeKAmXJlIGdvaW5nIHRvIGJlIHByb2Fj dGl2ZSwgZ2V0IHJlYWR5IHRvIHRha2UgdGhlIHRpbWUgYW5kLCBpZiBvdXRzaWRlIGhlbHAgbmVl ZGVkLCB0aGUgbW9uZXkgdG8gZG8gaXQgd2l0aG91dCBicmVha2luZyBsZWdpdCBtYWlsLiZxdW90 Ozwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwg MCk7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUwLCA0OSwgNDgpOyBmb250LWZhbWlseTog JnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O1NlZ29lIFVJIFdlYiAoV2VzdCBFdXJvcGVhbikm cXVvdDssICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAtYXBwbGUtc3lzdGVtLCBzeXN0ZW0tdWksIFJv Ym90bywgJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTQuNjY2N3B4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1 MCwgNDksIDQ4KTsgZm9udC1mYW1pbHk6ICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAmcXVvdDtTZWdv ZSBVSSBXZWIgKFdlc3QgRXVyb3BlYW4pJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSZxdW90OywgLWFw cGxlLXN5c3RlbSwgc3lzdGVtLXVpLCBSb2JvdG8sICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0LjY2NjdweDsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudCI+LUFkbWl0dGVkbHks DQogdGhhdCdzIHdoZXJlIG15IGJpYXMgY29tZXMgaW4uIE15IGpvYiBpcyB3b3JraW5nIHdpdGgg b3JnYW5pemF0aW9ucyB0aGF0IGhhdmUgcGFpZCBteSBlbXBsb3llciBmb3IgbWUgdG8gYmUgdGhh dCBvdXRzaWRlIGhlbHAsIHNvIGl0J3MgcmFyZSBmb3IgbWUgdG8gc2VlIGhvdyBiYWRseSBpdCBj YW4gYmUgZG9uZSBieSBwZW9wbGUgc2V0dGluZyByZXN0cmljdGl2ZSBETUFSQyBwb2xpY2llcyB3 aXRob3V0IGtub3dpbmcgd2hhdCB0aGV5J3JlIGRvaW5nLjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBpZD0iU2lnbmF0dXJlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsg Y29sb3I6cmdiKDAsMCwwKSI+DQpCZXN0LDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9y OnJnYigwLDAsMCkiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdi KDAsMCwwKSI+DQpBdXR1bW4gVHlyLVNhbHZpYTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNv bG9yOnJnYigwLDAsMCkiPg0KYXR5cnNhbHZpYUBhZ2FyaS5jb208L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCkFnYXJpIFByaW5jaXBhbCBDdXN0b21lciBTdWNj ZXNzIEVuZ2luZWVyPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFs LEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9ImFwcGVuZG9u c2VuZCI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZl dGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+ DQo8L2Rpdj4NCjxociB0YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsg d2lkdGg6OTglIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNl PSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZTox MXB0Ij48Yj5Gcm9tOjwvYj4gTmVpbCBBbnVza2lld2ljeiAmbHQ7bmVpbEBtYXJtb3QtdGVjaC5j b20mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDEyLCAyMDIwIDM6MTcg UE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gTGV2aW5lICZsdDtqb2hubEB0YXVnaC5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBkbWFyY0BpZXRmLm9yZyAmbHQ7ZG1hcmNAaWV0Zi5vcmcmZ3Q7OyBBdXR1 bW4gVHlyLVNhbHZpYSAmbHQ7YXR5cnNhbHZpYUBhZ2FyaS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbZG1hcmMtaWV0Zl0gbm9uLW1haWxpbmcgbGlzdCB1c2UgY2FzZSBmb3IgZGlm ZmVyaW5nIGhlYWRlciBkb21haW5zPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iQm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExcHQiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48YnI+DQo8YnI+DQomZ3Q7IE9u IEF1ZyA3LCAyMDIwLCBhdCAxMjoxMiBQTSwgSm9obiBMZXZpbmUgJmx0O2pvaG5sQHRhdWdoLmNv bSZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IO+7v0luIGFydGljbGUgJmx0O0JZNVBS MTNNQjI5OTlBRDk1QjRCRDdDODA5NzFGREE0RkQ3NDkwQEJZNVBSMTNNQjI5OTkubmFtcHJkMTMu cHJvZC5vdXRsb29rLmNvbSZndDsgeW91IHdyaXRlOjxicj4NCiZndDsmZ3Q7IEkgZmVlbCBsaWtl IHdoYXQgaXMgaGFwcGVuaW5nIHNvbWV0aW1lcyBpcyB0aGF0IGNlbnRyYWwgdW5pdmVyc2l0eSBJ VCBpcyB0cnlpbmcgdG8gZHJhZyB0aGVpciB3aG9sZSBpbnN0aXR1dGlvbnMgaW50byBhPGJyPg0K Jmd0OyZndDsgbW9yZSBzZWN1cmUgcG9zdHVyZSBiZWZvcmUgYW55Ym9keSBpbiBhIHBvc2l0aW9u IHRvIHN0b3AgdGhlbSBmdWxseSB1bmRlcnN0YW5kcyB3aGF0J3MgZ29pbmcgb24gbGVzdCB0aGV5 IGJlIHRvbGQgdG88YnI+DQomZ3Q7Jmd0OyBzdG9wIGJlY2F1c2UgaXQgbWlnaHQgbWFrZSB0aGlu Z3MgYSBsaXR0bGUgaW5jb252ZW5pZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdhcyB3aXRo IHlvdSB1cCB1bnRpbCB0aGF0IHNlbnRlbmNlLCBzaW5jZSBpdCB0cml2aWFsaXplcyB0aGUgcmVh bDxicj4NCiZndDsgcHJvYmxlbXMgdGhhdCBvdmVybHkgc3RyaWN0IERNQVJDIHBvbGljaWVzIGNh dXNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBKdXN0IHllc3RlcmRheSBJIHdhcyBzb3J0aW5nIG91 dCBhIHByb2JsZW0gd2l0aCBwZW9wbGUgdHJ5aW5nIHRvPGJyPg0KJmd0OyBmaW5pc2ggZWRpdGlu ZyBhIHJldmlzZWQgSUVURiBzdGFuZGFyZCBhYm91dCByZWFsLXRpbWUgd2ViPGJyPg0KJmd0OyBh cHBsaWNhdGlvbnMuIFNvbWUgb2YgdGhlIGF1dGhvcnMnIG1lc3NhZ2VzIHdlcmUgZGlzYXBwZWFy aW5nLDxicj4NCiZndDsgYXBwYXJlbnRseSBhdCByYW5kb20uIEkgc2F3IHdoYXQgdGhlIHByb2Js ZW0gd2FzLCBvbmUgb2YgdGhlIGF1dGhvcnM8YnI+DQomZ3Q7IGlzIGF0IGEgYmlnIGNvbXBhbnkg d2hvc2UgSVQgZGVwYXJ0bWVudCBpbnNpc3RzIG9uIHA9cmVqZWN0IChhbmQgaGFzPGJyPg0KJmd0 OyBibG93biBvZmYgY29tcGxhaW50cyBmcm9tIGZhaXJseSBzZW5pb3IgcGVvcGxlIGFib3V0IHRo ZSBwcm9ibGVtcyBpdDxicj4NCiZndDsgY2F1c2VzKSwgdGhlIG90aGVyIHVzZXMgYW4gTUlUIGFs dW1uaSBhZGRyZXNzIHRoYXQgcmVjZW50bHkgbW92ZWQgaXRzPGJyPg0KJmd0OyBob3N0aW5nIHRv IE1pY3Jvc29mdCB3aXRob3V0IHRlbGxpbmcgYW55b25lIHRoYXQgdGhlIG5ldyBob3N0IGVuZm9y Y2VzPGJyPg0KJmd0OyBETUFSQyBwb2xpY3kgd2hpbGUgdGhlIG9sZCBvbmUgZGlkbid0Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBNeSBndWVzcyBpcyB0aGF0IE1JVCBmaWd1cmVkIE1pY3Jvc29mdCB3 aWxsIGhvc3QgdGhpcyBmb3IgZnJlZSwgdGhhdCdzPGJyPg0KJmd0OyBncmVhdCwgdG90YWxseSB1 bmF3YXJlIHRoYXQgc29tZSBvZiBpdHMgdXNlcnMnIG1haWwgd291bGQgc2lsZW50bHk8YnI+DQom Z3Q7IGJyZWFrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRvbGQgdGhlbSBhcyBhIHdvcmthcm91 bmQgdGhleSBuZWVkZWQgdG8gZGlyZWN0bHkgY2MgZWFjaCBvdGhlciB3aGVuPGJyPg0KJmd0OyB0 aGV5IHNlbmQgYW55dGhpbmcgdG8gdGhlIGdyb3VwIGxpc3QsIGJ1dCB0aGUgd2hvbGUgdGhpbmcg aXMgYTxicj4NCiZndDsgc2VsZi1pbmZsaWN0ZWQgd291bmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFIncyw8YnI+DQomZ3Q7IEpvaG48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGRtYXJjIG1haWxpbmcg bGlzdDxicj4NCiZndDsgZG1hcmNAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v bmFtMTIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmRtYXJjJmFtcDthbXA7ZGF0YT0w MiU3QzAxJTdDYXR5cnNhbHZpYSU0MGFnYXJpLmNvbSU3QzIzODhjNDY5M2Y5YTQxZDg0ZDQzMDhk ODNmMGQ3YWI0JTdDMDU3NzMxMjMzODVlNDIwZDg0NGVmMDFhZWU1ZTM3YWIlN0MwJTdDMCU3QzYz NzMyODY3NDQyMDAwNjE4NCZhbXA7YW1wO3NkYXRhPXUyeHA3VU1TN09IemtreXpIZW9LYTlSaTN3 OHY3c2pKV3ZXJTJCWHVlcG1qNCUzRCZhbXA7YW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly9uYW0x Mi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGZG1hcmMmYW1wO2FtcDtkYXRhPTAyJTdD MDElN0NhdHlyc2FsdmlhJTQwYWdhcmkuY29tJTdDMjM4OGM0NjkzZjlhNDFkODRkNDMwOGQ4M2Yw ZDdhYjQlN0MwNTc3MzEyMzM4NWU0MjBkODQ0ZWYwMWFlZTVlMzdhYiU3QzAlN0MwJTdDNjM3MzI4 Njc0NDIwMDA2MTg0JmFtcDthbXA7c2RhdGE9dTJ4cDdVTVM3T0h6a2t5ekhlb0thOVJpM3c4djdz akpXdlclMkJYdWVwbWo0JTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQo8YnI+DQpXaGVu IG1haWwgYnJlYWtzIGl04oCZcyBtb3JlIHRoYW4gYW4gaW5jb252ZW5pZW5jZS4gSW4gYnVzaW5l c3MgaXQgY2FuIG1hdGVyaWFsbHkgYWZmZWN0IHBlb3BsZeKAmXMgbGl2ZWxpaG9vZHMuPGJyPg0K PGJyPg0KJm5ic3A7SSBkbyB0aGluayB0aGF0IHNvbWV0aW1lcyBwZW9wbGUgZG9u4oCZdCB0YWtl IHA9cmVqZWN0IHNlcmlvdXNseSBlbm91Z2gsIGFuZCBkb27igJl0IHJlYWxpemUgaG93IG11Y2gg dGltZSBhbmQgbW9uaXRvcmluZyBhbmQgcHJlcCBpdCB0YWtlcy4gSSBtb3N0bHkgd29yayB3aXRo IHNtYWxsZXIgZW50aXRpZXMgYnV0IEkgYWR2aXNlIHN0YXlpbmcgYXQmbmJzcDsgcD1ub25lIG9m IHRoZSB0aW1lIHVubGVzcyB0aGVyZeKAmXMgc3Bvb2ZpbmcuIE90aGVyd2lzZSwgaXTigJlzDQog cmVwb3J0aW5nIG9ubHksIHdhdGNoIHRoZSByZXBvcnRzLCBhbmQgdGFrZSBhY3Rpb24gaWYgYW5k IG9ubHkgaWYgdGhlcmXigJlzIGEgcHJvYmxlbS4NCjxicj4NCjxicj4NCkkgZG8gZ2V0IHRoZSBp bnN0aW5jdCB0byBiZSBwcm9hY3RpdmUgYnV0IGlmIHlvdeKAmXJlIGdvaW5nIHRvIGJlIHByb2Fj dGl2ZSwgZ2V0IHJlYWR5IHRvIHRha2UgdGhlIHRpbWUgYW5kLCBpZiBvdXRzaWRlIGhlbHAgbmVl ZGVkLCB0aGUgbW9uZXkgdG8gZG8gaXQgd2l0aG91dCBicmVha2luZyBsZWdpdCBtYWlsLg0KPC9k aXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY5PR13MB299920E15CC75E9D72F67170D7430BY5PR13MB2999namp_-- From nobody Thu Aug 13 02:31:33 2020 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 0976A3A0A6A for ; Thu, 13 Aug 2020 02:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 l2qRTVUozzyP for ; Thu, 13 Aug 2020 02:31:30 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 95D3E3A0A69 for ; Thu, 13 Aug 2020 02:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597311087; bh=JioZ5Ure84erkcU1DkDUYP7BJwVTcngnZjmd6WGLAYI=; l=824; h=To:References:From:Date:In-Reply-To; b=CfHSwZ5KF8OUiGv+Xq+lKN9UEGGqhwkhBZyuQVrdcULkDktbqrfkj0Q94SO8Yre8l eRsROro7eqBgBpJlIikeEXOCcZpzlqHFGyaG26EXvT8DCr3pUFbWt2DbfTE/1jnKSo 7BGKkpdTfUV2DyvTLjiES2NwAw3cqV4wmqXgzkRRr4yeWCfKYfBFYjouVU+KX Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.255]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B4.000000005F35086E.00007815; Thu, 13 Aug 2020 11:31:26 +0200 To: dmarc@ietf.org References: <20200812235933.F11011E8A8CB@ary.local> From: Alessandro Vesely Message-ID: Date: Thu, 13 Aug 2020 11:31:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200812235933.F11011E8A8CB@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 09:31:32 -0000 On 2020-08-13 1:59 a.m., John Levine wrote: > In article <000001d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> you write: >> The author fails to recognize that we have a single-author email >> architecture. Consequently, the last entity to alter the message IS the >> author. > > Sorry, but no. The structure of Internet mail is quite clear, and that's not it. > > I can believe there are people who wish it were like that, but no. I think Doug meant the email architecture as induced by DMARC. Some people can sit together and write a multi-authored message. If they set a multi-mailbox From:, then their message cannot be DMARC validated, and can hardly be sent to a mailing list. Let me note that much of Doug's analysis is correct. We need to fix the weak points he mentions. Best Ale -- From nobody Thu Aug 13 07:14:11 2020 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 A13A03A0C7F for ; Thu, 13 Aug 2020 07:14:03 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jjpAVisWlbN for ; Thu, 13 Aug 2020 07:14:01 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87293A0C81 for ; Thu, 13 Aug 2020 07:14:01 -0700 (PDT) X-ASG-Debug-ID: 1597328039-11fa311da6a42a0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id tvpsJ0Fr8427fEgV (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 13 Aug 2020 10:13:59 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=36EnbyqXZak+JZLgacCP0Z+U7Zm3AOXXcm8kbJbySjo=; b=dee51zlw8bqvWw+eChIJUCiSvTiSqBdj+2eKmt4vODB0Z9enjnx9mvQyf22seFeIL aLUFSKW/ejTOhyzvcwMaeaYJ5siePbkK/NQ7Oo+f5yk/t/6eNRR1l5pDUv9QyqwNY MW9SRiuxopNtHzNKh2mqw14OIq8hnYWWzr9/rasZk= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Thu, 13 Aug 2020 10:13:50 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'Alessandro Vesely'" , Date: Thu, 13 Aug 2020 10:13:50 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] "Email architecture is single author" Message-ID: <000f01d6717b$f7ae7510$e70b5f30$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdZxeSrYIqYE/lTdTSeNzcAkkfEVEQ== Content-Language: en-us X-Exim-Id: 000f01d6717b$f7ae7510$e70b5f30$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597328039 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2073 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83878 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] "Email architecture is single author" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 14:14:07 -0000 In brief: My thinking is based on these foundations: - the incoming email gateway is an AAA server which conditionally allows anonymous logins - The NIST framework for digital identity. https://pages.nist.gov/800-63-3/ In that regard, digital identity is the focus, not human headcount. "Customerservice@example.com" can be an author, even though different individuals are responsible for different messages. My definition of a multiple-author architecture would be one where: - General: The different section of the message must be tagged with the identity of the author for that section. - Specific: Since the email infrastructure is an untrusted environment, the identities must be verifiable by some mechanism. The chairs would probably consider this off-topic at this time, but I would be willing to pursue a theoretical discussion at an appropriate time or forum. On the larger point: You can launch an experiment with or without the paperwork blessing of IETF Experimental status, and you may get IETF blessing despite my objections. You can begin recruiting domain owners immediately. So I am not your problem. What you need is a really good sales pitch to convince many thousands of domain owners, and the trade press, that this is something that they should implement. The pitch needs to include: - The mailing list problem is important to the email security manager. - The mailing list behavior which creates the problem is legitimate. (Abandon the argument that DMARC creates the problem.) - This proposal is a sufficient solution to the problem. - This proposal is the best solution to the problem. - This proposal is a secure solution to the problem. You should view me as the practice session for the sales pitch that really matters. You will not get far with the sales pitch my telling your audience that they are wrong. My warning is that you do not have a convincing sales pitch at this time. I believe the sales pitch has problems in every one of these categories. DF From nobody Thu Aug 13 08:03:54 2020 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 D76EE3A0C98 for ; Thu, 13 Aug 2020 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=FV/n1cL+; dkim=pass (2048-bit key) header.d=taugh.com header.b=tQG/bZHB 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 rEQzpX8ntTqq for ; Thu, 13 Aug 2020 08:03:50 -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 31C273A0B94 for ; Thu, 13 Aug 2020 08:03:49 -0700 (PDT) Received: (qmail 67106 invoked from network); 13 Aug 2020 15:03:48 -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; s=1061f.5f355654.k2008; i=johnl-iecc.com@submit.iecc.com; bh=SgVrqBmC+Mb0Ux6J1xZ71v25tnS1BILP82691p8HQOI=; b=FV/n1cL+9QzZJ+L5/fVMJNW1fAFsinVEKS2aKb6HPpA+v8sbp/KIAz9BrMp49mvFuM44dgF7M1faW9171PMTxX9yPf7lr6oSmlAkJtebBosv+W8DSr492Knmy77GzhyW0q4MuT096QcCQJX3hNk1Bju/hFw5iMY71osJP/7WVVnXdoiFOjd8LfZ8vnldqK2hUPWNKqw5TGH6+zzLecUxPchS6D8nJ4l3sPf3EXAL4nOuiDsw/OADnG+phl1Lf9wty2R5GMXD/YxzoIbK/jPPOIY3vku/X0kgpAXU9DX4rpMhKuf2e9COZP87B6bmvFijzuPtc8D5b6bJfa/ljfrB4w== 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; s=1061f.5f355654.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=SgVrqBmC+Mb0Ux6J1xZ71v25tnS1BILP82691p8HQOI=; b=tQG/bZHB2cHuYOvoq5ziSmCYFEDHv3aAosjYbljae+KlijqoTUW9LRIePznhWNE8DNTtRkCw2abDnUpWeIUmohj+7aY1LKb6+R5oEl+cWLl4Og0Ww0E/4AFcd+nLdfou1Q0jcioel/mIjpgd3aCRm3I9A4Uw+4crbC9ar50w0z++GabZi1q1UOydXns1wTW9vY0GO734mlcdOQafCtJyuqYu7nF5cQxOM6jehToM+AoDlrfhVzqZB8odOPYpbSxlw7NJdedPgIak5mwuNqZMg9RfsuoIQl14AkdJPVa/V6e4VjJ7oU/BYfAy2uiTykwCFfMcZOvjRXyWsHbyRbolrg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 13 Aug 2020 15:03:47 -0000 Date: 13 Aug 2020 11:03:47 -0400 Message-ID: <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> From: "John R Levine" To: "Autumn Tyr-Salvia" Cc: "dmarc@ietf.org" In-Reply-To: References: <20200807191216.43E971E4014E@ary.qy>, MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 15:03:53 -0000 > -Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by people setting restrictive DMARC policies without knowing what they're doing. If they all talked to you first, we'd be having a very different discussion. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 13 12:06:44 2020 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 AB55F3A104E for ; Thu, 13 Aug 2020 12:06:41 -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 D6kcO6_sk0JS for ; Thu, 13 Aug 2020 12:06:39 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CFC3A104C for ; Thu, 13 Aug 2020 12:06:39 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id z6so8444654iow.6 for ; Thu, 13 Aug 2020 12:06:39 -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=S2BOpuOrrQ6yr9O814/pgh9NJmG1AVfKWutqvU9gcVQ=; b=UdlwlMSHUpYUk7tKaiFyPUyMIeUTIip/hNjG9RMmTvNX5KTb5gXSIbYl1LL8WJg0ko 8vx9nWqVDCcG6J8U0zAf7BMdXw89hz9xZbo7mYzX5cqqiaYGSBaPxAThQ8pWBZQjSBU5 +cURwfx9Srzyby5x0Mp1Aqye4WuiBizx0G1aU= 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=S2BOpuOrrQ6yr9O814/pgh9NJmG1AVfKWutqvU9gcVQ=; b=lbQxxyQUJ7snBbOmff+7JpnzqWKjjfaY8HqU+u8v2x2RsqD9xrVuclvDN0k1DhK6vz 2dcrnCXnFbvAhRrVYcCv6ll2Q2zAMvdbLtFiyhrRR/obzlcT9dRiXYP33Aut9bgfuxX/ MnDuU9nGB8G00WUpav3LxzsA5N/GPc0fGj+uWgObH883kLAR8Ik17I2yweFLce2jlVOi mWRYHO302adSVDvRHNiO5tyDE/NWj8ohkv2pgo873uFBAlCUZ0guJNO3I5SvioI1gXt+ KY0YOQaOAbh5yKWfh2ve+3xobANIQEAbAItzPJ/IcDhpkKB2/L9BLY4ngEmCAi6Gevr8 LB4Q== X-Gm-Message-State: AOAM5323RIH4aomlU/yzaqbW35MLWZOeKvJGeUSIOkQEjkBVzeOlIlIW e2qAeQKCYwNHYdZ/Y+VVoAyFBxOKPqeiXcNxIq7CuvuoJK/NKQ== X-Google-Smtp-Source: ABdhPJybpRZPtyH+lfExjCoWCXGLUnKA32CA4Bj9CEICig7cJUiAqNK4XudRGu4s8wNb6uGhcdsKfiRsQIp2m3FfLWs= X-Received: by 2002:a05:6638:1129:: with SMTP id f9mr6437013jar.35.1597345598709; Thu, 13 Aug 2020 12:06:38 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> In-Reply-To: <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> From: Neil Anuskiewicz Date: Thu, 13 Aug 2020 12:06:02 -0700 Message-ID: To: Alessandro Vesely Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000febe4f05acc7007e" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 19:06:42 -0000 --000000000000febe4f05acc7007e Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 1:57 AM Alessandro Vesely wrote: > On 2020-08-12 5:16 p.m., Steve Atkins wrote: > > On 12/08/2020 04:32, Dave Crocker wrote: > >> > >> Here's why I think it won't: They already have From:. > >> > >> The real value in DMARC is not what is displayed to the end-user but > >> in having a required field that cites the originating domain name. > >> That doesn't change if there are additional fields that might or > >> might not mention the originating domain. > > > > I think we disagree on the goal of DMARC. The entire point of DMARC is > > brand protection. Control over what is displayed to the user, not > > what's in any particular header. You could use it for other things, > > but that's what informed publishers of DMARC say they're using it for > > (sometimes phrased as "protection against phishing" but that too is > > all about what's displayed to the recipient). > > > Both MX filtering and MUA displaying are relevant, possibly more or > less relevant according to users and organizations. > > > > If you display the contents of Author to the user, then DMARC > > publishers will want to control that. > > > > If MUAs will display the contents of the Author: header where the > > From: header is now then draft-crocker-dmarc-author-00 effectively > > moves what used to be Sender: header to the From: header and what used > > to be the From: header to the Author: header. > > > I'd bet we have a good deal of time before MUAs react to the addition > of Author:. MX filters will react before them. MLM software will > hopefully react even faster. In fact, MUAs reaction will be based > rather on how the field usage will have been shaped by MXes and MLMs > than on Dave's I-D directly. > > IMHO, Author: is a necessary complement to DKIM transformations. One > transformation being "From: was rewritten, original value was saved in > Author:". Based on that tag, a DKIM verifier can produce a > canonicalization where the value of From: is put back in place, along > with undoing other transformations, so as to verify the original > signature. > > > > You could achieve exactly the same result, with much less deployment > > effort, by updating DMARC to enforce the Sender header and leaving > > MUAs displaying the From: header. > > > Sender: and Author: are not mutually exclusive. While it's true that > they aim at the same result, they are /not exactly/ like each other. > MLMs already set Sender:, and can easily begin to set Author:, but > won't stop to rewrite From: until they know MXes have upgraded. We > should conceive a standard that allows such dynamics. > > > > That wouldn't be acceptable to anyone who wants to publish DMARC, > > so the Author: proposal won't be either. > > Both these workarounds presume that domains hosting users' mailboxes > may want to publish a somewhat relaxed policy, yet stricter than > p=none. That seems plausible, especially if the class of acceptable > senders is tunable. Tunable! You said the magic word I have a client now getting spoofing. Tightening above p=none is a non starter as about 100% of MajorCRM emails fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh, and some local office has a random MailChimp account not authenticated. We can't turn the knob on policy and MajorCRM support says you can't have your own mail from. Normally, with a client we would get on a screen share with Bob (the doer of all things) at a company or some other efficient arrangment to be able to make changes in applications, update DNS, test, monitor. Here, there's this dept with control of the CRM, another for marketing, another controls DNS, and a vendor says something isn't possible. My point is that it sure would be nice to be able to tune so that BigCRM and BigCRM Marketing * mail would pass DMARC comfortably, and we could then turn the dial on policy to cut off the spoofers without breaking legit mail. Yes, I know that this isn't the mailing list issue but tuning could solve that problem, too. Neil --000000000000febe4f05acc7007e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 1:57 AM Aless= andro Vesely <vesely@tana.it> w= rote:
On 2020-08= -12 5:16 p.m., Steve Atkins wrote:
> On 12/08/2020 04:32, Dave Crocker wrote:
>>
>> Here's why I think it won't:=C2=A0 They already have From:= .
>>
>> The real value in DMARC is not what is displayed to the end-user b= ut
>> in having a required field that cites the originating domain name.=
>> That doesn't change if there are additional fields that might = or
>> might not mention the originating domain.
>
> I think we disagree on the goal of DMARC. The entire point of DMARC is=
> brand protection. Control over what is displayed to the user, not
> what's in any particular header. You could use it for other things= ,
> but that's what informed publishers of DMARC say they're using= it for
> (sometimes phrased as "protection against phishing" but that= too is
> all about what's displayed to the recipient).


Both MX filtering and MUA displaying are relevant, possibly more or
less relevant according to users and organizations.


> If you display the contents of Author to the user, then DMARC
> publishers will want to control that.
>
> If MUAs will display the contents of the Author: header where the
> From: header is now then draft-crocker-dmarc-author-00 effectively > moves what used to be Sender: header to the From: header and what used=
> to be the From: header to the Author: header.


I'd bet we have a good deal of time before MUAs react to the addition <= br> of Author:.=C2=A0 MX filters will react before them.=C2=A0 MLM software wil= l
hopefully react even faster.=C2=A0 In fact, MUAs reaction will be based rather on how the field usage will have been shaped by MXes and MLMs
than on Dave's I-D directly.

IMHO, Author: is a necessary complement to DKIM transformations.=C2=A0 One =
transformation being "From: was rewritten, original value was saved in=
Author:".=C2=A0 Based on that tag, a DKIM verifier can produce a
canonicalization where the value of From: is put back in place, along
with undoing other transformations, so as to verify the original
signature.


> You could achieve exactly the same result, with much less deployment <= br> > effort, by updating DMARC to enforce the Sender header and leaving > MUAs displaying the From: header.


Sender: and Author: are not mutually exclusive.=C2=A0 While it's true t= hat
they aim at the same result, they are /not exactly/ like each other.
MLMs already set Sender:, and can easily begin to set Author:, but
won't stop to rewrite From: until they know MXes have upgraded.=C2=A0 W= e
should conceive a standard that allows such dynamics.


> That wouldn't be acceptable to anyone who wants to publish DMARC,<= br> > so the Author: proposal won't be either.

Both these workarounds presume that domains hosting users' mailboxes may want to publish a somewhat relaxed policy, yet stricter than
p=3Dnone.=C2=A0 That seems plausible, especially if the class of acceptable=
senders is tunable.

Tunable! You said the m= agic word I have a client now getting spoofing. Tightening above p=3Dnone i= s a non starter as about 100% of MajorCRM emails fail SPF (foo.majorcrm is = the=C2=A0RFC5321.from), 62% of MajorCRM mail fails DKIM, and 100% of MajorC= RM Marketing * fails SPF (bar.some-esp.= com). Oh, and some local office has a random MailChimp account not auth= enticated.

We can't turn the knob on policy an= d MajorCRM support says you can't have your own mail from. Normally, wi= th a client we would get on a screen share with Bob (the doer of all things= ) at a company or some other efficient arrangment=C2=A0to be able to make c= hanges in applications, update DNS, test, monitor.=C2=A0

Here, there's this dept with control of the CRM, another for mar= keting, another controls DNS, and a vendor says something isn't possibl= e.

My point is that it sure would be nice to be ab= le to tune so that BigCRM and BigCRM Marketing * mail would pass DMARC comf= ortably, and we could then turn the dial on policy to cut off the spoofers = without breaking legit mail.

Yes, I know that this= isn't the mailing list issue but tuning could solve that problem, too.=

Neil


--000000000000febe4f05acc7007e-- From nobody Thu Aug 13 12:21:02 2020 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 A88183A106E for ; Thu, 13 Aug 2020 12:21:00 -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, 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 4PtD9Pf5TnAw for ; Thu, 13 Aug 2020 12:20:59 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 D5B133A1066 for ; Thu, 13 Aug 2020 12:20:58 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id 88so6308085wrh.3 for ; Thu, 13 Aug 2020 12:20:58 -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; bh=4pyMs+M8PiCw4k56kGmv5Z/gpW7p32TZS3fnBAMZeZ4=; b=p1PrtK85446JtzDwgEwm1dMBA9M81W4+y9IlVH6A10pR2D+9n+W4G1GXYXXYqa+M1/ xy74fjC0a//wffIf1JAXErVMjs3sdDZWfv2BLuIPlodoQMD0BDiEX7spwksDndzoOT7O 3OlaaH6+QatEl+Z7FTAPzmAUv/Ypdg5V5gJU6prBwLa1iJMpWvZO+RgnwL8PTL8I92cG FUtCe3JVh3t1tsio/7XxamTVpUFx6fGnhTJy4TpFq3z9tAiq3457UA9SQIMUOnkkts72 d4xUIa4QGtfxY8rWyH5Eow/NcuZWrxJejMvhxJ+YAFBBefxb25zNPfHxdrnaaeMvd/vs 9fJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4pyMs+M8PiCw4k56kGmv5Z/gpW7p32TZS3fnBAMZeZ4=; b=a9rfZBhJnyYMdtEfWHp+MSKgo529NwXt9rzXwqJU312qvgW3a3BTcSVROR7Vf7VPTE Cf2DGYsWpHHpT5MNHuyLtKLIrnm1ksqaStaRfQFWSJHZ+QMwDws6sRjj4mAUCSDJ+kO0 HKCUTZ9y31HVKnchNtPKxsooMM/r8C4jXcG3PNIJSxRd95aUIj96iME+KEVJLL28Lt3W O6yN1PQOzfzSySf368XCUlyZOUC0hoT78V0ykE+XTCSS1sPh6sdObMukYERcy+zwy/+6 AHHgvI2z+RxCVeJUPzycE59rWtbnZ2Xe0hWA/WG5Hc/LLl+W+eH5U9zJI4Izey1aL0kf V+cw== X-Gm-Message-State: AOAM531y9dd+3vFCsoTQ9jMNYiO0RA0iydNcWPW1RRkw78ZWhLOeEV3/ 8rJ8dFO0nqPuaGz7PhJI29PCOfYkvVm92VcBmU+K1g== X-Google-Smtp-Source: ABdhPJwW2IhtdJ8cjlW49bbk6h7UvAh8w24cuEacBADXNYRf8aTQSCqCxh2qhgFr8F8HiTnLc7n/vZI5NCS69c5JuN0= X-Received: by 2002:adf:9526:: with SMTP id 35mr5676813wrs.326.1597346457168; Thu, 13 Aug 2020 12:20:57 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> In-Reply-To: From: Dotzero Date: Thu, 13 Aug 2020 15:20:46 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000029adc905acc73450" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 19:21:01 -0000 --00000000000029adc905acc73450 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz wrote: > > > Tunable! You said the magic word I have a client now getting spoofing. > Tightening above p=none is a non starter as about 100% of MajorCRM emails > fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails > DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh, > and some local office has a random MailChimp account not authenticated. > > We can't turn the knob on policy and MajorCRM support says you can't have > your own mail from. Normally, with a client we would get on a screen share > with Bob (the doer of all things) at a company or some other efficient > arrangment to be able to make changes in applications, update DNS, test, > monitor. > > Here, there's this dept with control of the CRM, another for marketing, > another controls DNS, and a vendor says something isn't possible. > > So what you are saying is that you want an IETF working group to write a standard that papers over poor self control on the part of your organization. > My point is that it sure would be nice to be able to tune so that BigCRM > and BigCRM Marketing * mail would pass DMARC comfortably, and we could then > turn the dial on policy to cut off the spoofers without breaking legit mail. > > Yes, I know that this isn't the mailing list issue but tuning could solve > that problem, too. > > The way you solve the problem described above is to get control of your mail flows. I've worked with various "big CRM" vendors and they will gladly accept a delegated subdomain (they control DNS and therefore SPF and DKIM signing as well as publishing DMARC. There are other approaches as well. Your post illustrates one of the problems with the discussion on this list. People are conflating internal organizational issues with requirements for interoperability. You could always publish 0.0.0.0 -all for your SPF record and solve all your DMARC assertion issues very easily. Michael Hammer --00000000000029adc905acc73450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 3:06 PM Neil = Anuskiewicz <neil@marmot-tech.co= m> wrote:


Tunable! You said the magic word I have a client now getti= ng spoofing. Tightening above p=3Dnone is a non starter as about 100% of Ma= jorCRM emails fail SPF (foo.majorcrm is the=C2=A0RFC5321.from), 62% of Majo= rCRM mail fails DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh, a= nd some local office has a random MailChimp account not authenticated.

We can't turn the knob on policy and MajorCRM supp= ort says you can't have your own mail from. Normally, with a client we = would get on a screen share with Bob (the doer of all things) at a company = or some other efficient arrangment=C2=A0to be able to make changes in appli= cations, update DNS, test, monitor.=C2=A0

Here, th= ere's this dept with control of the CRM, another for marketing, another= controls DNS, and a vendor says something isn't possible.
So what you are saying is that you wa= nt an IETF working group to write a standard that papers over poor self con= trol on the part of your organization.
=C2=A0
My point is that it sure would be nice to be able to t= une so that BigCRM and BigCRM Marketing * mail would pass DMARC comfortably= , and we could then turn the dial on policy to cut off the spoofers without= breaking legit mail.

Yes, I know that this isn= 9;t the mailing list issue but tuning could solve that problem, too.
<= div>

The way you solv= e the problem described above is to get control of your mail flows. I'v= e worked with various "big CRM" vendors and they will gladly acce= pt a delegated subdomain (they control DNS and therefore SPF and DKIM signi= ng as well as publishing DMARC. There are other approaches as well. Your po= st illustrates one of the problems with the discussion on this list. People= are conflating internal organizational issues with requirements for intero= perability. You could always publish 0.0.0.0 -all for your SPF record and s= olve all your DMARC assertion issues very easily.=C2=A0

Michael Hammer=C2=A0
--00000000000029adc905acc73450-- From nobody Thu Aug 13 12:42:30 2020 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 32C703A10A8 for ; Thu, 13 Aug 2020 12:42:29 -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 zPJOeURHPjJF for ; Thu, 13 Aug 2020 12:42:27 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 910653A10A7 for ; Thu, 13 Aug 2020 12:42:27 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id q14so6558359ilj.8 for ; Thu, 13 Aug 2020 12:42:27 -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=fU863HjBv6rb+mxlIP95iWEQHQ8UoYRltsetw6p00IM=; b=N0OUfOe9DtTog/PPXoA0eT5qMdQ7msbELlDLyWJovh4KU/kYpmgdbSWTXiiVeriWrY 9YlebLnv2aVaPS0+0jw1+4ODY7usHxPGIGzWXY6ffPwbpnUiWzT2lOY6H2PTy11l04r+ oLq2ir+puxKIPrQHUELVr8Dw1B2eIyr2clSZc= 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=fU863HjBv6rb+mxlIP95iWEQHQ8UoYRltsetw6p00IM=; b=QMoCtUjCYwJPlFi5bt/gqTuZG8xHdvUCwIQFgTc95PGul3MJWTKfryQ41iR3o8oEoB e25bxOWTtszDzIKqNEwhkLXyGYV4id6Zi3YX2F9tPu0OmUMgOS/xXrcrBAyRLf6SV2pD akxwsQWfguS4xgCzTh3/UlRav0prfFNGnA6X+F5Z5PksSfGnPBtKU3yZ8vyNC0fFdn4y gjEAWND+HkADIQWoFKfF7fr2zwLI881YSMeCgNCZZurq8f25LHLD3yPuVQbNl7LBN47Y vR94Zf8pRJ7I5HHnkA0WLewwyQaWS4/rt9TdrwBJPDSWqURubzHH3zUCfA/Kach5xxRt FOiQ== X-Gm-Message-State: AOAM530iFKxKPpp7QcN6jqpFkh41Kd3KkuoVmRtqBlofA3BqLMTRTQTL qh7NNo80AXlFqa4DH7OlWJv76+cXsWW1fVDvw9/HtQ== X-Google-Smtp-Source: ABdhPJwt2wjWFdnuu+s95CFrRiDZyLZtaDLroPSmrNvQvohXbxBu9aK83KK5JKhVxuoZAhURbqXNHclvM/ngK53NEMY= X-Received: by 2002:a92:d4cc:: with SMTP id o12mr5985863ilm.90.1597347746872; Thu, 13 Aug 2020 12:42:26 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> In-Reply-To: From: Neil Anuskiewicz Date: Thu, 13 Aug 2020 12:41:50 -0700 Message-ID: To: Dotzero Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000091d5605acc7812b" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 19:42:29 -0000 --000000000000091d5605acc7812b Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 12:21 PM Dotzero wrote: > > > On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz > wrote: > >> >> >> Tunable! You said the magic word I have a client now getting spoofing. >> Tightening above p=none is a non starter as about 100% of MajorCRM emails >> fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails >> DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh, >> and some local office has a random MailChimp account not authenticated. >> >> We can't turn the knob on policy and MajorCRM support says you can't have >> your own mail from. Normally, with a client we would get on a screen share >> with Bob (the doer of all things) at a company or some other efficient >> arrangment to be able to make changes in applications, update DNS, test, >> monitor. >> >> Here, there's this dept with control of the CRM, another for marketing, >> another controls DNS, and a vendor says something isn't possible. >> >> So what you are saying is that you want an IETF working group to write a > standard that papers over poor self control on the part of your > organization. > Not my organization. I'm a freelancer. No, I'm saying that the IETF should write a standard that helps people in the field solve problems. > > >> My point is that it sure would be nice to be able to tune so that BigCRM >> and BigCRM Marketing * mail would pass DMARC comfortably, and we could then >> turn the dial on policy to cut off the spoofers without breaking legit mail. >> >> Yes, I know that this isn't the mailing list issue but tuning could solve >> that problem, too. >> >> > The way you solve the problem described above is to get control of your > mail flows. I've worked with various "big CRM" vendors and they will gladly > accept a delegated subdomain (they control DNS and therefore SPF and DKIM > signing as well as publishing DMARC. There are other approaches as well. > Your post illustrates one of the problems with the discussion on this list. > People are conflating internal organizational issues with requirements for > interoperability. You could always publish 0.0.0.0 -all for your SPF record > and solve all your DMARC assertion issues very easily. > I set up subdomains for clients to use for their mail streams all the time so I agree. It's just the standard that sometimes stands in the way of cutting off spoofers. And that's ultimately the goal of the standard. Allow legit mail, stop bad guys. --000000000000091d5605acc7812b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 12:21 PM Dotz= ero <dotzero@gmail.com> wrot= e:


On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz &= lt;neil@marmot-te= ch.com> wrote:


Tunable! You said the magic word I have a client now = getting spoofing. Tightening above p=3Dnone is a non starter as about 100% = of MajorCRM emails fail SPF (foo.majorcrm is the=C2=A0RFC5321.from), 62% of= MajorCRM mail fails DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh= , and some local office has a random MailChimp account not authenticated.

We can't turn the knob on policy and MajorCRM s= upport says you can't have your own mail from. Normally, with a client = we would get on a screen share with Bob (the doer of all things) at a compa= ny or some other efficient arrangment=C2=A0to be able to make changes in ap= plications, update DNS, test, monitor.=C2=A0

Here,= there's this dept with control of the CRM, another for marketing, anot= her controls DNS, and a vendor says something isn't possible.

So what you are saying is that you= want an IETF working group to write a standard that papers over poor self = control on the part of your organization.

Not my organization. I'm a freelancer. No, I'm say= ing that the IETF should write a standard that helps people in the field so= lve problems.=C2=A0
=
=C2=A0
My point is that it sure would be nice to be able to t= une so that BigCRM and BigCRM Marketing * mail would pass DMARC comfortably= , and we could then turn the dial on policy to cut off the spoofers without= breaking legit mail.

Yes, I know that this isn= 9;t the mailing list issue but tuning could solve that problem, too.
<= div>

The way you solv= e the problem described above is to get control of your mail flows. I'v= e worked with various "big CRM" vendors and they will gladly acce= pt a delegated subdomain (they control DNS and therefore SPF and DKIM signi= ng as well as publishing DMARC. There are other approaches as well. Your po= st illustrates one of the problems with the discussion on this list. People= are conflating internal organizational issues with requirements for intero= perability. You could always publish 0.0.0.0 -all for your SPF record and s= olve all your DMARC assertion issues very easily.=C2=A0

I set up subdomains for clients to use for t= heir mail streams all the time so I agree. It's just the standard that = sometimes stands in the way of cutting off spoofers. And that's ultimat= ely the goal of the standard. Allow legit mail, stop bad guys.
<= /div> --000000000000091d5605acc7812b-- From nobody Thu Aug 13 14:32:54 2020 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 530973A07E0 for ; Thu, 13 Aug 2020 14:32:52 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBuu4QL25nRw for ; Thu, 13 Aug 2020 14:32:50 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FED3A07DB for ; Thu, 13 Aug 2020 14:32:50 -0700 (PDT) X-ASG-Debug-ID: 1597354368-11fa311da6bd7e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id vCAlsqPCDNgOs8uX (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 13 Aug 2020 17:32:48 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=jWZFHhNTvDrvTgJRuEhVO3TzEdrv1kL9EjEXKdSzmnE=; b=UJtPs0/S7M676I9/V8j1Unzqcv/0R7nkjxIRUfY3C/2mELKUXXzB4icfJPe4lKhMQ O3PWkdR6mMuMaDpm9OITt50Bzv+DbJh0q4v1zfBeZ91OiXfJI+dq0tn/hR+lFGQaS tE7zA5Pm4hKgxz2Y7tfYtxU79Hr+ErpN1SzazI9HQ= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Thu, 13 Aug 2020 17:32:41 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> In-Reply-To: Date: Thu, 13 Aug 2020 17:32:41 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] draft-crocker-dmarc-author-00 ? Message-ID: <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01D67197.BF6B02B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YXhy+8P112qQBOrsLgLyH+mwTAHSH1UaAxLNSP0BfAMl1wHdRDkuqCK64gA= Content-Language: en-us X-Exim-Id: 003501d671b9$467c0670$d3741350$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597354368 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5452 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83880 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 21:32:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0036_01D67197.BF6B02B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I followed Neil=E2=80=99s discussion of MajorCRM: =20 The current DMARC architecture supports authorizing a vendor to mail on = behalf of their clients if the client includes them in their SPF policy = or delegates a DKIM scope to them and they use it. =20 I agree that SPF is too limiting (including hard limits on complexity), = and DKIM is too complex for an uncooperative vendor. =20 In most cases, a solution would be a controlled third-party signature = authorization along the lines of RFC 6541. The client would configure the authorization in his own DNS and the and = the vendor would only need to sign with their own DKIM signature. This = is not an unreasonable ask for most vendors, but this particular one = seems inexcusable. =20 Unfortunately, the past attempts with third-party signatures have died = for lack of interest. The clients of this vendor might be motivated to = participate, but it would also require participation from the domains = that receive messages from this vendor on behalf of the client. Dave = Crocker=E2=80=99s proposal has the same obstacles because it is a form = of third-party signature authorization. =20 We would need to find a highly respected mailer who thinks they could = stir up interest from their clients. But major mailers will not depend = on a new system until they are sure that it is fully deployed. So the = chicken-and-egg problem may doom every effort. =20 DF =20 ------=_NextPart_000_0036_01D67197.BF6B02B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If I followed = Neil=E2=80=99s discussion of MajorCRM:

 

The current DMARC = architecture supports authorizing a vendor to mail on behalf of their = clients if the client includes them in their SPF policy or delegates a = DKIM scope to them and they use it.

 

I agree that SPF is too = limiting (including hard limits on complexity), and DKIM is too complex = for an uncooperative vendor.

 

In most cases, a = solution would be a controlled third-party signature authorization along = the lines of RFC 6541.

The client would configure the authorization in = his own DNS and the and the vendor would only need to sign with their = own DKIM signature.=C2=A0=C2=A0 This is not an unreasonable ask for most = vendors, but this particular one seems = inexcusable.

 

Unfortunately, the past = attempts with third-party signatures have died for lack of = interest.=C2=A0 The clients of this vendor might be motivated to = participate, but it would also require participation from the domains = that receive messages from this vendor on behalf of the = client.=C2=A0=C2=A0 Dave Crocker=E2=80=99s proposal has the same = obstacles because it is a form of third-party signature = authorization.

 

We would need to find a = highly respected mailer who thinks they could stir up interest from = their clients.=C2=A0=C2=A0 But major mailers will not depend on a new = system until they are sure that it is fully deployed.=C2=A0=C2=A0 So the = chicken-and-egg problem may doom every effort.

 

DF

 

------=_NextPart_000_0036_01D67197.BF6B02B0-- From nobody Thu Aug 13 14:39:21 2020 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 B69CA3A0802 for ; Thu, 13 Aug 2020 14:39:19 -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=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 NBNQDXZZ0agq for ; Thu, 13 Aug 2020 14:39:18 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 5C4C23A07FF for ; Thu, 13 Aug 2020 14:39:18 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id q14so3382347ilm.2 for ; Thu, 13 Aug 2020 14:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YzLMyCnZi8NCiD1NZXM3TjrFqdnYEdDREJmcdXqRyg8=; b=TzTomW1si2nUw1+NIjxBAb1puOKJfjeKdgevNELLosupa3r/3K233j2y2Z/PFejX5d i9NrJDC1XN2+8GNOygFx2ASqyHkKmqhCMg+7GQ8PlfuEnoHtWttqwo31YdVRGYs1It5X NebuxFPVkzo9NV0QXhk+SCAotrsNEZa1U9EFo= 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=YzLMyCnZi8NCiD1NZXM3TjrFqdnYEdDREJmcdXqRyg8=; b=VFqo52cstv7wd0KOLeYahj6cVZtbYC0OK9X+wIYGtJavcWSWEGK8yt8oSA8MCaP486 oWvoVjrtwl1xfXSqG6H/godZiRovHJskwKNZWda95Cc1o0Q5sIgPoZ7zlD7EmP1jesJb 4ulu/yIo0fZUenOKioGn724qd9AHJ4fS5i/2ATYftoQUYMMhtMpxB8N0+hz3YKMZ/AGC n+jL0m4veczAwaj17jPfK9KtJBb4q8eJtVQHrH/J/dUw89mgt7BcZTiB+l+Lzk1B8I1b XDhMMmhQCH//TPy2WIhbPs51mFF9G2xZoVI+pMgW3irCO3keGiH9bfo7d1NpbTNCrXKa N+ag== X-Gm-Message-State: AOAM533zImib2e1bzJa5WJfEcOhpw5Tj+9YX4EKVf4uyGJI7jqUdj57l I4iIoVrkQL91kVYGy5UPVZltGMk7q0qe1qWmL9qJhA== X-Google-Smtp-Source: ABdhPJzztr+f4WmNW9B3u1sA5vserXV7NbdCvHf5qkiQOnSm56MgSolIo2G3CiLUbnWfo7wdGb0zO07hehR5JjSa6TU= X-Received: by 2002:a92:c7cf:: with SMTP id g15mr6270011ilk.120.1597354757319; Thu, 13 Aug 2020 14:39:17 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 13 Aug 2020 14:38:40 -0700 Message-ID: To: Neil Anuskiewicz Cc: Alessandro Vesely , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e40cbe05acc922a1" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 21:39:20 -0000 --000000000000e40cbe05acc922a1 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz wrote: > > Tunable! You said the magic word I have a client now getting spoofing. > Receiving spoofed mail or having their domain *being* spoofed? > My point is that it sure would be nice to be able to tune so that BigCRM > and BigCRM Marketing * mail would pass DMARC comfortably, and we could then > turn the dial on policy to cut off the spoofers without breaking legit mail. > Passing DMARC is not a be-all-end-all. That's what local policy is for. I fail to see why local policy would not solve your problem (as described). --Kurt --000000000000e40cbe05acc922a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000e40cbe05acc922a1-- From nobody Thu Aug 13 14:43:02 2020 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 8FA293A080C for ; Thu, 13 Aug 2020 14:43:00 -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=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 1SOX99e9fx8o for ; Thu, 13 Aug 2020 14:42:59 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 1F0603A080A for ; Thu, 13 Aug 2020 14:42:59 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id r13so2398361iln.0 for ; Thu, 13 Aug 2020 14:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oa3qMRn93CmD6boH8BBeWLs+Rej05JK0zTIeBhyhEig=; b=b3kYpoaZ9v3/DiJvD91sovWQkrNWEgWXLsdnc7Lgs3aD+ojBqEPFKQuV8mIhvrOniB 6b+k1Ot/NAp0ONn56G88UvuM40Zpt2dfbygiSAKqoctqpZqhQm9GsF08K7leRdTkIkcy 0slsCxeMkLWM+/eDgN/OgMfJO/5OCWeoh9eBo= 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=Oa3qMRn93CmD6boH8BBeWLs+Rej05JK0zTIeBhyhEig=; b=LAWOkJ4HO2x0e41t9kMYfoL8j7d4RxntwvED9xVpz5u7Y0oslkjpc8Mee87sESqcX6 pSgsm9wN4qYS7po1H6+8neKvOpS7/K0v78Afzvm5os6FQ3nebd3CqNrjsTENTYeHioHJ 527SC031ph80ASvEYZtqcUZ+g/qj9xyUmuFCIurDph8jj2yItEakxdk089O4FbPusbQ8 AOj2yYjsgDnncG5D2GGmqioCRN9yZVYIno0cBkEWTU3ixGqGa4522sQweiWIw7YQHaUk cSIEYxFqq0h4C6sJI/gmB231xA2qXupCKqKciljcpQZhAnSLiktrWoBhDXvAZCSAWZRl SHwA== X-Gm-Message-State: AOAM532goky+MOo8hI3DhUM1/abWVTpq+dHECdz2YocXksFyLcTlv7/W IYskbNNEL6IiD56Z9aOrZppU57Z7DtUNqtlyEjyuXveOnWc= X-Google-Smtp-Source: ABdhPJx0N+aFaY77cZnMAKfmbvYvU+HUA2n2pInsfUrbCPLuiGYsSNH8IyK8u9FZbNXIOR+zHZLt2gVfZAmpw9Vi+1c= X-Received: by 2002:a92:d651:: with SMTP id x17mr6507522ilp.23.1597354978430; Thu, 13 Aug 2020 14:42:58 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> From: "Kurt Andersen (b)" Date: Thu, 13 Aug 2020 14:42:22 -0700 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000011e5fb05acc93067" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 21:43:01 -0000 --00000000000011e5fb05acc93067 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy or > delegates a DKIM scope to them and they use it. > > > > I agree that SPF is too limiting (including hard limits on complexity), > and DKIM is too complex for an uncooperative vendor. > > > > In most cases, a solution would be a controlled third-party signature > authorization along the lines of RFC 6541. > > The client would configure the authorization in his own DNS and the and > the vendor would only need to sign with their own DKIM signature. > If "DKIM is too complex for [this] uncooperative vendor", why would having the "vendor...sign with...DKIM" be workable? --Kurt --00000000000011e5fb05acc93067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The= current DMARC architecture supports authorizing a vendor to mail on behalf= of their clients if the client includes them in their SPF policy or delega= tes a DKIM scope to them and they use it.

=C2=A0

I agree that SPF i= s too limiting (including hard limits on complexity), and DKIM is too compl= ex for an uncooperative vendor.

=C2=A0

In most cases, a s= olution would be a controlled third-party signature authorization along the= lines of RFC 6541.

The client would configure the authorization i= n his own DNS and the and the vendor would only need to sign with their own= DKIM signature.=C2=A0 =C2=A0


If "DKIM is too complex for [this] uncooperative vendor",= why would having the "vendor...sign with...DKIM" be workable?

--Kurt=C2=A0
--00000000000011e5fb05acc93067-- From nobody Thu Aug 13 14:53:47 2020 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 42A5B3A0831 for ; Thu, 13 Aug 2020 14:53:45 -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, 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 qGj9wbqzZaHm for ; Thu, 13 Aug 2020 14:53:44 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 184A63A0835 for ; Thu, 13 Aug 2020 14:53:43 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 184so6321102wmb.0 for ; Thu, 13 Aug 2020 14:53:42 -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; bh=q9/Jw3G+CnuyZe0vzWRwKketiAoPP9Xkl/5ngL1DPGI=; b=B9rk36vwH9jpxv0sILhIzFFRASYUAm6kqSzhEwTfFubg74lAqrN3/4Xun/uXYj73yP ukE0yf7mvvBBwaG4eAthMjQeJ4LBKpk+kD6bqaUGPaQOsilqy+MEdBht/6sWSf+nD/vc 7wwDIdSXU/ZoLz8wcFz9wEzEoV4BwUQzlp4UYZ26NOeApZPAvzATesLWqlYGsGU0PV3b jZE5Hur4aJOHaiE7kVnrqhb4ekiCKADD4c4dzcArS1hNGtIGWr3D929s/Q0W+/sd+zfm Y9A3Bvv6H1bijXvJgFeNTJEe6pi5+mb0xThtTofFYAUIz7XKnFkzM/1F+WgDEPyW6YWs Feqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=q9/Jw3G+CnuyZe0vzWRwKketiAoPP9Xkl/5ngL1DPGI=; b=MWrAbJ38wBpWEMG5IYRXQIIZnMOzEyeasEWQdGkxVHK93YcKbqjD+eZ21XS3Yr4W54 LS5aYRSD5XV9UomUTFMX2927i7q8+S0oMnhSyFd1VX95CEZNc6thd+t4DR/f9zOWRbk9 42w2Pui9AKCO7m/8P/4gEMaLx8BwD6dklAnS8n5dMj0AX7EvbUxxYEEkqI2eIF/HZ3is Mosb+84WatX+JDeZ0yORCzfv24kMUfmaPDwc2MHQeOHJ8wymxOicTeonXPXC38yFfzFK 0LA5SywNDgkzF+IEL/ENHmHtm/ljGCiwM8M9p4N4NDaQxb0tCbRbxCXT5mh9VBl8gtQq 6Q7A== X-Gm-Message-State: AOAM531WXQsP8A6icnADzy3Mg2NBFAPgEP/HLrF4KyHLvz1sG06+dnaN zERc1GMYJhViA16D0TP0j0wUiW9LlN6UbMttXUqWcw== X-Google-Smtp-Source: ABdhPJxQN94eJw4wrWeYpKL/nGOG1DEnjYpcVFSVHi4ejCetEYCxHmNJWgyRu88+WQ8EAhcocHQFSHocZE0WIRkUU0A= X-Received: by 2002:a7b:cf3a:: with SMTP id m26mr6433525wmg.25.1597355621233; Thu, 13 Aug 2020 14:53:41 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Thu, 13 Aug 2020 17:53:30 -0400 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006236d605acc9567a" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 21:53:45 -0000 --0000000000006236d605acc9567a Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote: > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy or >> delegates a DKIM scope to them and they use it. >> >> >> >> I agree that SPF is too limiting (including hard limits on complexity), >> and DKIM is too complex for an uncooperative vendor. >> >> >> >> In most cases, a solution would be a controlled third-party signature >> authorization along the lines of RFC 6541. >> >> The client would configure the authorization in his own DNS and the and >> the vendor would only need to sign with their own DKIM signature. >> > > If "DKIM is too complex for [this] uncooperative vendor", why would having > the "vendor...sign with...DKIM" be workable? > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years ago it was difficult to find vendors who were willing to deal with DKIM and able to do a good job in implementing. The common mantra was "how does this fit into my business model". These days I would consider it table stakes. Michael Hammer > > --0000000000006236d605acc9567a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 5:43 PM Kurt = Andersen (b) <kboth@drkurt.com&g= t; wrote:
On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <= ;fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
=

The current DMARC architecture supports authorizing a vendor to mail= on behalf of their clients if the client includes them in their SPF policy= or delegates a DKIM scope to them and they use it.

=C2=A0

I agree= that SPF is too limiting (including hard limits on complexity), and DKIM i= s too complex for an uncooperative vendor.

=C2=A0

In most= cases, a solution would be a controlled third-party signature authorizatio= n along the lines of RFC 6541.

The client would configure the auth= orization in his own DNS and the and the vendor would only need to sign wit= h their own DKIM signature.=C2=A0 =C2=A0

<= div>
If "DKIM is too complex for [this] uncooperative ve= ndor", why would having the "vendor...sign with...DKIM" be w= orkable?

Wrong answer. If= the vendor is uncooperative then fire the vendor. 4-5 years ago it was dif= ficult to find vendors who were willing to deal with DKIM and able to do a = good job in implementing. The common mantra was "how does this fit int= o my business model". These days I would consider it table stakes.

Michael Hammer
=C2=A0
--0000000000006236d605acc9567a-- From nobody Thu Aug 13 15:09:36 2020 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 5811E3A084D for ; Thu, 13 Aug 2020 15:09:34 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, 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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPfCDGoA_cTM for ; Thu, 13 Aug 2020 15:09:32 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4AC3A084C for ; Thu, 13 Aug 2020 15:09:32 -0700 (PDT) X-ASG-Debug-ID: 1597356570-11fa311da6bdd90001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id DzbLA2aXpop2gVqd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 13 Aug 2020 18:09:30 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=qRo349vaP+e8WWNy9/1O18+2uYxYdzLI8TBvUZRLfM4=; b=n+85Jb964Y2Luu+bLDoH9ZZbK8uFyW8SfYH/Mu+db3JUBjlqZyrtvU8nLqZX3pl1O nhScnGs50uKbL/RUvskrtPPp70DNq/HHBtbnGx9NfnBrvaH1C9wa3Da/MkCGS9sIo w/V22hFNFo4djqeR8jbzjaZggM7NsbMmiF2wqtjCg= Received: by webmail.bayviewphysicians.com via HTTP; Thu, 13 Aug 2020 18:09:23 -0400 To: "dmarc@ietf.org" Date: Thu, 13 Aug 2020 18:09:20 -0400 X-ASG-Orig-Subj: Firing the vendor Message-ID: <291fe9b1380249bbb13bbd77234c788d@com> MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=1a61e44d63964dddb5dbce5f067377ea Importance: normal From: "Douglas E. Foster" X-Exim-Id: 291fe9b1380249bbb13bbd77234c788d X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597356570 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4869 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83880 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] Firing the vendor X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 22:09:35 -0000 This is a multipart message in MIME format. --1a61e44d63964dddb5dbce5f067377ea Content-Type: multipart/alternative; boundary=29c42964402341ecb48693b84766b299 --29c42964402341ecb48693b84766b299 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yours is the better answer!DF
-------- Original message --------
From: Dotzero
Date: 8/13/20 5:54 PM (GMT-05:00)
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote: > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy or >> delegates a DKIM scope to them and they use it. >> >> >> >> I agree that SPF is too limiting (including hard limits on complexity), >> and DKIM is too complex for an uncooperative vendor. >> >> >> >> In most cases, a solution would be a controlled third-party signature >> authorization along the lines of RFC 6541. >> >> The client would configure the authorization in his own DNS and the and >> the vendor would only need to sign with their own DKIM signature. >> > > If "DKIM is too complex for [this] uncooperative vendor", why would having > the "vendor...sign with...DKIM" be workable? > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years ago it was difficult to find vendors who were willing to deal with DKIM and able to do a good job in implementing. The common mantra was "how does this fit into my business model". These days I would consider it table stakes. Michael Hammer > > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --29c42964402341ecb48693b84766b299 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yours is the better answer!

DF


--= ------ Original message --------
From: Dotzero <dotzero@gmail.= com>
Date: 8/13/20 5:54 PM (GMT-05:00)
To: dmarc= @ietf.org
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-0= 0 ?



On Thu, Aug = 13, 2020 at 5:43 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Thu, Aug 13, 2020 a= t 2:33 PM Doug Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org= > wrote:

The current DMARC architecture supports aut= horizing a vendor to mail on behalf of their clients if the client includes= them in their SPF policy or delegates a DKIM scope to them and they use it= .

=A0

I agree that SPF is too limiting (including hard limits on co= mplexity), and DKIM is too complex for an uncooperative vendor.

=A0

In most cases, a solution would be a controlled third-party sign= ature authorization along the lines of RFC 6541.

The client would = configure the authorization in his own DNS and the and the vendor would onl= y need to sign with their own DKIM signature.=A0 =A0


If "DKIM is too complex for [this] unco= operative vendor", why would having the "vendor...sign with...DKI= M" be workable?

Wron= g answer. If the vendor is uncooperative then fire the vendor. 4-5 years ag= o it was difficult to find vendors who were willing to deal with DKIM and a= ble to do a good job in implementing. The common mantra was "how does = this fit into my business model". These days I would consider it table= stakes.

Michael Hammer
=A0
--29c42964402341ecb48693b84766b299-- --1a61e44d63964dddb5dbce5f067377ea-- From nobody Thu Aug 13 15:13:49 2020 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 8B4D23A084D; Thu, 13 Aug 2020 15:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=bluepopcorn.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 iBnsBygbWH0i; Thu, 13 Aug 2020 15:13:46 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 F2D0E3A05DE; Thu, 13 Aug 2020 15:13:45 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:f58d:ff2e:3780:4f1d]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07DMDhlm027052 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 13 Aug 2020 15:13:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1597356825; bh=3zk0l3P0bpZ2nJLQLtqXs42kdk/2YJOpoY40/zwgMEY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jfQNbzdLaqhW3dGnuYHWQfTweGEO+yeWGIJCHeuE1ufN5+0MU5GZ0dRpcVMR3LjiY hKJuaoKcfchA7NrQ9ixSbCV9YbCAVoI2T901cLR03epADZtFVxoeRxryTGQo/AfGfy U2OnlefXvvvKCwSlfeUYUu34OGQrPddVYbMtTgdQ= To: Doug Foster , "'Alessandro Vesely'" , dmarc@ietf.org References: <000f01d6717b$f7ae7510$e70b5f30$@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <02dc0578-b675-a094-3bf6-105c14c65c2c@bluepopcorn.net> Date: Thu, 13 Aug 2020 15:13:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <000f01d6717b$f7ae7510$e70b5f30$@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] "Email architecture is single author" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 22:13:48 -0000 On 8/13/20 7:13 AM, Doug Foster wrote: > My thinking is based on these foundations: > - the incoming email gateway is an AAA server which conditionally allows > anonymous logins > - The NIST framework for digital identity. https://pages.nist.gov/800-63-3/ I fail to see how NIST SP 800-63-3 Digital Identity Guidelines has anything to do with this. Jim Fenton Altmode Networks From nobody Thu Aug 13 15:53:30 2020 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 DD5F43A0A65 for ; Thu, 13 Aug 2020 15:53:28 -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 IW-OaobX3Xdu for ; Thu, 13 Aug 2020 15:53:27 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539E33A0A5E for ; Thu, 13 Aug 2020 15:53:27 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id q14so3511930ilm.2 for ; Thu, 13 Aug 2020 15:53:27 -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=TsyaDqHMplFn2GrWqZ3bctSmHy2/9te6yWE50XB2Buo=; b=JDeI0PDJlR8z11GbuAiD1vCkEBMU9IyH48ACoTBO+Zp+JnLVrOY1pZfT8rVWr4ih9Z jm+ioWZFEanKu4sK0EAh754S8E5Ww76KeTfK5aHsEA7m9MypkI6ALeOwQabZDPIl/jLp wAUb8SSf4H3LUC9Nf+KwHiPR0e4o8K9bc0D50= 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=TsyaDqHMplFn2GrWqZ3bctSmHy2/9te6yWE50XB2Buo=; b=K2yBoHXjkU8N34IsfEdT6F/Md8wEAnIRBhB5Lpmf3FKnWr9d71x6P5UO3WdXtf/HEM caWcNGXs1tqVjXCO+DtS+olWQOW2m8TCLWj4+NWhYbZ1AvdIgPq/CAlnCyOCUO2h+5pX 40xpmr1X92BhvdAdRVjMrC8jGaQvYZNK1S+kvQv5Rf94vift89L9Ix47fItGcqBI0KtR TPzo9mjuLcIcZC6fA+l/z/OJpm9gWUpmkF4M2wEk53nkzPyT5NtVhxTHoMHl8CCyU5Ww dyoSmh2/16zxiR5mHqrokSBfFtqRrRV/0f54gB263EndYCsITu1IX03y1Hw+mQ/JliMT iQdg== X-Gm-Message-State: AOAM532IQnrcPM0bgIv3vCJDG7n4hokFufr9f70cz/dXj0DPKu4JH7q0 LTNPyyQIMEnmUYDdQCAHCy2zB7x44ej2kspQoNh6gnIhG7DciQ== X-Google-Smtp-Source: ABdhPJzNHKTZuEhlfXfPL6J5LTPTfsEoez6E8L4fTewusFUBURmu7lZawf3ke6H7t5R4b1XfW9asmvpVkWDLK9ix7f4= X-Received: by 2002:a92:9118:: with SMTP id t24mr105094ild.220.1597359206467; Thu, 13 Aug 2020 15:53:26 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> From: Neil Anuskiewicz Date: Thu, 13 Aug 2020 15:52:50 -0700 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000014a44c05acca2c96" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 22:53:29 -0000 --00000000000014a44c05acca2c96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: > If I followed Neil=E2=80=99s discussion of MajorCRM: > > > > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy o= r > delegates a DKIM scope to them and they use it. > And client's domain is only in the Mail from uses the vendor's domain ( somevendorxyz123.foo.com). It passes SPF in but it's not in alignment with the organizational domain name (example.com) that the client uses in the header from. This is super common and, as a practical matter, it works... except if you ever want to use DMARC's policy for anything other than reporting. The vast majority of people think that if you add include:bar.com (whatever vendor KB says) in the SPF that they are good to go. So many businesses have several entries in their organizational domain's SPF record yet the RFC5321.from is the vendor's domain. The client sometimes goes over the 10 DNS lookups with includes that aren't doing anything for them. I'm not sure that 10 DNS lookup limit. There are some prominent services of various sorts for which the single include will do over 10 DNS lookups and hat's just one of many includes a client might have (I know this isn't about SPF per se). Yes, I can usually quickly set up a subdomain to use instead of somevendorxyz123.foo.com but this isn't always possible or it requires pushing to get it done. This makes DMARC a sketchy tool to use for any policy above none which is in and of itself useful. --00000000000014a44c05acca2c96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 2:33 PM Doug = Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:

If I fol= lowed Neil=E2=80=99s discussion of MajorCRM:

=C2=A0<= /span>

The c= urrent DMARC architecture supports authorizing a vendor to mail on behalf o= f their clients if the client includes them in their SPF policy or delegate= s a DKIM scope to them and they use it.

<= /div>

And client's domain is only in th= e Mail from uses the vendor's domain (somevendorxyz123.foo.com). It passes SPF in but it's not= in alignment with the organizational domain name (example.com) that the client uses in the header from.=C2=A0

This is super common and, as a practical matter, it wo= rks... except if you ever want to use DMARC's policy for anything other= than reporting. The vast majority of people think that if you add include:= bar.com (whatever vendor KB says) in the SPF= that they are good to go. So many businesses have several entries in their= organizational domain's SPF record yet the=C2=A0RFC5321.= from is the vendor's domain. The client sometimes goes over the 10 DNS = lookups with includes that aren't doing anything for them. I'm not = sure that 10 DNS lookup limit. There are some prominent services of various= sorts for which the single include will do over 10 DNS lookups and hat'= ;s=C2=A0just one of many includes a client might have (I know this isn'= t about SPF per se).

Yes, I can usually qui= ckly set up a subdomain to use instead of=C2=A0somevendorxyz123.foo.com but this isn't always poss= ible or it requires pushing to get it done.

Th= is makes DMARC a sketchy tool to use for any policy above none which is in = and of itself useful.




--00000000000014a44c05acca2c96-- From nobody Thu Aug 13 16:12:37 2020 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 C98263A0A73 for ; Thu, 13 Aug 2020 16:12:35 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Od1AvTFd; dkim=pass (2048-bit key) header.d=taugh.com header.b=py4Dz2pN 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 6u0PYa-96eTn for ; Thu, 13 Aug 2020 16:12: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 610773A0A6A for ; Thu, 13 Aug 2020 16:12:33 -0700 (PDT) Received: (qmail 78401 invoked from network); 13 Aug 2020 23:12:31 -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=1323f.5f35c8df.k2008; bh=zN6wbXoDyf5zySD91YSKff7DOoZZ96IGgokdDslm9pQ=; b=Od1AvTFd8REe+gzVfQyRlDvFdjYfPK5+jlEB3wXhoB4tVhubi11SXVBXC6lPdpypqolNPwMAx4BRwMRTjCuhX6HYx+hVJ4qs1T8x2+MXJ1KSa+qb1xJW8UXJOgoth4/1ioMEPAAyB1jg4YEzh9sM+v/I385NEdGIENi5L0a2b3syvmu2ieRVCbSOVAUb3HeravuEKeuw8Nga01BLa5vEDNL155dwezNeFsIcfy3vetqLJtAyOFXLo0fpeSfa7IHz5pRBl1gZfaKfK1ieE7LHC4lYkIgT8ExIE6OG/MwBvIG9/flc80MlLPMFomhC6/Pcrv+pDH4EqSGoN4Jr5Qa41Q== 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=1323f.5f35c8df.k2008; bh=zN6wbXoDyf5zySD91YSKff7DOoZZ96IGgokdDslm9pQ=; b=py4Dz2pNsjbtDn2Q9GDCjh9akQjrjzgOXLBx5NxY+6x3EXPzF86AEYl5D9cfbBSnnNyTd2GjwM8DQRKLEtG/6pl8iFNhoZ/hkGHnoI+wprx2Kcn06fFqFoM13Q5y/BQnEfK/nNqGiaBT4NgL1D/ri5f2JZHeIYhrd8RkLYI6akfUuGmxGNQd/Dm9kkicvoips8eMcfWy2k6qFdwFCJbWLdjsLsmSQHEsRIDfH9w+gL0brjcAR5sr7pBvxRSIbGg/c6yVpBQxiw8Ia4gLbsRaJn0xoPYtbsANV/G7rxTQ8A4iu71nFe8KgAm7Pz9n7nQB8eEAWGdigdCwoZLFEyMWMg== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Aug 2020 23:12:30 -0000 Received: by ary.local (Postfix, from userid 501) id 41D7D1E92420; Thu, 13 Aug 2020 19:12:31 -0400 (EDT) Date: 13 Aug 2020 19:12:31 -0400 Message-Id: <20200813231231.41D7D1E92420@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 23:12:36 -0000 In article you write: >-=-=-=-=-=- > >During IETF 108, the chairs realized that there was interest in Dave's >RFC5322.Sender draft. > >This starts a Call for Adoption for draft-crocker-dmarc-sender It needs some work but it's worth adopting. I might do a review or two but you know how shy I am. R's, John From nobody Thu Aug 13 17:21:44 2020 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 0F5DF3A0B69 for ; Thu, 13 Aug 2020 17:21:43 -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, 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 rkMoK0oFTp31 for ; Thu, 13 Aug 2020 17:21:41 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 C99893A0B67 for ; Thu, 13 Aug 2020 17:21:41 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id n4so3833852vsl.10 for ; Thu, 13 Aug 2020 17:21:41 -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=zv8olDrokq67GU9icGef+ZKij/hGMbOFeRaPNrFSLXY=; b=nlZdwLXG7yDvaFFQDfzL5bq6V5iwSBpolBYCeCaoVMxmShmr2uCfUU5s7yCwdeK5HT nxy9SCChWlQRrXCZncc9hJD/Yuw9EVybE2Bhsg4mTkXqbpw4W9oMpHyW2BlCCNL6OXpo Xg03PGG2zn+VmLSSzIqY07Iqk2KtciOAlosUX4gr6MI1X6i4Yjoye1xrHcx3HZ2NxmbA lqUAU3KdTKruaegyEPsGbtUJ0NbYmuM8ng+Ggu60E+hSw25KeGp4uqAJTcHgSjJlcaIY 1a/CAt2IxL/HKdduj/Rwp+dpebKJZppToKjwaHKvsWTpCU7ZiKsuqD7lOlMDG11LZHqQ UOaA== 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=zv8olDrokq67GU9icGef+ZKij/hGMbOFeRaPNrFSLXY=; b=FGlH9BfOclvcVSLBXq4Y8p8BBAhcolYSJZLQzzdr2HmFEec5Iuu/gwWiiLIECK8iou q+aDtYleP622Ud8P47qIdaRNrU299pXBsiqtHVuFuyAQmRC23OaLh6qTGD9yj32TIB1i fQkfJg7iuj8dnqn50fnzbdXwuHq4wG0MciVUlF/TTLLEVGtOLlO4agJXKpGm8cXOQs99 7bSlM4TB+uZqVBSNLGoeWjpCdEyhm54HVTSO/6oPjxNOKib9vLvuslGexK8TtiSjdxNc 01MscE3fIS6l6LTyHhcQMK+CMmEp7Ost0C6r69rMFJCTcgLHuSasOqVliFiRLMqIgTd0 kWig== X-Gm-Message-State: AOAM530qKwCWkYhXIBPOef6FhCvbFxe/WT9trF8ARyb3IcFmSBVs5NQt ntSuDzl+0p9r8RQQIhtHAkLaSNU0Hgyn3ErpsDoNNw== X-Google-Smtp-Source: ABdhPJxWC39BAzPYoV7yV55SjXzPzSQklXhKoPn/6o+7lmOmLToX4H+Ogt4omNAw+llcWjZsR96T8t2w16h7FjjW/QY= X-Received: by 2002:a67:1305:: with SMTP id 5mr84061vst.52.1597364500792; Thu, 13 Aug 2020 17:21:40 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> In-Reply-To: <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> From: "Murray S. Kucherawy" Date: Thu, 13 Aug 2020 17:21:28 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a58c3705accb678a" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 00:21:43 -0000 --000000000000a58c3705accb678a Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker wrote: > > We have had a lot of attempts at third-party authorization schemes > .... > > With this in mind, I cannot see any point in designing yet another > > vouching or authorization scheme unless we have evidence that an > > interesting fraction of the world's mail systems want to use it. I > > don't see that, and honestly see no chance that we ever will. > > +1 > I'm disappointed that the experiment never really got its day in court, but the consensus is clear. +1. -MSK --000000000000a58c3705accb678a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 10:27 AM Dave Cro= cker <dhc@dcrocker.net> wrote= :
> We have had a lot of attempts at third-party authorizatio= n schemes
....
> With this in mind, I cannot see any point in designing yet another
> vouching or authorization scheme unless we have evidence that an
> interesting fraction of the world's mail systems want to use it. I=
> don't see that, and honestly see no chance that we ever will.

+1

I'm disappointed that the experi= ment never really got its day in court, but the consensus is clear. =C2=A0+= 1.

-MSK
--000000000000a58c3705accb678a-- From nobody Thu Aug 13 17:23:25 2020 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 B483F3A0B67; Thu, 13 Aug 2020 17:23:22 -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, 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 RKBk8sdvCBgA; Thu, 13 Aug 2020 17:23:21 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 15AE93A0B58; Thu, 13 Aug 2020 17:23:21 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id j188so3868023vsd.2; Thu, 13 Aug 2020 17:23:21 -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=s7OzY07XnWSJlwR8glJYQS6jtOB5EcppD/elEdxOUfg=; b=nyS509yj5s2qplxGczPKnvyVjW1wiF3D0FnDB9DOcQz34d+hQjWnh96mEd2gNL1aYs zIcMss4Nl8LUBR15/Zisd2vuF0F7unPvSvnZkdJrsDbcriDr0CnGAxn26LEIVqS5Nhq3 IaiSnw70K4CuQ/637q7Za95cUvaw65umyR6qtLxf78LM/Q/TxjlkG3QkSnNgS+hY5EpU RhjjoV/uPEd8xh/c8ELX+DU1zaAalHPIn+BFfS4eSCH9wJY/lBWsXeF1FtpC9l9PYNt+ Oy6OtLOK1b3MNEwLbc8TneK02ANuOwjqQLhP3jJqJh0IWkjDek8D0HXPeXzzIykXyvg4 770Q== 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=s7OzY07XnWSJlwR8glJYQS6jtOB5EcppD/elEdxOUfg=; b=KTrIcpE1N51pgM2KCAH8h+9JETbTpYl84sDvHBlV1ugRifK9VLz3utQW2rAWCC/YjG LJ03ZGDuBAncktw5pXwLyhBcx4MOYbNvd/0e+LbkBsG5xpyDvPiKXmtBSvq4tTwHbQLd cwb1oaF4+uK32LjRzBt4wiyojAaYzrlntnOhcLl8T2REfyS30GSvL0z9/08VKntcl8Fy qF6kzIMD2DuXVY3iA1VcUDo6nqkKxsvhxIG8Pq573rbExUwmCOal62BeFq9DRIwE/OpX d7tj0ps3Tqi1CZMkfRBGDbZ1xkc6M+usy0OuwXhzWs/PVDvUDyA62u7urGo2wn9xv5+v Czpw== X-Gm-Message-State: AOAM533Bf2krbmDHgz0lf8CyBA3kK+3iD2ccLWKbDx8/IGYPRSxxHvlJ 3tSra7aV4dTToSLi7UqqiNinyv44OUN0MDsji5K8RQ== X-Google-Smtp-Source: ABdhPJx8gLFLC4TTtVrHEWph2n9ocA49lJndxptILZl0wrT72AXSWV5SsJRfDEaO4Az99tQC8azmdu8Ed1Ob0DSnxX0= X-Received: by 2002:a67:eb91:: with SMTP id e17mr73896vso.7.1597364600136; Thu, 13 Aug 2020 17:23:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 13 Aug 2020 17:23:07 -0700 Message-ID: To: Tim Wicinski Cc: IETF DMARC WG , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009167f405accb6d4d" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 00:23:23 -0000 --0000000000009167f405accb6d4d Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. > > This starts a Call for Adoption for draft-crocker-dmarc-sender > > The draft is available here: > https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ > > Currently, the draft is marked as "Standards Track". The chairs feel if > the > working group does adopt this, it should begin as "Experimental". If we > start > to see adoption of this work, this can be changed back to "Standards > Track" before > Working Group Last Call. Of course, we welcome input from the working > group on this. > > Please review this draft to see if you think it is suitable for adoption, > and > send any comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 24 August 2020 > DISCUSS. (just kidding; +1 for adoption) -MSK, participating, except for the joke part, that was with full authority --0000000000009167f405accb6d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 12:05 PM Tim Wici= nski <tjw.ietf@gmail.com> w= rote:
Duri= ng IETF 108, the chairs realized that there was interest in Dave's
= RFC5322.Sender draft. =C2=A0

This starts a Call for Adoption for dra= ft-crocker-dmarc-sender

The draft is available here: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/

Cu= rrently, the draft is marked as "Standards Track".=C2=A0 The chai= rs feel if the
working group does adopt this, it should begin as "E= xperimental".=C2=A0 If we start
to see adoption of this work, this= can be changed back to "Standards Track" before
Working Group= Last Call.=C2=A0 Of course, we welcome input from the working group on thi= s.

Please review this draft to see if you think it is suitable for a= doption, and
send any comments to the list, clearly stating your view.<= br>
Please also indicate if you are willing to contribute text, review, = etc.

This call for adoption ends: 24 August 2020

DISCUSS.

(just kiddin= g; +1 for adoption)

-MSK, participating, except fo= r the joke part, that was with full authority
--0000000000009167f405accb6d4d-- From nobody Thu Aug 13 18:43:23 2020 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 0EDAC3A0BE3; Thu, 13 Aug 2020 18:43:22 -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, 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 nK0GhK8Ae-8S; Thu, 13 Aug 2020 18:43:20 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 4A03E3A0B55; Thu, 13 Aug 2020 18:43:20 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id f12so6927772wru.13; Thu, 13 Aug 2020 18:43:20 -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=XyRv022z0qCcLLkQIrgBADXhNczb/GOHnurXC9EnZ8Y=; b=tsZM41pp8dLF0MlrfxSqUDbQ6a52SIbwgqD33IxYnrftaIOyXrYo7hcrKYeVEJPeiL /cT2Knp5dTbOk6c2AEb3kOMMpkblPSXpcKztcy1nEAqnp0OlA95PwmOkYK5hOGYDLGUI ndFd73+hQJQOP1SYXU8o1h3XiqPM0c/cfWhbmRRDBpr7ToMjM2tIUf6yyMTTykZLDNLo 4MUEA9HLld8OV0UcxDYC9wee33BwUQwGlYso1pOvW61RJDQn0TxRHWM+3xzmNvGT0g/B r+smFgpGRvgjgmJ5GzYyGH3+LLeh8lG6tFDXqwpOX4poKBQaX4gZjlJUIhkCST78eYz9 dDjQ== 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=XyRv022z0qCcLLkQIrgBADXhNczb/GOHnurXC9EnZ8Y=; b=DMtgU3nFzTqRfl8x9FGGCaXIsv11DEJEJXA984BUhQk5cKH4nuyRUcYgzEUXjQXPjm 9JilrtEtWgOA/U08gB3qMtPZd7jYxhRN7gpEZ5aGIi+KqfmbgdXqxvW8kyMzl+Oy0mcI zYTMzDAiqtCM4f37eqlAi0eaSxFGWnDu+UhziRVs27a/c8vGuJctrYjXuiHmJjjHzBZo 59qc0AkovhgVcQ9VQnYy4Dla7YuIjRKqsRwanqeNsAKozu78ed/vaa83qox02FVkaOdg 0NkQvYcaumrHZbuwSj7K2DTu8eMty1v67o1y4CXRktwGMFcKs34f4stsbzSJc8fbBAkS 37TA== X-Gm-Message-State: AOAM5311DUhH+gaChRm9ktJgwyLLM0aTjHV3eWM07tJESSh9sdr7c+et PmBMEuX0M52CEI9JHvlHVyU17ifIW36QSANho38= X-Google-Smtp-Source: ABdhPJykHoVhKLTMQl88uzQbSJvRDODnPiMGqKGakQj6fK4Sq31JvSOugGft9wTn9TdtwKRS/iXRehw6+qs1j9fIoso= X-Received: by 2002:adf:fd82:: with SMTP id d2mr437404wrr.72.1597369398765; Thu, 13 Aug 2020 18:43:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Thu, 13 Aug 2020 21:43:08 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: Tim Wicinski , IETF DMARC WG , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000096adf005accc8bf8" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 01:43:22 -0000 --00000000000096adf005accc8bf8 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 8:23 PM Murray S. Kucherawy wrote: > On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > >> During IETF 108, the chairs realized that there was interest in Dave's >> RFC5322.Sender draft. >> >> This starts a Call for Adoption for draft-crocker-dmarc-sender >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ >> >> Currently, the draft is marked as "Standards Track". The chairs feel if >> the >> working group does adopt this, it should begin as "Experimental". If we >> start >> to see adoption of this work, this can be changed back to "Standards >> Track" before >> Working Group Last Call. Of course, we welcome input from the working >> group on this. >> >> Please review this draft to see if you think it is suitable for adoption, >> and >> send any comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 24 August 2020 >> > > DISCUSS. > > (just kidding; +1 for adoption) > > -MSK, participating, except for the joke part, that was with full authority > > "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers from a similar problem as PRA in the SenderId draft. There is no way to validate that the specific intermediary is authorized by the (From) domain originating the email through it's generic signalling that it authorizes intermediaries. This means that any source can emit a message claiming to be a legitimate intermediary just as any source could game PR to gain a neutral result. This raises a significant question as to the value of this proposed draft. It essentially reverts to depending on reputation as to whether the intermediary's assertions (I'm really really trustworthy) should be accepted. One could achieve similar outcomes using only reputation and local policy override of DMARC policy. The only way a scheme along the lines of the proposed one would be if the specific intermediary were authorized either through a seperate DKIM signing of a field (with the intermediary domain ) that would remaintact even if the DKIM signing of the entire message were broken by the (authorized) intermediary. The proposed approach is easily abusable by individuals with malicious intent. Michael Hammer --00000000000096adf005accc8bf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 8:23 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Mon, Aug 10, 2020 at 12:05 PM Tim Wi= cinski <tjw.ietf= @gmail.com> wrote:
During IETF 108, the chairs realized that there was interes= t in Dave's
RFC5322.Sender draft. =C2=A0

This starts a Call = for Adoption for draft-crocker-dmarc-sender

The draft is available h= ere: https://datatracker.ietf.org/doc/draft-crocker-dmarc-s= ender/

Currently, the draft is marked as "Standards Track&q= uot;.=C2=A0 The chairs feel if the
working group does adopt this, it sho= uld begin as "Experimental".=C2=A0 If we start
to see adoptio= n of this work, this can be changed back to "Standards Track" bef= ore
Working Group Last Call.=C2=A0 Of course, we welcome input from the = working group on this.

Please review this draft to see if you think = it is suitable for adoption, and
send any comments to the list, clearly= stating your view.

Please also indicate if you are willing to contr= ibute text, review, etc.

This call for adoption ends: 24 August 2020=

DISCUSS.

(just kidding; +1 for adoption)

-MSK, part= icipating, except for the joke part, that was with full authority
=

"DISCUSS" shouldn't really = be a joke. draft-crocker-dmarc-sender suffers from a similar problem as PRA= in the SenderId draft. There is no way to validate that the specific inter= mediary is authorized by the (From) domain originating the email through it= 's generic signalling that it authorizes=C2=A0intermediaries. This mean= s that any source can emit a message claiming to be a legitimate intermedia= ry just as any source could game PR to gain a neutral result. This raises a= significant question as to the value of this proposed draft. It essentiall= y=C2=A0reverts to depending on reputation as to whether the intermediary= 9;s assertions (I'm really really trustworthy) should be accepted. One = could achieve similar outcomes using only reputation and local policy overr= ide of DMARC policy.=C2=A0

The only way a scheme along the lines of = the proposed one would be if the specific intermediary were authorized eith= er through a seperate DKIM signing of a field (with the intermediary domain= ) that would remaintact even if the DKIM signing of the entire message wer= e broken by the (authorized) intermediary.

The proposed approach is = easily abusable by individuals with malicious intent.

Michael Hammer=
--00000000000096adf005accc8bf8-- From nobody Thu Aug 13 18:44:48 2020 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 63B063A0BE3 for ; Thu, 13 Aug 2020 18:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=bbiw.net header.b=Xzd9bjAU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dmsR0yBQ 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 UmJUQqF2ZVKs for ; Thu, 13 Aug 2020 18:44:42 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFBF3A0B55 for ; Thu, 13 Aug 2020 18:44:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 930C4E28; Thu, 13 Aug 2020 21:44:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 13 Aug 2020 21:44:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=C tnivnPB1wZEA4+0tNjcIY7aWMJUiJb6wzEoPT7aFwA=; b=Xzd9bjAUi4yzfT+rc +s7uB75P7KsRCSz8dmvjIqo+aEl77dCV8VIJQh59irU5KJhuTsnZ/d016eG8+Iad 4DiU2aBuXpyHyVn0ts9HeMYdt28S9MitEryOhMh5KU4cr3L0C1ShWx606ycNAXON fT5VoyS2neZO00A4fupog3TFCcMnwEfQ2OZY+Ml2M772VjU0gkUjHEF4LFF6KQSg lhwEVzGBOGFQguAVSKHOckNe+DZJk7/i7nbBEqd+T584WP/eHY8lIrxfKTKWhJxR ip0wXiTFXzzDkIMSdRTI9GmS0WoSL5JjW0Kg3azaD8zCOOJtjNZKeoJQpvtXHQ0w j8sPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=CtnivnPB1wZEA4+0tNjcIY7aWMJUiJb6wzEoPT7aF wA=; b=dmsR0yBQYr8UD35RAjyJHkUime1S/hXT03vwcMBoYk27fUPaHk2vyh3VZ mSmLqzxJTqdy4zm2vpksN0Fh85wJ0TTrrf9XlSvXgVRJoxyg05mYaIgj2esWZYt0 RATnYNsfsFDGApFH/wIavd3PMtXIhHe7Mk6fA2IO557mnvSMd7f9erUf49de30Il gL5+zX8LNqrLwraVcJcNGpgjysNoHpr9eNUtZdaeKAaeGxUf1kLepltzeKa+x1wN 50IUV/ulfhjtVSSRKngxCQc8ecQjkc+L0MqTxHgf53LdCXIldjqinrVxdilcW8mT 64/+kB/sZWP05iDFZ5xer/xfnwEhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleeigdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthekredttdefjeenucfhrhhomhepffgrvhgv ucevrhhotghkvghruceouggtrhhotghkvghrsegssghifidrnhgvtheqnecuggftrfgrth htvghrnheptddvfedugeehjefgvdffffelleegudfftedvueejkeeuveeiledufefhgfev hfejnecuffhomhgrihhnpegssghifidrnhgvthenucfkphepuddtkedrvddviedrudeivd drieefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep uggtrhhotghkvghrsegssghifidrnhgvth X-ME-Proxy: Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id AD6BC3280060; Thu, 13 Aug 2020 21:44:40 -0400 (EDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2e5408af-c3c1-1b34-4600-70a355ef0eb5@bbiw.net> Date: Thu, 13 Aug 2020 18:44:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 01:44:46 -0000 On 8/13/2020 5:21 PM, Murray S. Kucherawy wrote: > I'm disappointed that the experiment never really got its day in court, > but the consensus is clear.  +1. 30 years ago, there was a generally adventurous tone in the community. Things are a lot more cautious now. I remember back then hearing various ideas or proposals and for many of them thinking "I've no idea whether that will be useful or successful but it sounds like something worth trying." Not so much these days. Alas. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 13 19:02:29 2020 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 ED2FC3A0C00 for ; Thu, 13 Aug 2020 19:02:27 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=VPIS2Ilq; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZUKL2/i5 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 XhonYEEc8lQZ for ; Thu, 13 Aug 2020 19:02:26 -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 3FE623A0BF4 for ; Thu, 13 Aug 2020 19:02:26 -0700 (PDT) Received: (qmail 8726 invoked from network); 14 Aug 2020 02:02:24 -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=2211.5f35f0b0.k2008; bh=2Y8NeLGWvADbUEpCMXDa3mylLoTk9m/gpxQoJaVIUoI=; b=VPIS2IlqZLtGbNrPESq80cKgwGVWlEMC5OMCnvYysDfMcDBQQj2rZK1Cw68pwYnW+wspdku8joQ3Di8NfmtqGZpblfO9aS18MzTGIR0MeMbL9W2PfWe3xYtq1+GrK1qNYiKuxqagQzB6HLPMIiExN8MO0YX7xSarUArgzgZuPN4u2dJcatSZHyg6LKXQBLkhdUQzOinB0Cg8oP6LnD7wPeQNTX1egilNO77ka8Ij293I+Z2ZzjQ5FJquhFm7uDWn1zLnLpzVT/ssjJXkBDZcchF4nw9TDCYS/vKdCfr+ogT7QiyZsUa555fXJuKZZL5zbtd94o2XaXCpOZgqmeQoZQ== 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=2211.5f35f0b0.k2008; bh=2Y8NeLGWvADbUEpCMXDa3mylLoTk9m/gpxQoJaVIUoI=; b=ZUKL2/i5JTRbZzeEI53bNNcufUJqDmlfQNF7zkx+qJ03mRwywMaBeb2EUe9+0t1CB9zKLXlliwVZB4uX+B7XkInUfZVss8SsbqFDFoOowZRpvKqQxm+HgywhpYYEu2PT7RGuxHtvfWnDd3tT/XEAPLEe8JhYoUv6uCtIAMkKiEFXnzPS95Q8biISjx/iLOoiHi49B0ffn+LHoMILETKtyBybzOeUdKDobfv0+SGOBHGEgpTBCzd21Dm9HI3HwVwEzIrEXQncmbYu0UdYV2JnIlszVa4FWpRTTN38Xa8yjtA5n1FegV5xKMPtZ+Vd2+zkc1Qoe7dF8HBAjyRugfP0mA== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Aug 2020 02:02:24 -0000 Received: by ary.local (Postfix, from userid 501) id A5D141E92DCC; Thu, 13 Aug 2020 22:02:23 -0400 (EDT) Date: 13 Aug 2020 22:02:23 -0400 Message-Id: <20200814020223.A5D141E92DCC@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <2e5408af-c3c1-1b34-4600-70a355ef0eb5@bbiw.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 02:02:28 -0000 In article <2e5408af-c3c1-1b34-4600-70a355ef0eb5@bbiw.net> you write: >I remember back then hearing various ideas or proposals and for many of >them thinking "I've no idea whether that will be useful or successful >but it sounds like something worth trying." Not so much these days. Alas. I'm perfectly happy to try stuff but considering how concentrated the mail business has gotten, unless a gorilla or two seems interested, "try" won't really happen. Also, we now have several more decades of experience about stuff that seemed appealing but failed. There's no shame in learning from experience. R's, John From nobody Thu Aug 13 19:08:12 2020 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 85A523A0C04 for ; Thu, 13 Aug 2020 19:08:10 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=G2dIYSev; dkim=pass (2048-bit key) header.d=taugh.com header.b=NK0AErh1 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 MQds_13j1oxs for ; Thu, 13 Aug 2020 19:08:08 -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 94FF93A03F5 for ; Thu, 13 Aug 2020 19:08:08 -0700 (PDT) Received: (qmail 10148 invoked from network); 14 Aug 2020 02:08:07 -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=27a1.5f35f207.k2008; bh=5UoZIBYZAsVr8I63wIG3SOx3i/Z+SKV4F++Ne8ZuReI=; b=G2dIYSevj7/0e7C4aPDzj3zkJFzqrn9Qlx54QhW5x3S5tjtx+0b/PujVF67WX486zMsJoKrTweL7jPfNX3uHp1gTceLZvbMmHXn6ZAblP0yNPCV4fXDBEdaTYJL/H8F5sTi3qySbhKED0VwOX5PWha/Ndm2VQJZ5qiDmYqG8JytKxWff2oKqHCAhjikY8EebXanNoFvukt5qLR7Z/c9l0OVmuXewYS9ZdftWfMsxvNYw5NFluRBTuF7gDpeA2/35J56Pm6DeB3HxQvnSrRlAZW6r1GECSOl8JSy+xjeg48El0VOB0Qyb3viMK9qT113ufsnLAFvdEHlv0oug9+6oZw== 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=27a1.5f35f207.k2008; bh=5UoZIBYZAsVr8I63wIG3SOx3i/Z+SKV4F++Ne8ZuReI=; b=NK0AErh1RbSmcSwXMh1xXHYE/Fx2FnGoRDPfQKexLDlqzqj8GKLaPU9SrUBcX2wj4MJwcxbw2bjlBIgnpnDP5wwJFREkJajp/6dqJqpxQXzGdHSogZqQf6sZcgjO7KnGOnHkB1flgkJ/pjP/Qpveb7q3TNkfunSLnS6eprVHb8HAYdh0g987vBSA25+IsOCLVvp0qI5Kb54hEyz+LT1ZCflc64R+vKk4D2tQzFrfiHaLFvmO6qcrcnndixnOWl73BfiYP80qEJCvdQM5haui8cv7IlWnCdJO5EcFz3l81OWGbe2Nm87LBvqQ63ePyVbwoYLcnxg+P5Ouj6vauQCmKA== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Aug 2020 02:08:07 -0000 Received: by ary.local (Postfix, from userid 501) id 7D8BF1E92E0C; Thu, 13 Aug 2020 22:08:06 -0400 (EDT) Date: 13 Aug 2020 22:08:06 -0400 Message-Id: <20200814020806.7D8BF1E92E0C@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dotzero@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 02:08:11 -0000 In article you write: >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers >from a similar problem as PRA in the SenderId draft. There is no way to >validate that the specific intermediary is authorized by the (From) domain >originating the email through it's generic signalling that it >authorizes intermediaries. This means that any source can emit a message >claiming to be a legitimate intermediary just as any source could game PR >to gain a neutral result. That's a feature, not a bug. I want recipients to be able to assess the mail my lists send on its own merits. >One could achieve similar outcomes using >only reputation and local policy override of DMARC policy. Only if you believe that the domain on the From: line is automatically more credible than the one on the Sender: line. The whole third party problem is that the people sending their mail through lists or whatever are in fact doing so legitimately, but for various reasons their organizations' DMARC policies lie and say they aren't. R's, John From nobody Thu Aug 13 23:01:19 2020 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 D2A903A0D78 for ; Thu, 13 Aug 2020 23:01:09 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 1UOm90JAsNkA for ; Thu, 13 Aug 2020 23:01:05 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 7A22C3A0DAD for ; Thu, 13 Aug 2020 23:01:05 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id mw10so3887157pjb.2 for ; Thu, 13 Aug 2020 23:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=EqG2LYHwroc9wVav/C6LZV+vJ47jRG2Clz+4lCwEKsI=; b=hTCSkCB5piAwoiIyPW/ZxuK48DO5NparlzxO3oKNwDorDHxRUUf9aiU+LSuKCJRZtH atWANJ89cvuGvbppUuJZzXzbVIjfoJXxi8Nd83szyV2kkLsN/cAsIQqi08+s4moR3mY9 4AsEkE4dwHDGsr7a/f9Q4SbfriflW+vVKnQ6U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=EqG2LYHwroc9wVav/C6LZV+vJ47jRG2Clz+4lCwEKsI=; b=Ob2prsts0HlOaLutODdjssX9QrnzlBJ0WbfwJOr4AATlcZG63T+qL0kwW3J4zNIzN2 2Ilva2W11LUDP/sWLeXMweKwJ2hZe+1wUGbb0KmdPwWaC9FAlZPCj55qAZuKlX1wbQu+ pDlnfpOX5M2XZ8CCXeA/J6uhfA9os6qmr/kTGJBKLFrT9GdhR2p83lriSMlQUz90RzIG 5/HtGTGrVoqvmKzaJrp1SmdSza/diNwQqzeUCLznNywLItnosgT1JGAOXmF65xqdkP1A K5K8slHWJF6ukMt2fz1YUoCop2qAIryr0yqbDAC6da4POubayOX1QhAoEvzJ5oq9vCnQ 9GXA== X-Gm-Message-State: AOAM5325+RPam6KpOihjHTScyxojybzshF7kL64YvCsRqN6ee9YlcPGE ixi9Nvl2g3CvS9vXnuu9LVZxl8mQyoyp8fmL X-Google-Smtp-Source: ABdhPJxGMvelAQzCOoOg0nvCZ05rKqMpUaoktqBH22/F8PmQN9p593ghweLgBpeHe9In/L0ctpoWxQ== X-Received: by 2002:a17:902:bc85:: with SMTP id bb5mr927613plb.54.1597384863967; Thu, 13 Aug 2020 23:01:03 -0700 (PDT) Received: from ?IPv6:2601:1c0:cb00:7680:7ca1:3eb5:41ea:2a35? ([2601:1c0:cb00:7680:7ca1:3eb5:41ea:2a35]) by smtp.gmail.com with ESMTPSA id m29sm7185864pgc.55.2020.08.13.23.01.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2020 23:01:03 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-21E184DC-1BE6-4EB2-A758-A444D2644E81 Content-Transfer-Encoding: 7bit From: Neil Anuskiewicz Mime-Version: 1.0 (1.0) Date: Thu, 13 Aug 2020 23:01:02 -0700 Message-Id: <61A742FF-DBBE-4B22-AA88-8F0E5779CEDB@marmot-tech.com> References: <291fe9b1380249bbb13bbd77234c788d@com> Cc: "dmarc@ietf.org" In-Reply-To: <291fe9b1380249bbb13bbd77234c788d@com> To: "Douglas E. Foster" X-Mailer: iPad Mail (17G68) Archived-At: Subject: Re: [dmarc-ietf] Firing the vendor X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 06:01:17 -0000 --Apple-Mail-21E184DC-1BE6-4EB2-A758-A444D2644E81 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 13, 2020, at 3:09 PM, Douglas E. Foster wrote: >=20 > =EF=BB=BF > Yours is the better answer! >=20 > DF >=20 >=20 > -------- Original message -------- > From: Dotzero > Date: 8/13/20 5:54 PM (GMT-05:00) > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ? >=20 >=20 >=20 >> On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrot= e: >>> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: >>=20 >>> The current DMARC architecture supports authorizing a vendor to mail on b= ehalf of their clients if the client includes them in their SPF policy or de= legates a DKIM scope to them and they use it.. >>>=20 >>> =20 >>>=20 >>> I agree that SPF is too limiting (including hard limits on complexity), a= nd DKIM is too complex for an uncooperative vendor. >>>=20 >>> =20 >>>=20 >>> In most cases, a solution would be a controlled third-party signature au= thorization along the lines of RFC 6541. >>>=20 >>> The client would configure the authorization in his own DNS and the and t= he vendor would only need to sign with their own DKIM signature. =20 >>>=20 >>=20 How would this resolve the alignment failures with regard to the RFC5321.fro= m (SPF from) with the organizational domain?=20 And I think the vendors motivation is not putting dev and support resources.= Does this delegation scheme solve that problem?=20 >> If "DKIM is too complex for [this] uncooperative vendor", why would havin= g the "vendor...sign with...DKIM" be workable? The vendors for whom it would would work already make getting DKIM signing s= et up easy so there=E2=80=99s no problem to be solved. For the others there=E2=80=99s not much incentive to devote resources and no= t much risk to the vendor to mitigate. No incentive and little risk means no= t on radar unless you care about doing things right. Inbox providers could u= p the anti more and there=E2=80=99s been some movement in that area.=20 >=20 > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 yea= rs ago it was difficult to find vendors who were willing to deal with DKIM a= nd able to do a good job in implementing. The common mantra was "how does th= is fit into my business model". These days I would consider it table stakes.= I see your point but the vast majority of customers Of said vendors aren=E2= =80=99t aware there=E2=80=99s a problem until there is. But make authenticat= ion and alignment easy and part of setup as the best vendors do puts people o= n the right path without hassles, barriers and disincentives. Fire the vendor isn=E2=80=99t always that easy if you=E2=80=99re locked in a= nd you=E2=80=99ve got shit to do. We=E2=80=99re talking about stone masons, a= ccountants, non profit organizations, home inspectors, SaaS companies, and a= ll the other people who have stuff to get done.=20 Yeah, I=E2=80=99ve helped clients fire plenty of vendors but I=E2=80=99m jus= t saying it is not first on one=E2=80=99s to do list most days.= --Apple-Mail-21E184DC-1BE6-4EB2-A758-A444D2644E81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Aug 13, 2020, at 3:09 PM, Douglas E. Foste= r <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:

=EF=BB=BF
Yours i= s the better answer!

DF

-------- Original message --------
From: Dotzero <dotzero@gmail.com>
Date: 8/13/20 5:54= PM (GMT-05:00)
To: dmarc@ietf.org
Subject: Re: [dmar= c-ietf] draft-crocker-dmarc-author-00 ?



On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) <= kboth@drkurt.com> wrote:
On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd=3D40bayviewphy= sicians.com@dmarc.ietf.org> wrote:

The current DMARC arc= hitecture supports authorizing a vendor to mail on behalf of their clients i= f the client includes them in their SPF policy or delegates a DKIM scope to t= hem and they use it..

 

I agree that SPF is too limiting (includi= ng hard limits on complexity), and DKIM is too complex for an uncooperative v= endor.

 

In most cases, a solution would be a controlle= d third-party signature authorization along the lines of RFC 6541.=

T= he client would configure the authorization in his own DNS and the and the v= endor would only need to sign with their own DKIM signature.   


How would this resolve the alignment failures= with regard to the RFC5321.from (SPF from) with the organizational domain?&= nbsp;

And I think the vendors motivation is not put= ting dev and support resources. Does this delegation scheme solve that probl= em? 

If "DKIM is too complex f= or [this] uncooperative vendor", why would having the "vendor...sign with...= DKIM" be workable?
The vendors for whom it would would work already make getting DKIM s= igning set up easy so there=E2=80=99s no problem to be solved.
For the others there=E2=80=99s not much incentive to devote reso= urces and not much risk to the vendor to mitigate. No incentive and little r= isk means not on radar unless you care about doing things right. Inbox provi= ders could up the anti more and there=E2=80=99s been some movement in that a= rea. 
=

Wrong answer. If the vendor i= s uncooperative then fire the vendor. 4-5 years ago it was difficult to find= vendors who were willing to deal with DKIM and able to do a good job in imp= lementing. The common mantra was "how does this fit into my business model".= These days I would consider it table stakes.
I see your point but the vast majority of customers Of said vendors &n= bsp;aren=E2=80=99t aware there=E2=80=99s a problem until there is. But make a= uthentication and alignment easy and part of setup as the best vendors do pu= ts people on the right path without hassles, barriers and disincentives.
Fire the vendor isn=E2=80=99t always that easy if you=E2=80=99= re locked in and you=E2=80=99ve got shit to do. We=E2=80=99re talking about s= tone masons, accountants, non profit organizations, home inspectors, SaaS co= mpanies, and all the other people who have stuff to get done. 

Yeah, I=E2=80=99ve helped clients fire plenty of vendors bu= t I=E2=80=99m just saying it is not first on one=E2=80=99s to do list most d= ays.
= --Apple-Mail-21E184DC-1BE6-4EB2-A758-A444D2644E81-- From nobody Fri Aug 14 01:27:19 2020 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 3C8FA3A08A2 for ; Fri, 14 Aug 2020 01:27:18 -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, 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 M2BW6pQBLgAX for ; Fri, 14 Aug 2020 01:27:16 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 690CA3A089F for ; Fri, 14 Aug 2020 01:27:16 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id a15so7576027wrh.10 for ; Fri, 14 Aug 2020 01:27:16 -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; bh=YgyeBQgOPJ4eEXiboU5H7bWW32ezbEIZ/HKuLQHgtN8=; b=hL7t/vwPL5NgmX5NGlQTU7H15stGL1cWLJ/swGncBK/JC6gZnM+o1h4P2+PKSN+o/f 28CTMVPYutVjH8qDiG8co//aD1zRR8HqFRDNO7TKXFwduD1U/nJtHz6VDImB+RE9GGGs Z1aKMpaI00LtKjcvbc9Iyx4sdt8K8iCm1m1XNxATjn6aZH3ygSGtrRvWms1M+h/D4/eF kpMvb7oyczHP48I3qtTaliI0M7bR2uuMml5svWVcSLeYsmZWPaR6QBlXcXOS2uQdETMj 7FjzBmq9QyLoHuRvfaT85p2cbKx+DbYr2QDw6Do7rz/no5rmWKpt8L5ChhT9H68Kd3Mm vcHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YgyeBQgOPJ4eEXiboU5H7bWW32ezbEIZ/HKuLQHgtN8=; b=owPD4la3hLzH0Kma0hsKw1qrPZotYpgDYc4RBv/2UoUopQheMXqqJxrn3CgZhxbeEB i8VviNKLfO+azYMQ23dVAYOaFA5tioUdKD77wnaWeTvyk8EawNhXqw0LOEkinwW/YepN YgfepSKXw7BBE7nkNeE/Gm0U1H/dLY11H3W6xuXNNgQlGE3UPwjpGU2SdGLy8MtmSHeS +cJTaUFzmWU0bo7/VQ++T/25/eF5TVg6gwRGg0/tRzRtNo/PNKQtH+Eco+u46etoRXXV fcZ5LYetvGnxbvgXhT8jmKX5srFvvGlyu7Mr2UKnAxzvK0Ehq7hvike6sZ1s2Px81aH6 A10w== X-Gm-Message-State: AOAM5313tKHFZfcNfvXBVEnFojT34DJPLEsP73Mc+ClyPnNFxYRBLQ47 EbVo2PWuqMp4Pu0cExCsgs638+aSr87DjaVTxaHlxKe04L0= X-Google-Smtp-Source: ABdhPJyPgH4AJ6JyJc9MQnt5qRXAV56AfEmFjLao2G7qGMvL3cO1sw+kZ4bpQBX2/mIznwRmE1QrT0turcAp7gxhaxo= X-Received: by 2002:adf:fd82:: with SMTP id d2mr1653700wrr.72.1597393634527; Fri, 14 Aug 2020 01:27:14 -0700 (PDT) MIME-Version: 1.0 References: <20200814020806.7D8BF1E92E0C@ary.local> In-Reply-To: <20200814020806.7D8BF1E92E0C@ary.local> From: Dotzero Date: Fri, 14 Aug 2020 04:27:03 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000270c4905acd23056" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 08:27:18 -0000 --000000000000270c4905acd23056 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 13, 2020 at 10:08 PM John Levine wrote: > In article 99yVu0dgLz-z19iwfA@mail.gmail.com> you write: > >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers > >from a similar problem as PRA in the SenderId draft. There is no way to > >validate that the specific intermediary is authorized by the (From) domain > >originating the email through it's generic signalling that it > >authorizes intermediaries. This means that any source can emit a message > >claiming to be a legitimate intermediary just as any source could game PR > >to gain a neutral result. > > That's a feature, not a bug. I want recipients to be able to assess > the mail my lists send on its own merits. > And recipient domains do just that using local policy override. DMARC policy is at best a request to the Validator/Receiving Domain. If a Validator/Receiving Domain chooses to honor the published DMARC policy for a domain such as p=reject, then they are in fact assessing the mail your lists send based on the merits as they see them. The same goes if they decide to not honor that published DMARC policy and accept mail from your lists. Earlier in my DMARC journey I felt that MLMs should adjust and send list mail as themselves. Now I have come to the conclusion that they should reject list submissions from accounts at domains which publish a DMARC policy of p=reject. Domains should not be able to externalize their internal problems to others. > > >One could achieve similar outcomes using > >only reputation and local policy override of DMARC policy. > > Only if you believe that the domain on the From: line is automatically > more credible than the one on the Sender: line. The whole third party > problem is that the people sending their mail through lists or > whatever are in fact doing so legitimately, but for various reasons > their organizations' DMARC policies lie and say they aren't. > I think you are misusing the term "credible". Domains which are publishing p=reject policies are making an assertion regarding mail purporting to be authorized by their domain. It is not an assertion that their mail is "good" or should be delivered to a recipient or even given preferential treatment with regard to filters or policy. The assertion is simply that mail purporting to be authorized by my domain must pass either SPF or DKIM validation or else we request that in the event of neither of these properly validating for a particular email message, please reject this message. Don't think of it as being about "legitimate" or "not legitimate". There is a certain (normally small) amount of mail that fails to validate even when it passes directly from the outbound MTA to the recipient domain's MTA. The sending domain is accepting that this otherwise valid mail may (SHOULD?) be rejected by the receiving domain. The organizations DMARC policies aren't lying. They are simply saying "If this then that." This ultimately goes back to the elephant in the room. Does an individual user's use of an account at a domain trump the organization's right to define how an account at a domain may/should be used? I absolutely agree that in an ideal world this issue should not be externalized yet here we are. This is why I made the point above that lists should respect DMARC policy and not accept submissions from domains with DMARC p=reject policies. It becomes "Not your circus and not your monkey". and forces the problem back to the domain and it's users. If an MLM isn't modifying the message then the DKIM signature should survive and this discussion is irrelevant. I think this covers the range of MLM use cases that have been a topic of discussion. If the MLM admin really wants to poke those domains publishing p=reject then they can respond to user subscribe attempts or submissions that are rejected with an explanation that they need to go have a meaningful discussion with their mail admin/IT staff/domain account provider or whoever is responsible for publishing p=reject for tht domain but still allowing users to sign up for MLMs or attempt to use other intermediaries. popcorn is of course optional. Michael Hammer --000000000000270c4905acd23056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 13, 2020= at 10:08 PM John Levine <johnl@taugh= .com> wrote:
In article <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=3D99yVu0dgLz-z19iwfA@mail.g= mail.com> you write:
>> "DISCUSS" shouldn't really be a joke. draft-crocker-= dmarc-sender suffers
>from a similar problem as PRA in the SenderId draft. There is no way to=
>validate that the specific intermediary is authorized by the (From) dom= ain
>originating the email through it's generic signalling that it
>authorizes intermediaries. This means that any source can emit a messag= e
>claiming to be a legitimate intermediary just as any source could game = PR
>to gain a neutral result.

That's a feature, not a bug. I want recipients to be able to assess
the mail my lists send on its own merits.

And recipient domains do just that using local policy override. DMARC po= licy is at best a request to the Validator/Receiving Domain. If a Validator= /Receiving Domain chooses to honor the published DMARC policy for a domain = such as p=3Dreject, then they are in fact assessing the mail your lists sen= d based on the merits as they see them. The same goes if they decide to not= honor that published DMARC policy and accept mail from your lists. Earlier= in my DMARC journey I felt that MLMs should adjust and send list mail as t= hemselves. Now I have come to the conclusion that they should reject list s= ubmissions from accounts at domains which publish a DMARC policy of p=3Drej= ect. Domains should not be able to externalize their internal problems to o= thers.

>One could achieve similar outcomes using
>only reputation and local policy override of DMARC policy.

Only if you believe that the domain on the From: line is automatically
more credible than the one on the Sender: line. The whole third party
problem is that the people sending their mail through lists or
whatever are in fact doing so legitimately, but for various reasons
their organizations' DMARC policies lie and say they aren't.

I think you are misusing the term "credi= ble". Domains which are publishing p=3Dreject policies are making an a= ssertion regarding mail purporting to be authorized by their domain. It is = not an assertion that their mail is "good" or should be delivered= to a recipient or even given preferential treatment with regard to filters= or policy. The assertion is simply that mail purporting to be authorized b= y my domain must pass either SPF or DKIM validation or else we request that= in the event of neither of these properly validating for a particular emai= l message, please reject this message. Don't think of it as being about= "legitimate" or "not legitimate". There is a certain (= normally small) amount of mail that fails to validate even when it passes d= irectly from the outbound MTA to the recipient domain's=C2=A0MTA. The s= ending domain is accepting that this otherwise valid mail may (SHOULD?) be = rejected by the receiving domain. The organizations DMARC policies aren'= ;t lying. They are simply saying "If this then that."
<= br>
This ultimately goes back to the elephant in the room. Does a= n individual user's use of an account at a domain trump the organizatio= n's right to define how an account at a domain may/should be used? I ab= solutely agree that in an ideal world this issue should not be externalized= yet here we are. This is why I made the point above that lists should resp= ect DMARC policy and not accept submissions from domains with DMARC p=3Drej= ect policies. It becomes "Not your circus and not your monkey". a= nd forces the problem back to the domain and it's users. If an MLM isn&= #39;t modifying the message then the DKIM signature should survive and this= discussion is irrelevant. I think this covers the range of MLM use cases t= hat have been a topic of discussion. If the MLM admin really wants to poke = those domains publishing p=3Dreject then they can respond to user subscribe= attempts=C2=A0or submissions=C2=A0that=C2=A0are rejected with an explanati= on that they need to go have a meaningful discussion=C2=A0with their mail a= dmin/IT staff/domain account provider or whoever is responsible for publish= ing p=3Dreject for tht domain but still allowing users to sign up for MLMs = or attempt to use other intermediaries. popcorn is of course optional.

Michael Hammer
--000000000000270c4905acd23056-- From nobody Fri Aug 14 01:38:51 2020 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 6DC5A3A0847 for ; Fri, 14 Aug 2020 01:38:49 -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, 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 s2UM6IaLUoqJ for ; Fri, 14 Aug 2020 01:38:48 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 4501B3A0849 for ; Fri, 14 Aug 2020 01:38:48 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id 9so6800442wmj.5 for ; Fri, 14 Aug 2020 01:38:48 -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; bh=VYu6yyaR4JGB7fDlHCOtOTtLcOkZhdeN6iyJmWnr9BM=; b=o6lhj50eUK49q8t/9O4yeSb3PSeh+RH7BzEt8Z3uFI0Wocfpwp5pwiPMJTfJFRpdDD SjdQPn9R6kc7go9NqEAx4JELp7MqftXHaP4fc/+NFa+MY8K6bSRHOHWcZ6XEFNcmZ9tU hgFGpwwltGl3WusfnpCSPyLZ5u4KHdYjim48OBkZO8q/f7327oa57/zL5C7PeS+QVc8Y WQH4gsixOGR8jpykZkugd8FpVKuk4S0DHsYdamZJWTdJzCJ23Fl+OykjjRONiB2+BNqK izwb6lufuVCTX9k7mvsLtfemO5osPIGkm+EbqcEqklI4ZiEe58J2kuvZ9AC7BbyEwy9o D+eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VYu6yyaR4JGB7fDlHCOtOTtLcOkZhdeN6iyJmWnr9BM=; b=p/3jCMJ5lkEg0nD6xAsEyv2FbzEAIUxfarlg5GoVkSGxkDpDQoiQTP8rXLg+wAuRsg rNvfPNHION+GVi3itr4poThN1EKRgANaLFnF89i98ip9q0nYdBrY5bUWN1yLx91Du4Mf kGm8ckQc+oz25VmTmBmgUOhlMsI9ZgnmGiGuzwL2sQra83iIoLVE1KNZwZb+o+Z/Yna1 w+r4x/U5mFEHRMDDHqBM94jIIciyvKkSI8pQj+cE9Wbj3GRTdGglWFocUHSvL0EVkgUT 6MZnUT09j8u45eXdq6NMt/ncfDPpbCOT56NZ9FUigqKnrdlVZQUkzVx6jpV31bkhPeqP O2Qw== X-Gm-Message-State: AOAM532oPa2xXdwsmB3KwKMbRAmgPyy1IBzijdQtm7+sM1MI5dRRrW6r IpJL/Aw/wkJPzNl3ruxXGOTix8KclWi/f6bKUK+XBVFm X-Google-Smtp-Source: ABdhPJzlV7jCv5Z+HVO5McutiKszHU3QCB7JOyiNEErQECBxBnsvfkXAvPv8aKJamEImAAGWiZ0NgTuatR3atXcKACU= X-Received: by 2002:a1c:de86:: with SMTP id v128mr1544237wmg.36.1597394326472; Fri, 14 Aug 2020 01:38:46 -0700 (PDT) MIME-Version: 1.0 References: <291fe9b1380249bbb13bbd77234c788d@com> <61A742FF-DBBE-4B22-AA88-8F0E5779CEDB@marmot-tech.com> In-Reply-To: <61A742FF-DBBE-4B22-AA88-8F0E5779CEDB@marmot-tech.com> From: Dotzero Date: Fri, 14 Aug 2020 04:38:35 -0400 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000654c2205acd25944" Archived-At: Subject: Re: [dmarc-ietf] Firing the vendor X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 08:38:49 -0000 --000000000000654c2205acd25944 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2020 at 2:01 AM Neil Anuskiewicz wrote: > > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 > years ago it was difficult to find vendors who were willing to deal with > DKIM and able to do a good job in implementing. The common mantra was "ho= w > does this fit into my business model". These days I would consider it tab= le > stakes. > > I see your point but the vast majority of customers Of said vendors > aren=E2=80=99t aware there=E2=80=99s a problem until there is. But make = authentication and > alignment easy and part of setup as the best vendors do puts people on th= e > right path without hassles, barriers and disincentives. > This is NOT an interoperability issue that needs to be solved by the IETF. It's a personal problem between a client and their vendor. > > Fire the vendor isn=E2=80=99t always that easy if you=E2=80=99re locked i= n and you=E2=80=99ve got > shit to do. We=E2=80=99re talking about stone masons, accountants, non pr= ofit > organizations, home inspectors, SaaS companies, and all the other people > who have stuff to get done. > Perhaps the IETF needs to come up with an RFC for people who are locked in and have shit to do. On the other hand, thst may not fall into the realm of technical problems that the IETF deals with. > > Yeah, I=E2=80=99ve helped clients fire plenty of vendors but I=E2=80=99m = just saying it is > not first on one=E2=80=99s to do list most days. > And that may be why clients who hire such vendors feel pain, not just with email authentication but with a whole raft of other issues. A vendor problem !=3D something that the IETF is going to fix with an RFC. Michael Hammer --000000000000654c2205acd25944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 2:01 AM Neil = Anuskiewicz <neil@marmot-tech.co= m> wrote:

<= div class=3D"gmail_attr"><SNIP>

Wrong a= nswer. If the vendor is uncooperative then fire the vendor. 4-5 years ago i= t was difficult to find vendors who were willing to deal with DKIM and able= to do a good job in implementing. The common mantra was "how does thi= s fit into my business model". These days I would consider it table st= akes.
I see your point but the vast maj= ority of customers Of said vendors =C2=A0aren=E2=80=99t aware there=E2=80= =99s a problem until there is. But make authentication and alignment easy a= nd part of setup as the best vendors do puts people on the right path witho= ut hassles, barriers and disincentives.

This is NOT an interoperability issue that needs to be solved by the IET= F. It's a personal problem between a client and their vendor.

Fire the vendor isn=E2=80=99t always that easy if you=E2=80=99re l= ocked in and you=E2=80=99ve got shit to do. We=E2=80=99re talking about sto= ne masons, accountants, non profit organizations, home inspectors, SaaS com= panies, and all the other people who have stuff to get done.=C2=A0

Perhaps the IETF needs to come up with = an RFC for people who are locked in and have shit to do. On the other hand,= thst may not fall into the realm of technical problems that=C2=A0the IETF = deals with.

Yeah, I=E2=80=99ve helped clients fire plenty= of vendors but I=E2=80=99m just saying it is not first on one=E2=80=99s to= do list most days.

And that=C2= =A0may be why clients who hire such vendors feel pain, not just with email = authentication but with a whole raft of other issues. A vendor problem !=3D= something that the IETF is going to fix with an RFC.

<= div>Michael Hammer
--000000000000654c2205acd25944-- From nobody Fri Aug 14 02:20:57 2020 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 ABC1C3A08A9 for ; Fri, 14 Aug 2020 02:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 e1X6BJIyXTmH for ; Fri, 14 Aug 2020 02:20:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 C8D8B3A087F for ; Fri, 14 Aug 2020 02:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597396850; bh=mYy/v4fXuEFee1AN+Y6+edHxJ5mDz1q2Zk63XeU+Swo=; l=1286; h=To:References:From:Date:In-Reply-To; b=BJgQ3uELk4sUkbSmM+mvT1rw5Kx/R7AjdELKXbQWmDCfOaOutLpYYcWkYrSjinRBx 2Ow/C97+qeo3aBfcLbaKdB5h68gaHYrTaHTyZGsJOy0Uf/BobPkcUHf2IbwLcR3VjA NvVLzlccoSxjq0GjEuNtC1LgUjJI3w1MjnSWYhblVZDBeCK5u8Ewreg4XEPKs Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.36.146]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0B0.000000005F365772.00006B16; Fri, 14 Aug 2020 11:20:50 +0200 To: dmarc@ietf.org References: <20200810172411.A13681E7CD8B@ary.local> From: Alessandro Vesely Message-ID: <10d4cb3b-baf5-0bfc-6160-70db96b9f0d1@tana.it> Date: Fri, 14 Aug 2020 11:20:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200810172411.A13681E7CD8B@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 09:20:56 -0000 On 2020-08-10 7:24 p.m., John Levine wrote: > In article <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> you write: >> Even an external reputation system requires recipient >> participation. That is why I suggested both a >> send3="parameters" clause to indicate sender support for >> third-party authorization and a verify3="parameters" clause to >> indicate recipient support for third-party authentication. When >> both are visible to the non-domain message source, that source >> can have confidence that the message will be handled as >> authorized. > > We have had a lot of attempts at third-party authorization schemes > going back at least to vouch-by-reference in 2009 and ATPS in 2012, > and the Spamhaus Whitelist in 2010. Every single one of them failed, > not due to technical problems, but because nobody was interested. We can either try and understand what was wrong in those schemes, or abandon authorization schemes forever. Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent success. PGP, GPG, and even personal CA certificates never became really popular, so we could have concluded that digital signature aren't worth considering for anti-spoof protocols. Yet, someone thought about DKIM... Best Ale -- From nobody Fri Aug 14 02:21:19 2020 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 776E43A08A9 for ; Fri, 14 Aug 2020 02:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 LVPyDEw2_yBV for ; Fri, 14 Aug 2020 02:21:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 DE6123A0900 for ; Fri, 14 Aug 2020 02:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597396873; bh=zqmHDGm4EX51rv6p7c3QjnHf2Aephbk6JCHV2uRe7lE=; l=1919; h=To:References:From:Date:In-Reply-To; b=DRJNh3Kp4jT/3cSuPK18GSNBrRUKArPzjXrEa/Vk+kzzWPUdvyNDnSr57Ob8b/v2P 8zix+Gkv6PRfyjAc19It966DlRsSJ1AIyc2lOrg8mDLKMD4LlbJIfweqWw/iri0U4k C7flwF+KVSXfPe4CSImxuqr3C5/Pv/b1gvk0lB93FwyxZZi0ni7Ms/KbS05kQ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.171.36.146]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BB.000000005F365788.00006B2C; Fri, 14 Aug 2020 11:21:12 +0200 To: dmarc@ietf.org References: <20200814020806.7D8BF1E92E0C@ary.local> From: Alessandro Vesely Message-ID: Date: Fri, 14 Aug 2020 11:21:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 09:21:18 -0000 On 2020-08-14 10:27 a.m., Dotzero wrote: > On Thu, Aug 13, 2020 at 10:08 PM John Levine wrote: >> In article you write: >>> "DISCUSS" shouldn't really be a joke. [...] Adopting the I-D should boost the discussion, not hamper it. No reason to discuss about adoption... >> That's a feature, not a bug. I want recipients to be able to assess >> the mail my lists send on its own merits. >> > > And recipient domains do just that using local policy override. > DMARC policy is at best a request to the Validator/Receiving > Domain. If a Validator/Receiving Domain chooses to honor the > published DMARC policy for a domain such as p=reject, then they are > in fact assessing the mail your lists send based on the merits as > they see them. The same goes if they decide to not honor that > published DMARC policy and accept mail from your lists. Agreed. However, local policy override based on unspecified external sources is not easy for medium-small domains. > Earlier in my DMARC journey I felt that MLMs should adjust and > send list mail as themselves. Now I have come to the conclusion > that they should reject list submissions from accounts at domains > which publish a DMARC policy of p=reject. Oh, in case, users can get another freemail account, or use trash email addresses. Should the email infrastructure depend on the existence of such operators? IMHO, a myriad of medium-small domains is more robust and more reliable than a few gorillas managing the whole world communications. > Domains should not be able to externalize their internal problems > to others. You're sticking to the original concept that DMARC protection shall only be granted to heavily abused domains which don't host users' mailboxes. People's email must be spoofable. Why? Best Ale -- From nobody Fri Aug 14 04:09:09 2020 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 E57C63A0F88 for ; Fri, 14 Aug 2020 04:09:07 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2K8eWdMfV-X for ; Fri, 14 Aug 2020 04:09:06 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4403A0F87 for ; Fri, 14 Aug 2020 04:09:06 -0700 (PDT) X-ASG-Debug-ID: 1597403344-11fa311da6c3070001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id iD3s6wlyuwjDuAcP (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 14 Aug 2020 07:09:05 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=WuhvdnpvHtHn0dbj3N+wvAuJUfmI7L+KWbt+Ff4VSE8=; b=gfa/eSruG3OWHJvBW9moiHsfLcPTxwaysyAsl3FCI67HzD8NHZs9SLc10EN3dqV65 HS4qzbrv6sbZmR8IMvVaJsQ0eXxK9FqMKTbX7xpepi6oo5e7dGeHRPyRxZFLtbgD/ ck416ty/tQzNGSQecGCrRgzveq1cEoAHOBTgGgbZU= From: "Douglas E. Foster" To: "IETF DMARC WG" Date: Fri, 14 Aug 2020 11:08:56 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=e8242023ec694573a42ac57d840423c8 In-Reply-To: References: <20200814020806.7D8BF1E92E0C@ary.local> X-Exim-Id: bcbbd1cb28214dc69b7977c1ea03960b X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597403345 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 1398 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 11:09:08 -0000 This is a multipart message in MIME format. --e8242023ec694573a42ac57d840423c8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Michael Hammer / Dotzero writes: "Earlier in my DMARC journey I felt that MLMs should adjust and send list m= ail as themselves. Now I have come to the conclusion that they should rejec= t list submissions from accounts at domains which publish a DMARC policy of= p=3Dreject. Domains should not be able to externalize their internal probl= ems to others." My DMARC reports show no authorized transactions being rejected, but I do h= ave two servers in Japan that are actively spoofing my organization's ident= ity. How is that an "internal" problem? DF --e8242023ec694573a42ac57d840423c8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Michael Hammer / D= otzero writes:

"Earlier in my DMARC journey I felt= that MLMs should adjust and send list mail as themselves. Now I have come = to the conclusion that they should reject list submissions from accounts at= domains which publish a DMARC policy of p=3Dreject. Domains should not be = able to externalize their internal problems to others."


My DMARC reports show no authorized transactions being= rejected, but I do have two servers in Japan that are actively spoofing my= organization's identity.  How is that an "internal" problem?

DF

--e8242023ec694573a42ac57d840423c8-- From nobody Fri Aug 14 07:12:58 2020 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 049C33A113D for ; Fri, 14 Aug 2020 07:12:57 -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, 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 ZwVW3kGro-Ba for ; Fri, 14 Aug 2020 07:12:55 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 0B7363A112F for ; Fri, 14 Aug 2020 07:12:55 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id c80so7601792wme.0 for ; Fri, 14 Aug 2020 07:12:54 -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=6Np4fGOEIZPyvPbSGTuYQq6bHVx7rEnm9sxxCrg1ouc=; b=IkX8HozQ/EOJt6PnmU52EG/SKPPFkp1pVbCQJBLhsjBG3aF1KYxUH0rY90dYUbl61v dDVttQtxw93844ZxZC5wrNH7ydfFsiQWiViiFE93tX1QoUnYaNcQFcvhpAqY0kfluUdL wt7Hbbr9IY+Xxeo5IRbvHFo0i3dBRGfiT5Ej4wWFfFapIqVlqTtM+fBUJm0PPeEpcp13 ex7s1cguE0Zk/D48Wxkw5WuJZxPM00z29195fJXtNLJej/Ej0QlLTmMcSrGftfl07kQE wjP2c8M8J0JNmVwG4kDzByI1ZZh2y+Eyp/YPwsDRqmKTeoOud3kYOHkYvQmH1j7731yq 3IIQ== 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=6Np4fGOEIZPyvPbSGTuYQq6bHVx7rEnm9sxxCrg1ouc=; b=I0ASDdFvdNaIQd0TVaACMBbn94MsDQtgZu5VUqiSe36zpS//nBFYNLmmn6qW4WtkdI tKHxLh5H3M7LL5gSln+rmsy/zlaZTw0hU76JjTEI5l62ehV6oeuHzRja1xb+bfz82qC8 6yVmZYOgEtNjpOtszm6+nirEkg2g1/elLWrx/FP+6syXUIcwfq8HHimltYMx8jE/fZCo 5mb+RzqJ0ilP4m0XuL/K6EG7R4UtbsR32V7Iyyk8W8VJOjxF3aA4IQF5zwGHzPkH6TVa jolo5q/3ei550juAQmQjoXkexXjxuJwB8WtjJAPvRL8mRfrx/K8aSthHGYvjtnzBbgWK IBQg== X-Gm-Message-State: AOAM533av7r20WptQmFQ9aInmY7VwLBeeKy0KtyOBtRJdwllX0UzI5XV en6YZZNz94+IBoNFQCYeU1gaViJ+iFL9YeyKh9bsByox X-Google-Smtp-Source: ABdhPJyFifTkKRywqALyVTXdZxjVN/CRxBvd4478n6cv1ubk/kbizcmFd1dklI6NO6+mAgbMcY8OqcnSulpIrHiEjDA= X-Received: by 2002:a1c:3dc3:: with SMTP id k186mr2666023wma.122.1597414373466; Fri, 14 Aug 2020 07:12:53 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <10d4cb3b-baf5-0bfc-6160-70db96b9f0d1@tana.it> In-Reply-To: <10d4cb3b-baf5-0bfc-6160-70db96b9f0d1@tana.it> From: Dotzero Date: Fri, 14 Aug 2020 10:12:42 -0400 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004a25ea05acd70453" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:12:57 -0000 --0000000000004a25ea05acd70453 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely wrote: > On 2020-08-10 7:24 p.m., John Levine wrote: > > In article <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> you > write: > >> Even an external reputation system requires recipient > >> participation. That is why I suggested both a > >> send3="parameters" clause to indicate sender support for > >> third-party authorization and a verify3="parameters" clause to > >> indicate recipient support for third-party authentication. When > >> both are visible to the non-domain message source, that source > >> can have confidence that the message will be handled as > >> authorized. > > > We have had a lot of attempts at third-party authorization schemes > > going back at least to vouch-by-reference in 2009 and ATPS in 2012, > > and the Spamhaus Whitelist in 2010. Every single one of them failed, > > not due to technical problems, but because nobody was interested. > > > We can either try and understand what was wrong in those schemes, or > abandon authorization schemes forever. > > Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent > success. > > PGP, GPG, and even personal CA certificates never became really > popular, so we could have concluded that digital signature aren't > worth considering for anti-spoof protocols. Yet, someone thought > about DKIM... > There is a little bit of history behind the impetus for SPF and DKIM. In 2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on Email Authentication and SPAM. It also let it be known that if the private sector didn't come up with solutions it was willing to move forward with regulation. This helped drive activity for SPF, the merger of DK and IIM to create DKIM and Microsoft's push for SenderID. Private sector folks did not want to risk what government regulation might look like. At that time there were also folks pushing for PGP, GPG, Personal Certificate and S/MIME as paths forward. Even with that, it took a while for industry efforts to gain some sense of clarity. Notice that the general path forward was basically domain based and not individual user/client based. There was a debate within the DKIM effort regarding i= vs d= to the extent that at one industry event people were walking around with little stickers on their badges to indicate which they supported. I believe that was courtesy of Dave Crocker. Michael Hammer --0000000000004a25ea05acd70453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 5:21 AM Aless= andro Vesely <vesely@tana.it> w= rote:
On 2020-08= -10 7:24 p.m., John Levine wrote:
> In article <2ef8e773e7bf467481a05ab3fc4d937f@bayvi= ewphysicians.com> you write:
>> Even an external reputation system requires recipient
>> participation.=C2=A0 =C2=A0That is why I suggested both a
>> send3=3D"parameters" clause to indicate sender support f= or
>> third-party authorization and a verify3=3D"parameters" c= lause to
>> indicate recipient support for third-party authentication. When >> both are visible to the non-domain message source, that source
>> can have confidence that the message will be handled as
>> authorized. >
> We have had a lot of attempts at third-party authorization schemes
> going back at least to vouch-by-reference in 2009 and ATPS in 2012, > and the Spamhaus Whitelist in 2010.=C2=A0 Every single one of them fai= led,
> not due to technical problems, but because nobody was interested.


We can either try and understand what was wrong in those schemes, or
abandon authorization schemes forever.

Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent
success.

PGP, GPG, and even personal CA certificates never became really
popular, so we could have concluded that digital signature aren't
worth considering for anti-spoof protocols.=C2=A0 Yet, someone thought
about DKIM...

There is a little bit of = history behind the impetus for SPF and DKIM. In 2003 and 2004 the FTC (U.S.= Federal Trade Commission) held workshops on Email Authentication and SPAM.= It also let it be known that if the private sector didn't come up with= solutions it was willing to move forward with regulation. This helped driv= e activity for SPF, the merger of DK and IIM=C2=A0 to create DKIM and Micro= soft's push for SenderID. Private sector folks did not want to risk wha= t government regulation might look like. At that time there were=C2=A0also = folks pushing for PGP, GPG, Personal Certificate and=C2=A0 S/MIME as=C2=A0 = paths forward. Even with that, it took a while for industry efforts to gain= some sense of clarity. Notice that the general path forward was basically = domain based and not individual user/client based. There was a debate withi= n the DKIM effort regarding i=3D vs d=3D to the extent that at one industry= event people were walking around with little stickers on their badges to i= ndicate which they supported. I believe that was courtesy of Dave Crocker.<= /div>

Michael Hammer
--0000000000004a25ea05acd70453-- From nobody Fri Aug 14 07:20:01 2020 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 450B73A1186 for ; Fri, 14 Aug 2020 07:20:00 -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, 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 ngnFVvUDPrDG for ; Fri, 14 Aug 2020 07:19:58 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 7259F3A121F for ; Fri, 14 Aug 2020 07:19:00 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id p14so7615651wmg.1 for ; Fri, 14 Aug 2020 07:19:00 -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=GxGXPd8UVMu/nlHesYcEIM9E3hkANeD0ZRjfvk961FY=; b=b/0qJ6L8Qfc2/gOppdlA1hvHk92t4URPJNJXKm1gYiwjhxsmY7scXOIW6H4QzM+SKl eirAVpe285rV2tPCLIDHikKlYOQ14lBfTE7qWOBXtWCEBIg17jpUH/jUibGQlyn3aEAq MBwk3HFPpQmtiZXqaSHYgkLSV/I5mFeszz1sTJsaZbkGQ7VFu7zgyVtnRqiW/YW0GCRv A/jNgHVD82ZDtuLL4TMxNb13XofQxhDn7fkl4TWhpBc/01w6CTKA4+AL3R3xoJyyUFv0 DOdCj4upjuaa6HwFyRxu++xRSdOGwAsL3V84h+ShYjxyIqeySlN+yKYFGtlO/s8RYsPi +MdA== 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=GxGXPd8UVMu/nlHesYcEIM9E3hkANeD0ZRjfvk961FY=; b=oxks2HnB5E1CXqa7ftM2w7aMl2q9SW9/44sQxELfN5B53z1PYl4RV7UfjTTZy49TQX opmjVpwiYTqn/uowGp/tT8ftwrD+JrbP1QPaSq/s7CkLug+Bn1ABmJgK2XCYL7WhZW8j vwqZKBkr0DxsIUPVNoBVftIPv3n1tZDGU+drMQtWhjlpOGiM6w/EwCb+QwSHx7yUeBIV tKC2FHrsCLN6SCHUxN5zeoeGY+c/hpiMCXz4psXmBVLs4MzeVyg05azx2JqSWaWsocOW OkGp/t/MgDi49bUUol++KTlW+M1qZejdg/IDA97qDpHAQPO22MJUonZ4uCPGd8VIBryB /f/A== X-Gm-Message-State: AOAM5329lIuP9mz3GalxViy3L5UKyWCLvXwHaV63sRbuzerFtjNR/MmW ShXX/cYYfXBV2n4dxE+lFcTgdHMBb8w368FGXqU= X-Google-Smtp-Source: ABdhPJx3uKVehfEAPipd+mDQR+L8xs3k96LCQpec9uT7go41Nmr2oZvRM3J+8wkJ/8jpNQZYh8XKGiZrqAPitzngCs0= X-Received: by 2002:a1c:de86:: with SMTP id v128mr2698727wmg.36.1597414738974; Fri, 14 Aug 2020 07:18:58 -0700 (PDT) MIME-Version: 1.0 References: <20200814020806.7D8BF1E92E0C@ary.local> In-Reply-To: From: Dotzero Date: Fri, 14 Aug 2020 10:18:48 -0400 Message-ID: To: "Douglas E. Foster" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000135cfd05acd71a25" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:20:00 -0000 --000000000000135cfd05acd71a25 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 7:09 AM Douglas E. Foster wrote: > Michael Hammer / Dotzero writes: > > "Earlier in my DMARC journey I felt that MLMs should adjust and send list > mail as themselves. Now I have come to the conclusion that they should > reject list submissions from accounts at domains which publish a DMARC > policy of p=reject. Domains should not be able to externalize their > internal problems to others." > > > My DMARC reports show no authorized transactions being rejected, but I do > have two servers in Japan that are actively spoofing my organization's > identity. How is that an "internal" problem? > > DF > How is that relevant to the discussion thread? Are they MLMs or other intermediaries which your users are sending messages to/through? If not then it sounds like DMARC is working exactly as intended for you as long as validators/receivers are respecting your DMARC policy assertions. Michael Hammer --000000000000135cfd05acd71a25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 7:09 AM Dougl= as E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
Michael Hammer / Dotzero writes:

"Earlier in my DMARC journey I felt that MLMs should adjust a= nd send list mail as themselves. Now I have come to the conclusion that the= y should reject list submissions from accounts at domains which publish a D= MARC policy of p=3Dreject. Domains should not be able to externalize their = internal problems to others."


= My DMARC reports show no authorized transactions being rejected, but I do h= ave two servers in Japan that are actively spoofing my organization's i= dentity.=C2=A0 How is that an "internal" problem?

DF=

How is that = relevant to the discussion thread? Are they MLMs or other intermediaries wh= ich your users are sending messages to/through? If not then it sounds like = DMARC is working exactly as intended for you as long as validators/receiver= s are respecting your DMARC policy assertions.=C2=A0

Michael Hammer
--000000000000135cfd05acd71a25-- From nobody Fri Aug 14 07:31:50 2020 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 A148A3A1147 for ; Fri, 14 Aug 2020 07:31:49 -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, 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 SY7CKFjkEWJC for ; Fri, 14 Aug 2020 07:31:48 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 C3CEC3A1146 for ; Fri, 14 Aug 2020 07:31:47 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id 88so8557054wrh.3 for ; Fri, 14 Aug 2020 07:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w/BAT0FyRv6Xi+zh4mTZAXOAxlLHk2esjRN5U8bvxpI=; b=jrKVv6pi3QwEE+ox5/Zpe6WaKpwLLrvWstWSfGmdR41nPYZUGsFs9WRVvMSEkJ8odp LNDa36aNqVjxpEsUtfFpjeHM9I50NDK51lHc32QiN4TvOESRWTkUBvcQ2OLBnNXmeXgR 4wWWtJ9qUJx2TC/iX6zgf1rcJk403dRlRggzowqaSLuRD4ijrg7i3FhfWZ6+yB8hVoJk i4/5wPRDR+bRKMGf8FJpgZ1bcfOoezKZJQQO3kFlI/YmucM29TRW69nMGNCqBtykZ7FT mkVTt2t0U3N3PcBfAL75SBWyNZL1agJIhfbKOSu2cUm1ZXSfxk4mUIDUdVexmtc2zbtZ 3XRA== 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=w/BAT0FyRv6Xi+zh4mTZAXOAxlLHk2esjRN5U8bvxpI=; b=WC2QTooEZR4bnJe0BKMkUXhM9rc2jGVsxg7KxoWjOhCs3Q1leo76tPnD0SKDiLFIwx gs5QkpVUCO1R1n2hkvzfajwm5Z/4kBgJhp5WJnLPdFn8pZBySy1xE4w+Dkx4m6XMx/A4 COMMrWVS4MI96XMVCwpa32W98BDhTaGv3+l/JmWh55h4ZA6Vbrb3+inSAhyF5Vt8vCGb yl6k7xfoMTYpeccxWCfDgNJwMAerEAiBAZ1MHL7Qi80L/Vjq75S9zUoO+YmCIKRl5bKo riDLBShkbpEg8Tm/lGHy/hctzZdwyC4vLy0yV7VDS9sunW6eZltCNvN8aicuGqzxL5F/ Hfjw== X-Gm-Message-State: AOAM533tLbxbOqI1kvKwrfv95+ZqczqljCpju3W07AviRUShATCfL2ty 72AvwB4d/Lnu52OG1wZOOVEfle92lWSwo/+HGJMgc1UN X-Google-Smtp-Source: ABdhPJzGiHWe7uXf0wrOk0Lbh+h6qBhyK11mx3cQ594EtSuUV7LnNvLFM7y6E2eG6soOVUI9BcEm8JY3P4qSy06d5Jk= X-Received: by 2002:adf:edc3:: with SMTP id v3mr2967161wro.193.1597415506269; Fri, 14 Aug 2020 07:31:46 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Fri, 14 Aug 2020 10:31:35 -0400 Message-ID: To: Neil Anuskiewicz Cc: Doug Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cf633605acd74759" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:31:50 -0000 --000000000000cf633605acd74759 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz wrote: > > > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> If I followed Neil=E2=80=99s discussion of MajorCRM: >> >> >> >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy = or >> delegates a DKIM scope to them and they use it. >> > > And client's domain is only in the Mail from uses the vendor's domain ( > somevendorxyz123.foo.com). It passes SPF in but it's not in alignment > with the organizational domain name (example.com) that the client uses in > the header from. > > This is super common and, as a practical matter, it works... except if yo= u > ever want to use DMARC's policy for anything other than reporting. The va= st > majority of people think that if you add include:bar.com (whatever vendor > KB says) in the SPF that they are good to go. > "Vast majority of people"? Can you please provide data that supports this assertion? > So many businesses have several entries in their organizational domain's > SPF record yet the RFC5321.from is the vendor's domain. The client > sometimes goes over the 10 DNS lookups with includes that aren't doing > anything for them. I'm not sure that 10 DNS lookup limit. There are some > prominent services of various sorts for which the single include will do > over 10 DNS lookups and hat's just one of many includes a client might ha= ve > (I know this isn't about SPF per se). > > Yes, I can usually quickly set up a subdomain to use instead of > somevendorxyz123.foo.com but this isn't always possible or it requires > pushing to get it done. > So you are saying "Email authentication is hard. Let's go shopping"? > > This makes DMARC a sketchy tool to use for any policy above none which is > in and of itself useful. > Not at all. It simply means that the people/organizations involved have some problems. Please consider the following joke: How many Psychiatrists does it take to change a light bulb? Only one but the bulb has to want to change. I've been involved in setting up DMARC with a policy of p=3Dreject for somewhere North of 6,000 domains. As a sending domain, the heavy lifting is in getting buy-in across the organization that it is a worthwhile effort, getting control of your organization's mail flows and ensuring policies and procedures are communicated and followed. For complex environments there may need to be some automation required for creating and maintaining private/public key pairs and DNS records but that is much more straightforward than the aforementioned heavy lifting. Michael Hammer. > > --000000000000cf633605acd74759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 13, 2020 at 6:53 PM Neil = Anuskiewicz <neil@marmot-tech.co= m> wrote:


On Thu, Aug 13, 2020 at 2:33 PM Doug= Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote= :

If I followed Neil=E2=80=99s discussion of MajorCRM:

=C2=A0

The current DMARC architecture supports authorizing a vendor = to mail on behalf of their clients if the client includes them in their SPF= policy or delegates a DKIM scope to them and they use it.

=


This is super common and, as a practical matter, it works... except if you= ever want to use DMARC's policy for anything other than reporting. The= vast majority of people think that if you add include:bar.com (whatever vendor KB says) in the SPF t= hat they are good to go.

"Vast majority of people"? Can you please provide data=C2=A0that= supports this assertion?
=C2=A0
So = many businesses have several entries in their organizational domain's S= PF record yet the=C2=A0RFC5321.from is the vendor's domain= . The client sometimes goes over the 10 DNS lookups with includes that aren= 't doing anything for them. I'm not sure that 10 DNS lookup limit. = There are some prominent services of various sorts for which the single inc= lude will do over 10 DNS lookups and hat's=C2=A0just one of many includ= es a client might have (I know this isn't about SPF per se).

Yes, I can usually quickly set up a subdomain to use = instead of=C2=A0somevendorxyz123.foo.com but this isn't always possible or it re= quires pushing to get it done.

<= /div>
So you are saying "Email authentication is hard. Let's g= o shopping"?=C2=A0

<= div>This makes DMARC a sketchy tool to use for any policy above none which = is in and of itself useful.

Not at all. It simply means that the people/organizations involved have = some problems. Please consider the following joke:=C2=A0

How many Psychiatrists does it take to change a light bulb? Only one= but the bulb has to want to change.

I've been= involved in setting up DMARC with a policy of p=3Dreject for somewhere Nor= th of 6,000 domains. As a sending domain, the heavy lifting is in getting b= uy-in across the organization that it is a worthwhile=C2=A0effort, getting = control=C2=A0of your organization's mail flows and ensuring policies an= d procedures are communicated and followed. For complex environments there = may need to be some automation required for creating and maintaining privat= e/public key pairs and DNS records but that is much more straightforward th= an the aforementioned=C2=A0heavy lifting.

Michael = Hammer.
=C2=A0
<= /div>
--000000000000cf633605acd74759-- From nobody Fri Aug 14 07:46:00 2020 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 D1D553A0D20 for ; Fri, 14 Aug 2020 07:45:58 -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=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 ZcCtCrgBITVG for ; Fri, 14 Aug 2020 07:45:57 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 688AE3A0C54 for ; Fri, 14 Aug 2020 07:45:57 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 4440B9F1F7 for ; Fri, 14 Aug 2020 07:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597416356; bh=ByBaZHOjXX0ut9KT7kIogo6aWjw4cg8iBildowTXmjE=; h=From:Subject:Date:References:To:In-Reply-To:From; b=Fk/L2VjZQx9Hlmt6oJb0fxWJiIsmf/nSMxaC7XvXL9S4n+PU9TNbwltaW3zh9Vpx6 Ia7CbD1Mx3TEjcni4SPhbUG7GZdxH1BUlEQ3p75AO572kDifjuKTTfrPE+vHNWVmHR wRfFToaaHlEUF768KPKVD8PZGVElS5DF6djfUVEg= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_92CF9DF9-2823-4E68-B87B-3BA18A6DFF7F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 14 Aug 2020 15:45:54 +0100 References: <20200814020806.7D8BF1E92E0C@ary.local> To: IETF DMARC WG In-Reply-To: Message-Id: <3253B303-7A8B-436A-BB14-3E59FA6C96B1@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:45:59 -0000 --Apple-Mail=_92CF9DF9-2823-4E68-B87B-3BA18A6DFF7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Aug 2020, at 09:27, Dotzero wrote: >=20 > Now I have come to the conclusion that they should reject list = submissions from accounts at domains which publish a DMARC policy of = p=3Dreject. Domains should not be able to externalize their internal = problems to others. This effectively cuts off users at multiple ISPs from ever participating = in mailing lists. Which is exactly what we=E2=80=99re trying to fix with = this proposal.=20 Just because a user has an address at a consumer mailbox provider that = publishes p=3Dreject does not make them a second class citizen banned = from participating in any mailing list.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_92CF9DF9-2823-4E68-B87B-3BA18A6DFF7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Aug 2020, at 09:27, Dotzero <dotzero@gmail.com> = wrote:

 Now I have come to the conclusion = that they should reject list submissions from accounts at domains which = publish a DMARC policy of p=3Dreject. Domains should not be able to = externalize their internal problems to = others.

This effectively cuts off users at multiple ISPs = from ever participating in mailing lists. Which is exactly what we=E2=80=99= re trying to fix with this proposal. 

Just because a user has an address at a consumer = mailbox provider that publishes p=3Dreject does not make them a second = class citizen banned from participating in any mailing = list. 

laura 
-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_92CF9DF9-2823-4E68-B87B-3BA18A6DFF7F-- From nobody Fri Aug 14 07:59:01 2020 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 E8EB83A0C5F for ; Fri, 14 Aug 2020 07:58:58 -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=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 T0dNE_ZHwCtk for ; Fri, 14 Aug 2020 07:58:57 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EDE3A0C5D for ; Fri, 14 Aug 2020 07:58:57 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id p18so4844111ilm.7 for ; Fri, 14 Aug 2020 07:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=FvCeOKGh0IfNvP8e4UizLz0cGMp0qUJ/x9M4o6si+BI=; b=TUpZPlcY4FfHfE89xTd9F5ELQEhZcRXTiz7scdLbSq8GVBZv0Rtuv5gUd0gy5kieQi MJ/UT5ye/Gd15Fxc4QNoKwnlO4XGJ/n2nizF/H6CyLmN190qoQ5cO6Uk3omvAZKa8oof /MP3vYfnI9F2h8WwDwi+hSZM9UBgOYOKvFJFc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FvCeOKGh0IfNvP8e4UizLz0cGMp0qUJ/x9M4o6si+BI=; b=tY8IZKv9lN4OR352O7UTv7zNVmf6aQL59mGtL1qduCdh/YsgG6QxmaNRMNelv2gq5/ abjFlx37AFo8/z+q6HNXeU8OdRO2wBeGZ7X7SGIeeIItxdIcQMqP9h4npryUZnxYBheq pUfH+p75z7gWgr6GgHZFafcrE28sNq/KINZj8RSyT81hiwq4uWycReVuYwBo3CbFUvIs OMezjY7Fz2RQ1cxyioP8Hoe2w3NrHjx1nlOgnqGld47L4StzVJZL9ZDjdzQBWA7DDZX2 5MM+3rer8Qtt+EkFro1tVqg3H9J0bsa/0mitwS8ZoXWxpAA73mUe5coSLiFIsHCsZP6e o+TQ== X-Gm-Message-State: AOAM533IV/KNJ6CKfl+c9kQaHrcmSVE/+WPlw4GY5a4IF5ODhO7pyaHn pJJJfgbsKvfp4R5kENwCwl588jKHzpreQ3oqk3wV+CGF7iiSg2h/ X-Google-Smtp-Source: ABdhPJxyHKZCUkj/0tlo6JkAOiMyMabtpBXsYJbRCYmfYjeiGXYGW7l3UKeUGlfiBIDUdLUXzZSQoVfmQ5cASDuOHJA= X-Received: by 2002:a92:7310:: with SMTP id o16mr2150034ilc.23.1597417136152; Fri, 14 Aug 2020 07:58:56 -0700 (PDT) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Fri, 14 Aug 2020 07:58:19 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f57aee05acd7a8b6" Archived-At: Subject: [dmarc-ietf] Good paper analyzing inter-component flaws in email security X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:58:59 -0000 --000000000000f57aee05acd7a8b6 Content-Type: text/plain; charset="UTF-8" It would be worthwhile for everyone in the group to read through https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun as they analyze implementation flaws that allow attacks against DMARC in existing implementations. The paper should be publicly accessible now since the conference is in progress. There's also a slide deck with a summarized set of results from their study. --Kurt --000000000000f57aee05acd7a8b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would be worthwhile for everyone in the group to read t= hrough=C2=A0https://www.usenix.org/conference/usenixsecurity2= 0/presentation/chen-jianjun as they analyze implementation flaws that a= llow attacks against DMARC in existing implementations.

= The paper should be publicly accessible now since the conference is in prog= ress. There's also a slide deck with a summarized set of results from t= heir study.

--Kurt
--000000000000f57aee05acd7a8b6-- From nobody Fri Aug 14 08:13:14 2020 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 E26A53A0C88 for ; Fri, 14 Aug 2020 08:13:11 -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=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 Wv8RqdhWS5kn for ; Fri, 14 Aug 2020 08:13:10 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 2661B3A0EE3 for ; Fri, 14 Aug 2020 08:13:09 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id a5so10988709ioa.13 for ; Fri, 14 Aug 2020 08:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a9xITa87XrsDUF7Yu/MrPTQEtBrlSIvpB73J7cgCofA=; b=DC8vwb7TmztTJBHn/B5m0cZQUt/F/15SN6IY41rGyvxpE/qC2iD6y0hi29NRC2MtOg z2t09CY/H5+ufc08cYhgrEc0MsU3Qd0VkKgBOg02pwKayv8yXWhsRMaipDsCgf9EXojh phvZkdNUrEyYjpwJz8/Wi3k9AeYw61SpguBa8= 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=a9xITa87XrsDUF7Yu/MrPTQEtBrlSIvpB73J7cgCofA=; b=YfLvz2T9e5rGGrlyUdiNVCa7qaylM+paj/iZQhwo/BbAgBwP4BrOs7RJQdM/Pz8oa2 V3Z8Nmi+puHjZu9rzwmRtTsk5m0zeVNIc5hNIpOlHW1PyfSjB07fERhvb1ZJWxap+32M QDSy4dmBv4qe8Q+sM8tlLAPeRsmrjiQOf1t0pCgFnZT8aE27kv6/PN7thipPD/KeO22J gk49/4R0+L/PRYN4pKBl4qFSON//hRm3YxHawTd+RnzAgkYI/MHel33O7yYOijTY6JLJ /McD+Tyto5H1lw2b200quM48bn1L6j2YJiNOvMwyb+nrWixrnbj6wGDZAQRWkDViWjKN Jw/Q== X-Gm-Message-State: AOAM531TEdQbTF1GvzDTviM7Vo/sZZXzccrYkIGtGei/rea3IttdLNOm fpBrEdT7i9DDp60lS2SUu6iO/HuvnRu2aqJWlc9RmA== X-Google-Smtp-Source: ABdhPJyjU5LaL1azRdDOk3yCLSymTmoMcYSljnQ0KRVaVFVzcni5vmfP7VRnhKOjwkuOWpKNZjbQeavTPsXkJrtTPQc= X-Received: by 2002:a5d:9344:: with SMTP id i4mr2504313ioo.106.1597417989113; Fri, 14 Aug 2020 08:13:09 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 14 Aug 2020 08:12:32 -0700 Message-ID: To: Dotzero Cc: Neil Anuskiewicz , IETF DMARC WG , Doug Foster Content-Type: multipart/alternative; boundary="000000000000cca90005acd7dbef" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 15:13:12 -0000 --000000000000cca90005acd7dbef Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > > I've been involved in setting up DMARC with a policy of p=reject for > somewhere North of 6,000 domains. As a sending domain, the heavy lifting is > in getting buy-in across the organization that it is a worthwhile effort, > getting control of your organization's mail flows and ensuring policies and > procedures are communicated and followed. For complex environments there > may need to be some automation required for creating and maintaining > private/public key pairs and DNS records but that is much more > straightforward than the aforementioned heavy lifting. > Also note that said "heavy lifting" is not a one time expenditure of effort. Having hoisted the weight bar above your head, it requires organizational will and ongoing knowledge to stick to the higher bar week in and week out. Entropy is never your friend in an organizational security context. Neither are acquisitions :-) --Kurt --000000000000cca90005acd7dbef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 14, 2020 at 7:31 AM Dotzero &= lt;dotzero@gmail.com> wrote:

I've been involved in setting up DMARC with a policy of p= =3Dreject for somewhere North of 6,000 domains. As a sending domain, the he= avy lifting is in getting buy-in across the organization that it is a worth= while=C2=A0effort, getting control=C2=A0of your organization's mail flo= ws and ensuring policies and procedures are communicated and followed. For = complex environments there may need to be some automation required for crea= ting and maintaining private/public key pairs and DNS records but that is m= uch more straightforward than the aforementioned=C2=A0heavy lifting.
<= /div>

Also note that said "heavy= lifting" is not a one time expenditure of effort. Having hoisted the = weight bar above your head, it requires organizational will and ongoing kno= wledge to stick to the higher bar week in and week out. Entropy is never yo= ur friend in an organizational security context. Neither are acquisitions := -)

--Kurt
--000000000000cca90005acd7dbef-- From nobody Fri Aug 14 09:05:51 2020 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 1AE933A0D02 for ; Fri, 14 Aug 2020 09:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 UoHDkNj8_HOq for ; Fri, 14 Aug 2020 09:05:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 9D8803A0F2F for ; Fri, 14 Aug 2020 09:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597421144; bh=E+ztH1GIRJ8LSxWypkwAGYnvYQ9cFg+uKDAeEoFWiCs=; l=2766; h=From:To:Cc:References:Date:In-Reply-To; b=BI18s3yPYnFMCfrEgWGH5R6iOejZpZEDYq3bXcQiAJDXc+M48GGqR0oYlze3Cc8ji hSqeJAzytncJx//Xpi/2/xaZZ0BafXyxAK50cJwRJYQ6r4ZK7Wc8gBnRghWWZ6F0PD xH+qBc9p6Fk1tSxKmDgRLXwQYc7anXUfWvXIQoSWU2qfmMu7/DGryVmTKWpVS Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.68.73]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F36B658.000016EC; Fri, 14 Aug 2020 18:05:44 +0200 From: Alessandro Vesely To: Dotzero Cc: IETF DMARC WG References: <20200810172411.A13681E7CD8B@ary.local> <10d4cb3b-baf5-0bfc-6160-70db96b9f0d1@tana.it> Message-ID: <1c9b482a-71e5-6adf-33de-26b0ff28d984@tana.it> Date: Fri, 14 Aug 2020 18:05:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:05:49 -0000 On 2020-08-14 4:12 p.m., Dotzero wrote: > On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely wrote: >> On 2020-08-10 7:24 p.m., John Levine wrote: >>> In article <2ef8e773e7bf467481a05ab3fc4d937f@bayviewphysicians.com> you write: >>>> Even an external reputation system requires recipient >>>> participation. That is why I suggested both a >>>> send3="parameters" clause to indicate sender support for >>>> third-party authorization and a verify3="parameters" clause to >>>> indicate recipient support for third-party authentication. When >>>> both are visible to the non-domain message source, that source >>>> can have confidence that the message will be handled as >>>> authorized. >>> >>> We have had a lot of attempts at third-party authorization schemes >>> going back at least to vouch-by-reference in 2009 and ATPS in 2012, >>> and the Spamhaus Whitelist in 2010. Every single one of them failed, >>> not due to technical problems, but because nobody was interested. >> >> >> We can either try and understand what was wrong in those schemes, or >> abandon authorization schemes forever. >> >> Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent >> success. >> >> PGP, GPG, and even personal CA certificates never became really >> popular, so we could have concluded that digital signature aren't >> worth considering for anti-spoof protocols. Yet, someone thought >> about DKIM... >> > > There is a little bit of history behind the impetus for SPF and DKIM. In > 2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on > Email Authentication and SPAM. It also let it be known that if the private > sector didn't come up with solutions it was willing to move forward with > regulation. This helped drive activity for SPF, the merger of DK and IIM > to create DKIM and Microsoft's push for SenderID. Private sector folks did > not want to risk what government regulation might look like. At that time > there were also folks pushing for PGP, GPG, Personal Certificate and > S/MIME as paths forward. Even with that, it took a while for industry > efforts to gain some sense of clarity. Notice that the general path forward > was basically domain based and not individual user/client based. There was > a debate within the DKIM effort regarding i= vs d= to the extent that at > one industry event people were walking around with little stickers on their > badges to indicate which they supported. I believe that was courtesy of > Dave Crocker. Thanks for that, I put a reference to your post on the wikipedia[*] (the original link to the FTC event expired sometimes in 2012). Best Ale -- [*] https://en.wikipedia.org/wiki/Email_authentication#Rationale From nobody Fri Aug 14 09:18:30 2020 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 0AC9B3A0D71 for ; Fri, 14 Aug 2020 09:18:29 -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, 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 W3XCQybTrnbs for ; Fri, 14 Aug 2020 09:18:27 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 23C953A0CFB for ; Fri, 14 Aug 2020 09:18:27 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id a14so8846175wra.5 for ; Fri, 14 Aug 2020 09:18:26 -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=I4XNwtJRb4+xW/R2qnJsCSEUx7OLmgwVxVKujz6HBlk=; b=JmSI4RI/YP2pecSA91Oy15uM8m9kYd8fg3wjbt+tkvYRRd2zJhw7zKcfE4wehZLSve laFi1T1kLEroWuM1b/DAU7vTiqS8US/CrLrEYmzCEWLVLvZEYWb1hq7ZnTMvjMaLa9th jUTdz6BHyMo9DfcLwbM091+DEP6UlHlkWLgh5H/DA4ntFbfhF2yPbNVt0AePnIcF0J8h Fn8GB8M8fgRFVipmFpGzCAxrjqmxCvIG7yqNlFXnGUq8DHagm100s2bAytyKV09z1wSB fbk4wshkftEhKyRHCbJDSmKq1ucxTaFwTbnH4bKEpfaFzdvLkLJBILyv/y58WivccHTG wYGA== 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=I4XNwtJRb4+xW/R2qnJsCSEUx7OLmgwVxVKujz6HBlk=; b=kaBQY7R/kv/IFxoNeORVHMg/9TsYHTEWTXoS5UL9jjlTpp0N3keatvyNj3vh1/DF31 hkvYUvSkt/urRJmMbsUJu/1hFtaWShFVypT+adjBG43OaPLY55cX/OxEHiax0BTXyI1G VS3hN8xFw8+mKpjjl3aZ4GD7yifIhd611R2U2DmxXiM6S8GmlMwhWAwg/Cq1BrxhVFTw FOAu70yQ0C50eL4tsvI4FayT9fiPaS67mZcmL5OgHaQokP/u7kcKm6yVI03ngv3Rt/da gG5TUfQtEs5Tl+hCiabkfmhXua0OFSZD9WK3AXA3TOf1IpTdI8VPqfLTpIrIThxF2iXL 6Mew== X-Gm-Message-State: AOAM533x3+PFb0QjzyFJGaL9mF74ylwXDt89Kj1BY566vZgTBQgf6C3+ vzfmZkaFXjHWl3fFlsgL/wJohmTiEHG3o/O+nOttAdB0 X-Google-Smtp-Source: ABdhPJxNDLQTXNlMkPxxBEcFpsOoJABNhnkggL+AVtnxqgjQhEnqSHGBwMQlUb98Nqj+g9aefouKTraiAKukmTuZBIk= X-Received: by 2002:adf:9526:: with SMTP id 35mr3554806wrs.326.1597421905513; Fri, 14 Aug 2020 09:18:25 -0700 (PDT) MIME-Version: 1.0 References: <20200814020806.7D8BF1E92E0C@ary.local> <3253B303-7A8B-436A-BB14-3E59FA6C96B1@wordtothewise.com> In-Reply-To: <3253B303-7A8B-436A-BB14-3E59FA6C96B1@wordtothewise.com> From: Dotzero Date: Fri, 14 Aug 2020 12:18:14 -0400 Message-ID: To: Laura Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003c110005acd8c5a3" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:18:29 -0000 --0000000000003c110005acd8c5a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins wrote: > > > On 14 Aug 2020, at 09:27, Dotzero wrote: > > Now I have come to the conclusion that they should reject list > submissions from accounts at domains which publish a DMARC policy of > p=3Dreject. Domains should not be able to externalize their internal prob= lems > to others. > > > This effectively cuts off users at multiple ISPs from ever participating > in mailing lists. Which is exactly what we=E2=80=99re trying to fix with = this > proposal. > Does the proposal actually fix the problem? Does the proposal actually fix the problem without creating other problems? After reading an re-reading Dave's draft, my conclusion is that the answer is no to both questions. > > Just because a user has an address at a consumer mailbox provider that > publishes p=3Dreject does not make them a second class citizen banned fro= m > participating in any mailing list. > You are conflating the provision of Internet connectivity with the provision of email services. That ship sailed a long time ago. There are a number of ISPs which no longer provide email accounts/port 25 services. If a user with an account at one of those domains wanted to use their login as an email address are you suggesting that others should send responses to that "email address" even though no MX is available for that account and mail will never reach that user? It is clear to me that a domain owner/admin has the right to determine how that domain will or will not be used. The individual is not banned from ever participating in a mailing list. They simply can't use an account from that particular domain. There are plenty of other places they can get an email account from. They also have the opportunity to tell their existing provider they are unhappy with policy. Providers can and do change their policies. For the longest time, the address block associated with Amazon Simple Mail Service was a swamp of badness. Legitimate users and organizations started deciding to not use other Amazon AWS services as a result of their mail being blocked. Amazon got religion and started cleaning up their mess. So yes, even large players can respond to market and community pressures. I'm not the person who initially suggested MLMs reject users/email from domains that publish p=3Dreject. That was John Levine. Perhaps he was being sarcastic, perhaps not. It is certainly a forcing mechanism. And that may just be what is needed for domains to think carefully about how they implement DMARC. Michael Hammer > > laura > > -- > Having an Email Crisis? We can help! 800 823-9674 > > Laura Atkins > Word to the Wise > laura@wordtothewise.com > (650) 437-0741 > > Email Delivery Blog: https://wordtothewise.com/blog > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000003c110005acd8c5a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 10:46 AM Laur= a Atkins <laura@wordtothewise= .com> wrote:


On 14 Aug 2020, at 09:27, Dotzero <dotzero@gmail.com> wrote:

=C2=A0Now I have come to the conclusion that they should reject list= submissions from accounts at domains which publish a DMARC policy of p=3Dr= eject. Domains should not be able to externalize their internal problems to= others.

This= effectively cuts off users at multiple ISPs from ever participating in mai= ling lists. Which is exactly what we=E2=80=99re trying to fix with this pro= posal.=C2=A0

Does the pro= posal actually fix the problem? Does the proposal actually fix the problem = without creating other problems? After reading an re-reading Dave's dra= ft, my conclusion is that the answer is no to both questions.=C2=A0

=C2=A0

Jus= t because a user has an address at a consumer mailbox provider that publish= es p=3Dreject does not make them a second class citizen banned from partici= pating in any mailing list.=C2=A0

You are conflating the provision of Internet connectivity=C2=A0 wi= th the provision of email services. That ship sailed a long time ago. There= are a number of ISPs which no longer provide email accounts/port 25 servic= es. If a user with an account at one of those domains wanted to use their l= ogin as an email address are you suggesting that others should send respons= es to that "email address" even though no MX is available for tha= t account and mail will never reach that user? It is clear to me that a dom= ain owner/admin has the right to determine how that domain will or will not= be used. The individual is not banned from ever participating in a mailing= list. They simply can't use an account from that particular domain. Th= ere are plenty of other places they can get an email account from. They als= o have the opportunity to tell their existing provider they are unhappy wit= h policy. Providers can and do change their policies. For the longest time,= the address block associated=C2=A0with Amazon Simple Mail Service was a sw= amp of badness. Legitimate users and organizations started deciding to not = use other Amazon AWS services as a result of their mail being blocked. Amaz= on got religion and started=C2=A0cleaning up their mess. So yes, even large= players can respond to market and community pressures.

I'm not the person who initially suggested MLMs reject users/emai= l from domains that publish p=3Dreject. That was John Levine. Perhaps he wa= s being sarcastic, perhaps not. It is certainly a forcing mechanism. And th= at may just be what is needed for domains to think carefully about how they= implement DMARC.

Michael Hammer
laura=C2=A0

--=C2=A0
Having an Email = Crisis?=C2=A0 We can help! 800 823-9674=C2=A0

Laur= a Atkins
Word to the Wise
(650)= 437-0741

Email Delivery Blog: https://wordtothewise.com/blog







_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000003c110005acd8c5a3-- From nobody Fri Aug 14 09:23:27 2020 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 A258E3A0DED for ; Fri, 14 Aug 2020 09:23:26 -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, 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 nf1UzefZgqnB for ; Fri, 14 Aug 2020 09:23:25 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 4303F3A0D96 for ; Fri, 14 Aug 2020 09:23:25 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id f18so8701983wmc.0 for ; Fri, 14 Aug 2020 09:23:25 -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=GPPzhGmgrCw8sbP2m4cvHwgU2OBksXCalbrJkI/QnfA=; b=pfdVh8YEGiUSVO0MKWOeQBwUEul2cGFnf8SV92LWOENdmaWHfr8uMkzhNE3r1U3evG 6WNyEj6cVyOxno3AWYdwC62UV8bXEiQl977KyR2nc/wLpy2h8hIZUKV5C5QuVlPIZ6cz IxmWM2NVBkHQxEZBjy0A75lcfxEkiGRmRmOj9y7ZmUs23qFV92N82GxBxLhYxrXavhB+ hgbtplxObv+12rf2pXVj0a4vcLVrg6dLAr+g4j/t1hnwKwM7SIVn+tJMvz5urNYY9YkM cAj0vC3/FH7MOnI/m+ZRz1RL19JN9Jt4fJf1W0CDhLAaO7KMspd46bkmJeDI1Db5Cda1 FKfA== 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=GPPzhGmgrCw8sbP2m4cvHwgU2OBksXCalbrJkI/QnfA=; b=EM0LzlTAvCfkUSB5t3HJ7fqRfA5oZpY75vFCjLl6qrw/M6sHOknyJg2Y1Oy9rUq2zF XoN0AB+KFwBey53436F7KxgIOaAocVq3f2zb75TQMTTpr4ngWKYA4euFkk44oLckWhd9 joekfc+2oEdDxdgXHMkPqn08/SytgO/oDFrbc6bWuO/qs93S6+Ukyfnl1yBOLTahaGxZ qGoUJ7UPG9CZEMsCgO+nfhARoWxPSZ+vTAZ0gm+n4sfMqANH+Vowmfiz9urj0zlgPFSM xKNOTAph8VOnu9+EsRWzIn3lUXEU1l/uPWw0znLiCgh6LpHNfGuj8dvqLrdDdaxxAFs7 CndQ== X-Gm-Message-State: AOAM530ORXA4xgnTZIovYCbD5wTEQaNwpnxTGf2laqj/4BsLsOkNLeyb uXt2BK16aKemrIE6FBUT00QjWETUFn97xiTbAizYu09QEzQ= X-Google-Smtp-Source: ABdhPJw7Mp9sNEoC1HHouRwu+4rgnH+UC/i39+A8yZ2CzmjaVgakX4OWFtNXzpVBMVtsYoeTGFD5up0aPuxvv0X644M= X-Received: by 2002:a1c:7407:: with SMTP id p7mr3281921wmc.117.1597422203823; Fri, 14 Aug 2020 09:23:23 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Fri, 14 Aug 2020 12:23:13 -0400 Message-ID: To: "Kurt Andersen (b)" Cc: Neil Anuskiewicz , IETF DMARC WG , Doug Foster Content-Type: multipart/alternative; boundary="00000000000003ec5005acd8d754" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:23:27 -0000 --00000000000003ec5005acd8d754 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 11:13 AM Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > >> >> I've been involved in setting up DMARC with a policy of p=reject for >> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >> in getting buy-in across the organization that it is a worthwhile effort, >> getting control of your organization's mail flows and ensuring policies and >> procedures are communicated and followed. For complex environments there >> may need to be some automation required for creating and maintaining >> private/public key pairs and DNS records but that is much more >> straightforward than the aforementioned heavy lifting. >> > > Also note that said "heavy lifting" is not a one time expenditure of > effort. Having hoisted the weight bar above your head, it requires > organizational will and ongoing knowledge to stick to the higher bar week > in and week out. Entropy is never your friend in an organizational security > context. Neither are acquisitions :-) > > --Kurt > I absolutely agree with you, Kurt. On the other hand this is true for many things. I almost want to respond with "What's your point?" (sarcastically). Is this an interoperability problem that is solved by IETF standards or is it an organizational problem that requires an organizational solution? Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-) Michael Hammer --00000000000003ec5005acd8d754 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 11:13 AM Kurt= Andersen (b) <kboth@drkurt.com&= gt; wrote:
On Fri, Aug 14, 2020 at 7:31 AM Dotzero <dotzero@gmail.com&= gt; wrote:

I've been involved in setting up DMARC with a po= licy of p=3Dreject for somewhere North of 6,000 domains. As a sending domai= n, the heavy lifting is in getting buy-in across the organization that it i= s a worthwhile=C2=A0effort, getting control=C2=A0of your organization's= mail flows and ensuring policies and procedures are communicated and follo= wed. For complex environments there may need to be some automation required= for creating and maintaining private/public key pairs and DNS records but = that is much more straightforward than the aforementioned=C2=A0heavy liftin= g.

Also note that said &q= uot;heavy lifting" is not a one time expenditure of effort. Having hoi= sted the weight bar above your head, it requires organizational will and on= going knowledge to stick to the higher bar week in and week out. Entropy is= never your friend in an organizational security context. Neither are acqui= sitions :-)

--Kurt
<= div>
I absolutely agree with you, Kurt. On the other hand thi= s is true for many things. I almost want to respond with "What's y= our point?" (sarcastically). Is this an interoperability=C2=A0problem = that is solved by IETF standards or is it an organizational problem that re= quires an organizational solution? Perhaps we need to generate an RFC entit= led "Don't Do Stupid Things". ;-)

Mi= chael Hammer
--00000000000003ec5005acd8d754-- From nobody Fri Aug 14 09:35:23 2020 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 2BE793A0E00 for ; Fri, 14 Aug 2020 09:35:21 -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=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 kX2cbe3n_yv1 for ; Fri, 14 Aug 2020 09:35:18 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6908F3A0D96 for ; Fri, 14 Aug 2020 09:35:18 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 051CA9F1F7 for ; Fri, 14 Aug 2020 09:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597422917; bh=1IH+ZuxtCnX4bRzLdUf19kJ7fKFGG1VdnFY71/lP8CA=; h=From:Subject:Date:References:To:In-Reply-To:From; b=OtaO/w0prqzq6u0VoU0/zWCdkck+3NbaS4cvtHdC0HipMncTEbTMF2pChpSo7owBa iMGJjoS7O5/2wRs0GcuKwWnCLXzW2rXY0iWyKfzWuhUQuGqVyKWcgAWJ4nHj58sqME vrPp3bJtlQirPo0uVUUA34AqS3lmwPiqZ5Z86si8= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_ED6E16BD-40F7-4CDB-8A12-624AB2B05136" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 14 Aug 2020 17:35:14 +0100 References: <20200814020806.7D8BF1E92E0C@ary.local> <3253B303-7A8B-436A-BB14-3E59FA6C96B1@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <6616567A-3C50-4366-8B31-6EB8BBA30E7D@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:35:21 -0000 --Apple-Mail=_ED6E16BD-40F7-4CDB-8A12-624AB2B05136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Aug 2020, at 17:18, Dotzero wrote: >=20 >=20 >=20 > On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins > wrote: >=20 >=20 >> On 14 Aug 2020, at 09:27, Dotzero > wrote: >>=20 >> Now I have come to the conclusion that they should reject list = submissions from accounts at domains which publish a DMARC policy of = p=3Dreject. Domains should not be able to externalize their internal = problems to others. >=20 > This effectively cuts off users at multiple ISPs from ever = participating in mailing lists. Which is exactly what we=E2=80=99re = trying to fix with this proposal.=20 >=20 > Does the proposal actually fix the problem? Does the proposal actually = fix the problem without creating other problems? After reading an = re-reading Dave's draft, my conclusion is that the answer is no to both = questions.=20 And that=E2=80=99s why we=E2=80=99re having this discussion, to = determine if it does or not.=20 >=20 > Just because a user has an address at a consumer mailbox provider that = publishes p=3Dreject does not make them a second class citizen banned = from participating in any mailing list.=20 >=20 > You are conflating the provision of Internet connectivity with the = provision of email services. That ship sailed a long time ago. There are = a number of ISPs which no longer provide email accounts/port 25 = services. If a user with an account at one of those domains wanted to = use their login as an email address are you suggesting that others = should send responses to that "email address" even though no MX is = available for that account and mail will never reach that user? I was speaking of companies like Yahoo and AOL, companies that provide = email services and not internet connectivity. They publish p=3Dreject = and any solution that is =E2=80=98well, they just don=E2=80=99t get to = use mailing lists=E2=80=9D seems to create a problem. At one point, = gmail announced they will be publishing p=3Dreject, which meant users of = 2 of the 3 major consumer mailbox providers would be prohibited from = joining mailing lists.=20 > It is clear to me that a domain owner/admin has the right to determine = how that domain will or will not be used. The individual is not banned = from ever participating in a mailing list. They simply can't use an = account from that particular domain. There are plenty of other places = they can get an email account from. They also have the opportunity to = tell their existing provider they are unhappy with policy. Providers can = and do change their policies. For the longest time, the address block = associated with Amazon Simple Mail Service was a swamp of badness. = Legitimate users and organizations started deciding to not use other = Amazon AWS services as a result of their mail being blocked. Amazon got = religion and started cleaning up their mess. So yes, even large players = can respond to market and community pressures. >=20 > I'm not the person who initially suggested MLMs reject users/email = from domains that publish p=3Dreject. That was John Levine. Perhaps he = was being sarcastic, perhaps not. It is certainly a forcing mechanism. = And that may just be what is needed for domains to think carefully about = how they implement DMARC. That is not how the quoting came through on my client. I was attempting = to be succinct and trim the message. Here=E2=80=99s the full email I was = responding to. In my client you appear to be the one saying MLMs should = reject anyone using a domain with p=3Dreject. If the quoting was = incorrect, I apologize for the mistake.=20 > On 14 Aug 2020, at 09:27, Dotzero wrote: >=20 >=20 >=20 > On Thu, Aug 13, 2020 at 10:08 PM John Levine > wrote: > In article = > you write: > >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender = suffers > >from a similar problem as PRA in the SenderId draft. There is no way = to > >validate that the specific intermediary is authorized by the (From) = domain > >originating the email through it's generic signalling that it > >authorizes intermediaries. This means that any source can emit a = message > >claiming to be a legitimate intermediary just as any source could = game PR > >to gain a neutral result. >=20 > That's a feature, not a bug. I want recipients to be able to assess > the mail my lists send on its own merits. >=20 > And recipient domains do just that using local policy override. DMARC = policy is at best a request to the Validator/Receiving Domain. If a = Validator/Receiving Domain chooses to honor the published DMARC policy = for a domain such as p=3Dreject, then they are in fact assessing the = mail your lists send based on the merits as they see them. The same goes = if they decide to not honor that published DMARC policy and accept mail = from your lists. Earlier in my DMARC journey I felt that MLMs should = adjust and send list mail as themselves. Now I have come to the = conclusion that they should reject list submissions from accounts at = domains which publish a DMARC policy of p=3Dreject. Domains should not = be able to externalize their internal problems to others. >=20 > >One could achieve similar outcomes using > >only reputation and local policy override of DMARC policy. >=20 > Only if you believe that the domain on the From: line is automatically > more credible than the one on the Sender: line. The whole third party > problem is that the people sending their mail through lists or > whatever are in fact doing so legitimately, but for various reasons > their organizations' DMARC policies lie and say they aren't. >=20 > I think you are misusing the term "credible". Domains which are = publishing p=3Dreject policies are making an assertion regarding mail = purporting to be authorized by their domain. It is not an assertion that = their mail is "good" or should be delivered to a recipient or even given = preferential treatment with regard to filters or policy. The assertion = is simply that mail purporting to be authorized by my domain must pass = either SPF or DKIM validation or else we request that in the event of = neither of these properly validating for a particular email message, = please reject this message. Don't think of it as being about = "legitimate" or "not legitimate". There is a certain (normally small) = amount of mail that fails to validate even when it passes directly from = the outbound MTA to the recipient domain's MTA. The sending domain is = accepting that this otherwise valid mail may (SHOULD?) be rejected by = the receiving domain. The organizations DMARC policies aren't lying. = They are simply saying "If this then that." >=20 > This ultimately goes back to the elephant in the room. Does an = individual user's use of an account at a domain trump the organization's = right to define how an account at a domain may/should be used? I = absolutely agree that in an ideal world this issue should not be = externalized yet here we are. This is why I made the point above that = lists should respect DMARC policy and not accept submissions from = domains with DMARC p=3Dreject policies. It becomes "Not your circus and = not your monkey". and forces the problem back to the domain and it's = users. If an MLM isn't modifying the message then the DKIM signature = should survive and this discussion is irrelevant. I think this covers = the range of MLM use cases that have been a topic of discussion. If the = MLM admin really wants to poke those domains publishing p=3Dreject then = they can respond to user subscribe attempts or submissions that are = rejected with an explanation that they need to go have a meaningful = discussion with their mail admin/IT staff/domain account provider or = whoever is responsible for publishing p=3Dreject for tht domain but = still allowing users to sign up for MLMs or attempt to use other = intermediaries. popcorn is of course optional. >=20 > Michael Hammer > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_ED6E16BD-40F7-4CDB-8A12-624AB2B05136 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Aug 2020, at 17:18, Dotzero <dotzero@gmail.com> = wrote:



On Fri, Aug 14, 2020 at 10:46 AM Laura = Atkins <laura@wordtothewise.com> wrote:


On 14 = Aug 2020, at 09:27, Dotzero <dotzero@gmail.com> wrote:

 Now I have come to the conclusion that they should = reject list submissions from accounts at domains which publish a DMARC = policy of p=3Dreject. Domains should not be able to externalize their = internal problems to = others.

This effectively cuts off users at = multiple ISPs from ever participating in mailing lists. Which is exactly = what we=E2=80=99re trying to fix with this = proposal. 

Does the proposal actually fix the = problem? Does the proposal actually fix the problem without creating = other problems? After reading an re-reading Dave's draft, my conclusion = is that the answer is no to both = questions. 

And that=E2=80=99s why we=E2=80=99re having this = discussion, to determine if it does or not. 


Just because a user has an address at a = consumer mailbox provider that publishes p=3Dreject does not make them a = second class citizen banned from participating in any mailing = list. 

You are conflating the provision of = Internet connectivity  with the provision of email services. That = ship sailed a long time ago. There are a number of ISPs which no longer = provide email accounts/port 25 services. If a user with an account at = one of those domains wanted to use their login as an email address are = you suggesting that others should send responses to that "email address" = even though no MX is available for that account and mail will never = reach that user?

I was speaking of companies like Yahoo and AOL, = companies that provide email services and not internet connectivity. = They publish p=3Dreject and any solution that is =E2=80=98well, they = just don=E2=80=99t get to use mailing lists=E2=80=9D seems to create a = problem. At one point, gmail announced they will be publishing p=3Dreject,= which meant users of 2 of the 3 major consumer mailbox providers would = be prohibited from joining mailing lists. 

It is = clear to me that a domain owner/admin has the right to determine how = that domain will or will not be used. The individual is not banned from = ever participating in a mailing list. They simply can't use an account = from that particular domain. There are plenty of other places they can = get an email account from. They also have the opportunity to tell their = existing provider they are unhappy with policy. Providers can and do = change their policies. For the longest time, the address block = associated with Amazon Simple Mail Service was a swamp of badness. = Legitimate users and organizations started deciding to not use other = Amazon AWS services as a result of their mail being blocked. Amazon got = religion and started cleaning up their mess. So yes, even large = players can respond to market and community pressures.

I'm not the person who = initially suggested MLMs reject users/email from domains that publish = p=3Dreject. That was John Levine. Perhaps he was being sarcastic, = perhaps not. It is certainly a forcing mechanism. And that may just be = what is needed for domains to think carefully about how they implement = DMARC.

That is not how the quoting came through on my = client. I was attempting to be succinct and trim the message. Here=E2=80=99= s the full email I was responding to. In my client you appear to be the = one saying MLMs should reject anyone using a domain with p=3Dreject. If = the quoting was incorrect, I apologize for the = mistake. 

On 14 Aug 2020, at 09:27, Dotzero <dotzero@gmail.com> = wrote:



On Thu, Aug = 13, 2020 at 10:08 PM John Levine <johnl@taugh..com> wrote:
In article = <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=3D99yVu0dgLz-z19iwfA@mail.gmail.com> you write:
>> "DISCUSS" shouldn't really be a joke. = draft-crocker-dmarc-sender suffers
>from a similar = problem as PRA in the SenderId draft. There is no way to
>validate that the specific intermediary is authorized by = the (From) domain
>originating the email through it's = generic signalling that it
>authorizes intermediaries. = This means that any source can emit a message
>claiming = to be a legitimate intermediary just as any source could game PR
>to gain a neutral result.

That's a feature, not a bug. I want recipients to be able to = assess
the mail my lists send on its own merits.

And recipient domains do just that using local policy = override. DMARC policy is at best a request to the Validator/Receiving = Domain. If a Validator/Receiving Domain chooses to honor the published = DMARC policy for a domain such as p=3Dreject, then they are in fact = assessing the mail your lists send based on the merits as they see them. = The same goes if they decide to not honor that published DMARC policy = and accept mail from your lists. Earlier in my DMARC journey I felt that = MLMs should adjust and send list mail as themselves. Now I have come to = the conclusion that they should reject list submissions from accounts at = domains which publish a DMARC policy of p=3Dreject. Domains should not = be able to externalize their internal problems to = others.

>One could achieve similar = outcomes using
>only reputation and local policy = override of DMARC policy.

Only if you = believe that the domain on the From: line is automatically
more credible than the one on the Sender: line. The whole = third party
problem is that the people sending their mail = through lists or
whatever are in fact doing so = legitimately, but for various reasons
their organizations' = DMARC policies lie and say they aren't.

I think you are misusing = the term "credible". Domains which are publishing p=3Dreject policies = are making an assertion regarding mail purporting to be authorized by = their domain. It is not an assertion that their mail is "good" or should = be delivered to a recipient or even given preferential treatment with = regard to filters or policy. The assertion is simply that mail = purporting to be authorized by my domain must pass either SPF or DKIM = validation or else we request that in the event of neither of these = properly validating for a particular email message, please reject this = message. Don't think of it as being about "legitimate" or "not = legitimate". There is a certain (normally small) amount of mail that = fails to validate even when it passes directly from the outbound MTA to = the recipient domain's MTA. The sending domain is accepting that = this otherwise valid mail may (SHOULD?) be rejected by the receiving = domain. The organizations DMARC policies aren't lying. They are simply = saying "If this then that."

This ultimately goes back to the elephant in the room. Does = an individual user's use of an account at a domain trump the = organization's right to define how an account at a domain may/should be = used? I absolutely agree that in an ideal world this issue should not be = externalized yet here we are. This is why I made the point above that = lists should respect DMARC policy and not accept submissions from = domains with DMARC p=3Dreject policies. It becomes "Not your circus and = not your monkey". and forces the problem back to the domain and it's = users. If an MLM isn't modifying the message then the DKIM signature = should survive and this discussion is irrelevant. I think this covers = the range of MLM use cases that have been a topic of discussion. If the = MLM admin really wants to poke those domains publishing p=3Dreject then = they can respond to user subscribe attempts or = submissions that are rejected with an explanation that they = need to go have a meaningful discussion with their mail admin/IT = staff/domain account provider or whoever is responsible for publishing = p=3Dreject for tht domain but still allowing users to sign up for MLMs = or attempt to use other intermediaries. popcorn is of course = optional.

Michael = Hammer
____________________________________________= ___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

laura 


-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_ED6E16BD-40F7-4CDB-8A12-624AB2B05136-- From nobody Fri Aug 14 09:42:43 2020 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 CF6FA3A0E33 for ; Fri, 14 Aug 2020 09:42:41 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=QFJIvj0d; dkim=pass (2048-bit key) header.d=taugh.com header.b=mDwzlWC7 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 ofZz2gbyuiK3 for ; Fri, 14 Aug 2020 09:42:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7EB3A0E1E for ; Fri, 14 Aug 2020 09:42:39 -0700 (PDT) Received: (qmail 41868 invoked from network); 14 Aug 2020 16:42:37 -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=a38a.5f36befd.k2008; bh=1vIZNGbhLHCk0q6AgVCgqBT6bS9CIwQQXFtMjg0WtCM=; b=QFJIvj0dUixfxshcdFovBjw/ktUDLGA7Gx4GqyhX2x/LDenozmsL9WxWA7eOpBMFeZUAegZ9ZJ1AtlEzkDWvqvxS+GUN9FXlQStBnVLbchfcaUDGjUYMmjAWv+5rbzWdM6WWgyKt3me7ChM0jrnFQLsU1C4s7VwnmAoEBzKWMhzr7VTj05t9i/Xka0fu2q1TKS5sS+5X+G4GCBPzZ8TAK10saM71zyMjb2+YlEfJJ9kJCxPSgsgB3azMarYlzaLwRYFp6sVYntZz6LL/FcGSX8m/bPNv4+7Zo1Ugf1ShPy6vFMf3U4JfBUGssiDcWeom4dNaLMDKx0l9KG5l9/9Q0w== 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=a38a.5f36befd.k2008; bh=1vIZNGbhLHCk0q6AgVCgqBT6bS9CIwQQXFtMjg0WtCM=; b=mDwzlWC7NDzUb0Rt0eEvkf8ybEKbxgo2UXb8nkLZrp1MnysHYp7OTY6EXocy36+UIMKTUDE52d8CXSnnm1fknthRHeKMXlBW27LbJxOFN360Bxe1SqsLMKpWhI0HOQfm/llZlfVkDYBGLYtliva8dYQSZVBBfwtWpHf5li08SjOXBpCsnUd7rDNKfHmYFMMdW+RXOUFNStn0J3nIxWqE1hzXHnONBcGpHuIYYLQuSkBc1fUgsABnqxLWy7C086C0jXcthvGkB5V1SvZXbFYkGwpy8BAP1b75XSWU00RNmpRzH20quiZxlpx4v9Dn15bSyuOx6ErU1G/Al1la3yyReQ== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Aug 2020 16:42:37 -0000 Received: by ary.local (Postfix, from userid 501) id 313071E971DB; Fri, 14 Aug 2020 12:42:37 -0400 (EDT) Date: 14 Aug 2020 12:42:37 -0400 Message-Id: <20200814164237.313071E971DB@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dotzero@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:42:42 -0000 In article you write: >policy of p=reject. Domains should not be able to externalize their >internal problems to others. Isn't that exactly the mailing list problem? >> Only if you believe that the domain on the From: line is automatically >> more credible than the one on the Sender: line. The whole third party >> problem is that the people sending their mail through lists or >> whatever are in fact doing so legitimately, but for various reasons >> their organizations' DMARC policies lie and say they aren't. >> > >I think you are misusing the term "credible". Domains which are publishing >p=reject policies are making an assertion regarding mail purporting to be >authorized by their domain. It is not an assertion that their mail is >"good" or should be delivered to a recipient ... No, it's an assertion that mail that's unaligned is unauthorized, and a request to reject it. For mail that their users send through mailing lists, that assertion is false and the request clearly not what the organization and its users want. This is what I conclude from the number of unhappy people to whom I have had to explain that their mail is disappearing because their employer told recipient systems to do so. > This is why I made the point above that lists should respect DMARC >policy and not accept submissions from domains with DMARC p=reject >policies. Lists have been around a lot longer than DMARC has. Perhaps you meant to say that domains whose users participate in mailing lists should not publish restrictive DMARC policies. If they don't want their users to send mail to lists, they should tell their users not to send mail to lists. There are lots of organizations that actively want their employees to participate in the IETF, to the extent that they give them paid time for IETF activities, yet publish p=reject policies to cripple that participation. I wish they would make up their minds. R's, John From nobody Fri Aug 14 10:04:42 2020 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 23F7C3A0E3F for ; Fri, 14 Aug 2020 10:04:40 -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, 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 AQS-l-EZ0A_b for ; Fri, 14 Aug 2020 10:04:38 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 7C03A3A0B31 for ; Fri, 14 Aug 2020 10:04:38 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id g8so8046951wmk.3 for ; Fri, 14 Aug 2020 10:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tSjOazK+xM1VybTEUqGGotLBH3M+oLh5gdgdc6cYJcQ=; b=YBkvQqKvmXARhUGy4xnS4xak7sRa0kSjgaxY28Wn0SpsL0yzC+CblkIl69QGwXOONb bM+8GQ+hKUybeHfRovYwpN44oHc3LAHHYsUGWtVr1si6DmwNUNLVdgZpk/C6gp8yVq+s Hjkuyz9MeRAkdgrtkNa7ytNfZkfnD6gn0wYR2i4tyqvUlFx2BAy8ap1gxM4PzDe0u++/ riq6P04aiJSlrJcoEkEEE0pxtO+utXSzH6K07dY2qhUYcVGsOvWAOOlUG2zlU9RdbFHo hVwgvC9Hnhyau4SxpILD3LOiDbj4FAPxYWet6++hGP2C2B5i7XbMt9YVlJwCHRTqVOVg QUAQ== 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=tSjOazK+xM1VybTEUqGGotLBH3M+oLh5gdgdc6cYJcQ=; b=W7Zi2Bv6vo5WDx3a6SGFWnN+/46sFoV1GGdrr3YGvQfFWZocWRi8qvnneNqdXOccdy fER17108xHclN9/ijcgY5ztVegVBktgqShWYaHWbFRMIu1qEzgl2uVYhiAF4ad4cGqHc DTHQcoHS9RaWleX0ZOVljrUdI3rhCQMJKlYDgsrt6ENkGFCuOPes3iBioeYQrQsvr8hI obs+/cDztDczoDrKrN5ly88jwkjHpwd3ZvjBMYPROwOOBCWP7TF9wV3O/dAVK3iqyQik Iv2l2ixwO6SO12Z5QSrpuhq33pWpMX4ICp52X3XPWjqtf3J/kjlJmAHcWgigUIOdFBvX Kkzw== X-Gm-Message-State: AOAM533HRc+VJy5eGrmv+aMY96ZAc2Xns4ZCWFZPIAe9mar3zjaXq9hW nZdTJorT4GipaMhwYezM/LCZtV1hhy3neiX/Y2VPpCxgY/M= X-Google-Smtp-Source: ABdhPJzJE7zzXmZqEMgCncgMmtIBdErrsgKG8rnX8ltBhGBh97DUvzBBFT+cQm2WSr4k7DJ0+KPqwMZOPf2s3U5d3a4= X-Received: by 2002:a7b:cf3a:: with SMTP id m26mr3556389wmg.25.1597424677022; Fri, 14 Aug 2020 10:04:37 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> In-Reply-To: <20200814164237.313071E971DB@ary.local> From: Dotzero Date: Fri, 14 Aug 2020 13:04:26 -0400 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006dee0105acd96aec" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:04:40 -0000 --0000000000006dee0105acd96aec Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 12:42 PM John Levine wrote: > In article g@mail.gmail.com> you write: > >policy of p=reject. Domains should not be able to externalize their > >internal problems to others. > > Isn't that exactly the mailing list problem? > No, that is the domains publishing a policy externally but not telling their users "Don't do that" problem. > > >> Only if you believe that the domain on the From: line is automatically > >> more credible than the one on the Sender: line. The whole third party > >> problem is that the people sending their mail through lists or > >> whatever are in fact doing so legitimately, but for various reasons > >> their organizations' DMARC policies lie and say they aren't. > >> > > > >I think you are misusing the term "credible". Domains which are publishing > >p=reject policies are making an assertion regarding mail purporting to be > >authorized by their domain. It is not an assertion that their mail is > >"good" or should be delivered to a recipient ... > > No, it's an assertion that mail that's unaligned is unauthorized, and > a request to reject it. For mail that their users send through mailing > lists, that assertion is false and the request clearly not what the > organization and its users want. This is what I conclude from the > number of unhappy people to whom I have had to explain that their mail > is disappearing because their employer told recipient systems to do > so. > "clearly not what the organization and its users want." Who am I going to believe, the organization and it's published policy or you? > > > This is why I made the point above that lists should respect DMARC > >policy and not accept submissions from domains with DMARC p=reject > >policies. > > Lists have been around a lot longer than DMARC has. Perhaps you meant > to say that domains whose users participate in mailing lists should > not publish restrictive DMARC policies. If they don't want their users > to send mail to lists, they should tell their users not to send mail > to lists. > I meant what I wrote. Domains who actively want their users to participate in mailing lists or even passively accept that their users participate in mailing lists shouldn't publish p=reject for the domain their users are sending from or should take steps to migrate the users to another domain/subdomain, etc. Conversely, if a domain IS publishing p=reject then yes, they should be taking steps internally but I also believe others should consider that domain's published policy as intentional and act accordingly. I've never heard of a DMARC policy getting published due to inaction. Someone with administrative rights actively published that policy. > > There are lots of organizations that actively want their employees to > participate in the IETF, to the extent that they give them paid time > for IETF activities, yet publish p=reject policies to cripple that > participation. I wish they would make up their minds. > Me too. Michael Hammer --0000000000006dee0105acd96aec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 14, 2020= at 12:42 PM John Levine <johnl@taugh= .com> wrote:
In article <CAJ4XoYcFbh8-nAxjxzzRgUahFfhcgcZQ2yMF2ewv_-DgUmhL=3Dg@mail.gmail.com> = you write:
>policy of p=3Dreject. Domains should not be able to externalize their >internal problems to others.

Isn't that exactly the mailing list problem?

<= /div>
No, that is the domains publishing a policy externally but not te= lling their users "Don't do that" problem.=C2=A0

>> Only if you believe that the domain on the From: line is automatic= ally
>> more credible than the one on the Sender: line. The whole third pa= rty
>> problem is that the people sending their mail through lists or
>> whatever are in fact doing so legitimately, but for various reason= s
>> their organizations' DMARC policies lie and say they aren'= t.
>>
>
>I think you are misusing the term "credible". Domains which a= re publishing
>p=3Dreject policies are making an assertion regarding mail purporting t= o be
>authorized by their domain. It is not an assertion that their mail is >"good" or should be delivered to a recipient ...

No, it's an assertion that mail that's unaligned is unauthorized, a= nd
a request to reject it. For mail that their users send through mailing
lists, that assertion is false and the request clearly not what the
organization and its users want. This is what I conclude from the
number of unhappy people to whom I have had to explain that their mail
is disappearing because their employer told recipient systems to do
so.

=C2=A0"clearly not what the or= ganization and its users want."

Who am I goin= g to believe, the organization and it's published policy or you?
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
> This is why I made the point above that lists should respect DMARC
>policy and not accept submissions from domains with DMARC p=3Dreject >policies.

Lists have been around a lot longer than DMARC has. Perhaps you meant
to say that domains whose users participate in mailing lists should
not publish restrictive DMARC policies. If they don't want their users<= br> to send mail to lists, they should tell their users not to send mail
to lists.

I meant what I wrote. Domains= who actively want their users to participate in mailing lists or even pass= ively accept that their users participate in mailing lists shouldn't pu= blish p=3Dreject for the domain their users are sending from or should take= steps to migrate the users to another domain/subdomain, etc. Conversely, i= f a domain IS publishing p=3Dreject then yes, they should be taking steps i= nternally but I also believe others should consider that domain's publi= shed policy as intentional and act accordingly. I've never heard of a D= MARC policy getting published due to inaction. Someone with administrative = rights actively published that policy.

There are lots of organizations that actively want their employees to
participate in the IETF, to the extent that they give them paid time
for IETF activities, yet publish p=3Dreject policies to cripple that
participation. I wish they would make up their minds.
=
Me too.

Michael Hammer=C2=A0
<= /div>
--0000000000006dee0105acd96aec-- From nobody Fri Aug 14 10:32:51 2020 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 EBE563A1200 for ; Fri, 14 Aug 2020 10:32:42 -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 8jB_9F7Pru-N for ; Fri, 14 Aug 2020 10:32:41 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53233A1201 for ; Fri, 14 Aug 2020 10:32:41 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id k4so9090269ilr.12 for ; Fri, 14 Aug 2020 10:32:41 -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=HcHHQ5yEp2hvzvNQbFu6xd1T7U2Ik9osM90ZQYqlPeQ=; b=bIC2jDhhlv8rpY5y/bMSHJwHcKsqhwp4zSlyxDwcQliTdE/WVjA7K7QhiIsk7ceWIT EJOxzXoG8XV3MkbA4Mo/5qKp0O7P4q+iJtZHc5DvHnQIZe8+171bLLlPlY52/qHAsmTB lYDUgMThrPd0iURfQt/tba3SdviVrDDcg/tbQ= 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=HcHHQ5yEp2hvzvNQbFu6xd1T7U2Ik9osM90ZQYqlPeQ=; b=Mq+KBCLhExKS5gdD4RWwP5Fma9McVfMK9g1+FVfQFf8qYthnhlFedj+vLVzE9ZAF0y 5RVGHY7Bs0BBjuJGVrQ2cv0q4Xq7r1xQPvozRQPY0xacAP1xLOwj0foRwhviJbhJW+jE pOq14sY7f5tM+1/Crj6ZDTZvJ4ByridesZdsPqZF/VCPe43VaWUtCU6ZcIIqP8PKJ4NI /Cu7dJ5T0fgrYSeiqderw4YKMNJLqPzx4kKdlsHJWRCmc6DuFphNPpgiYzMmYkfkyDjn 3+FIPWj2mmhO0pyoqeScoV7AuBY5hRg9EAQ/fhQEmhl7lkdhsZuFDyJZr397Uz/y0OBQ 1BZg== X-Gm-Message-State: AOAM530wllnAlwlODjw4dp/cSVXxv7iSJMrGRIsyKEukfCvv5+44ggLJ nPSb79agTT8O3TXgX59GGf/VuK/+K9oJO1WH3TFSaA== X-Google-Smtp-Source: ABdhPJxWdY77Tr/U41kpV3QqZPyAvP06mave9uMOXGOxSNzr8KGxPzpXs5avtKSEBSdlpWJsOhaTcphxUzsYmu040z0= X-Received: by 2002:a92:85c8:: with SMTP id f191mr3500501ilh.242.1597426360829; Fri, 14 Aug 2020 10:32:40 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: Neil Anuskiewicz Date: Fri, 14 Aug 2020 10:32:04 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Dotzero , IETF DMARC WG , Doug Foster Content-Type: multipart/alternative; boundary="000000000000cae61705acd9ceed" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:32:50 -0000 --000000000000cae61705acd9ceed Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > >> >> I've been involved in setting up DMARC with a policy of p=reject for >> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >> in getting buy-in across the organization that it is a worthwhile effort, >> getting control of your organization's mail flows and ensuring policies and >> procedures are communicated and followed. For complex environments there >> may need to be some automation required for creating and maintaining >> private/public key pairs and DNS records but that is much more >> straightforward than the aforementioned heavy lifting. >> > > Also note that said "heavy lifting" is not a one time expenditure of > effort. Having hoisted the weight bar above your head, it requires > organizational will and ongoing knowledge to stick to the higher bar week > in and week out. Entropy is never your friend in an organizational security > context. Neither are acquisitions :-) > > Yes, and that's why I use DMARC mostly as a tool for reporting. My clients > are typically small businesses who are worried about selling widgets not > about email so even if I help them set up email perfectly, they could make > a change a year from now without updating their SPF record or deploying > DKIM. I just changed my policy to reject (just for fun) assuming this email > will get through because of DMARC's OR logic. > --000000000000cae61705acd9ceed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 8:13 AM Kurt = Andersen (b) <kboth@drkurt.com&g= t; wrote:
On Fri, Aug 14, 2020 at 7:31 AM Dotzero <dotzero@gmail.com&g= t; wrote:

I've been involved in setting up DMARC with a pol= icy of p=3Dreject for somewhere North of 6,000 domains. As a sending domain= , the heavy lifting is in getting buy-in across the organization that it is= a worthwhile=C2=A0effort, getting control=C2=A0of your organization's = mail flows and ensuring policies and procedures are communicated and follow= ed. For complex environments there may need to be some automation required = for creating and maintaining private/public key pairs and DNS records but t= hat is much more straightforward than the aforementioned=C2=A0heavy lifting= .

Also note that said &qu= ot;heavy lifting" is not a one time expenditure of effort. Having hois= ted the weight bar above your head, it requires organizational will and ong= oing knowledge to stick to the higher bar week in and week out. Entropy is = never your friend in an organizational security context. Neither are acquis= itions :-)

Yes, and that's why I use DMARC mos= tly as a tool for reporting. My clients are typically small businesses who = are worried about selling widgets not about email so even if I help them se= t up email perfectly, they could make a change a year from now without upda= ting their SPF record or deploying DKIM. I just changed my policy to reject= (just for fun) assuming this email will get through because of DMARC's= OR logic.
--000000000000cae61705acd9ceed-- From nobody Fri Aug 14 11:16:17 2020 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 823C63A11C5 for ; Fri, 14 Aug 2020 11:16:14 -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, 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 IBhiM587Tb-D for ; Fri, 14 Aug 2020 11:16:11 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 3FB8C3A11D7 for ; Fri, 14 Aug 2020 11:15:52 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id t14so8660266wmi.3 for ; Fri, 14 Aug 2020 11:15:52 -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=brhO2zHxfUP+sMM3qgxsoXxsumwZlsWPy4DDKV+8qew=; b=qxACvAMlDFnyxUoperqeudSX9gyG5VPE4M+Hg2hjGxIf7ZgQZTFb5Wf+qh+zpUmbUe D4WoBMduz2MqRXcm/s03WMOV3/hlMN5r/1CZfny+d1ooYoJXfEoJ7fGhRPiMd7IVbAgA AwK/QdG3NMGv6JPDLvsEhDa2VnIikoUbLOPodTmih6Sc36aqIqUHM0LEtn8jIAIHB+3y /AJGZcvS8hC34wPP/CihuboAaMOG29GyHISNR1OnsyOHFKCSBgn20FAnfOpl2Ev0CIJh fQgvlUodZfcagw09eNnadymA41pqv+D97tWWX3E+GfJVBTPhsN4I6PnpcmbSLyzxZV1P vy4g== 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=brhO2zHxfUP+sMM3qgxsoXxsumwZlsWPy4DDKV+8qew=; b=bA/5ljY4fmrQkeo3iDWuFSPZjc5iCd7rnHr7i2M/ktrGLAL34xbssUy4N5x4pxi1qC eHMydg3m30Gg5Sji3WgeXN1plfia176B5qcQs+S9Rx0lMIGolZHylQsEEdYj87Y14/xY hBABCKBAvwrAdPw6OQklyZcAvZ0bN3drXrXoXdQjf4HuJVlIwrlxumEvxxpAHYuvP1sE zhiuCYjMja6xj/0WrhqUOpcxeQubsRf1VsjQKSWezN4k5UXr0gJC7Ra3SKPiQIo9nM73 PhFy5LVXl+JVZiQUBLPVedR7HCt0wajL72SPVPAtsI9rXEVgUwXxcQXO7v7YTFgWUCL1 E0oA== X-Gm-Message-State: AOAM533x17g91S4PPBCOrIzthlPlqOOCxS451BYwzzvjAYrjhj6OTCEJ w0sbCejCsGdPidqPeuPz2WFxkPdxUT0IZa/l06M= X-Google-Smtp-Source: ABdhPJw1zwjP4vwlK5ppS/BowH7/vWSeyzE+nXiWJ+OCSRF6SteyyB2gHIm0a4OAuETQe+2pj7YVDqrLsSsC0OZ6k8w= X-Received: by 2002:a1c:7407:: with SMTP id p7mr3651347wmc.117.1597428950719; Fri, 14 Aug 2020 11:15:50 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: Dotzero Date: Fri, 14 Aug 2020 14:15:39 -0400 Message-ID: To: Neil Anuskiewicz Cc: "Kurt Andersen (b)" , IETF DMARC WG , Doug Foster Content-Type: multipart/alternative; boundary="0000000000002963aa05acda69cc" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 18:16:15 -0000 --0000000000002963aa05acda69cc Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz wrote: > > > On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) > wrote: > >> On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: >> >>> >>> I've been involved in setting up DMARC with a policy of p=reject for >>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >>> in getting buy-in across the organization that it is a worthwhile effort, >>> getting control of your organization's mail flows and ensuring policies and >>> procedures are communicated and followed. For complex environments there >>> may need to be some automation required for creating and maintaining >>> private/public key pairs and DNS records but that is much more >>> straightforward than the aforementioned heavy lifting. >>> >> >> Also note that said "heavy lifting" is not a one time expenditure of >> effort. Having hoisted the weight bar above your head, it requires >> organizational will and ongoing knowledge to stick to the higher bar week >> in and week out. Entropy is never your friend in an organizational security >> context. Neither are acquisitions :-) >> >> Yes, and that's why I use DMARC mostly as a tool for reporting. My >> clients are typically small businesses who are worried about selling >> widgets not about email so even if I help them set up email perfectly, they >> could make a change a year from now without updating their SPF record or >> deploying DKIM. I just changed my policy to reject (just for fun) assuming >> this email will get through because of DMARC's OR logic. >> > Which brings us back to the question of organizational implementation issues vs interoperability issues. Can a technical standards body solve the problem of organizations shooting themselves in the foot because they are worried about selling widgits and not about email? Why do I have a feeling they start caring about email when it no longer works for them? They have created a self induced personal interoperability issue. If they changed their MX to use a random port other than port 25 to receive SMTP connections would you suggest that the RFC should be written to accommodate that? Michael Hammer --0000000000002963aa05acda69cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 1:32 PM Neil = Anuskiewicz <neil@marmot-tech.co= m> wrote:


On Fri, Aug 14, 2020 at 8:13 AM Kurt= Andersen (b) <kbo= th@drkurt.com> wrote:
On Fri, Aug 14, 2020 at 7:31= AM Dotzero <dotz= ero@gmail.com> wrote:
<= br>
I've been involved in setting = up DMARC with a policy of p=3Dreject for somewhere North of 6,000 domains. = As a sending domain, the heavy lifting is in getting buy-in across the orga= nization that it is a worthwhile=C2=A0effort, getting control=C2=A0of your = organization's mail flows and ensuring policies and procedures are comm= unicated and followed. For complex environments there may need to be some a= utomation required for creating and maintaining private/public key pairs an= d DNS records but that is much more straightforward than the aforementioned= =C2=A0heavy lifting.

Also= note that said "heavy lifting" is not a one time expenditure of = effort. Having hoisted the weight bar above your head, it requires organiza= tional will and ongoing knowledge to stick to the higher bar week in and we= ek out. Entropy is never your friend in an organizational security context.= Neither are acquisitions :-)

Yes, and that's = why I use DMARC mostly as a tool for reporting. My clients are typically sm= all businesses who are worried about selling widgets not about email so eve= n if I help them set up email perfectly, they could make a change a year fr= om now without updating their SPF record or deploying DKIM. I just changed = my policy to reject (just for fun) assuming this email will get through bec= ause of DMARC's OR logic.

Which brings us back to the question of organ= izational implementation issues vs=C2=A0 interoperability issues. Can a tec= hnical standards body solve the problem of organizations shooting themselve= s in the foot because they are worried about selling widgits=C2=A0and not a= bout email? Why do I have a feeling they start caring about email when it n= o longer works for them? They have created a self induced personal interope= rability issue. If they changed their MX to use a random port other than po= rt 25 to receive SMTP connections would you suggest that the RFC should be = written to accommodate=C2=A0that?

Michael Hammer
--0000000000002963aa05acda69cc-- From nobody Fri Aug 14 11:31:27 2020 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 BC83F3A0FDC for ; Fri, 14 Aug 2020 11:31:25 -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=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 nVeryHFQBstp for ; Fri, 14 Aug 2020 11:31:13 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 2471F3A1008 for ; Fri, 14 Aug 2020 11:31:13 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id b16so11723768ioj.4 for ; Fri, 14 Aug 2020 11:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+P1+jmFVSdrdueGNDwl1swF7y5uMRJxd96l/tOZiLk=; b=UrZRf11Gs5uwhUsxcef1512KZ1ePgC41M3x6ngAfr3FxB5FMyZrD0DSsePNvqDfSew WrOiUjnFkW2kQKD41YN81bj7OP+FptLI6tWuOt2MVo1sQMqDsY4aFsqXSoivqy6kKo1N eq9bKS8UZpEsiGRzmb7RxN+nT9fcoDR7rjBPk= 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=5+P1+jmFVSdrdueGNDwl1swF7y5uMRJxd96l/tOZiLk=; b=g3Y3Cv4Y0IwyfY2rmGtHneS8js0U28Z5q7XeLAkAdZQ//YfvXiiHlG/snkqvYRRdZg ZpkY028mh09Soy0G2/RdB3GXVRKsxFwaZG1HUhwXrMa0FGlam94qqH3PYgA+JR/c9Hls gGTzlUQPUifFex19DJDkWfyBY2+lk7vu1Lk68KKVuPRs3ZoRH6wPPukagapFlqTLytOI OwAtka+zk871i/PR2WdZd/YVW0rMZ0hwU4z0B6bM5aRKZg+1cgjoDyK6q3eUafOpBxcw dXJ8jRoevZS0vC826SyYFg+7uAdQsz3pUaJ07nalmO2h1KRCKThOeLq1C/tGaEzO2Bd9 2iNg== X-Gm-Message-State: AOAM531N+5GhsKQJvNrZnu4fF22OPaLtMG8ZqzWmB1dYODuQwryoTu/x ee+5eOgvQFPplLwSWHVarWMXuTSVMcNLReB5TVKRcg== X-Google-Smtp-Source: ABdhPJzo90Xdu5Y6blgq0Yt/ASGW5DDJXUDrhFXhbTuxGOd4msZlPHjIpqqJRbf/9ynAQcvfK+OpQEvYSIE5BIA1daE= X-Received: by 2002:a6b:bd45:: with SMTP id n66mr2079291iof.121.1597429872064; Fri, 14 Aug 2020 11:31:12 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 14 Aug 2020 11:30:35 -0700 Message-ID: To: Dotzero Cc: Neil Anuskiewicz , IETF DMARC WG , Doug Foster Content-Type: multipart/alternative; boundary="000000000000141bd905acdaa05b" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 18:31:26 -0000 --000000000000141bd905acdaa05b Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote: > > Is this an interoperability problem that is solved by IETF standards or > is it an organizational problem that requires an organizational solution? > Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-) > I think that it might be out of the DMARC-WG's charter, but such an RFC would be eminently quotable along with 2549 and other such work. --Kurt --000000000000141bd905acdaa05b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 14, 2020 at 9:23 AM Dotzero &= lt;dotzero@gmail.com> wrote:

=C2=A0Is this an interoperability=C2=A0problem that is solved b= y IETF standards or is it an organizational problem that requires an organi= zational solution? Perhaps we need to generate an RFC entitled "Don= 9;t Do Stupid Things". ;-)

I think that it might be out of the DMARC-WG's charter, but such= an RFC would be eminently=C2=A0quotable along with 2549 and other such wor= k.

--Kurt=C2=A0
--000000000000141bd905acdaa05b-- From nobody Fri Aug 14 12:09:08 2020 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 8284D3A1154; Fri, 14 Aug 2020 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 t2r_83_iNZZP; Fri, 14 Aug 2020 12:09:05 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 390573A1149; Fri, 14 Aug 2020 12:09:05 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:981f:33af:623a:645b]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07EJ91lk012687 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 14 Aug 2020 12:09:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1597432143; bh=zC7sNeY4UeTEbRvGK8tZFRq5SFLP4dDmtoiNlKHzios=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=plfOSjpxO+L1CGPhGIETF4J2z03NBUoW6ePTEw7aIEhiduXog8f6NRTkmEmWkoG40 qOrRr6Gmq8lQuI4hXj90UmbmKsvDYMLFzOXyLTC+yzOCd8+z56lRR9LpVqcRzzbyYn i6lo24tJCo6VGMt6o6aVv9AC8pQtgwsRb+KYxn4Y= To: Tim Wicinski , IETF DMARC WG Cc: dmarc-chairs@ietf.org References: From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <745030ea-c2e6-16a4-690f-bbb639b9b8b8@bluepopcorn.net> Date: Fri, 14 Aug 2020 12:08:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------35D3303FFC88E5A236849012" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 19:09:07 -0000 This is a multi-part message in MIME format. --------------35D3303FFC88E5A236849012 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/10/20 12:04 PM, Tim Wicinski wrote: > > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. =C2=A0 > > This starts a Call for Adoption for draft-crocker-dmarc-sender I do not support adoption of this draft as a working group document for different reasons than I have seen expressed by others on the list. If the Sender header field is to be used by DMARC in the manner described in this draft, it should be an integral part of the DMARCbis specification rather than a separate extension to it. In other words, this should be an issue on the DMARC WG issue tracker rather than a working group draft (and presumably eventual RFC). There are enough different combinations of originators and receivers that might use Sender (which the chart in Section 2 begins to describe) that we don't need the ongoing ambiguity of whether the receiver does or does not implement this as an extension. I have other comments on the proposal, but will stop here as they are not directly germane to the question of adoption. -Jim --------------35D3303FFC88E5A236849012 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/10/20 12:04 PM, Tim Wicinski wrote:

During IETF 108, the chairs realized that there was interest in Dave's
RFC5322.Sender draft.  

This starts a Call for Adoption for draft-crocker-dmarc-sender

I do not support adoption of this draft as a working group document for different reasons than I have seen expressed by others on the list.

If the Sender header field is to be used by DMARC in the manner described in this draft, it should be an integral part of the DMARCbis specification rather than a separate extension to it. In other words, this should be an issue on the DMARC WG issue tracker rather than a working group draft (and presumably eventual RFC). There are enough different combinations of originators and receivers that might use Sender (which the chart in Section 2 begins to describe) that we don't need the ongoing ambiguity of whether the receiver does or does not implement this as an extension.

I have other comments on the proposal, but will stop here as they are not directly germane to the question of adoption.

-Jim

--------------35D3303FFC88E5A236849012-- From nobody Fri Aug 14 12:16:11 2020 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 CAA1E3A11EC for ; Fri, 14 Aug 2020 12:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 P22FRQwYgz4Z for ; Fri, 14 Aug 2020 12:16:04 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 2B8873A11E6 for ; Fri, 14 Aug 2020 12:16:04 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:981f:33af:623a:645b]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07EJFxXF012853 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 14 Aug 2020 12:16:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1597432561; bh=ZYDDKcouZw49f86HSD/KN2uQmby0wfJ2LGqhPsmC+Es=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PrMvNtINBW1WWHaWT666tqx7fUxY6V4d6/A/C/xhUM0fu9A1erfk5tjj5ULwxCutA Kij0U/E/RmuYREZRiirHR71aBlAZCZIgUPE+BJVnG7uWc/bGWFYQ2MDydzDSdNUMWl zFOzplmiqaAmxb6CKuZkaloD62xHs5YMC+j/VIhU= To: "Kurt Andersen (b)" , Dotzero Cc: IETF DMARC WG References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Fri, 14 Aug 2020 12:15:54 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BCB78339BE3C367D8E0F146D" Content-Language: en-US Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 19:16:10 -0000 This is a multi-part message in MIME format. --------------BCB78339BE3C367D8E0F146D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 8/14/20 11:30 AM, Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 9:23 AM Dotzero > wrote: > > >  Is this an interoperability problem that is solved by IETF > standards or is it an organizational problem that requires an > organizational solution? Perhaps we need to generate an RFC > entitled "Don't Do Stupid Things". ;-) > > > I think that it might be out of the DMARC-WG's charter, but such an > RFC would be eminently quotable along with 2549 and other such work. We already have a number of such RFCs: https://datatracker.ietf.org/doc/search?name=considered+harmful&sort=&rfcs=on&activedrafts=on&by=group&group= -Jim --------------BCB78339BE3C367D8E0F146D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
On Fri, Aug 14, 2020 at 9:23 AM Dotzero <dotzero@gmail.com> wrote:

 Is this an interoperability problem that is solved by IETF standards or is it an organizational problem that requires an organizational solution? Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)

I think that it might be out of the DMARC-WG's charter, but such an RFC would be eminently quotable along with 2549 and other such work.

We already have a number of such RFCs:

https://datatracker.ietf.org/doc/search?name=considered+harmful&sort=&rfcs=on&activedrafts=on&by=group&group=

-Jim

--------------BCB78339BE3C367D8E0F146D-- From nobody Fri Aug 14 12:16:25 2020 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 C39583A121F for ; Fri, 14 Aug 2020 12:16:14 -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, 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 BrrqoqhKP3dZ for ; Fri, 14 Aug 2020 12:16:13 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87973A1206 for ; Fri, 14 Aug 2020 12:16:12 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id f7so9272058wrw.1 for ; Fri, 14 Aug 2020 12:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ybc8nVVebsumHwtWYqIN7+SuKomkaWXzk/3yDakchP0=; b=vOoSGaV20FVzQuPXgbpAM3EvrHzH6s0tFKvc+zlRZTJQOooJZYA7lUVUGEE45tKk23 bAg6x53ImgfjfuECFEjvfUey06VRxEXhXDoLN8K41sBQyiJdVA+7PeYLR9S6Wp+XHA6q Hc0cW1gSvEXAsXprzT4bE3uLSD0I6j1Zm7RjQRhXNS6xdyvZw5i+4nut0R1diHM1/jM5 CmSlrMRyStY45GIB45NfFlSYEzQP9mRfqGGGhVMFQWTVbYw9kVvzKOLCZVVC730FRPaa R3/5uc41wPDOD4ZTPuXLJBaAl3k5UJj1HUhFTRG13S5x2CTSEs4whOGjm7/1vy3V2C4p y1Pw== 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=ybc8nVVebsumHwtWYqIN7+SuKomkaWXzk/3yDakchP0=; b=KwMBNNY4A0wQQ2Xp2/70rTS59+JEx7kQr1gaynElOtqdqX9l+mIZ8plZju03za672R ZqR3ATy/s4VOMUmcMCjgn6HwXtv32U6jrbHQoSAEMLge4x0AGLBHJlQE0aeY/+oL45/f SbH58R9BDzoQ4TKmnFgKG8aDVoyMgNcE4jDS3w2VEfJWWMtgOtygjnlE9ksy3Th0H6Dk qfI8VqfrOIKPg8OAf5qx7OfusYhEMFdxHx8qdlXXwQRQI9pA7qCnAodXBXPIiaISMMLf 1NcC11GbkHNUpP7u2lClG97Saspb/xAV7yQv0BZ6TLBAlGOZOlY+pfVXIqOrY/OPoZus JaeQ== X-Gm-Message-State: AOAM531FSyJ0nwyYJOgsYzfb/zv/CAqex7Z4Zn1+SQLF8dX+gCRr3p2R y0frlimyyNhpBAJw2VGh/5ZfJwjNbBXqxSyOAM1QvDPF X-Google-Smtp-Source: ABdhPJwxN/zt9sc1p5cxjoU+XztcyyELSAovUXCAsuAokrJN15obDWYaktrnCTR6d17XR9wiYXE6JLxSggq9jJvtlgs= X-Received: by 2002:adf:f289:: with SMTP id k9mr4028217wro.203.1597432571175; Fri, 14 Aug 2020 12:16:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Fri, 14 Aug 2020 15:16:00 -0400 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f5283005acdb403e" Archived-At: Subject: Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 19:16:22 -0000 --000000000000f5283005acdb403e Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 10:59 AM Kurt Andersen (b) wrote: > It would be worthwhile for everyone in the group to read through > https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun > as they analyze implementation flaws that allow attacks against DMARC in > existing implementations. > > The paper should be publicly accessible now since the conference is in > progress. There's also a slide deck with a summarized set of results from > their study. > > --Kurt > Did a first look at the slide deck. Some interesting stuff. Some is clearly interoperability and should be considered by the working group. Some is DMARC/DKIM/SPF implementation issues and some like the display name is intractable. As someone suggested to me today, it would be incredibly useful to disambiguate the Display Name from the From email address for anti-abuse purposes but my feeling is a) that is something for the email core group (not this group) and b) there would be incredible pushback against such an effort. Michael Hammer --000000000000f5283005acdb403e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 10:59 AM Kurt= Andersen (b) <kboth@drkurt.com&= gt; wrote:
It would be worthwhile for everyone in the group to read throug= h=C2=A0https://www.usenix.org/conference/us= enixsecurity20/presentation/chen-jianjun as they analyze implementation= flaws that allow attacks against DMARC in existing implementations.
The paper should be publicly accessible now since the conferen= ce is in progress. There's also a slide deck with a summarized set of r= esults from their study.

--Kurt

Did a first look at the slide deck. Some interest= ing=C2=A0stuff. Some is clearly interoperability and should be considered b= y the working group. Some is DMARC/DKIM/SPF implementation=C2=A0issues and = some like the display name is intractable. As someone suggested to me today= , it would be incredibly useful to disambiguate the Display Name from the F= rom email address for anti-abuse purposes but my feeling is a) that is some= thing for the email core group (not this group) and b) there would be incre= dible pushback against such an effort.

Michael Ham= mer
--000000000000f5283005acdb403e-- From nobody Fri Aug 14 12:23:32 2020 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 8B7243A11F0 for ; Fri, 14 Aug 2020 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 m4lWHcSbTWr2 for ; Fri, 14 Aug 2020 12:23:28 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 9CE2D3A11E5 for ; Fri, 14 Aug 2020 12:23:28 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:981f:33af:623a:645b]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07EJNMVh012961 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 14 Aug 2020 12:23:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1597433004; bh=G60PXVZJpoIrhDUxHcragm5y6jXKX4olukjiyttoidk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YOMa1uhYUKtXAh5wvJWkYQWkCJ9pg/HE2cqIhxPsxxiFqMFI0J/5s6SWwWhf9Guss qs4OuDu1RmlDZxTXLELzd77zeyAjcPiYHV3Vmb9BOZWH71b4Jclfud5dlkJumu2cce MvU/SWw2qqvLPSUw5kBgX1B7fpIwXe/01OwllrOA= To: Dotzero , "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Fri, 14 Aug 2020 12:23:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B55625028C6A882BAFB02B5B" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 19:23:31 -0000 This is a multi-part message in MIME format. --------------B55625028C6A882BAFB02B5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/14/20 12:16 PM, Dotzero wrote: > > > On Fri, Aug 14, 2020 at 10:59 AM Kurt Andersen (b) > wrote: > > It would be worthwhile for everyone in the group to read > through=C2=A0https://www.usenix.org/conference/usenixsecurity20/pre= sentation/chen-jianjun > as they analyze implementation flaws that allow attacks against > DMARC in existing implementations. > > The paper should be publicly accessible now since the conference > is in progress. There's also a slide deck with a summarized set of > results from their study. > > --Kurt > > > Did a first look at the slide deck. Some interesting=C2=A0stuff. Some i= s > clearly interoperability and should be considered by the working > group. Some is DMARC/DKIM/SPF implementation=C2=A0issues and some like = the > display name is intractable. As someone suggested to me today, it > would be incredibly useful to disambiguate the Display Name from the > From email address for anti-abuse purposes but my feeling is a) that > is something for the email core group (not this group) and b) there > would be incredible pushback against such an effort. > Agreed. I watched the presentation this morning and he points out a number of likely implementation issues that are worth evaluating. Haven't had a chance to read the paper in detail yet. But he doesn't seem to have considered primarily cases where the From email address is presented to and evaluated by the user. He largely ignores MUAs that show only the friendly name and research showing that even if displayed, it is frequently ignored. -Jim --------------B55625028C6A882BAFB02B5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/14/20 12:16 PM, Dotzero wrote:


On Fri, Aug 14, 2020 at 10:59 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
It would be worthwhile for everyone in the group to read through https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun as they analyze implementation flaws that allow attacks against DMARC in existing implementations.

The paper should be publicly accessible now since the conference is in progress. There's also a slide deck with a summarized set of results from their study.

--Kurt

Did a first look at the slide deck. Some interesting stuff. Some is clearly interoperability and should be considered by the working group. Some is DMARC/DKIM/SPF implementation issues and some like the display name is intractable. As someone suggested to me today, it would be incredibly useful to disambiguate the Display Name from the From email address for anti-abuse purposes but my feeling is a) that is something for the email core group (not this group) and b) there would be incredible pushback against such an effort.

Agreed. I watched the presentation this morning and he points out a number of likely implementation issues that are worth evaluating. Haven't had a chance to read the paper in detail yet.

But he doesn't seem to have considered primarily cases where the From email address is presented to and evaluated by the user. He largely ignores MUAs that show only the friendly name and research showing that even if displayed, it is frequently ignored.

-Jim

--------------B55625028C6A882BAFB02B5B-- From nobody Fri Aug 14 12:47:50 2020 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 791643A041A for ; Fri, 14 Aug 2020 12:47:48 -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=unavailable 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 f6re_1E5rdUW for ; Fri, 14 Aug 2020 12:47:47 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 F0BCA3A0406 for ; Fri, 14 Aug 2020 12:47:46 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id t4so9438360iln.1 for ; Fri, 14 Aug 2020 12:47:46 -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=0Qjnn3FzANlN+BMYmdmbdG0zNKoZ3v70ufwbsAZQ0hQ=; b=VJfOVBPkr8AYoSOPf5xLJHTISBX5wFhqB32YQIJnxS2lEKOUZ9LIRqEveDOmO/Um46 ZaR/51HM/CXEnOU0T6ONCJ+Z8y5irmJ3PhOe9Gx+n0Mi89BSbWFcPfYgIwtiq8kzWoyC yGZKJ4qYWFJ9fkNAQFTPr+3iLi4wWBWPAkHj4= 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=0Qjnn3FzANlN+BMYmdmbdG0zNKoZ3v70ufwbsAZQ0hQ=; b=cusWlDdG00fTxxCb74dTxVQk49BGTnXX/VXXTlTeUtM+uziDLIhjuaFQ3Gig88fCh7 p2dMKje6qQfNrLV9UZ4yGr01iVBFTBDNrx0cLdPRlEP2tQGlw0+RFR077esUOGWHYgnU wAEYMo+zmhwFk9IYWmder6kzlNi3oUMP3bwD2fna+/B2Qa6E50nn0JJIfOoObo0H/JVf 1kdilBF2spn7X4Ft3l0kwWaIBWPDKIxEqAYQJOiqaqxhr3hV97E+pAfRDUNgo7Re1uaa U54kCjBH0M9lnwOOniVcNv1/SmTsmV0bJj1vwHyUK8W56a8GkknqdcWlrfePGg4+YPqe q5eQ== X-Gm-Message-State: AOAM5305wLc+T6XVTuZqSojaecr4Vbzk0c4mwWkJ8/ISRJJ81us2mthY YufIukISYTtG5/Yo3slstJ07u4snqeYGv48Bily3OA== X-Google-Smtp-Source: ABdhPJwYS/Bu8lP752LoZj6hsqR3mKMVoEuiA7drkT4+co98Mumua5sakTx6TiOBDYvnLaf0ojmivNubpTEBcPYj2Bk= X-Received: by 2002:a92:85c8:: with SMTP id f191mr3953131ilh.242.1597434465959; Fri, 14 Aug 2020 12:47:45 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: Neil Anuskiewicz Date: Fri, 14 Aug 2020 12:47:09 -0700 Message-ID: To: Dotzero Cc: "Kurt Andersen (b)" , IETF DMARC WG , Doug Foster Content-Type: multipart/alternative; boundary="000000000000e55c9505acdbb1c7" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 19:47:49 -0000 --000000000000e55c9505acdbb1c7 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 11:15 AM Dotzero wrote: > > > On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz > wrote: > >> >> >> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) >> wrote: >> >>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: >>> >>>> >>>> I've been involved in setting up DMARC with a policy of p=reject for >>>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >>>> in getting buy-in across the organization that it is a worthwhile effort, >>>> getting control of your organization's mail flows and ensuring policies and >>>> procedures are communicated and followed. For complex environments there >>>> may need to be some automation required for creating and maintaining >>>> private/public key pairs and DNS records but that is much more >>>> straightforward than the aforementioned heavy lifting. >>>> >>> >>> Also note that said "heavy lifting" is not a one time expenditure of >>> effort. Having hoisted the weight bar above your head, it requires >>> organizational will and ongoing knowledge to stick to the higher bar week >>> in and week out. Entropy is never your friend in an organizational security >>> context. Neither are acquisitions :-) >>> >>> Yes, and that's why I use DMARC mostly as a tool for reporting. My >>> clients are typically small businesses who are worried about selling >>> widgets not about email so even if I help them set up email perfectly, they >>> could make a change a year from now without updating their SPF record or >>> deploying DKIM. I just changed my policy to reject (just for fun) assuming >>> this email will get through because of DMARC's OR logic. >>> >> > Which brings us back to the question of organizational implementation > issues vs interoperability issues. Can a technical standards body solve > the problem of organizations shooting themselves in the foot because they > are worried about selling widgits and not about email? Why do I have a > feeling they start caring about email when it no longer works for them? > They have created a self induced personal interoperability issue. If they > changed their MX to use a random port other than port 25 to receive SMTP > connections would you suggest that the RFC should be written to > accommodate that? > > No, it probably can't solve that sort of problem and maybe there's not really a problem. DMARC does work as advertised, though adoption's low. Under 50% of companies have any DMARC record. Of those who deploy DMARC, about ~2% have p=quarantine and ~5% p=reject, though some industries such as finance it looks like it's closer to 15% p=reject. I'm sure these numbers aren't perfect but what you have likely isn't radically different. Why is adoption low? Is that a big problem? Why so few aggressive policies? Is that a big problem? Can a standards body do anything about any of it? Should they? I have no idea. --000000000000e55c9505acdbb1c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 11:15 AM Dotz= ero <dotzero@gmai= l.com> wrote:


On Fri, Aug 14, 2020 at 1:32 PM = Neil Anuskiewicz <neil@marmot-tech.com> wrote:


On Fri, Aug 1= 4, 2020 at 8:13 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Fr= i, Aug 14, 2020 at 7:31 AM Dotzero <dotzero@gmail.com> wrote:

I've be= en involved in setting up DMARC with a policy of p=3Dreject for somewhere N= orth of 6,000 domains. As a sending domain, the heavy lifting is in getting= buy-in across the organization that it is a worthwhile=C2=A0effort, gettin= g control=C2=A0of your organization's mail flows and ensuring policies = and procedures are communicated and followed. For complex environments ther= e may need to be some automation required for creating and maintaining priv= ate/public key pairs and DNS records but that is much more straightforward = than the aforementioned=C2=A0heavy lifting.
<= div>
Also note that said "heavy lifting" is not a o= ne time expenditure of effort. Having hoisted the weight bar above your hea= d, it requires organizational will and ongoing knowledge to stick to the hi= gher bar week in and week out. Entropy is never your friend in an organizat= ional security context. Neither are acquisitions :-)

Yes, and that's why I use DMARC mostly as a tool for reporting. My c= lients are typically small businesses who are worried about selling widgets= not about email so even if I help them set up email perfectly, they could = make a change a year from now without updating their SPF record or deployin= g DKIM. I just changed my policy to reject (just for fun) assuming this ema= il will get through because of DMARC's OR logic.

Which brings us back t= o the question of organizational implementation issues vs=C2=A0 interoperab= ility issues. Can a technical standards body solve the problem of organizat= ions shooting themselves in the foot because they are worried about selling= widgits=C2=A0and not about email? Why do I have a feeling they start carin= g about email when it no longer works for them? They have created a self in= duced personal interoperability issue. If they changed their MX to use a ra= ndom port other than port 25 to receive SMTP connections would you suggest = that the RFC should be written to accommodate=C2=A0that?

No, it probably can't solve that sort o= f problem and maybe there's not really a problem. DMARC does work as ad= vertised, though adoption's low.

=C2=A0Under 5= 0% of companies have any DMARC record. Of those who deploy DMARC, about ~2%= have p=3Dquarantine and ~5% p=3Dreject, though some industries such as fin= ance it looks like it's closer to 15% p=3Dreject. I'm sure these nu= mbers aren't perfect but what you have likely isn't radically diffe= rent.

Why is adoption low? Is that a big problem? = Why so few aggressive policies? Is that a big problem?=C2=A0

=
Can a standards body do anything about any of it? Should they? I= have no idea.=C2=A0
--000000000000e55c9505acdbb1c7-- From nobody Fri Aug 14 13:42:40 2020 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 C8F3D3A082C for ; Fri, 14 Aug 2020 13:42:38 -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=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 OHhPavaxRhsc for ; Fri, 14 Aug 2020 13:42:37 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 3411E3A0835 for ; Fri, 14 Aug 2020 13:42:34 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k23so11987810iom.10 for ; Fri, 14 Aug 2020 13:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+fe0ZP3VdROUxgpyY7R8QChSbBGYDyYnve0DXYW8lPU=; b=WrNqAmjRJ0T9v2vG2WzZ9ipz+4/K/7p7jpGsD5o9zcRgcbw21rmiCu5DgouLBHLMUG mvKPgSWsyJpGSkhqffayu6CEepI0B4uZ7WEI1sEktd+e0pHSMvKpjP11L7u3pKGwo+tN 4Ez0PzXMz/iuG5AVHUmESw1i43kitet/CD83A= 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=+fe0ZP3VdROUxgpyY7R8QChSbBGYDyYnve0DXYW8lPU=; b=pBcHjsrFhdWNBigYKFqVSSvOswFpwal5FUkAREP3S4l/UhljAIp3Pc7AmTAU1d1grO huh41D+ZlXs9C0tCJ8GXKajHiY/x9r0FnUr0upix5ijmZakdlxK4gEcNfOFXSRx626Ca 6+on2wAKPTIHtkbhPdROEeyWucEqaTpqiiJOR9OdsAhcXBHfpfIRMZ8+gr9CSU6gHL60 KSebrqgdHn2wNmO1PP4qaJttjCeRO/frRFkF0RilnrcTLKqvXTalCIDhnB/VGOrWNmfg DNoy68mSxf97z+bq9BRwzsaZX4BxUVLh9wDXoNyxwwY0812QDbT5hYAAC4VMF7LWu36K rgqA== X-Gm-Message-State: AOAM531GUVQYxE+Zu7sGRJrvJ3IG0ujjZBly0chWnpoTfrdVareM8lVu wFfxlAO2Agql2epQL20cjvSCiHqDpgrkFojqHPKBHg== X-Google-Smtp-Source: ABdhPJywILDIb6R1ZCCMrT3B9B5O/vmvxXK7iWgRQJy6/uiRZ77itYESdUKFpvT5wFa0RumEDlklIoNrmVYtP3pTvCc= X-Received: by 2002:a05:6638:12d4:: with SMTP id v20mr4076389jas.108.1597437753307; Fri, 14 Aug 2020 13:42:33 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 14 Aug 2020 13:41:56 -0700 Message-ID: To: Jim Fenton Cc: Dotzero , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d64dd805acdc75fc" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 20:42:39 -0000 --000000000000d64dd805acdc75fc Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton wrote: > On 8/14/20 11:30 AM, Kurt Andersen (b) wrote: > > On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote: > >> >> Is this an interoperability problem that is solved by IETF standards or >> is it an organizational problem that requires an organizational solution? >> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-) >> > > I think that it might be out of the DMARC-WG's charter, but such an RFC > would be eminently quotable along with 2549 and other such work. > > We already have a number of such RFCs: > > > https://datatracker.ietf.org/doc/search?name=considered+harmful&sort=&rfcs=on&activedrafts=on&by=group&group= > > -Jim > Maybe we should write _Implementing Email Security Without Understanding What You Are Doing Is Considered Harmful_ - that could fall within our remit. --Kurt --000000000000d64dd805acdc75fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 14, 2020 at 12:16 PM Jim Fent= on <fenton@bluepopcorn.net= > wrote:
=20 =20 =20

On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:

=20
On Fri, Aug 14, 2020 at 9:23 AM Dotzero <dotzero@gmail.com> wrote:

=C2=A0Is this an interoperability=C2=A0problem that is= solved by IETF standards or is it an organizational problem that requires an organizational solution? Perhaps we need to generate an RFC entitled "Don't Do Stupi= d Things". ;-)

I think that it might be out of the DMARC-WG's charter, but such an RFC would be eminently=C2=A0quotable along with 254= 9 and other such work.

We already have a number of such RFCs:

https://datatracker.ietf.org/doc/search?name= =3Dconsidered+harmful&sort=3D&rfcs=3Don&activedrafts=3Don&b= y=3Dgroup&group=3D

-Jim

Maybe we should write _Implement= ing Email Security Without Understanding What You Are Doing Is Considered H= armful_ - that could fall within our remit.

--Kurt= =C2=A0
--000000000000d64dd805acdc75fc-- From nobody Fri Aug 14 15:45:15 2020 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 8C42B3A046E for ; Fri, 14 Aug 2020 15:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 f4HlbH3PJSkH for ; Fri, 14 Aug 2020 15:45:12 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 3784E3A043A for ; Fri, 14 Aug 2020 15:45:12 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id g19so12278564ioh.8 for ; Fri, 14 Aug 2020 15:45:12 -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=Ej2MXGdNjIXL5Ahmhpt12bA6zBYw4AZH2QpXJCkLSsM=; b=cM1Io8HfTPcqpbD2AYTAunvL2QmuWAUlChVPxeckpQQTfMQCwMeBST9o3wo4n0NQbZ yMPm0zgZK89/cOBin9LgDMo2dQgC+EJoHhFX0y95J+1pu3xeg29tHfw1ut4dv54L8W4d eGZdz7ROvTj80QwJxlvvKnPvaTEn8MwJlqNvZF6vNdeQa3XpbuKm6ACur426HPk4BUq/ zZTwHbs7iNpxEr6/FaiBnuaOHePl009Jc0wmGI1mrpiymrgVSwcgP8xYwjDnhhMKJ4p1 ZEJzBeLKbDs56/VyUMNeKVUYxusAE4YA3vkkQJRf6MSsMhf2pTSBhrtKBpfMgIztQTVY NBTA== 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=Ej2MXGdNjIXL5Ahmhpt12bA6zBYw4AZH2QpXJCkLSsM=; b=EdSa+S+0YnKsIW6uBf0DgL0X7Up9Ka9zvzqEWYkrUs8seR+9dQeG1Dr3ZBkyf5bC4R 53i47qBB61mi/gl1V6Hx747FI5DYTJzeqwyKbLoXgbpG0i5l1bwiAq3QPdQYZKJE6vjh 52ZCwtyZB9F/GZsWO73qphS0Pd88wymyucgGPLWzVKW7GYl5QGLr97qq+Dd54w2qiQAZ +KlPeQq2EWTxW6WKVpPp8486PpM/LIwGTyx+CEAfv/xHMF0lJD7aSOCK1oD8inYUCBfV JuR27QM7Afskxt6l3CbFm1Z2o2EycMO9j5zsmS5vvAtAYktwOFrCmnUsf/FQWPfrcD3w /htQ== X-Gm-Message-State: AOAM531d4IQ3Eq7U4yWDj9JqY3fnwCEc3HEseGBK5a5t8IvuAsRzVsDc qKWIRVrqqrx0Xnl2t48eyTUgFdjAWxOHft6ldTSg X-Google-Smtp-Source: ABdhPJz4d73lYhRNRefc1ALErplLBYXwbs5aAr4A/S75pcZfWvi1PdkIZElGc43fjUdbOrlajxlclq/tVu/kKw7ayQ0= X-Received: by 2002:a05:6638:25d3:: with SMTP id u19mr4556897jat.103.1597445111260; Fri, 14 Aug 2020 15:45:11 -0700 (PDT) MIME-Version: 1.0 References: <745030ea-c2e6-16a4-690f-bbb639b9b8b8@bluepopcorn.net> In-Reply-To: <745030ea-c2e6-16a4-690f-bbb639b9b8b8@bluepopcorn.net> From: Brandon Long Date: Fri, 14 Aug 2020 15:44:59 -0700 Message-ID: To: Jim Fenton Cc: Tim Wicinski , IETF DMARC WG , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006839af05acde2c0e" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 22:45:14 -0000 --0000000000006839af05acde2c0e Content-Type: text/plain; charset="UTF-8" On Fri, Aug 14, 2020 at 12:09 PM Jim Fenton wrote: > On 8/10/20 12:04 PM, Tim Wicinski wrote: > > > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. > > This starts a Call for Adoption for draft-crocker-dmarc-sender > > I do not support adoption of this draft as a working group document for > different reasons than I have seen expressed by others on the list. > > If the Sender header field is to be used by DMARC in the manner described > in this draft, it should be an integral part of the DMARCbis specification > rather than a separate extension to it. In other words, this should be an > issue on the DMARC WG issue tracker rather than a working group draft (and > presumably eventual RFC). There are enough different combinations of > originators and receivers that might use Sender (which the chart in Section > 2 begins to describe) that we don't need the ongoing ambiguity of whether > the receiver does or does not implement this as an extension. > +1 If DMARC wasn't experimental, maybe I could see adding it separately, but this seems like a fairly fundamental change and shouldn't just be a bolt-on... especially since as written this appears to undermine the existing DMARC.. ie if DMARC is "apply this policy to these messages" and this addition says "nah, don't apply them to some of those messages". Brandon --0000000000006839af05acde2c0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 14, 2020 at 12:09 PM Jim = Fenton <fenton@bluepopcorn.net= > wrote:
=20 =20 =20
On 8/10/20 12:04 PM, Tim Wicinski wrote:
=20

During IETF 108, the chairs realized that there was interest in Dave's
RFC5322.Sender draft. =C2=A0

This starts a Call for Adoption for draft-crocker-dmarc-sender

I do not support adoption of this draft as a working group document for different reasons than I have seen expressed by others on the list.

If the Sender header field is to be used by DMARC in the manner described in this draft, it should be an integral part of the DMARCbis specification rather than a separate extension to it. In other words, this should be an issue on the DMARC WG issue tracker rather than a working group draft (and presumably eventual RFC). There are enough different combinations of originators and receivers that might use Sender (which the chart in Section 2 begins to describe) that we don't need the ongoing ambiguity of whether the receiver does or does not implement this as an extension.


+1
If DMARC wasn't experimental, maybe I could see adding it s= eparately, but this seems like a fairly fundamental change and shouldn'= t just be a bolt-on... especially since as written this appears to undermin= e the existing DMARC.. ie if DMARC is "apply this policy to these mess= ages" and this addition says "nah, don't apply them to some o= f those messages".

Brandon=C2=A0
<= /div> --0000000000006839af05acde2c0e-- From nobody Fri Aug 14 18:47:48 2020 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 0EB8A3A151C for ; Fri, 14 Aug 2020 18:47:47 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=OidFUg6F; dkim=pass (2048-bit key) header.d=taugh.com header.b=Xi8CRUoa 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 7rbhIgt5Cc2L for ; Fri, 14 Aug 2020 18:47:45 -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 687F93A151B for ; Fri, 14 Aug 2020 18:47:45 -0700 (PDT) Received: (qmail 63578 invoked from network); 15 Aug 2020 01:47:42 -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=f857.5f373ebe.k2008; bh=9mt+fp0s/1fkCqgqQz5CS4zG3ehE5mJKsQPhlAVmdCE=; b=OidFUg6FlvgNEmUw5ROyH00eXWxlEDTKnDtspDN7QhqDkNitV9GvbgvsKIDT2AUjcLWVBfIAhOxCaT1kWQHC7ujTBGHJjM38qZjxwWFLqlGevVQ0VeMSJA6yguK75gGnrdAVd4Qg/5M58RLPtNHTnjjP9b7IkpJANJjHooLHGTeSQA+LR7J7TUAl3Xsi0qbOQyhoukK0RTHHS/OUOco8ZvmFDKHzZDy1lyRc9Ye2WJ9Na3NkL65RCRH8w/PF25CBV+CPkwf/72d+oBcou4q/y08OW/445cZ5mt3NH12lpZNdk9+8i0EE2QuPgLPpvkgMPZBJgG9Qs7fe/ept3/+dRA== 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=f857.5f373ebe.k2008; bh=9mt+fp0s/1fkCqgqQz5CS4zG3ehE5mJKsQPhlAVmdCE=; b=Xi8CRUoabj+sw9dHzK2MSSk6sR1mCSapvIYy5NDixSjjwr+NWCr/NYDJkm0ixipkSc/eT5HHQwJJ47cfIQVeSkVNCIJjZFTwG04Tl0SRGF+pPHUfdrFiP5ABGzvlWAUsxCl4Uf/ceh7HVQuiFbZo8fVzOVDYq2crSU3ayrl58xnhs1mNz3M5yFALaRIit81Y2hNkh932ctbPoUsYdNzcimGGcCH96Y+n4lDQCy5aVgHwlMpj/2KgsOl8lCR1hlqCJ22F3vVHxTDzDwZp7YXYqtK0rk6f2ZR6jbsr7R5Yi5yx5+15lIt2ya1ut413wMJ12lallp4usBOeZH5WNoiotg== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Aug 2020 01:47:42 -0000 Received: by ary.local (Postfix, from userid 501) id A5E7D1E99A65; Fri, 14 Aug 2020 21:47:41 -0400 (EDT) Date: 14 Aug 2020 21:47:41 -0400 Message-Id: <20200815014741.A5E7D1E99A65@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Good paper analyzing inter-component flaws in email security X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 01:47:47 -0000 In article you write: >-=-=-=-=-=- > >It would be worthwhile for everyone in the group to read through >https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun >as they analyze implementation flaws that allow attacks against DMARC in >existing implementations. They found some interesting and unlikely implementation bugs but I didn't see anything that looked like a design problem. From nobody Sat Aug 15 00:46:58 2020 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 1643B3A08B9 for ; Sat, 15 Aug 2020 00:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 2b5PeK4OkCop for ; Sat, 15 Aug 2020 00:46:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 A58293A08B6 for ; Sat, 15 Aug 2020 00:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597477611; bh=LKQtmlm9dLcAgS8qYZaNDtyEdxstYLOaGen4UrVvLD0=; l=2901; h=To:References:From:Date:In-Reply-To; b=BmyD/0xY6ZPdgZM5oKZq0kClNrs368bkqfEG5H1rRONUEeu/Kz+8iRblNPZqGzgiQ lxtoChNu8LwbMSgMDwWQLGU88y7xNRmrQVFj5cKWXUkHMxAXbRb995gpqhcHuUAFLK QJ18FSWuBXZDb4ivlCVfySU9bmhIXzI1xBrT7bZD77pmEvuxveBLkWlXqFh+k Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F3792EA.00004950; Sat, 15 Aug 2020 09:46:50 +0200 To: dmarc@ietf.org, Dotzero , John Levine References: <20200814164237.313071E971DB@ary.local> From: Alessandro Vesely Message-ID: <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> Date: Sat, 15 Aug 2020 09:46:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 07:46:56 -0000 On 2020-08-14 7:04 p.m., Dotzero wrote: > On Fri, Aug 14, 2020 at 12:42 PM John Levine wrote: >> In article you write: >>> [...] >> >>> This is why I made the point above that lists should respect DMARC >>> policy and not accept submissions from domains with DMARC p=reject >>> policies. >> >> Lists have been around a lot longer than DMARC has. That doesn't grant lists any extra right. Others consider current global usage as a priority gauge. >> Perhaps you meant to say that domains whose users participate in >> mailing lists should not publish restrictive DMARC policies. If >> they don't want their users to send mail to lists, they should >> tell their users not to send mail to lists. Should they file lawsuits against online infringers? > I meant what I wrote. Domains who actively want their users to participate > in mailing lists or even passively accept that their users participate in > mailing lists shouldn't publish p=reject for the domain their users are > sending from or should take steps to migrate the users to another > domain/subdomain, etc. Why people's mailboxes must be spoofable? Syllogism goes like so: Mailing list must not accept strict DMARC policies, humans may happen to use mailing lists, therefore email domains which hosts mailboxes used by humans must not publish strict DMARC policies. Is that really what we seek? I hope not. This is not the mailcore WG where they have to bring to full standard a time-honored paper. We're talking about a protocol that is gaining adoption slowly as it has some troubles. It's going to be Proposed Standard anyway. Fixes may go as far as introducing Sender:. In such a scenario, why should we stick to the restricted p=none except transactional? > Conversely, if a domain IS publishing p=reject then yes, they > should be taking steps internally but I also believe others should > consider that domain's published policy as intentional and act > accordingly. I've never heard of a DMARC policy getting published > due to inaction. Someone with administrative rights actively > published that policy. Possibly, that policy was pushed for security reasons. We may say they don't know what they're doing. They may say the same of us. If DMARC cannot secure people's mailboxes, perhaps we should invent a different protocol. It may still be based on SPF and DKIM authentication. And still be called DMARC, no? >> There are lots of organizations that actively want their employees to >> participate in the IETF, to the extent that they give them paid time >> for IETF activities, yet publish p=reject policies to cripple that >> participation. I wish they would make up their minds. >> > > Me too. We could make up our minds as well... Best Ale -- From nobody Sat Aug 15 00:59:15 2020 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 4A5DB3A0913 for ; Sat, 15 Aug 2020 00:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 NBYfvOij-Dkk for ; Sat, 15 Aug 2020 00:59:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2B5193A0912 for ; Sat, 15 Aug 2020 00:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597478351; bh=tAD2soYNCsONGtasc27+XTVsFmTJq9VZ8B93JQgUwUc=; l=854; h=To:References:From:Date:In-Reply-To; b=B6BhbSfnWSm6sTx+uqPiEGu7g9JebDUwEIpQwRPY3znCu/YQyWbWdd6j9mPQPXOkc U6zmHQJ64uwSJ4lZNdqKyKitQOmQLDFse0QLWdfALPBaR06qofhykeM5bYGPHV3kbc ugfbAr0O6mTRwYUYTG8W8vbaPrXaeG8h7Cu3In/5EigoqBnsffxg4m7y5Psyo Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F3795CF.00004AE2; Sat, 15 Aug 2020 09:59:11 +0200 To: dmarc@ietf.org References: <745030ea-c2e6-16a4-690f-bbb639b9b8b8@bluepopcorn.net> From: Alessandro Vesely Message-ID: Date: Sat, 15 Aug 2020 09:59:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <745030ea-c2e6-16a4-690f-bbb639b9b8b8@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 07:59:14 -0000 On Fri 14/Aug/2020 21:08:56 +0200 Jim Fenton wrote: > > If the Sender header field is to be used by DMARC in the manner > described in this draft, it should be an integral part of the DMARCbis > specification rather than a separate extension to it. In other words, > this should be an issue on the DMARC WG issue tracker rather than a > working group draft (and presumably eventual RFC). There are enough > different combinations of originators and receivers that might use > Sender (which the chart in Section 2 begins to describe) that we don't > need the ongoing ambiguity of whether the receiver does or does not > implement this as an extension. 100% agreed. However, since I haven't yet understood how exactly the spec is going to be split among various I-Ds, I voted for adoption in order to boost discussion. Best Ale -- From nobody Sat Aug 15 02:02:24 2020 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 63F933A0BB9 for ; Sat, 15 Aug 2020 02:02:22 -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, 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 m0P-PaTG-bqi for ; Sat, 15 Aug 2020 02:02:20 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 65F0A3A0BB8 for ; Sat, 15 Aug 2020 02:02:20 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id q68so3351804uaq.0 for ; Sat, 15 Aug 2020 02:02:20 -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=g7sW9D694Ur1smqnDT4Nb+oWMZYHnJJqLis9Ym+56+g=; b=j2/fUuMsgHTSLguewr/siEcZaRxlHcX3nMN+EoDigO65EkTJyY27vf1NOVfVlMYnr4 9zE5Jtbul3ghgd1puQhjKgtGHU7I50ZOQypg7ACLker1l9MCE+gk499pEfGjpsYKDRMU lovjXGlqkobt75T5IqO5S+7J8NHyWgwM7GkTCQoPY+bkKtWIfT6cYlOvIvaJpvbfK/Yi Uy6eNp/5Qi3BqBcWBq+T6rWZlJVpaGHaiSqnzYclxc8UiCF4NCeRIKN+QLchp/wGTAB0 Y3x9s/hSKqO0907/jUkEflz6Yo53N/rR3Fe5Qdld3/nzlUadqCpk0NGV/vjErxeaJ6nU i+DQ== 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=g7sW9D694Ur1smqnDT4Nb+oWMZYHnJJqLis9Ym+56+g=; b=EadWS4nOI6gwk/ET1Jyjvkk/icoOf2zAcUSu6M3I99qser2+v4jhcmoBt8Jesv4uu6 a0GDJSFrxKGU9FZcpVKnFJ9h5VCTnT0xXurs31FPX7Jy3MkWTv0nDXfpBNbcCnk4NnV9 fcbPLQrR+C5T3gv6dfGNc5eZLN/2PW4YnI8/nF8D/6cNQXt+Kt1qA1eTYEUQXxkl3NhV 5+EOzYZZ9vEmdLDgxkvlwss35KW6CfwJ+fdsOpAIQO7Lf2NhM1g2aof6RwgXrTy4PTeD UJErJNRSeEy0Ey1wL1Fcpm0ihXTuRKJtkI+8bFPbQti+EEN3YKV4LoLVa7kaMcTFRzRZ q7wA== X-Gm-Message-State: AOAM531+Bw2795SzyK9h5PFM6K6a8EatHfDsXlu3HIsLNyu64h65IjAi cYDoeQNBNgNPDMEj6LWTXVifxK0FlzFw6nKeQHk= X-Google-Smtp-Source: ABdhPJwRRDMowbRvhhtQOYgFr9yHh+Mzxh9F+Y8KH7XIMe+ZvfycF8HKaZu6mfCJFzdWaIG89tHmTMo9+xb4UkB74gI= X-Received: by 2002:a9f:26a5:: with SMTP id 34mr3639149uay.67.1597482139218; Sat, 15 Aug 2020 02:02:19 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> In-Reply-To: <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> From: "Murray S. Kucherawy" Date: Sat, 15 Aug 2020 02:02:06 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG , Dotzero , John Levine Content-Type: multipart/alternative; boundary="0000000000007179ce05ace6cbc7" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 09:02:22 -0000 --0000000000007179ce05ace6cbc7 Content-Type: text/plain; charset="UTF-8" Emphatically hatless: On Sat, Aug 15, 2020 at 12:47 AM Alessandro Vesely wrote: > >> Lists have been around a lot longer than DMARC has. > > That doesn't grant lists any extra right. Others consider current > global usage as a priority gauge. > This line of thinking has bothered me for a long time. Imagine you're a large soft drink manufacturer. Your delicious, popular product is sold in grocery stores the world over, sometimes directly from your production line, sometimes via a local reseller. Your sales team does one or the other depending on the use case. Business has been good for a generation or two. One day you decide you don't like resellers anymore because some of them mis-promote your product, so you somehow arrange that the cans in the stores that passed through resellers suddenly and randomly begin invalidating themselves by bursting, making a mess of the store and soaking customers. Other products nearby are also ruined. This reflects poorly on the resellers, some of whom are forced to stop doing business with you. Stores get angry and are forced to reconsider doing business with you as well, but you're big and popular and so many of them have to deal with your mess on an ongoing basis. Many customers take their business elsewhere; the stores suffer. The argument here appears to be that is that this is justified, because the ecosystem of manufacturers, grocery stores, resellers, and customers that has existed for as long as you can remember has no right to operate that way if you suddenly decide you don't want it to; it's your brand, and your word about your brand is final irrespective of how you choose to enforce it. You're suddenly, for reasons you feel are legitimate, asserting that the ecosystem was broken to begin with despite the fact that you've been a willing participant for decades, and therefore you are at liberty to disrupt it (though, admittedly, you may have been unaware of the blast radius of doing so). Now, you may be right that the ecosystem was built on the incorrect premise that domain names don't need to be treated as sacrosanct. (Let's ignore for the moment the stuff about hindsight.) But that assertion clearly differs from the well-established foundation upon which a great deal rests today. It is far from trivial to change that now. It's possible to do, to be sure, but dropping it into the world overnight has a hugely disruptive impact. Such a change needs to be an evolution, with the cooperation and collaboration of a preponderance of the participants, not a philosophical light switch you get to throw and expect everyone else to conform. I don't want any more soda on me. Why people's mailboxes must be spoofable? > I don't know about "must", but changing the fundamental assumption that it's acceptable in some cases for X to pretend to be Y (which is what MLMs do), at X's discretion, is a tectonic change that should have been rolled out with more community collaboration and grace than it was. I think we need to be more considerate of that fact if there is to be progress. Syllogism goes like so: Mailing list must not accept strict DMARC > policies, humans may happen to use mailing lists, therefore email > domains which hosts mailboxes used by humans must not publish strict > DMARC policies. Is that really what we seek? I hope not. > It is our current reality, and in my humble opinion, we've nobody to blame but ourselves. -MSK, participating. --0000000000007179ce05ace6cbc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Emphatically hatless:

On Sat, Aug = 15, 2020 at 12:47 AM Alessandro Vesely <vesely@tana.it> wrote:
>> Lists have been around = a lot longer than DMARC has.

That doesn't grant lists any extra right.=C2=A0 Others consider current=
global usage as a priority gauge.

This line = of thinking has bothered me for a long time.

Imagine you're a large soft drin= k manufacturer.=C2=A0 Your delicious, popular product is sold in grocery st= ores the world over, sometimes directly from your production line, sometime= s via a local reseller.=C2=A0=20 Your sales team does one or the other depending on the use case.=C2=A0=20 Business has been good for a generation or two.=C2=A0 One day you decide yo= u don't like resellers anymore because some of them mis-promote your pr= oduct, so you somehow arrange that the cans in the stores that passed throu= gh resellers suddenly and randomly begin invalidating themselves by burstin= g, making a mess of the store and soaking customers.=C2=A0 Other products n= earby are also ruined.=C2=A0 This reflects poorly on the resellers, some of= whom are forced to stop doing business with you.=C2=A0 Stores get angry an= d are forced to reconsider doing business with you as well, but you're = big and popular and so many of them have to deal with your mess on an ongoi= ng basis.=C2=A0 Many customers take their business elsewhere; the stores su= ffer.

The argument = here appears to be that is that this is justified, because the ecosystem of= manufacturers, grocery stores, resellers, and customers that has existed f= or as long as you can remember has no right to operate that way if you sudd= enly decide you don't want it to; it's your brand, and your word ab= out your brand is final irrespective of how you choose to enforce it.=C2=A0= You're suddenly, for reasons you feel are legitimate, asserting that t= he ecosystem was broken to begin with despite the fact that you've been= a willing participant for decades, and therefore you are at liberty to dis= rupt it (though, admittedly, you may have been unaware of the blast radius = of doing so).

Now, you may be right that the e= cosystem was built on the incorrect premise that domain names don't nee= d to be treated as sacrosanct.=C2=A0 (Let's ignore for the moment the s= tuff about hindsight.)=C2=A0 But that assertion clearly differs from the we= ll-established foundation upon which a great deal rests today.=C2=A0 It is = far from trivial to change that now.=C2=A0 It's possible to do, to be s= ure, but dropping it into the world overnight has a hugely disruptive impac= t.=C2=A0 Such a change needs to be an evolution, with the cooperation and c= ollaboration of a preponderance of the participants, not a philosophical li= ght switch you get to throw and expect everyone else to conform.
<= div>
I don't want any more soda on me.

Why people's mailboxes mus= t be spoofable?

I don't know about = "must", but changing the fundamental assumption that it's acc= eptable in some cases for X to pretend to be Y (which is what MLMs do), at = X's discretion, is a tectonic change that should have been rolled out w= ith more community collaboration and grace than it was.=C2=A0 I think we ne= ed to be more considerate of that fact if there is to be progress.

Syllogism goes like so:=C2=A0 Mailing list must not accept strict DMARC policies, humans may happen to use mailing lists, therefore email
domains which hosts mailboxes used by humans must not publish strict
DMARC policies.=C2=A0 Is that really what we seek?=C2=A0 I hope not.

It is our current reality, and in my humble o= pinion, we've nobody to blame but ourselves.

-= MSK, participating.
--0000000000007179ce05ace6cbc7-- From nobody Sat Aug 15 03:32:34 2020 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 8BA063A0C8E for ; Sat, 15 Aug 2020 03:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 r6B9Uq2hrZ-6 for ; Sat, 15 Aug 2020 03:32:32 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 300983A0C8B for ; Sat, 15 Aug 2020 03:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597487548; bh=kqRcXOJTjTH9A4kO3Y/ZsxIvNtiSdDybIZ+nQzWzB7A=; l=1274; h=To:Cc:References:From:Date:In-Reply-To; b=B2NUwXu35dg5Gt1o5X4w6PD4B+G7ZwzSOjnhYoZFqvTJu9aXhZl6gzwtIuDjkrgdj TTGv9Oa+EaRA0Pn907sBh6ukdlO9QNn/8KFcWHx2i4DPFTP9Xbc0crP7LbLDAKY8vq wS3vtuLeF9wtLIOpUCTooQPWQBGYjgHz8rXVlCmwyiJaQmHIieg1l4UAVYVob Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC026.000000005F37B9BB.00005A15; Sat, 15 Aug 2020 12:32:27 +0200 To: "Murray S. Kucherawy" Cc: IETF DMARC WG , John Levine , Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> From: Alessandro Vesely Message-ID: Date: Sat, 15 Aug 2020 12:32:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 10:32:34 -0000 On Sat 15/Aug/2020 11:02:06 +0200 Murray S. Kucherawy wrote: > On Sat, Aug 15, 2020 at 12:47 AM Alessandro Vesely wrote: > [...] > >> Syllogism goes like so: Mailing list must not accept strict DMARC >> policies, humans may happen to use mailing lists, therefore email >> domains which hosts mailboxes used by humans must not publish strict >> DMARC policies. Is that really what we seek? I hope not. >> > > It is our current reality, and in my humble opinion, we've nobody to blame > but ourselves. The workarounds we have on the table, to standardize From: rewriting possibly copying the original From: value to some other field (Author:, To:, Reply-To:), to verify DKIM modulo transformations, and to accept a tunable set of Sender:'s do have the potential to smooth enough harshness and thereby avoid that cans which invalidate themselves mess up the store and ruin nearby products, don't they? The first one of them has already proved its effectiveness. If X pretends to be Y, it must do so in a verifiable, uncloakable way. How processes which rely on the cloak can still believe it has to be worked out case by case. The more alternatives we provide, the more likely one of them can suit a given case. Best Ale -- From nobody Sat Aug 15 09:49:43 2020 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 6991D3A0775 for ; Sat, 15 Aug 2020 09:49:41 -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, 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 5LHp97djJ-U1 for ; Sat, 15 Aug 2020 09:49:40 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 0E16F3A074B for ; Sat, 15 Aug 2020 09:49:39 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id i129so6206695vsi.3 for ; Sat, 15 Aug 2020 09:49:39 -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=4tUd/g2xvYnj0ULIWtUfS/x5eKu8aIaWFH01AshRVpU=; b=vOLIdQVsAvVoKXc5kgu27Qxu+c3J9lIZZueuvdOjPMKNIPeP1CxXbOIpX+v/wkkXAv bELPyHWurBS3wEbv2oMGqfnH9ZteZ8eaW5xES43Qc8z5hrxVozJPFv8cVfSIp5F7QGeD 45NGBQIh71RLsG57sjZmw99PJdRcA8h9nXiWBe0ZiDtrcerYGi1cYP574dcQNksQGN4m U5j6vi93J1nAzC2IzUZuPPg3+eJoZ3SlTAUTbr6AI6c4R8qrCGkqQZGL53GvrKhUGoXH LdUvV4CATWPxc6yYoqOoImsQakGUUX/jgK6jAKBQ4gLiOBcPiDqe9cHSSbgycf5m321C NClQ== 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=4tUd/g2xvYnj0ULIWtUfS/x5eKu8aIaWFH01AshRVpU=; b=PIOqxB5g95qX2D/AkWXYgAAPS/xTQZvkijQwOdqPejkyrF+vUeA3/1+w4j47/GJHao tOoYnBHzJi7QCqkS0Cf5JHCE36iXPVpNrOEvN80OYPjX5/NU4KFVxYYbB2Y9+ZCYK9uL WiatxYMix1wgaw7aSMz1y3rdFxK6GCbh5ZZaFRAsORst28moPuc/XE2UUOEIOqTRXOoW AOh9TMP1s8W15eeA0W3ORn2oiqM58UZsE3odhtULkqrr237sTK30Ymp07TH6AreoT+TU hKhQWL5O5U+8BK4V071c6GqCWHpgd+20UTK12frwNRnIptXJbX04MBNIisLX5hNZPpTj RbOQ== X-Gm-Message-State: AOAM533j6AslhDeqVSC9h6g2XpYr5H3ng4Pftiqw1BQzLCVel2wOz905 YVZMMYKMUR5Ook9WVre/4mJ8VntdscziJ1m1HRw= X-Google-Smtp-Source: ABdhPJyTX1IWsDwOGW+pMwiVrFBDfTsEpMbxa7lymH4hOIj9A0uansPYxqo6V6n5mDT3uEp7BRLi3nEk75MHZ+djOcY= X-Received: by 2002:a05:6102:1c9:: with SMTP id s9mr4230531vsq.13.1597510178936; Sat, 15 Aug 2020 09:49:38 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 15 Aug 2020 09:49:27 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG , John Levine , Dotzero Content-Type: multipart/alternative; boundary="000000000000bd99e305aced5207" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 16:49:41 -0000 --000000000000bd99e305aced5207 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 15, 2020 at 3:32 AM Alessandro Vesely wrote: > The workarounds we have on the table, to standardize From: rewriting > possibly copying the original From: value to some other field > (Author:, To:, Reply-To:), to verify DKIM modulo transformations, and > to accept a tunable set of Sender:'s do have the potential to smooth > enough harshness and thereby avoid that cans which invalidate > themselves mess up the store and ruin nearby products, don't they? > They are all worthy of consideration, to be sure. But that's not the thing to which I was objecting. The premise that MLMs have actually been long-tolerated abusers is a flawed one, in my opinion. I actually used to think the same thing back in the RFC 4871 era, but I no longer agree. -MSK --000000000000bd99e305aced5207 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 15, 2020 at 3:32 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
The workarounds we have on the table, to standardize From: rew= riting
possibly copying the original From: value to some other field
(Author:, To:, Reply-To:), to verify DKIM modulo transformations, and
to accept a tunable set of Sender:'s do have the potential to smooth enough harshness and thereby avoid that cans which invalidate
themselves mess up the store and ruin nearby products, don't they?
<= /blockquote>

They are all worthy of consideration, to be= sure.=C2=A0 But that's not the thing to which I was objecting.

The premise that MLMs have actually been long-tolerated a= busers is a flawed one, in my opinion.=C2=A0 I actually used to think the s= ame thing back in the RFC 4871 era, but I no longer agree.
-MSK
--000000000000bd99e305aced5207-- From nobody Sat Aug 15 10:37:24 2020 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 97D8B3A0855 for ; Sat, 15 Aug 2020 10:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 CeXahbKj_Nd6 for ; Sat, 15 Aug 2020 10:37:20 -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 08C773A084E for ; Sat, 15 Aug 2020 10:37:19 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07FHe4WC016694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Aug 2020 10:40:04 -0700 To: Steve Atkins , dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <116c9644-8116-564b-5f76-feb53815ef08@dcrocker.net> Date: Sat, 15 Aug 2020 10:37:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 17:37:23 -0000 Steve, et al, On 8/12/2020 8:16 AM, Steve Atkins wrote: > On 12/08/2020 04:32, Dave Crocker wrote: >> Here's why I think it won't:  They already have From:. >> >> The real value in DMARC is not what is displayed to the end-user but >> in having a required field that cites the originating domain name.  >> That doesn't change if there are additional fields that might or >> might not mention the originating domain. > > I think we disagree on the goal of DMARC. The entire point of DMARC is > brand protection. Yes, but... High-level goals are fine.  But then they meet lower-level technical and operational pragmatics. For its originally-intended use, DMARC linked high and low pretty well. The expanded use doesn't and essentially was adopted more to do with stemming a denial of service attack. > Control over what is displayed to the user, I'm confused.  I thought this was a technical forum, not a marketing forum. User's typically don't see the email address and typically it won't matter if they do.  And this has been pointed out repeatedly. So while, yes, these have driven many people's thinking, that thinking isn't based on empirical realities. In this forum, we should not have to constantly be reminded that, in actual practice, none of these activities involve direct user behavior.  Operationally, they are only relevant to the receiving filtering engine. To the extent someone wants to claim otherwise, they should produce empirical evidence, not summaries of marketing views. (And this request also should not need this constant repetition.) > not what's in any particular header. You could use it for other > things, but that's what informed publishers of DMARC say they're using > it for (sometimes phrased as "protection against phishing" but that > too is all about what's displayed to the recipient). No doubt. But, really, there is no closed-loop mechanism to validate that it is achieving what they think it is for, namely getting users to make fewer bad decisions about their mail content. Certainly unauthorized use of a domain name in the From: field /correlates/ positively and perfectly with an assessment of spam, but it correlates negatively and perfectly with authorized uses, such as mailing lists. So in statistical terms, folk using DMARC see utility, but that's as a detector of some spam, and not other spam. And they are dismissive of the negatives, because it doesn't affect /them/. The tone that seems to permeate here is that we need to prevent any new identity -- addressing -- fields  because bad actors will abuse them. What this misses is whether that abuse matters.  I realize that it bothers us to see such abuse, but whether the abuse matters ought to be relevant. > If you display the contents of Author to the user, then DMARC > publishers will want to control that. So we need to cater to folk who want to do things that have no empirical validity?  Seems a poor basis for technical work. The reason the Author: field is being proposed is to regain author-to-recipient MUA-level utility. Also there's the small matter of anticipating strategic behavior of operators without actually knowing that the anticipation is correct and having no history of such behavior other than a single, problematic data point.  As I recall, DMARC uptake is a small percentage of the industry. That makes invocation of a predicted industry behavior also problematic. > If MUAs will display the contents of the Author: header where the > From: header is now then draft-crocker-dmarc-author-00 effectively > moves what used to be Sender: header to the From: header and what used > to be the From: header to the Author: header. As I keep noting, that is what DMARC has already done. It breaks basic, author-related utility of the From: field for MUA use.  That should matter. And the -sender- proposal can't fix that. (see below) > You could achieve exactly the same result, with much less deployment > effort, by updating DMARC to enforce the Sender header and leaving > MUAs displaying the From: header. That wouldn't be acceptable to > anyone who wants to publish DMARC, so the Author: proposal won't be > either. It would be nice for that to be as effective as folk want to believe, but it can't. 1. Sender is an optional field.  DMARC needs something that is always present.  That's really why there was no choice other than From:, for its original design. 2. DMARC has an installed base and the 'legacy' receiving engines need to be able to operate with DMARC without having to convert ot use of the Sender: field.  I tried to find a way to make this work and failed, which is why the current -sender- draft works in parallel to the From: field, rather than taking precedence over it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 10:52:05 2020 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 416CC3A0888 for ; Sat, 15 Aug 2020 10:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 IKPF4NVQK_ZQ for ; Sat, 15 Aug 2020 10:52:02 -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 A96943A088A for ; Sat, 15 Aug 2020 10:52:00 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07FHsfCN017708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Aug 2020 10:54:41 -0700 To: "Kurt Andersen (b)" , Neil Anuskiewicz Cc: "dmarc@ietf.org" , Alessandro Vesely References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0cd7ef9c-a5c8-8014-6ab7-e7a8bfc65b41@dcrocker.net> Date: Sat, 15 Aug 2020 10:51:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 17:52:04 -0000 On 8/13/2020 2:38 PM, Kurt Andersen (b) wrote: > Passing DMARC is not a be-all-end-all. That's what local policy is > for. I fail to see why local policy would not solve your problem (as > described). We tend to use the term 'local policy' to refer to exceptional behavior. (I'm not suggesting you were, but am using your reference to it as an excuse to make this small rant.) Receiving filtering engines do whatever they want.  Always. Always have.  No outside agency or actor or standard affects that fact at all. Rather, outside agencies, actors, and standards merely provide input to that filtering engine. "Local policy" is always and entirely in charge of what happens locally.  Everything else is subservient. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 10:57:51 2020 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 1843F3A089D for ; Sat, 15 Aug 2020 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 9aMCO-_DOJ_M for ; Sat, 15 Aug 2020 10:57:49 -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 328543A089C for ; Sat, 15 Aug 2020 10:57:49 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07FI0Y3m018152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Aug 2020 11:00:34 -0700 To: John Levine , dmarc@ietf.org References: <20200812200907.5D09F1E896D8@ary.local> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <603b1699-6a99-0fc3-3fc8-a037126a7b6e@dcrocker.net> Date: Sat, 15 Aug 2020 10:57:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200812200907.5D09F1E896D8@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 17:57:50 -0000 On 8/12/2020 1:09 PM, John Levine wrote: > Let's work on your Sender draft which doesn't try to change what MUAs display. and which won't fully fix the user-level problems, because... legacy DMARC. Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 11:12:27 2020 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 D757B3A0900 for ; Sat, 15 Aug 2020 11:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 WGedkdN557Yj for ; Sat, 15 Aug 2020 11:12:26 -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 047853A08EE for ; Sat, 15 Aug 2020 11:12:25 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07FIF9Yl020168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Aug 2020 11:15:10 -0700 To: Alessandro Vesely , "Murray S. Kucherawy" Cc: IETF DMARC WG , John Levine , Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> Date: Sat, 15 Aug 2020 11:12:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 18:12:27 -0000 On 8/15/2020 3:32 AM, Alessandro Vesely wrote: > If X pretends to be Y, If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. This continuing practice of characterizing valid use as if it were spoofing or pretending has been a major impediment to constructive discussion in the industry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 12:47:10 2020 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 395843A0C48 for ; Sat, 15 Aug 2020 12:47:08 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=qL9jyqQT; dkim=pass (2048-bit key) header.d=taugh.com header.b=RWlNOsyJ 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 DF7dyDcUJVag for ; Sat, 15 Aug 2020 12:47:07 -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 CFC5F3A0C46 for ; Sat, 15 Aug 2020 12:47:06 -0700 (PDT) Received: (qmail 45716 invoked from network); 15 Aug 2020 19:47:04 -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=b291.5f383bb8.k2008; bh=/D0DkfxpuHMr5LuuF8gVnPi/mRbVHKlc8IvSSudGJSw=; b=qL9jyqQTMa4qRPUBcwR+tsdm9g7kmOl0bFMqtZsWHyQ4GmRUlEaSWg3RbkHqSAzCgHuJ/elr4mcPlISofYEr15/Lmfb2szgDHbE1kEtutBK/BYbOc3XK1C0oIOgFOSFqfuYXbgUP4igJfCIPZ4Iuz+2rJUZjYeqUyU69DTfl7RjM4KrsLRoOdQtm81Od+dxMyWvRbLqjxhOo7/tzg5QQArhb4nvbpM7hJGlNQVJ1QXuTAnuLBJI8UvfjKRY1bY0TpfSLQ+A6E8wEvUVhg4HBONzWKj6JvzrSOAMUv8KieC8bB73KlyaP7Q7K4v4C6JRk7vgGja8ZVBND6XAs7lBHLA== 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=b291.5f383bb8.k2008; bh=/D0DkfxpuHMr5LuuF8gVnPi/mRbVHKlc8IvSSudGJSw=; b=RWlNOsyJIyzDftce341Ym++n5jD1cOHe3zq2n8sRhrbURFANVNCnw6I6dUUVpiYx3IssFYa3XpwpwTc8pgngL+i4Vz8Qt3AHaBk+3ITBcZBfTgRU+jlhn7nyKRsYFZS4ofS7hERBBj74poEZ+W4WhWDATvkqbt+RXtW85p6G4O5u1iWOwDFy7/2ABmtHmlvCExiRJqzWwm4m5KGPNy8Nqbi5ZOM0QM/nGRNI6GsxJ/hIi8nBvBQ7S2VGcirf+rt5mY4kImmV4MU6og6YaGwZ+MaCdtRlUC4RbuXY/cwrK2NPtMVP6aJ4F6kKovTYEf9idpbdmVt3u2B3T+g/78MvPw== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Aug 2020 19:47:03 -0000 Received: by ary.local (Postfix, from userid 501) id 9FC841E9D9DB; Sat, 15 Aug 2020 15:47:03 -0400 (EDT) Date: 15 Aug 2020 15:47:03 -0400 Message-Id: <20200815194703.9FC841E9D9DB@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:47:08 -0000 In article you write: >The premise that MLMs have actually been long-tolerated abusers is a flawed >one, in my opinion. I actually used to think the same thing back in the >RFC 4871 era, but I no longer agree. The same thing happens over and over. Someone invents a mail authentication scheme which works for a lot of mail, but not all mail. Then they roll it out, and its enthusiasts blame the victim as they try to redefine the mail that it doesn't handle as "spoofed" or otherwise illegimate. This happened with SPF, and it's sure happening again with DMARC. Can't wait to see what the next magic bullet aimed at our foot is. R's, John From nobody Sat Aug 15 12:48:52 2020 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 EB3BD3A0C5E for ; Sat, 15 Aug 2020 12:48:50 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=KzkakkeY; dkim=pass (2048-bit key) header.d=taugh.com header.b=rvmTBKLt 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 RsoARZJGtPeX for ; Sat, 15 Aug 2020 12:48:48 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5093A0C5C for ; Sat, 15 Aug 2020 12:48:48 -0700 (PDT) Received: (qmail 45951 invoked from network); 15 Aug 2020 19:48:47 -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=b37d.5f383c1f.k2008; bh=9XwqX/UX+fjXi1x1Ija9lYPMnrPKP881LseMzXRof3Q=; b=KzkakkeYPJNhzybw4Gbw8od72PQKhLUfmi4mWEc+s9JAAm1BzwUgRz4sqHAtXQ01Av5mVHGbIWYOrNV+WHn7cs94vrvCJ/ruP1VCszUT3m+DOIxL22jB0b2B2fxZCd4U53FCBcvpfv+WFy6s5yUjxz/AEMhYQ8RVXIPdGY0gNH3pK3c965OuLOoDlKs9ZcIm7nfrNVZItgdjRaUxRPcaOpybprqoeiq/YwLYGbrTmVH3JpqY5xb9vQ/qjA8uzgMknSNg87TV9GuMDQeWZXXr9VuG6S3oCBF7fwapqFUkDwhxxS6VOwEPkyjaV0E8NivUJjJKtZTOJy6ynpKDoZkr7A== 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=b37d.5f383c1f.k2008; bh=9XwqX/UX+fjXi1x1Ija9lYPMnrPKP881LseMzXRof3Q=; b=rvmTBKLtWpRUDeWldE2fI4mXuQK1mWnesV2UE3odwxHWsT5ELmH7nKZ0lKl2zPr0iXIDdj1vJ+hCaVK5VOnNZvB0WO6woH8R3DpQ6fiqnh6hXkgFGwJiutW2V3AkqnloVq1U3pLmPxm59fohx954MM2lnpt+XBUXLpBGJEw6mTt6GcAnYfhqnpNRhZZFs0gafx6I6lqpn6eaYwsT6B99dfIOWvp1kB/wNyd9wTq+U/Jht7VPO0di6i/Q8ku1pEYm1upV1Kxh0SFXPF0myTnY1rfg1mvg6tpsB2GLu+qb96VN9dAShcBjjpnUOJs9PTJQIn7H9RjRJ078GNALU5VbvQ== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Aug 2020 19:48:47 -0000 Received: by ary.local (Postfix, from userid 501) id 115A81E9D9F2; Sat, 15 Aug 2020 15:48:47 -0400 (EDT) Date: 15 Aug 2020 15:48:47 -0400 Message-Id: <20200815194847.115A81E9D9F2@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <603b1699-6a99-0fc3-3fc8-a037126a7b6e@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:48:51 -0000 In article <603b1699-6a99-0fc3-3fc8-a037126a7b6e@dcrocker.net> you write: >Also, I'm sorry to hear that the wg isn't capable of discussing two >drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year apart. R's, John From nobody Sat Aug 15 13:17:17 2020 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 53F4F3A05AA for ; Sat, 15 Aug 2020 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=Ge33NcPc; dkim=pass (2048-bit key) header.d=taugh.com header.b=CnIsLO4m 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 P2xeeOVz85o6 for ; Sat, 15 Aug 2020 13:17:15 -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 D52B43A0544 for ; Sat, 15 Aug 2020 13:17:14 -0700 (PDT) Received: (qmail 50381 invoked from network); 15 Aug 2020 20:17:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:content-type:content-transfer-encoding:mime-version:subject:references:in-reply-to; s=c4ca.5f3842c9.k2008; i=johnl-iecc.com@submit.iecc.com; bh=F/gs/ZMDMZlomGQVbhRzP28imV0Jj0zkVOKV8ofS138=; b=Ge33NcPc1vxhoHPrdFNsUz3GiTtOUpqVi3vi8yIwtC0Jac7B/wV77O2uqLxFUJJvHHoYmFPU1/PXtyaVDzLRg2aT4iUhQ9a4AQvd02/h9dmFPs7goUBPx6AI4b08hjTCix8x9IsRAO9sr7WSlqcGov3j9Y79eV0fn7SfLA3Zp6yQPcdp67lNbgUa4Vq/vFGjbhPV7Zwj/XI6AYuJclclOH+3fDhQrQd+WbNjljtI9Bckydz67cmzU5zzgQDezvPjvNK5/0QWJ3i1dT1tT+1g9MN+jnOAr6GzjKBrgA94bskDcYPCaUBpCDccbIjTMGiUiwbPN+DOOZc4OZHh70jScg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:content-type:content-transfer-encoding:mime-version:subject:references:in-reply-to; s=c4ca.5f3842c9.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=F/gs/ZMDMZlomGQVbhRzP28imV0Jj0zkVOKV8ofS138=; b=CnIsLO4mMjdp78eM/B/1kq0V6jcOFlNk9MxfHSwMmnLRsIVf2Z6VQKPniVjJiBZFZWEUxW6jo7qWh4ddfeMb/PSEijTAOSVl65f43UFrv+WP11Qxo1Yym03dMIxnjmQa1nigYlRxNGHpkBCPL2I8g12xzRwUBAAhJfAB4FrN1h3t4HZjRi4kKRK+85P+EQMGInjoRaAP250j29HAwrB4jgiu6CdpEzGH/5jQ5w3tK3XWlUDHDDikM3ROy3CtM3/OXNVg54BEULKE/AVviedAas8G0kBzWbwffeBIz3uVQe6WDNwigkg+qYtANts9JPgZ6GCzGewTWjimqujRM5MRCw== Received: from [IPv6:2601:87:4201:3c80:a435:32d4:4f07:2766] ([IPv6:2601:87:4201:3c80:a435:32d4:4f07:2766]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-128-GCM AEAD, johnl@iecc.com) via TCP6; 15 Aug 2020 20:17:12 -0000 Date: 15 Aug 2020 16:17:11 -0400 Message-Id: From: "John Levine" To: dcrocker@bbiw.net Cc: "IETF DMARC WG" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) References: <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> In-Reply-To: <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> X-Mailer: iPad Mail (17G68) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 20:17:16 -0000 Completely agree. Please consider the environment before reading this message. John Levine, johnl@taugh.com=20 > On Aug 15, 2020, at 14:12, Dave Crocker wrote: >=20 > =EF=BB=BFOn 8/15/2020 3:32 AM, Alessandro Vesely wrote: >> If X pretends to be Y, >=20 >=20 > If I put my gmail address into the from field, there is no pretending, no m= atter what platform I am using. >=20 > This continuing practice of characterizing valid use as if it were spoofin= g or pretending has been a major impediment to constructive discussion in th= e industry. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 From nobody Sat Aug 15 13:35:55 2020 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 3357A3A0803 for ; Sat, 15 Aug 2020 13:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 7WCrdlNYFBWH for ; Sat, 15 Aug 2020 13:35:52 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4517A3A07F6 for ; Sat, 15 Aug 2020 13:35:52 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07FKcU5U031263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Aug 2020 13:38:37 -0700 To: John Levine References: <20200815194847.115A81E9D9F2@ary.local> Cc: dmarc@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2f145705-5ca5-4661-9515-1f56bc125d4f@dcrocker.net> Date: Sat, 15 Aug 2020 13:35:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200815194847.115A81E9D9F2@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 20:35:53 -0000 On 8/15/2020 12:48 PM, John Levine wrote: >> Also, I'm sorry to hear that the wg isn't capable of discussing two >> drafts at the same time. > I'm pretty sure that my opinions about -author and -sender would be the same > even if they'd been published a year apart. John -- your response is oddly orthongonal to my comment. My comment was not about your opinion of either of the drafts but of your impatience with considering one you don't like. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 14:09:49 2020 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 B44913A0878; Sat, 15 Aug 2020 14:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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 cyqUY71cnoGI; Sat, 15 Aug 2020 14:09:46 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::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 0B9CF3A0861; Sat, 15 Aug 2020 14:09:46 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id n128so7573898oif.0; Sat, 15 Aug 2020 14:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HDhoFFIxbJge2RpWa3dUQlsvNy2QUJaxyHR99JrHh00=; b=ZEmFD6XnHO4SFyhxV+DgfCFOzJACQzv5TOxwayJQ129UOscsQimKZpCKt78697FANt BsM4iGk69DHMXm3A6awGwGStbkdiZ8+RAwr0H1IVVAx6uL6RygIzTRaUDtk7Oo2tjZrO 5E3txGZiZKrdSYyYm3oENyxs7KZJLFJRguV753cKTPvDbgaS7Js8tiXDi4DUIfUXP+Hl J++63a4E6w2PlKEEXO5t5wNIlDAzATAVR0fVEaMwF/c2XpVksifKe8USK6KyVAeIh+6x 0QnvHa44LGnt18Ors+P+6JOBshmQ1phB9p8wel8V3NTmcHtkEbqIvnY2+hBHT0WWwSrS O//Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HDhoFFIxbJge2RpWa3dUQlsvNy2QUJaxyHR99JrHh00=; b=B+rdSG4SbPLJz4h2EGYJIxo3OQtJAYKC19bbktDyNHoeDSCyqa4PY03yZ5UzgdLcEO U0hLEks9DliPeCgHrsFTqKW+Lx0BbOk7v9Mrd8+3V5887TgXa0o996269ktXltLJrTJc /brYt7L0LUaXr0cwNl98Li035pOmrN1HVE4B28RHUAJvGR0xCcZTrnedgdzqJmEGBcBh pMjKcLmSzcd/pGetCpyezX9DtbQkyLfNTknqFejZdL/oYw+rDOjaaP0zTRqYEDW8qLgC CjmdQfF2CxPFQnMNcho4gQmwkfUdqvpXkEPzbUusE1hxNFmDmitdyhSJI3eLR/FNaLjF YP2w== X-Gm-Message-State: AOAM533c4Z5Mcu2XDdhdTdn301nOvhZ/ZoV+1/S+ycGtAqEAHuQasc6s wpeCNwE2WuVvnUScEM2kzJdjMbg0GHU= X-Google-Smtp-Source: ABdhPJzPe1YfBcmuhyCA+ZEKt7s2UjgGfHBvx+zxtbYCGuQW0dBmKLEiqGji7yJbHhYc6ofgUz2ApA== X-Received: by 2002:a05:6808:601:: with SMTP id y1mr5447748oih.22.1597525785047; Sat, 15 Aug 2020 14:09:45 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:c031:520:d02:47a5? ([2600:1700:a3a0:4c80:c031:520:d02:47a5]) by smtp.gmail.com with ESMTPSA id p189sm2645506oia.18.2020.08.15.14.09.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Aug 2020 14:09:44 -0700 (PDT) To: IETF DMARC WG Cc: dmarc-chairs@ietf.org References: <745030ea-c2e6-16a4-690f-bbb639b9b8b8@bluepopcorn.net> From: Dave Crocker Message-ID: <79557858-26ea-e938-2df9-00ba7c6420d9@gmail.com> Date: Sat, 15 Aug 2020 14:09:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 21:09:48 -0000 > If DMARC wasn't experimental, maybe I could see adding it separately, > but this seems like a fairly fundamental change and shouldn't just be > a bolt-on Without suggesting a preference, it's worth considering nature/implication: 1. Separate    DMARCbis is likely to be small changes on the existing spec and incorporation of something like my draft's changes could  a) destablilize the effort, and b) make the bis effort take significantly longer.  Also, my proposal is a lot more fragile than the base DMARC spec, both in terms of possible technical issue and possible operational issues. 2. Integrated    Merging them makes it more likely that the result really is integrated and seamless. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 15:33:53 2020 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 16C5B3A0A12 for ; Sat, 15 Aug 2020 15:33:52 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9R6NTbeaU9F for ; Sat, 15 Aug 2020 15:33:49 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80FF3A0A06 for ; Sat, 15 Aug 2020 15:33:49 -0700 (PDT) X-ASG-Debug-ID: 1597530827-11fa3136ba105f0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id eOrcQRn7wcbGhTgA (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 15 Aug 2020 18:33:47 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=hZxEvWO592FB0J7n4/hbpu+APSXp52fQf877pz1mEGU=; b=X2jadYDjadKGjy01uc+8lGOnZCzPjwPq9P6/lX1yjgNJ8XGcuTmQw/v3zQhYMN8Em p0OIV7thBA6nnnPYXTg40h0K+l8o9Mac4ceCdOccNMPmpUNQJWhZmh+v7/6km7T2T nqcZeZinK3vxmYSiN39rsD/G0TYzIwKbH3NLZxX9E= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 15 Aug 2020 22:33:38 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field Reply-To: fosterd@bayviewphysicians.com Message-ID: <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=8d84e93a93cd4fe9a5b1282c48016ab4 In-Reply-To: References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> X-Exim-Id: 6755d0cef49e465bbf2bd170dbdc6aa3 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597530827 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 22949 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83922 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 22:33:52 -0000 This is a multipart message in MIME format. --8d84e93a93cd4fe9a5b1282c48016ab4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Based on the discussions here, it appears that the notion of From address v= alidation was envisioned from the beginning Sender Authentication discussio= ns. We have written evidence that Form address validation was anticipate= d in the DKIM and ATPS RFCs prior to DMARC. So we have more than a decad= e of warnings that From address validation was coming. While not everybod= y has time to read every RFC, the Mailing List trade press must have should= have been reporting on it as something to watch. Even after DMARC was in use, it appears that nobody in the mailing list com= munity felt inconvenienced until the AOL/Yahoo hack and their decision to i= mplement DMARC with p=3Dreject. This was the moment of Unhappy Surprise. = Bad guys had obtained many valid email addresses, so one of the concerns= was how to prevent them from spoofing those users to send spam. They cou= ld not use those address in the SMTP address because of SPF, but only DMARC= could prevent those addresses from being misused in the Message From addre= ss. It was the obvious thing to do and it would have been reckless for = them to do otherwise. Can you at least admit that the mailing list commun= ity was surprised because they failed to prepare for this contingency? But that moment is now in the rear view mirror. Mailing lists can get de= livery to all subscribers by confirming to the requirements of the DMARC-pa= rticipating domains, by using their own domain in the From address, at leas= t for those domains. I assume that there are still mailing list operatio= n that are not unable to comply with DMARC-participant expectations, becaus= e they have failed to upgrade. But an individual organization=E2=80=99s f= ailure to adapt is not a problem worthy of a standards body. I liked XP j= ust fine and hated Vista, like Windows7 OK but hated Windows 8. But Micro= soft killed support for XP and Windows 7 and my organization is adapting. = Life is unfair. COVID-19 is unfair and has caused a lot of problems. E= very organization has problems, and we all have jobs so that we can help so= lve them. The time to cry in your beer is over. Mailing lists have a in= teroperability solution, and they should use it whether they like it or not= , because that is what is necessary to get their mail delivered according t= o the requirements of the recipient organization. As a result, mailing l= ist operators really have no standing in this discussion, although they can= certainly speak as unhappy individual users and on behalf of their unhappy= users. Consequently, the real problem before us becomes the existence of users who= are unhappy because the From address on some mail does not meet their pref= erences. I have to ask why that is a problem worthy of a standards body?= I have about 8 different scenarios in my head where a user might be ha= ve unmet expectations with the format of the From address, or might experie= nce mailing list deliverability problems because of the email filtering pol= icy of its domain relative to the addressing practices of his mailing list.= If our requirement is to make every user happy, shall we head down the p= ath of all 8 problems, not just this one? This project was supposed to discuss moving DMARC from informational to sta= ndards track. It has been hijacked by those who, to paraphrase Shakespear= e, =E2=80=9Chave not come to praise DMARC, but to bury it.=E2=80=9D This = has been abetted by the chair=E2=80=99s assertion that we must square a cir= cle =E2=80=93 meet the MLs requirement for them to impersonate without auth= orization while continuing to advance the DMARC requirement to prohibit imp= ersonation without authorization. As part of that hijacking, we have been inundated by Mr. Crocker=E2=80=99s = assertions that the message From Address does not matter. All the years of= theoretical analysis that preceded DMARC and all of the operational succes= s from implementations of DMARC are just wrong, simply because he says so. = Worse yet, he asserts without justification that the message From address= should be unimportant to everybody except mailing list subscribers, for th= e simple reason that the Message From is so very important to his Mailing L= ist subscribers. It is comparable to asserting that the earth is flat, fo= r everyone except astronauts. This is sheer nonsense. More importantly, this discussion has failed to address the actual objectiv= e, which is to solve the asserted Mailing List problem as it relates to AOL= /Yahoo/Verizon. That enterprise does not seem to be involved in this proc= ess, and no one has offered reason why they will be swayed by anything said= here. The strategy seems to be that if we tell these people how stupid = they are, that they will do whatever we tell them they must do, even if the= solution is to weaken security for everyone on the Internet. That is no= t a winning strategy. DMARC has been mandated by at least three national governments,, by a varie= ty of businesses, and by this one consumer-oriented email hosting service. = It is here to stay, and any extensions to the specification will need to = improve security, not weaken it for the benefit of a special interest group= . Instead, we should be anticipating that the U.S. government will begin mand= ating DMARC for its contractors, in phases based on contractor categories. = Simply requiring it for Department of Defense contractors would be suffi= cient to include most of the major research-oriented universities. But ev= ery school that takes student loan payments is also considered a government= contractor, which covers almost all of them. Every branch of state and = local government also feeds from the federal trough, and concerns about ele= ction meddling means that they are likely targets for voluntary or required= implementation of DMARC. Essentially every health care institution is al= so a government contractor, because they take payments from Medicare or Med= icaid, usually both. It is time to begin a discussion rooted in what is feasible, and what is ap= propriate for IETF to undertake. ---------------------------------------- From: "Murray S. Kucherawy" Sent: 8/15/20 5:02 AM To: Alessandro Vesely Cc: IETF DMARC WG , John Levine , Dotzero = Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sende= r Header Field Emphatically hatless: On Sat, Aug 15, 2020 at 12:47 AM Alessandro Vesely wrote: >> Lists have been around a lot longer than DMARC has. That doesn't grant lists any extra right. Others consider current global usage as a priority gauge. This line of thinking has bothered me for a long time. Imagine you're a large soft drink manufacturer. Your delicious, popular pr= oduct is sold in grocery stores the world over, sometimes directly from you= r production line, sometimes via a local reseller. Your sales team does on= e or the other depending on the use case. Business has been good for a gen= eration or two. One day you decide you don't like resellers anymore becaus= e some of them mis-promote your product, so you somehow arrange that the ca= ns in the stores that passed through resellers suddenly and randomly begin = invalidating themselves by bursting, making a mess of the store and soaking= customers. Other products nearby are also ruined. This reflects poorly o= n the resellers, some of whom are forced to stop doing business with you. = Stores get angry and are forced to reconsider doing business with you as we= ll, but you're big and popular and so many of them have to deal with your m= ess on an ongoing basis. Many customers take their business elsewhere; the= stores suffer. The argument here appears to be that is that this is justified, because the= ecosystem of manufacturers, grocery stores, resellers, and customers that = has existed for as long as you can remember has no right to operate that wa= y if you suddenly decide you don't want it to; it's your brand, and your wo= rd about your brand is final irrespective of how you choose to enforce it. = You're suddenly, for reasons you feel are legitimate, asserting that the e= cosystem was broken to begin with despite the fact that you've been a willi= ng participant for decades, and therefore you are at liberty to disrupt it = (though, admittedly, you may have been unaware of the blast radius of doing= so). Now, you may be right that the ecosystem was built on the incorrect premise= that domain names don't need to be treated as sacrosanct. (Let's ignore f= or the moment the stuff about hindsight.) But that assertion clearly diffe= rs from the well-established foundation upon which a great deal rests today= . It is far from trivial to change that now. It's possible to do, to be s= ure, but dropping it into the world overnight has a hugely disruptive impac= t. Such a change needs to be an evolution, with the cooperation and collab= oration of a preponderance of the participants, not a philosophical light s= witch you get to throw and expect everyone else to conform. I don't want any more soda on me. Why people's mailboxes must be spoofable? I don't know about "must", but changing the fundamental assumption that it'= s acceptable in some cases for X to pretend to be Y (which is what MLMs do)= , at X's discretion, is a tectonic change that should have been rolled out = with more community collaboration and grace than it was. I think we need t= o be more considerate of that fact if there is to be progress. Syllogism goes like so: Mailing list must not accept strict DMARC policies, humans may happen to use mailing lists, therefore email domains which hosts mailboxes used by humans must not publish strict DMARC policies. Is that really what we seek? I hope not. It is our current reality, and in my humble opinion, we've nobody to blame = but ourselves. -MSK, participating. --8d84e93a93cd4fe9a5b1282c48016ab4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Based on the dis= cussions here, it appears that the notion of From address validation was en= visioned from the beginning Sender Authentication discussions.    = ;We have written evidence that Form address validation was anticipated in t= he DKIM and ATPS RFCs prior to DMARC.    So we have more than a d= ecade of warnings that From address validation was coming.   While not= everybody has time to read every RFC, the Mailing List trade press must ha= ve should have been reporting on it as something to watch.

Even a= fter DMARC was in use, it appears that nobody in the mailing list community= felt inconvenienced until the AOL/Yahoo hack and their decision to impleme= nt DMARC with p=3Dreject.   This was the moment of Unhappy Surprise. &= nbsp;  Bad guys had obtained many valid email addresses, so one of the= concerns was how to prevent them from spoofing those users to send spam. &= nbsp; They could not use those address in the SMTP address because of SPF, = but only DMARC could prevent those addresses from being misused in the Mess= age From address.     It was the obvious thing to do and it would= have been reckless for them to do otherwise.   Can you at least admit= that the mailing list community was surprised because they failed to prepa= re for this contingency?   

But that moment is now in t= he rear view mirror.    Mailing lists can get delivery to all sub= scribers by confirming to the requirements of the DMARC-participating domai= ns, by using their own domain in the From address, at least for those domai= ns.    I assume that there are still mailing list operation that = are not unable to comply with DMARC-participant expectations, because they = have failed to upgrade.   But an individual organization=E2=80=99s fai= lure to adapt is not a problem worthy of a standards body.   I liked X= P just fine and hated Vista, like Windows7 OK but hated Windows 8.   B= ut Microsoft killed support for XP and Windows 7 and my organization is ada= pting.    Life is unfair.  COVID-19 is unfair and has caused= a lot of problems.   Every organization has problems, and we all have= jobs so that we can help solve them.    The time to cry in your = beer is over.  Mailing lists have a interoperability solution, and the= y should use it whether they like it or not, because that is what is necess= ary to get their mail delivered according to the requirements of the recipi= ent organization.    As a result, mailing list operators really h= ave no standing in this discussion, although they can certainly speak as un= happy individual users and on behalf of their unhappy users.  

Consequently, the real problem before us becomes the existence of users = who are unhappy because the From address on some mail does not meet their p= references.    I have to ask why that is a problem worthy of a st= andards body?     I have about 8 different scenarios in my head w= here a user might be have unmet expectations with the format of the From ad= dress, or might experience mailing list deliverability problems because of = the email filtering policy of its domain relative to the addressing practic= es of his mailing list.   If our requirement is to make every user hap= py, shall we head down the path of all 8 problems, not just this one?

This project was supposed to discuss moving DMARC from informational t= o standards track.   It has been hijacked by those who, to paraphrase = Shakespeare, =E2=80=9Chave not come to praise DMARC, but to bury it.= =E2=80=9D   This has been abetted by the chair=E2=80=99s assertion tha= t we must square a circle =E2=80=93 meet the MLs requirement for them to im= personate without authorization while continuing to advance the DMARC requi= rement to prohibit impersonation without authorization.

As part o= f that hijacking, we have been inundated by Mr. Crocker=E2=80=99s assertion= s that the message From Address does not matter.  All the years of the= oretical analysis that preceded DMARC and all of the operational success fr= om implementations of DMARC are just wrong, simply because he says so. &nbs= p; Worse yet, he asserts without justification that the message From addres= s should be unimportant to everybody except mailing list subscribers, for t= he simple reason that the Message From is so very important to his Mailing = List subscribers.   It is comparable to asserting that the earth is fl= at, for everyone except astronauts.    This is sheer nonsense.

More importantly, this discussion has failed to address the actual = objective, which is to solve the asserted Mailing List problem as it relate= s to AOL/Yahoo/Verizon.   That enterprise does not seem to be involved= in this process, and no one has offered reason why they will be swayed by = anything said here.    The strategy seems to be that if we tell t= hese people how stupid they are, that they will do whatever we tell them th= ey must do, even if the solution is to weaken security for everyone on the = Internet.    That is not a winning strategy.

DMARC has = been mandated by at least three national governments,, by a variety of busi= nesses, and by this one consumer-oriented email hosting service.   It = is here to stay, and any extensions to the specification will need to impro= ve security, not weaken it for the benefit of a special interest group.

=

Instead, we should be anticipating that the U.S. government will beg= in mandating DMARC for its contractors, in phases based on contractor categ= ories.    Simply requiring it for Department of Defense contracto= rs would be sufficient to include most of the major research-oriented unive= rsities.   But every school that takes student loan payments is also c= onsidered a government contractor, which covers almost all of them.   =  Every branch of state and local government also feeds from the federa= l trough, and concerns about election meddling means that they are likely t= argets for voluntary or required implementation of DMARC.   Essentiall= y every health care institution is also a government contractor, because th= ey take payments from Medicare or Medicaid, usually both.

It is t= ime to begin a discussion rooted in what is feasible, and what is appropria= te for IETF to undertake.

 



From: "Murray S. Kucherawy" <superuser@gmail.com>=
Sent: 8/15/20 5:02 AM
To: Alessand= ro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <= dmarc@ietf.org>, John Levine <johnl@taugh.com>, Dotzero <dotzer= o@gmail.com>
Subject: Re: [dmarc-ietf] Call for Adop= tion: DMARC Use of the RFC5322.Sender Header Field
Emphatically hatless:

On Sat, Aug 15, 2020 at = 12:47 AM Alessandro Vesely <vesely@tana.it> wrote:
>> Lists have been arou= nd a lot longer than DMARC has.

That doesn't grant lists any extra r= ight.  Others consider current
global usage as a priority gauge.

This line of thinking has bothered me for a long t= ime.

I= magine you're a large soft drink manufacturer.  Your delicious, popula= r product is sold in grocery stores the world over, sometimes directly from= your production line, sometimes via a local reseller.  Your sales tea= m does one or the other depending on the use case.  Business has been = good for a generation or two.  One day you decide you don't like resel= lers anymore because some of them mis-promote your product, so you somehow = arrange that the cans in the stores that passed through resellers suddenly = and randomly begin invalidating themselves by bursting, making a mess of th= e store and soaking customers.  Other products nearby are also ruined.=   This reflects poorly on the resellers, some of whom are forced to st= op doing business with you.  Stores get angry and are forced to recons= ider doing business with you as well, but you're big and popular and so man= y of them have to deal with your mess on an ongoing basis.  Many custo= mers take their business elsewhere; the stores suffer.

The argument here appears to be that is tha= t this is justified, because the ecosystem of manufacturers, grocery stores= , resellers, and customers that has existed for as long as you can remember= has no right to operate that way if you suddenly decide you don't want it = to; it's your brand, and your word about your brand is final irrespective o= f how you choose to enforce it.  You're suddenly, for reasons you feel= are legitimate, asserting that the ecosystem was broken to begin with desp= ite the fact that you've been a willing participant for decades, and theref= ore you are at liberty to disrupt it (though, admittedly, you may have been= unaware of the blast radius of doing so).

Now, yo= u may be right that the ecosystem was built on the incorrect premise that d= omain names don't need to be treated as sacrosanct.  (Let's ignore for= the moment the stuff about hindsight.)  But that assertion clearly di= ffers from the well-established foundation upon which a great deal rests to= day.  It is far from trivial to change that now.  It's possible t= o do, to be sure, but dropping it into the world overnight has a hugely dis= ruptive impact.  Such a change needs to be an evolution, with the coop= eration and collaboration of a preponderance of the participants, not a phi= losophical light switch you get to throw and expect everyone else to confor= m.

I don't want any more soda on me.

Why people's mailboxes must = be spoofable?

I don't know about "must", bu= t changing the fundamental assumption that it's acceptable in some cases fo= r X to pretend to be Y (which is what MLMs do), at X's discretion, is a tec= tonic change that should have been rolled out with more community collabora= tion and grace than it was.  I think we need to be more considerate of= that fact if there is to be progress.

Syllogism goes like so:  Mailing li= st must not accept strict DMARC
policies, humans may happen to use maili= ng lists, therefore email
domains which hosts mailboxes used by humans m= ust not publish strict
DMARC policies.  Is that really what we seek= ?  I hope not.

It is our current reali= ty, and in my humble opinion, we've nobody to blame but ourselves.

-MSK, participating.
--8d84e93a93cd4fe9a5b1282c48016ab4-- From nobody Sat Aug 15 15:53:26 2020 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 79BBA3A0A92 for ; Sat, 15 Aug 2020 15:53:25 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Qa07CtHA; dkim=pass (2048-bit key) header.d=taugh.com header.b=p8EpBTk0 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 G8u-qtSYNCoL for ; Sat, 15 Aug 2020 15:53:24 -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 C18F63A0A86 for ; Sat, 15 Aug 2020 15:53:09 -0700 (PDT) Received: (qmail 83267 invoked from network); 15 Aug 2020 22:53:07 -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=1453f.5f386753.k2008; bh=Xnj55IkM2feK+r63n/yzPM5sFlm1BQ4Lr+HwlrYMjGU=; b=Qa07CtHAdbQXhGSt4V3oyJCanw9MWM9WV8l2LGSJJlG1b/D81x20tO6271eYiEBIty5TlDUz3V7L420bPExjCwH8zP6KG5JRGAndcakZfBYcqPJkSJu4plEF4y/pLzKBlJ0KpSyEcQNRsKGJZ2jj7m+BWr1vWvC5Elx4UoWwbpXeRj2s6zhyx4MNkJr2VhRhWatUaHaUQRSbXV3ZLqzlz/uGbZoa9FzQm3l3U9b54RRywnikboHR0beajRz7IpLC1qV1Kqolfrfoi2YDQSUiQgM6jSja73dtuSRMMhv6drbKxf74+NM/wJsTdTsWYn4qW1BybUF21fcM+4F190q54Q== 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=1453f.5f386753.k2008; bh=Xnj55IkM2feK+r63n/yzPM5sFlm1BQ4Lr+HwlrYMjGU=; b=p8EpBTk0Rz2dzI8kYPfPqOCgxR3EjgFEAy+iJ9ADod8/5bWU2PNEJKiBGPNcW3G9IJ/8DoODg8JwhiFVw923Mh2foM3e6bmQvPKR4rX4Qe8eodUWua9/WBbE5JBkvv4vGguWavHs1nh2RnoBQ13mt5l/7Gktw7PZrtmYERqXzk7fPFyoAg7IhFrCAalKtw+3p6LQGk2oSn14T5ZGqFj7tJFkjx3/ir/yyxhYiBUEUVa+3ez+aG0xuHS/jvxOneXKdiIi/EeO6XUBvvhenRS0PKdxFEhYINCWgAGTlZWscDLgz5zhnqv/jt/zuX6YXsv0WnE9vor5/SCo6NxJ999Lxg== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Aug 2020 22:53:07 -0000 Received: by ary.local (Postfix, from userid 501) id 967CC1E9E41D; Sat, 15 Aug 2020 18:53:06 -0400 (EDT) Date: 15 Aug 2020 18:53:06 -0400 Message-Id: <20200815225306.967CC1E9E41D@ary.local> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 22:53:26 -0000 In article <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> you write: >Based on the discussions here, it appears that the notion of From address validation was envisioned from the >beginning Sender Authentication discussions. We have written evidence that Form address validation was >anticipated in the DKIM and ATPS RFCs prior to DMARC. Not really. DKIM was deliberately designed not to be tied to any visible part of the message. ADSP was a poorly designed hack that was never implemented other than small experiments, and that I don't think many people understood. I got a lot of grief for making the most strict policy "discardable" even though that's obviously what it was. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Aug 15 15:59:45 2020 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 854DB3A0406 for ; Sat, 15 Aug 2020 15:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=VtgPgc/p; dkim=pass (2048-bit key) header.d=taugh.com header.b=nEwRjcZK 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 Azo7w85aAp40 for ; Sat, 15 Aug 2020 15:59:42 -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 BF5293A03FB for ; Sat, 15 Aug 2020 15:59:41 -0700 (PDT) Received: (qmail 85012 invoked from network); 15 Aug 2020 22:59:40 -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; s=14c12.5f3868dc.k2008; i=johnl-iecc.com@submit.iecc.com; bh=SX2QtuHV6h0O268EsaU6Z3BX6nuP5AAsly/HrWZLvV4=; b=VtgPgc/pF0jLR5rGjTLvN/tI6pVMZ1qWYVC5rQKjKYBtiGQoUKH2qHCOEK1Bw9RGFhiJF4V7GseQ/xdkiPNJocHL+ONo3WrxN8MYbWi8V/1DWHbsC8F96kdPmK4XnVB+m1tNN3yiExwGW07tOIwjzYRDkek0jil1pj/P/PQyJjTgt0PipJFJGV8bvv1MLzlbv4WbR0FvAM3adSDMmTvNMNQJhhmw0FtQNhnj95246RkA8nr3EPXfbJxJthmQaTHzGVM7P1iKXEkxrgmeF9ztGrdbzhErqe/IbRLpWuH5SSxLJKgl/PWq8/PH2h+hL/d2/6/G2jbTlndppiJLjskxAA== 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; s=14c12.5f3868dc.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=SX2QtuHV6h0O268EsaU6Z3BX6nuP5AAsly/HrWZLvV4=; b=nEwRjcZKEHc6LW52i0iN+yjzzBClLwAL8OiYps+LBVjyEnllPR5lDWJnvdWZOvZPeaxTbor7SMwl3QMQRW5hwKY2YteyZgp87EJXfBRH2gPsI76DBmPJayN2vUru6NuPSWcT0iliOv54ni8tJiPkeuxgqgGspyWBiNTLYfEgJA0lQMxxf5ISZIZ4YBE2JqR/U8LqQto62Vki0gAPcJhTJu2ZMUz57BV3AyImRGbK/3QyGaphWCsIPmMbLNmpsd1wlEX36vaLjvwAxDxnPgxUenGXFsH7JwZTXacs9A6PyNWurDYiQ1cjOwBkIifAEEvYD5D3fIBYF8g8C9I1Y+zTOg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 15 Aug 2020 22:59:40 -0000 Date: 15 Aug 2020 18:59:39 -0400 Message-ID: <1e999dc6-955-569a-91fc-a7f2f3ca8e@taugh.com> From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: <2f145705-5ca5-4661-9515-1f56bc125d4f@dcrocker.net> References: <20200815194847.115A81E9D9F2@ary.local> <2f145705-5ca5-4661-9515-1f56bc125d4f@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 22:59:44 -0000 On Sat, 15 Aug 2020, Dave Crocker wrote: > On 8/15/2020 12:48 PM, John Levine wrote: >>> Also, I'm sorry to hear that the wg isn't capable of discussing two >>> drafts at the same time. >> I'm pretty sure that my opinions about -author and -sender would be the >> same even if they'd been published a year apart. > > John -- your response is oddly orthongonal to my comment. > > My comment was not about your opinion of either of the drafts but of your > impatience with considering one you don't like. Um, if one thinks something is a bad idea, why should we spend more time on it? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Aug 15 16:02:16 2020 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 28B783A0406 for ; Sat, 15 Aug 2020 16:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=bbiw.net header.b=0z5jrFwr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lGmjOeNN 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 Tc6-dPML5D7r for ; Sat, 15 Aug 2020 16:02:13 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E9C3A03FB for ; Sat, 15 Aug 2020 16:02:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E1EED5C00AB; Sat, 15 Aug 2020 19:02:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 15 Aug 2020 19:02:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=g TAQxDzUy6JKMFh101sVlQFXmhbrdVwyCtlsQ2OUHOI=; b=0z5jrFwro/Hu5H29Z MWmNmQtwE39xOhsL/4bNdEMDr1y01p1ZMBUucqu/T/dY2PQkuhVE3dXtdNp6l2Xf gGUJNh1Yd5FE21exRc1mkAuVzhfOPFhJ3WfoH7sici1LQsYUG1pL3mWlBbZW4A7K NMa2THd8UVh7g5/6Pb+3cyrhb3UoSF3ZcmP1y3wdTZlZIB9HJKJiM1B1NOohbdQN XAWUv3lvsVx0D7UOpkarf6zaSZgTmiQsJxsM052FT4Ww34SZi+eHFKrGDQg8z5zc If5oujWldbjp3jBKXMKPaZxXpO3lVH5HMKHw/QEaQuZgMhlmpYWaO+89GvsZAJqB bsVnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=gTAQxDzUy6JKMFh101sVlQFXmhbrdVwyCtlsQ2OUH OI=; b=lGmjOeNNEROM/mTyn4ItyD90Iwulp230SSCiUutQcMx+i0forTQuuaHAd oi0M27jR37iIiP3o5JIkbAGioUpcxo3VPyMPYXcgExvh2FWA1/eXd6atFXyKvjRT Su74iIm5r0UDFQGHEYggV3DgDOfzJucnvkgbyZVg5KV575KptCBQdtwlRzGloPZN aOIEp8gIKBPV5PA1OT2wLnfXhSisApFN+7bf6QcTpVVPTgJq7ywuk7m0SloyOukc MfrAuUKs7AzIzPljmpIIvh+2L5s3Y8m0IVze+83Zde9RMmEWZZAh/9ASPTBOroUA rj2oxyAbgWb/NYI6p4iEDL3LXHhlA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddttddgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeffrghv vgcuvehrohgtkhgvrhcuoegutghrohgtkhgvrhessggsihifrdhnvghtqeenucggtffrrg htthgvrhhnpeeihfdvuefgjeekffdthfelveelteevfeegteefgeetjeejudejueegheef hefgieenucffohhmrghinhepsggsihifrdhnvghtnecukfhppedutdekrddvvdeirdduie dvrdeifeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegutghrohgtkhgvrhessggsihifrdhnvght X-ME-Proxy: Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 6587F328005A; Sat, 15 Aug 2020 19:02:11 -0400 (EDT) To: John R Levine Cc: dmarc@ietf.org References: <20200815194847.115A81E9D9F2@ary.local> <2f145705-5ca5-4661-9515-1f56bc125d4f@dcrocker.net> <1e999dc6-955-569a-91fc-a7f2f3ca8e@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <53988f5a-d95f-f459-0040-42d4f8c532d8@bbiw.net> Date: Sat, 15 Aug 2020 16:02:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <1e999dc6-955-569a-91fc-a7f2f3ca8e@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 23:02:14 -0000 On 8/15/2020 3:59 PM, John R Levine wrote: > On Sat, 15 Aug 2020, Dave Crocker wrote: >> My comment was not about your opinion of either of the drafts but of >> your impatience with considering one you don't like. > > Um, if one thinks something is a bad idea, why should we spend more time > on it? Out of respect for others who might disagree with you and others who might not have formed their opinion yet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 16:36:52 2020 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 A30993A0B2F for ; Sat, 15 Aug 2020 16:36:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JPV9uBxLiy2 for ; Sat, 15 Aug 2020 16:36:49 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E283A0B2A for ; Sat, 15 Aug 2020 16:36:48 -0700 (PDT) X-ASG-Debug-ID: 1597534607-11fa3136ba10930001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id hZfi7FtzuZrnvo4F (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 15 Aug 2020 19:36:47 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=yvgyrn5fos5YVX6MqAmmDjD69KpJBmZ/6QffHyygNEM=; b=gwrg0Absc7jHARI8ou8lhya0Jxk/EwKDfm9nP9i+V2T+XaUNUkj6bY3A9eqH6mYFd y8pJq13JrMfTlpkQrdMfsfggOgsTB6f0PWWs5a7tha/ZfUiodx8e6HoS8/Du/Xao2 EUPF2f40u5ktfx1MaKHR7ckMNRoK9CcFN5bfQrdN8= From: "Douglas E. Foster" To: Date: Sat, 15 Aug 2020 23:36:40 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=e42fb6f5f6824bc1aa19704b4034ef56 In-Reply-To: <20200815225306.967CC1E9E41D@ary.local> References: <20200815225306.967CC1E9E41D@ary.local> X-Exim-Id: c45b61d902e04be48abe3a4bede67692 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597534607 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4206 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83923 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M Custom Rule 7568M Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 23:36:51 -0000 This is a multipart message in MIME format. --e42fb6f5f6824bc1aa19704b4034ef56 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My comments about From validation were based on the wording of the RFCs, so= I stand by what I said. But are your really arguing that no one in the Mailing List business paid a= ttention to the concerns about the fraud and spoofing problems with email? This morning I had a conversation with the CEO of a company that was hit by= ransomware which arrived with the help of a single email. He is slowly g= etting his company back after paying a lot of money to people who want to d= estroy us. That is the problem we should be worried about. And that is why I am lett= ing my emotions show. This WG is playing the fiddle while Rome burns. Doug ---------------------------------------- From: "John Levine" Sent: 8/15/20 6:53 PM To: dmarc@ietf.org Cc: fosterd@bayviewphysicians.com Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sende= r Header Field In article <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> you wri= te: >Based on the discussions here, it appears that the notion of From address = validation was envisioned from the >beginning Sender Authentication discussions. We have written evidence that= Form address validation was >anticipated in the DKIM and ATPS RFCs prior to DMARC. Not really. DKIM was deliberately designed not to be tied to any visible part of the message. ADSP was a poorly designed hack that was never implemented other than small experiments, and that I don't think many people understood. I got a lot of grief for making the most strict policy "discardable" even though that's obviously what it was. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dumm= ies", Please consider the environment before reading this e-mail. https://jl.ly --e42fb6f5f6824bc1aa19704b4034ef56 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
My comments about = >From validation were based on the wording of the RFCs, so I stand by what I= said.
 
But are your really arguing that no one i= n the Mailing List business paid attention to the concerns about the fraud = and spoofing problems with email?

This morning I h= ad a conversation with the CEO of a company that was hit by ransomware whic= h arrived with the help of a single email.   He is slowly getting his = company back after paying a lot of money to people who want to destroy us.<= /div>

That is the problem we should be worried about. &n= bsp; And that is why I am letting my emotions show.  This WG is playin= g the fiddle while Rome burns.

Doug

=

From: "John Levine" <johnl@taugh= .com>
Sent: 8/15/20 6:53 PM
To: = dmarc@ietf.org
Cc: fosterd@bayviewphysicians.com
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the= RFC5322.Sender Header Field
In article <6755d0cef49e46= 5bbf2bd170dbdc6aa3@bayviewphysicians.com> you write:
>Based= on the discussions here, it appears that the notion of From address valida= tion was envisioned from the
>beginning Sender Authentication = discussions. We have written evidence that Form address validation was
>anticipated in the DKIM and ATPS RFCs prior to DMARC.
<= br>
Not really. DKIM was deliberately designed not to be tied to = any
visible part of the message. ADSP was a poorly designed hack = that was
never implemented other than small experiments, and that= I don't think
many people understood. I got a lot of grief for m= aking the most
strict policy "discardable" even though that's obv= iously what it was.

R's,
John
= --
Regards,
John Levine, johnl@taugh.com, Primary Perpe= trator of "The Internet for Dummies",
Please consider the environ= ment before reading this e-mail. https://jl.ly

--e42fb6f5f6824bc1aa19704b4034ef56-- From nobody Sat Aug 15 16:56:12 2020 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 AAC283A0B2F for ; Sat, 15 Aug 2020 16:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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 FSVGGun6ctoo for ; Sat, 15 Aug 2020 16:56:09 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED1C3A0A7D for ; Sat, 15 Aug 2020 16:56:09 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id l84so11592707oig.10 for ; Sat, 15 Aug 2020 16:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=aGZPHvZ+R/tKLDMPvUlxwrExz8Z16PZiKaw+lAJtzQA=; b=sXdt/j/nr7PWroMiZDIPdHis54Ld3a0s/12IZynkh8MHCX5KjLb2fhreE4zPhgt/Rp I8LNkRe96CYp3I26O4EuJa3mDW+XT2/hUJHgAoNFbCzLW3OblHrsbx4TPGWPYGUoW8zR oALRVEptinH7G/8PKSfWCrLLAYbRVu0JSPr3WOBr7NFNNMl1DhnShJEC+DRmDpl9Vb7H V2/EgiCoOj2jvIZ0Y12lRomRnEZvcw0zs1Nnpl+KwYUT7ntmlTrfVBLozl9htn828k5O lc5MX+wAwL9q0dcQBnLi7pChrxaU3h4IPUXI1bcq2OtElsVskv6XbGSCAqX0/qk2x+/3 /hSg== 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-transfer-encoding :content-language; bh=aGZPHvZ+R/tKLDMPvUlxwrExz8Z16PZiKaw+lAJtzQA=; b=cjdl7Qfzitq/7pvsWaUX3dYLZFHRjhKhImey87ezT9mChgenzG7B1Y7igcnhVSNPck 4Zk4UuxxLIAJmXNKX9EPvbFSUYG4Dv4nIgQUuzw6KPlhOYIAqlUZyFy3RP0CGYkBfCth 94qpTvimS+UIioZQwNO2ufAyuM6imdu01DHSVwfN40gwbIZZhoug3XC05PdmBDnP+riJ n2NJ9/h/+Y4+BZjVLBAzmCY550ihdDm+Yg5xUSf5JglbIQ26qgjJLm+XF0xv2/A2U8NY H5SkLRWurWKE7w4vmnrHIDcc+3bGbh4AaUumKnUnHs26DVPs/HhEZKLTpDJgde+ZHr6R Od/g== X-Gm-Message-State: AOAM53110fZS63L7vE7b9b2B6EgqujsOAzxX2wgQfWGzPyseEUY3+Pg8 7lMs5it/3CP1Y3+y6tnPuuEZg7r1hKY= X-Google-Smtp-Source: ABdhPJyBiDem1UawLMGIexSUCsZTkSrpDOcM3p5WVVKdlzJsNlxbnowcj6bHiGxih7/R1zQXXwYDkQ== X-Received: by 2002:aca:3081:: with SMTP id w123mr5348348oiw.132.1597535768586; Sat, 15 Aug 2020 16:56:08 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:c031:520:d02:47a5? ([2600:1700:a3a0:4c80:c031:520:d02:47a5]) by smtp.gmail.com with ESMTPSA id a187sm2548375ooc.19.2020.08.15.16.56.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Aug 2020 16:56:07 -0700 (PDT) To: fosterd@bayviewphysicians.com, "dmarc@ietf.org" References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> From: Dave Crocker Message-ID: <2796ddee-53c3-3db9-f147-37412fd8b0d1@gmail.com> Date: Sat, 15 Aug 2020 16:56:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 23:56:11 -0000 On 8/15/2020 3:33 PM, Douglas E. Foster wrote: > Consequently, the real problem before us becomes the existence of > users who are unhappy because the From address on some mail does not > meet their preferences.    I have to ask why that is a problem worthy > of a standards body? Who, exactly, do you think these services are /for/? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 15 19:19:04 2020 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 534803A0B91 for ; Sat, 15 Aug 2020 19:19:02 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=JFT8Q+Iw; dkim=pass (2048-bit key) header.d=taugh.com header.b=Lu2/cIDu 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 2czvvtVo4Q8z for ; Sat, 15 Aug 2020 19:19:00 -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 883363A0B65 for ; Sat, 15 Aug 2020 19:19:00 -0700 (PDT) Received: (qmail 16726 invoked from network); 16 Aug 2020 02:18:57 -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=4154.5f389791.k2008; bh=iSWAb8dYLgoVqmOwrFYPgazw3B1UatM7QAAtIRLezEI=; b=JFT8Q+IwX3olASk3b4avmYRlX1wiqfF2fZJpyGWh0fm+Zk3hprdyFxyYsiIgaxH+erRgpCtbQItva8FQxecr/QljK9WHtTY4KNetKpxb/s54uR24hjMrHiNGK/vB9aF8zbSzcvB4K1rIw/P49yCwUZjinHg9FZP6rS7d4MTF0cA+KjGXee18U2ujl+rr4ccTLzISear9JtIpLSnvyh+1V+BAJQbk8oZJUb4bhwNcySjMKyjFR8iRYjZVjFtBgbAaz4wxHM5eGz+w6k+7hjFlfMoERCz4SUZp6tcF4mKXxpA7ay/W/lVyYOmXvAR/3mhfGjkk+1/a/L1ShDPSKV/mog== 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=4154.5f389791.k2008; bh=iSWAb8dYLgoVqmOwrFYPgazw3B1UatM7QAAtIRLezEI=; b=Lu2/cIDuUCOVFkUcWe2RZZpB8T67FOrSyLeQOiLSo7mEyECmY1c1dCwsfNUxGPDBzF/JJtMNwytPzZXIOQwaSHpPn0NI7tiKUKYOxOz4xw6KmfDCXBCMLM8Rh8y0/nZdUerZM99Ur6PeASbsM4rfGoT80k7w4oKNGLxc8L6m1dvj+USD+9urkMlJ8XGpnThgt8hWmt4pvP+Cu/T1B0gB1WSCeg1wLYqnh+vHxClJhVfg5kwIOHoMwRZKVqW0W4KYbVQOewEVxazGfvaSQ79iMdib1M+r+v4bgVCWXdLJG18RBu+Kpgqf3j376En3pNku67N/OR+4gNBEyyxI380nXQ== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Aug 2020 02:18:57 -0000 Received: by ary.local (Postfix, from userid 501) id 9FADE1E9EE5F; Sat, 15 Aug 2020 22:18:56 -0400 (EDT) Date: 15 Aug 2020 22:18:56 -0400 Message-Id: <20200816021856.9FADE1E9EE5F@ary.local> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 02:19:02 -0000 In article you write: >-=-=-=-=-=- >But are your really arguing that no one in the Mailing List business paid attention to > the concerns about the fraud and spoofing problems with email? I am unaware of any mailing lists causing fraud and spoofing problems in email, so no more than anyone else. (Sending along real mail in ways that DMARC cannot describe is neither fraud nor spoofing, of course.) >This morning I had a conversation with the CEO of a company that was hit by ransomware which arrived with the help of a >single email. He is slowly getting his company back after paying a lot of money to people who want to destroy us. I think you would be dismayed how little of that would be stopped by more stringent DMARC policies. They use lookalike addresses, or they depend on MUAs that show the From header comments rather than the addresses. I once saw a very slick spear phish where the crook registered the victim's domain name subsituting "rn" for "m". R's, John PS: >My comments about From validation were based on the wording of the RFCs, so I stand by what I said. I hope you will forgive me if I do not accept your interpretation of RFCs that I wrote. From nobody Sun Aug 16 01:23:55 2020 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 2883A3A0884 for ; Sun, 16 Aug 2020 01:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 nS8CrZeBhA8T for ; Sun, 16 Aug 2020 01:23:52 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 B41713A087F for ; Sun, 16 Aug 2020 01:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597566228; bh=SXUdUHsfp/Ve7rQkUHv0THfE0xSyr/L+ZWJq0H6qtwo=; l=1367; h=To:Cc:References:From:Date:In-Reply-To; b=DNgsmWkvyMR0mJ9fqW8M0/804Ant6aHTcVeMtLL0flcWYSvsOD/jpsV0TRMBi9Xph +wwYClKD6mtVMPS62oDeL/VLNZ4fG0RpdU1nLX87S06WLw/vgUwKWyIVa42miFP60W xpHCqmBZ34ZlWzf4OuT/RmYihjR0//SQjOpHRmtySwSfXA7BzgHeeT9oyjfE+ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F38ED13.00000AE9; Sun, 16 Aug 2020 10:23:47 +0200 To: dcrocker@bbiw.net Cc: "Murray S. Kucherawy" , IETF DMARC WG , John Levine , Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> From: Alessandro Vesely Message-ID: <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> Date: Sun, 16 Aug 2020 10:23:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 08:23:54 -0000 On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32 AM, Alessandro Vesely wrote: >> If X pretends to be Y, > > > If I put my gmail address into the from field, there is no pretending, > no matter what platform I am using. That conflicts with the coarse-grained authentication strategy, established at the FTC Email Authentication Summit in November 2004, as Doug recalled. Your gmail address needs to be authenticated by gmail. Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and whitelisted as yet another domain (songbird.com) can hardly be verified. There is no "pretending", since it's you, but it is not formally distinguishable from spoof, is it? > This continuing practice of characterizing valid use as if it were > spoofing or pretending has been a major impediment to constructive > discussion in the industry. A system that is able to recognize all your domains and affiliations in order to authenticate messages does cost several orders of magnitude more than a simple "mechanical" verifier. That way, requiring too much flexibility is a push toward oligopoly. Of course, the alternative is to keep email as a casual, unreliable, unofficial means of communication. I'm not sure the latter is realistic, given current trends. Are we sticking our heads in the sand? Best Ale -- From nobody Sun Aug 16 02:41:33 2020 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 4171D3A0A3F for ; Sun, 16 Aug 2020 02:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 HPChYoqMl_gi for ; Sun, 16 Aug 2020 02:41:30 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2D76C3A0A12 for ; Sun, 16 Aug 2020 02:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597570886; bh=6IPl1nJM1yfAYs2z3iJRG4+G9eB0QlY1sClmIljbr+k=; l=173; h=From:To:Cc:References:Date:In-Reply-To; b=BehpVv/leUhKagDvvfZdWXgW6qpaOlqA/+TziM4b0/1hlVFzgK8nV+DPQ5NDkGcSz C9v5SbFvKAA8glCOQlVk68X40sADw3duSkFCvGyUoAKukAYDFEIes1oeAFtdLQksRg F5ye96KhphvHkKw/goghsC5DTKgCr7fngKNL4HRG31iuIsJfJDI7Juz7xgIL9 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F38FF46.00001252; Sun, 16 Aug 2020 11:41:26 +0200 From: Alessandro Vesely To: dcrocker@bbiw.net Cc: John Levine , IETF DMARC WG , "Murray S. Kucherawy" , Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> Message-ID: <4e298568-6ba3-0f71-9999-d4b4e1b2654c@tana.it> Date: Sun, 16 Aug 2020 11:41:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 09:41:31 -0000 On Sun 16/Aug/2020 10:23:45 +0200 I wrote: > FTC Email Authentication Summit in November 2004, as Doug recalled. Sorry, of course I meant Michael. Best Ale -- From nobody Sun Aug 16 03:15:11 2020 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 9D4383A0B29 for ; Sun, 16 Aug 2020 03:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 tyrfyZRtwf1K for ; Sun, 16 Aug 2020 03:15:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2DC2A3A0B23 for ; Sun, 16 Aug 2020 03:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597572905; bh=oPwI+trL2d65QvaPPufJSMbOVLU0D1ctpV2wK+LBrP4=; l=1000; h=To:References:From:Date:In-Reply-To; b=BBjl3UyzfNWmPY8iXQMVYATo9ap7Vn5pYIIEFCffcX74tILWKiT3Hp7bco2ocVX/P PzJ8VcoGEZUtIqiCg5YmHB2d1UR7Y4PHTf4seaqKjXeVb6AJkuqhYpQkig5fVya3yx +qnc0ib9jqtVXbXZEfB6T4fikZQCGar7vPJrqepM/AGBASU83CUvYfGeGu8oT Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F390729.0000161E; Sun, 16 Aug 2020 12:15:05 +0200 To: dmarc@ietf.org References: <20200816021856.9FADE1E9EE5F@ary.local> From: Alessandro Vesely Message-ID: <93f9236b-7b61-2466-8076-4b6f25bdb823@tana.it> Date: Sun, 16 Aug 2020 12:15:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200816021856.9FADE1E9EE5F@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 10:15:11 -0000 On Sun 16/Aug/2020 04:18:56 +0200 John Levine wrote: > In article you write: > >> This morning I had a conversation with the CEO of a company that >> was hit by ransomware which arrived with the help of a single >> email. He is slowly getting his company back after paying a lot >> of money to people who want to destroy us. > > I think you would be dismayed how little of that would be stopped > by more stringent DMARC policies. They use lookalike addresses, or > they depend on MUAs that show the From header comments rather than > the addresses. I once saw a very slick spear phish where the crook > registered the victim's domain name substituting "rn" for "m". Lookalike domains are also being addressed by browser developers. It is the obvious next-thing-to-do. Those algorithms could be ported to MUAs, except that it's pretty useless to seal the windows when the roof is still under construction. Best Ale -- From nobody Sun Aug 16 08:32:00 2020 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 16F083A0CFB for ; Sun, 16 Aug 2020 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 evAkMliBqtci for ; Sun, 16 Aug 2020 08:31:57 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77613A0CFA for ; Sun, 16 Aug 2020 08:31:55 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07GFYd8I011480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 16 Aug 2020 08:34:39 -0700 To: Alessandro Vesely Cc: John Levine , IETF DMARC WG , "Murray S. Kucherawy" , Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 16 Aug 2020 08:31:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 15:31:59 -0000 On 8/16/2020 1:23 AM, Alessandro Vesely wrote: > On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32 > AM, Alessandro Vesely wrote: > >>> If X pretends to be Y, >> >> >> If I put my gmail address into the from field, there is no pretending, >> no matter what platform I am using. > > > That conflicts with the coarse-grained authentication strategy, > established at the FTC Email Authentication Summit in November 2004, as 1. I was making a semantic point, not a technical or technical policy one. 2. There was nothing 'established' at that event. There were interesting discussions, but that's all. 3. I'm not finding the reference in any of Doug's notes that your are relying on. Please be specific about it. > Doug recalled.  Your gmail address needs to be authenticated by gmail. Good grief, no. There is no system rule to that effect. DMARC created that, but no policy before it was in place, nevermind accepted. > Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and > whitelisted as yet another domain (songbird.com) can hardly be > verified.  There is no "pretending", since it's you, but it is not > formally distinguishable from spoof, is it? Whether valid and invalid uses can be distinguished does not alter the fact that valid uses are valid. >> This continuing practice of characterizing valid use as if it were >> spoofing or pretending has been a major impediment to constructive >> discussion in the industry. > > A system that is able to recognize all your domains and affiliations in > order to authenticate messages does cost several orders of magnitude > more than a simple "mechanical" verifier.  That way, requiring too much > flexibility is a push toward oligopoly. I have no idea what you are referring it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 16 08:44:22 2020 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 6D30E3A0D1E for ; Sun, 16 Aug 2020 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=RHXFDeHf; dkim=pass (2048-bit key) header.d=taugh.com header.b=Hc2vy7Mj 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 GVDlxPOIkZnt for ; Sun, 16 Aug 2020 08: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 549C73A0D1C for ; Sun, 16 Aug 2020 08:44:18 -0700 (PDT) Received: (qmail 52837 invoked from network); 16 Aug 2020 15:44:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=ce60.5f395451.k2008; i=johnl-iecc.com@submit.iecc.com; bh=tw6jtCryJNJ9abPi+dYPRVaQUpr6EHk+xNuOsQwryDQ=; b=RHXFDeHfLrMoynD2Jy8tJwRkuMoQZ/iSQenNRIgVvaiX0DLwCTcGVGjN0FWtO4X96joE/h7FbORWWAoXRpfc/nCHnu8Mz0p7tNrlhm97UGM71HYS838nSk5ZPZygNU3wNb1DWd70pXxtcvXqcuuYOeBuDrvydLwG7BwR3bu4Dzdm0QOck7zgrV+gXbgXo7p5kUuHQO4iFcTHAi0rWy2qppByYv9/wDzjnYY69XW+Fwo3b4eP8i8+tNb43urrA6Cwn1xgwDpnK7DmsooW1oOUtypNbPEaLPwG7ZTihEQXxXOktSvtiYH/2krTVVhVmU3zkVHTiiKVTIm2BY6k2OXGvw== 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; s=ce60.5f395451.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=tw6jtCryJNJ9abPi+dYPRVaQUpr6EHk+xNuOsQwryDQ=; b=Hc2vy7Mj1zyS5sluoeK0kNLMUlq09c15GVLdg//gt9JCjujfaJKWgaFFrHtFT5y/Uy1GpVw3rehBj1P4HzgybwvRkc0nre+FvBP1hBJJiLG/pXU50BAAzUq3MdEuFfDfmHGdN0DmGv5iSgjii2fOTC80s0Zcfa4n11i3XyIZaqPesmuWoThXPO9euIw96ti/vmiExeajKeixUiWFRK7a8zhCg5kftR5lVfNJxVZ8tbJDWt0xGuuQL2DtdBKU2pIIFCPF/0dwgr8sCtlNsN8iKugwFigHN7kEk6qfrrCghj27T+VjSW4ZpEeDwjKngTdGZaIJYEFs9ztHUYMt46u1RA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 16 Aug 2020 15:44:16 -0000 Date: 16 Aug 2020 11:44:16 -0400 Message-ID: <5abe3867-f427-1d54-7abe-6c5715a893b7@taugh.com> From: "John R Levine" To: "Alessandro Vesely" Cc: "IETF DMARC WG" In-Reply-To: <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 15:44:21 -0000 >> If I put my gmail address into the from field, there is no pretending, no >> matter what platform I am using. > > That conflicts with the coarse-grained authentication strategy, established > at the FTC Email Authentication Summit in November 2004, ... No, it doesn't. It probably won't surprise you to hear that several of us were there. The FTC wanted a way to reliably associate a domain name with a message, and they gave SPF and Domainkeys and Sender-ID as examples. The IETF later published SPF and DKIM (which is a tweaked version of Domainkeys), as standard track RFCs each of which associate a domain name with a message. They all use a domain name in different places in the message; only Sender-ID used the From header address, and even then only if there was no Sender, or Resent-From, or Resent-Sender. (That was the infamous PRA patent.) It wasn't until DMARC came along that anything formalized the unfortunate misapprehension that the From header address is the only "real" identity. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Aug 16 08:47:36 2020 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 36F493A0D29 for ; Sun, 16 Aug 2020 08:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 RRj27Z4L4EqO for ; Sun, 16 Aug 2020 08:47:33 -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 063C03A0D25 for ; Sun, 16 Aug 2020 08:47:32 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07GFoH04013071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 16 Aug 2020 08:50:18 -0700 To: Dotzero , Alessandro Vesely Cc: IETF DMARC WG References: <20200810172411.A13681E7CD8B@ary.local> <10d4cb3b-baf5-0bfc-6160-70db96b9f0d1@tana.it> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <6abec496-479f-a9e0-1f66-786af53c161c@dcrocker.net> Date: Sun, 16 Aug 2020 08:47:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3F7E4BD89A6A1670FC025C78" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 15:47:34 -0000 This is a multi-part message in MIME format. --------------3F7E4BD89A6A1670FC025C78 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/2020 7:12 AM, Dotzero wrote: >       At that time there were also folks pushing for PGP, GPG, > Personal Certificate and  S/MIME as  paths forward. There was, by then, a long history of these failing to scale. > Even with that, it took a while for industry efforts to gain some > sense of clarity. Notice that the general path forward was basically > domain based and not individual user/client based. SPF and DomainKey were informal, spontaneous, private efforts. They established their viability long before reaching a standards venue.  So there was no 'policy' 'decision' to make this approach. > There was a debate within the DKIM effort regarding i= vs d= to the > extent that at one industry event people were walking around with > little stickers on their badges to indicate which they supported. I > believe that was courtesy of Dave Crocker. This was a follow-on issue after DKIM was initially published. We realized that the spec said that DKIM's goal was to provide an identifier, but then it didn't specify which one to use, the one in the i= parameter or the one in the d=.  (Note that neither of these was requirement to correlate with any other identifier in the message. The IETF working group debate about this was intense and was not converging on a choice. One of the early arrivals to the meeting walked through the hotel's entrance, saw me, and said "d= or i=?" and I realized we could have some fun both promoting the issue at this industry trade event, and possibly get some constructive discussion.  The meeting staff were helpful in provide sticky dots to use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------3F7E4BD89A6A1670FC025C78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/14/2020 7:12 AM, Dotzero wrote:
      At that time there were also folks pushing for PGP, GPG, Personal Certificate and  S/MIME as  paths forward.

There was, by then, a long history of these failing to scale.


Even with that, it took a while for industry efforts to gain some sense of clarity. Notice that the general path forward was basically domain based and not individual user/client based.

SPF and DomainKey were informal, spontaneous, private efforts.  They established their viability long before reaching a standards venue.  So there was no 'policy' 'decision' to make this approach.


There was a debate within the DKIM effort regarding i= vs d= to the extent that at one industry event people were walking around with little stickers on their badges to indicate which they supported. I believe that was courtesy of Dave Crocker.

This was a follow-on issue after DKIM was initially published.  We realized that the spec said that DKIM's goal was to provide an identifier, but then it didn't specify which one to use, the one in the i= parameter or the one in the d=.  (Note that neither of these was requirement to correlate with any other identifier in the message.

The IETF working group debate about this was intense and was not converging on a choice. One of the early arrivals to the meeting walked through the hotel's entrance, saw me, and said "d= or i=?" and I realized we could have some fun both promoting the issue at this industry trade event, and possibly get some constructive discussion.  The meeting staff were helpful in provide sticky dots to use.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------3F7E4BD89A6A1670FC025C78-- From nobody Sun Aug 16 10:19:06 2020 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 597623A080C for ; Sun, 16 Aug 2020 10:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.949, 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=isdg.net header.b=a8auzpmJ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=MoKSF3nq 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 Mbe3Zq5ALqqB for ; Sun, 16 Aug 2020 10:19:03 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (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 313BE3A058F for ; Sun, 16 Aug 2020 10:19:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3602; t=1597598335; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=+FXQI5qwZb7bTSB1sFk0IcT+GsU=; b=a8auzpmJtnpgH6gRR3Jerg+vcpz/W3MA4fD5mxBdO5u8enE8RWCQgw8y2By+5Y LOTHnrPcUz6MA0HFuM0mVaaeaAZEImIyY2dFvML+spXELeKF+GM3NHPgK84svEXD XoV6rrHqY1tN3ADwDRwJo0XKN9PhJ+rmM8iKf7iPTp4sY= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 16 Aug 2020 13:18:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 4030608095.1.7088; Sun, 16 Aug 2020 13:18:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3602; t=1597598187; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ed+Rw2/ SEa/nfz04Z8UNhLgRtmo7vK0Dg9fI/ZVhcQ0=; b=MoKSF3nqHEBV1YczspfBlnP XN4CaceIo/z9Szn0bzsO1QZQyc74eh4C3/5GfFO6uHoEWeONaAEirGDZ+xjrZ91A Bz+sjLABVRK0x7Njj7flaNGk/qjB9+5TFVH4JvUcj8nvi4vT+1+FFg+Q9EsRwcX6 ZI8+sydbBblDEfB3p05o= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sun, 16 Aug 2020 13:16:27 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3741362203.1.79424; Sun, 16 Aug 2020 13:16:26 -0400 Message-ID: <5F396A77.3000109@isdg.net> Date: Sun, 16 Aug 2020 13:18:47 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 17:19:05 -0000 On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote: > On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker > wrote: > > > We have had a lot of attempts at third-party authorization schemes > ..... > > With this in mind, I cannot see any point in designing yet another > > vouching or authorization scheme unless we have evidence that an > > interesting fraction of the world's mail systems want to use it. I > > don't see that, and honestly see no chance that we ever will. > > +1 > > > I'm disappointed that the experiment never really got its day in > court, +1 and I want to give you credit for trying. Without you, I might have been long gone from the DKIM project WGs. So I thank you for keeping it interesting, but.... > but the consensus is clear. +1. Here I have to disagree. I don't ask anyone to agree with me but to understand my viewpoint as a long time participant and advocate of the DKIM Policy Model. Early on, we had limited policy proponents. But not today. I have a different viewpoint, a viewpoint that really that was blocked by the two controlling cogs who had DKIM interest else where, namely Levine, Crocker. Crocker has been more open ended. Not Levine. Since day 0, Levine never liked policy and to his credit, he admitted it as much. He killed SSP with the "poison pill" (crippled draft) ADSP replacement he knew would never make it pass LC. Levine was always for the 3rd party trust/list signer idea - never a 1st party authorization. But he narrowed down the scope to the restrictive policy, removing any 3rd party consideration. The same will most likely be true with DMARC with the same problems. Yet, why would any list developer deny new security options for list operations? I never got that and that was before ADSP or even ATPS. When it comes to DKIM, if Levine didn't like it, it simply wasn't happening. Sad to say and I don't see that changing. So now that we have the top three cogs DKIM agreeing, there is not much reason to even bother anymore when one of them is the AD. What is one to think at this point? "Follow the Chieftain" syndrome? Just consider, we are 15+ yrs into all this and nothing was accomplished with DKIM in regards to LIST systems. DMARC, with the same exact problems as ADSP, snuck on via an informational status. Nothing wrong there, but it was pushed as a standard and ventures were started. Who wins? who loses? I believe it would be prudent for the AD to look at the reasons why the IETF has failed with this DKIM Project. If a cog is not for ADSP but for DMARC with the same problems, then what is that to say about this process? It has not been a fair process to say the least. A lot of wasted time, money and energy. It has been a long 15+ yrs and has become very tiring. :-( Despite the 3rd party authorization brush back, the concept has never gone away. It says a lot and it will never go away under the current DKIM POLICY model using the required hash bound Author Domain anchor as the forcing function for authorization. At this point, I would suggest to give the new generation IETF mail developers a new chance at DKIM-based security. Rewrite DKIM as v3.0 as you guys want it for 3rd party trust. Remove the Author Domain dependency so that the world can nip the Mail tampering bug opened with Levine's Rewrite crud. I wouldn't worry about backward compatibility. Two different streams, only the newer one will matter. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Aug 16 11:03:58 2020 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 64D953A0F26 for ; Sun, 16 Aug 2020 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 KNS8E-Pf5-OW for ; Sun, 16 Aug 2020 11:03:53 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 0C48B3A0F24 for ; Sun, 16 Aug 2020 11:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597601028; bh=O+8x22xcLb9ZvD/56S8Iu9ILK/kWiJemjk6e6wkWJ4w=; l=2896; h=To:Cc:References:From:Date:In-Reply-To; b=C5MgUE0NVYrV+IZPsEJU44T9IWOsCNE7h4mi47VAjJfre84raxc5SE0tl3Cn2qUXA lPskFYWjdrbMi/QEY08oNuE6rYKzcX2ergd8HdBYDEHw9iAPyqmSmd1GtJb2o+oifR 2DR8v+fTshX00WFfqmoeasH+WL++w5xrzmOFvedwQkG3WLSmnECLg/kSbSYJG Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F397504.00004458; Sun, 16 Aug 2020 20:03:48 +0200 To: dcrocker@bbiw.net Cc: "Murray S. Kucherawy" , IETF DMARC WG , John Levine , Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> From: Alessandro Vesely Message-ID: <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> Date: Sun, 16 Aug 2020 20:03:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 18:03:57 -0000 On Sun 16/Aug/2020 17:31:47 +0200 Dave Crocker wrote: > On 8/16/2020 1:23 AM, Alessandro Vesely wrote: >> On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote: >>> On 8/15/2020 3:32 AM, Alessandro Vesely wrote: >>> >>>> If X pretends to be Y, >>> >>> >>> If I put my gmail address into the from field, there is no >>> pretending, no matter what platform I am using. >> >> >> That conflicts with the coarse-grained authentication strategy, >> established at the FTC Email Authentication Summit in November >> 2004, as Doug^W Michael recalled. > > 1. I was making a semantic point, not a technical or technical policy > one. They have to match at some point. > 2. There was nothing 'established' at that event.  There were > interesting discussions, but that's all. I wasn't there. Can't it be considered the historic event that marked domain-level authentication as the promising strategy to counter email abuse? > 3. I'm not finding the reference in any of Doug^X Michael's notes > that your are relying on. Please be specific about it. https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E >> Your gmail address needs to be authenticated by gmail. > > Good grief, no.  There is no system rule to that effect.  DMARC > created that, but no policy before it was in place, never mind accepted. DMARC took that strategy to the extremes. A number of users and operators seem to have accepted it. Why cannot we accept it too? >> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and >> whitelisted as yet another domain (songbird.com) can hardly be >> verified.  There is no "pretending", since it's you, but it is not >> formally distinguishable from spoof, is it? > > Whether valid and invalid uses can be distinguished does not alter the > fact that valid uses are valid. The problem is to find the technical means that allow receivers and recipients to verify such validity. >>> This continuing practice of characterizing valid use as if it were >>> spoofing or pretending has been a major impediment to constructive >>> discussion in the industry. >> >> A system that is able to recognize all your domains and affiliations >> in order to authenticate messages does cost several orders of >> magnitude more than a simple "mechanical" verifier.  That way, >> requiring too much flexibility is a push toward oligopoly. > > I have no idea what you are referring it. Gmail has a visual perspective that allows them to know each and every email domain worldwide, and employs a number of people who help continuously upgrading domain reputation. In order to enjoy such technology, medium-small domains can get a G Suite account. That's oligopoly. If the technology were simpler and clearer, running one's own mail server could be a valid alternative. Best Ale -- From nobody Sun Aug 16 11:16:29 2020 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 2F0313A0FC2 for ; Sun, 16 Aug 2020 11:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 nXLref0sIeR0 for ; Sun, 16 Aug 2020 11:16:26 -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 EEB023A0FC7 for ; Sun, 16 Aug 2020 11:16:26 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07GIJ9Gv032318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 16 Aug 2020 11:19:10 -0700 To: Alessandro Vesely Cc: IETF DMARC WG References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Reply-To: dcrocker@bbiw.net Message-ID: <1703e878-e20a-8ae2-09e8-25470c0cf5f8@dcrocker.net> Date: Sun, 16 Aug 2020 11:16:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 18:16:28 -0000 >>>> If I put my gmail address into the from field, there is no >>>> pretending, no matter what platform I am using. >>> >>> >>> That conflicts with the coarse-grained authentication strategy, >>> established at the FTC Email Authentication Summit in November >>> 2004, as Doug^W Michael recalled. > >> 1. I was making a semantic point, not a technical or technical policy >> one. > > > They have to match at some point. it would be nice, wouldn't it? but that's separate from the factual statement I made. >> 2. There was nothing 'established' at that event.  There were >> interesting discussions, but that's all. > > > I wasn't there.  Can't it be considered the historic event that marked > domain-level authentication as the promising strategy to counter email > abuse? Reference to that event as if it 'established' anything is misguided, at best. The meetings were helpful, but not definitive. And the efforts at domain level authentication were wholly independent of these events. As already noted on this list, the events served as a plea from the government and, therefore, a signal that the government was concerned. >> 3. I'm not finding the reference in any of Doug^X Michael's notes >> that your are relying on.  Please be specific about it. > > > https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E Finally found that you meant Herr Hammer. >>> Your gmail address needs to be authenticated by gmail. >> >> Good grief, no.  There is no system rule to that effect.  DMARC >> created that, but no policy before it was in place, never mind accepted. > > > DMARC took that strategy to the extremes.  A number of users and > operators seem to have accepted it.  Why cannot we accept it too? That DMARC does something and that some people use it is quite different from claiming that there was some grand change in the semantics and operational policy of email. Why can't THAT be accepted? > >>> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and >>> whitelisted as yet another domain (songbird.com) can hardly be >>> verified.  There is no "pretending", since it's you, but it is not >>> formally distinguishable from spoof, is it? >> >> Whether valid and invalid uses can be distinguished does not alter the >> fact that valid uses are valid. > > The problem is to find the technical means that allow receivers and > recipients to verify such validity. Of course. But when it's at the expense of valid use that has worked for 45 years, then those means are problematic. Highly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 16 11:16:55 2020 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 BC1E73A0FCA for ; Sun, 16 Aug 2020 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=iKI3bDCR; dkim=pass (2048-bit key) header.d=taugh.com header.b=GXPmuJ3x 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 KA4KU2VHxkob for ; Sun, 16 Aug 2020 11:16:53 -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 046173A0FC9 for ; Sun, 16 Aug 2020 11:16:52 -0700 (PDT) Received: (qmail 79216 invoked from network); 16 Aug 2020 18:16:51 -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; s=1356c.5f397813.k2008; i=johnl-iecc.com@submit.iecc.com; bh=giY4ayaa2qYPYj7sejE6IGBSNmtlXt5CgPUxWxn/xAg=; b=iKI3bDCRudiGgfJu55WTTLK5n3ZqwGLV3cKbPVN1Y+P6CnH2h05TP/x5CrKVORb46j34zdg/gYBaB/xGrs+ILIKfTDEt8zcLYvg4we+S9ikTflhhmnKI65A1e5cwHdrweWgoyrVFpryRtZVImMVdNMT/XSY1iC+yYQsLgEFI5ZHn6H/nehMabwNHiWMNsNc3RbGcL8nDtKyuXCMKuuoimlHGCdnOdGrTePET/4g2cIGKDFb4la2k7D4JRWO9/SCKw6y6D0Loo4ANbNB25CTw5bA7rBm8zf3HYU2UlwzyeyEYEJ0pOVGA+zlcCPAkcQKSHf7t6TEI5sOybJYdQNHmKA== 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; s=1356c.5f397813.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=giY4ayaa2qYPYj7sejE6IGBSNmtlXt5CgPUxWxn/xAg=; b=GXPmuJ3xCVvykVmUX4BGW2DWu1jrRHI+RqiaUfViFQnV3ygguc9zj2kjyVPRGx1cLTRg8nz7q1YozxI7NqjO8rFwyjue73vcGmuL3BNZ8FInarKbMIAlOhp3hjJ1hqgtZBDi5zWVOw675wA1fFvamjHhuCaJ5idpWsHhl8ti9NfJZw/iRc5ErK0mwQ8yXLYirHQaNQZFNPQv5mBPew2eB52c8BKHrhQkxzeUX0dqoUnu84v6BYCrWrKEU3GPk4kb1tg2lqy6z6Y8+BGC9oUFq6E4O8M/wLvPhOEvqv0GbLDzT+7F0NodpEuDVqDlsGaw64Whmo8s4SiyqaqkjzlV7A== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 16 Aug 2020 18:16:50 -0000 Date: 16 Aug 2020 14:16:50 -0400 Message-ID: From: "John R Levine" To: "Alessandro Vesely" Cc: "IETF DMARC WG" In-Reply-To: <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-940272435-1597601810=:84766" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 18:16:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-940272435-1597601810=:84766 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 16 Aug 2020, Alessandro Vesely wrote: >>>> If I put my gmail address into the from field, there is no pretending, no >>>> matter what platform I am using. >>> >>> That conflicts with the coarse-grained authentication strategy, >>> established at the FTC Email Authentication Summit in November >>> 2004, as Doug^W Michael recalled. > >> 1. I was making a semantic point, not a technical or technical policy one. > > They have to match at some point. Sorry, that's just wrong. There's no technical reason a mail message can't have any identifiers the sender wants. >> 2. There was nothing 'established' at that event.  There were interesting >> discussions, but that's all. > > I wasn't there. Can't it be considered the historic event that marked > domain-level authentication as the promising strategy to counter email abuse? No, it was just some political theatre. We were already working on SPF and DKIM. > DMARC took that strategy to the extremes. A number of users and operators > seem to have accepted it. Why cannot we accept it too? Please review the previous bazillion messages on this topic. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-940272435-1597601810=:84766-- From nobody Sun Aug 16 12:09:14 2020 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 7EE2C3A0A4F for ; Sun, 16 Aug 2020 12:09:12 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DTHeHDzbBni for ; Sun, 16 Aug 2020 12:09:10 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422C83A0A4D for ; Sun, 16 Aug 2020 12:09:10 -0700 (PDT) X-ASG-Debug-ID: 1597604945-11fa3136ba13a10001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id YIvM11m6ylyRAZtt (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 16 Aug 2020 15:09:05 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=uNrMacoGfsRMDjB2uiknvIM3tmZSzdyKxJZro6Gx3Qc=; b=W3q8IzMcCBt1rwvKoFYgWicnQqtlDkj33twajLjZuzydWewrmOQuJTN8oGNU/8MtQ W414dVkCcAHrEAmzixQv4fOI1a8M4UrMddmzHTfCqvCLa+4Ee1JOBR9acJPy0jFPI IKQ12TnJT0ZgjdN1QKlyDXKGAXDvg+KvPtz3gsHJs= From: "Douglas E. Foster" To: Date: Sun, 16 Aug 2020 19:08:58 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Time for a change Reply-To: fosterd@bayviewphysicians.com Message-ID: <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=9cd6bcd0e0704e8294750d388c49e74b In-Reply-To: <5F396A77.3000109@isdg.net> References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> X-Exim-Id: 366e50ed8bda41cb879fa245e2d7c27a X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597604945 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 13854 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83943 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Time for a change X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 19:09:13 -0000 This is a multipart message in MIME format. --9cd6bcd0e0704e8294750d388c49e74b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The reality is that IETF has mostly provided followership, not leadership, = on matters of security. This forum is replicating history. As has been m= entioned in the historical review, SPF, DKIM, and DMARC were independently = successful projects, as was SSL. IETF provided after-the-fact blessing. = It is time to follow the same model. If there is an opportunity to accelerate DMARC adoption, I think it is in t= he area of third-party authentication, presumably based on ATSP. To move = the possibility forward, we need to move off this list. The target audienc= e for this capability will be organizations that are non-DMARC or DMARC p= =3Dnone specifically because DKIM delegation is an obstacle. I have no i= dea whether that category is a trivial or non-trivial group, so we would ne= ed to find out. Major ESPs are successfully implementing DKIM scope delega= tion to comply with DMARC, so maybe it is not the issue. DKIM delegation = creates complexity which becomes an obstacle to new entrants, so big ESPs m= ay like the status quo just fine. These are all things need to be assesse= d, and are more important than writing a new specification. Then, we need to expand the base of participants to include people who woul= d be willing to implement the third-party authentication scheme after it is= defined. I think that list would need to look something like this: A national government representative to ensure that any new proposal is not= vetoed, A financial services industry representativeAn Email Service Provi= der industry representativeA large organization that is holding back on DMA= RC p=3Dreject because DKIM delegation is an obstacle.One or more commercial= product representativesI would love to have Verizon Media participate, but= I have asked and had no response. If you want to participate, send me a direct email. More importantly, if= you have connections with people who could play the role of influencers, r= each out to them. If there are other topics that would move DMARC forward, we can put them up= for consideration. If you want to discuss special treatment for mailing l= ists, you are specifically disinvited. Doug Foster ---------------------------------------- From: hsantos=3D40isdg.net@dmarc.ietf.org Sent: 8/16/20 1:19 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing l= ist On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote: > On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker > wrote: > > > We have had a lot of attempts at third-party authorization schemes > ..... > > With this in mind, I cannot see any point in designing yet another > > vouching or authorization scheme unless we have evidence that an > > interesting fraction of the world's mail systems want to use it. I > > don't see that, and honestly see no chance that we ever will. > > +1 > > > I'm disappointed that the experiment never really got its day in > court, +1 and I want to give you credit for trying. Without you, I might have been long gone from the DKIM project WGs. So I thank you for keeping it interesting, but.... > but the consensus is clear. +1. Here I have to disagree. I don't ask anyone to agree with me but to understand my viewpoint as a long time participant and advocate of the DKIM Policy Model. Early on, we had limited policy proponents. But not today. I have a different viewpoint, a viewpoint that really that was blocked by the two controlling cogs who had DKIM interest else where, namely Levine, Crocker. Crocker has been more open ended. Not Levine. Since day 0, Levine never liked policy and to his credit, he admitted it as much. He killed SSP with the "poison pill" (crippled draft) ADSP replacement he knew would never make it pass LC. Levine was always for the 3rd party trust/list signer idea - never a 1st party authorization. But he narrowed down the scope to the restrictive policy, removing any 3rd party consideration. The same will most likely be true with DMARC with the same problems. Yet, why would any list developer deny new security options for list operations? I never got that and that was before ADSP or even ATPS. When it comes to DKIM, if Levine didn't like it, it simply wasn't happening. Sad to say and I don't see that changing. So now that we have the top three cogs DKIM agreeing, there is not much reason to even bother anymore when one of them is the AD. What is one to think at this point? "Follow the Chieftain" syndrome? Just consider, we are 15+ yrs into all this and nothing was accomplished with DKIM in regards to LIST systems. DMARC, with the same exact problems as ADSP, snuck on via an informational status. Nothing wrong there, but it was pushed as a standard and ventures were started. Who wins? who loses? I believe it would be prudent for the AD to look at the reasons why the IETF has failed with this DKIM Project. If a cog is not for ADSP but for DMARC with the same problems, then what is that to say about this process? It has not been a fair process to say the least. A lot of wasted time, money and energy. It has been a long 15+ yrs and has become very tiring. :-( Despite the 3rd party authorization brush back, the concept has never gone away. It says a lot and it will never go away under the current DKIM POLICY model using the required hash bound Author Domain anchor as the forcing function for authorization. At this point, I would suggest to give the new generation IETF mail developers a new chance at DKIM-based security. Rewrite DKIM as v3.0 as you guys want it for 3rd party trust. Remove the Author Domain dependency so that the world can nip the Mail tampering bug opened with Levine's Rewrite crud. I wouldn't worry about backward compatibility. Two different streams, only the newer one will matter. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --9cd6bcd0e0704e8294750d388c49e74b Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The= reality is that IETF has mostly provided followership, not leadership, on = matters of security.  This forum is replicating history.   As has= been mentioned in the historical review, SPF, DKIM, and DMARC were indepen= dently successful projects, as was SSL.  IETF provided after-the-fact = blessing.   It is time to follow the same model.

<= div>If there is an opportunity to accelerate DMARC adoption, I think it is = in the area of third-party authentication, presumably based on ATSP.  = To move the possibility forward, we need to move off this list.  The = target audience for this capability will be organizations that are non-DMAR= C or DMARC p=3Dnone specifically because DKIM delegation is an obstacle. &n= bsp;  I have no idea whether that category is a trivial or non-trivial= group, so we would need to find out.  Major ESPs are successfully imp= lementing DKIM scope delegation to comply with DMARC, so maybe it is not th= e issue.   DKIM delegation creates complexity which becomes an obstacl= e to new entrants, so big ESPs may like the status quo just fine.   Th= ese are all things need to be assessed, and are more important than writing= a new specification.

Then, we need to expand the = base of participants to include people who would be willing to implement th= e third-party authentication scheme after it is defined.   I think tha= t list would need to look something like this:

  • = A national government representative to ensure that any new proposal is not= vetoed, 
  • A financial services industry representative
    • An Email Service Provider industry representative
  • A large organiza= tion that is holding back on DMARC p=3Dreject because DKIM delegation is an= obstacle.
  • One or more commercial product representatives
  • I= would love to have Verizon Media participate, but I have asked and had no = response.
If you want to participate, send me a direct email.=    More importantly, if you have connections with people who cou= ld play the role of influencers, reach out to them.

If there are other topics that would move DMARC forward, we can put them = up for consideration.  If you want to discuss special treatment for ma= iling lists, you are specifically disinvited.


=
Doug Foster





From: hsantos=3D40isdg.net@dmarc.ietf.org
Sent: 8/16/20 1:19 PM
To: dmarc@ietf.org
Subjec= t: Re: [dmarc-ietf] third party authorization, not, was non-mailin= g list
On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker <dhc@dcrocker= .net
> <mailto:dhc@dcrocker.net>> wrote:
&g= t;
> > We have had a lot of attempts at third-party authori= zation schemes
> .....
> > With this in mind, = I cannot see any point in designing yet another
> > vouchin= g or authorization scheme unless we have evidence that an
> &g= t; interesting fraction of the world's mail systems want to use it. I
=
> > don't see that, and honestly see no chance that we ever will= .
>
> +1
>
>
= > I'm disappointed that the experiment never really got its day in
=
> court,

+1 and I want to give you credit = for trying. Without you, I might
have been long gone from the DKI= M project WGs. So I thank you for
keeping it interesting, but....=

> but the consensus is clear. +1.
Here I have to disagree. I don't ask anyone to agree with me b= ut to
understand my viewpoint as a long time participant and advo= cate of the
DKIM Policy Model. Early on, we had limited policy pr= oponents. But
not today.

I have a differ= ent viewpoint, a viewpoint that really that was blocked
by the tw= o controlling cogs who had DKIM interest else where, namely
Levin= e, Crocker. Crocker has been more open ended. Not Levine. Since
d= ay 0, Levine never liked policy and to his credit, he admitted it as
<= div>much. He killed SSP with the "poison pill" (crippled draft) ADSP
<= div>replacement he knew would never make it pass LC. Levine was always
for the 3rd party trust/list signer idea - never a 1st party
authorization. But he narrowed down the scope to the restrictivepolicy, removing any 3rd party consideration. The same will mostlikely be true with DMARC with the same problems. Yet, why would any
list developer deny new security options for list operations? I never=
got that and that was before ADSP or even ATPS. When it comes to=
DKIM, if Levine didn't like it, it simply wasn't happening. Sad = to say
and I don't see that changing. So now that we have the top= three cogs
DKIM agreeing, there is not much reason to even bothe= r anymore when
one of them is the AD. What is one to think at thi= s point? "Follow
the Chieftain" syndrome?

Just consider, we are 15+ yrs into all this and nothing was
acc= omplished with DKIM in regards to LIST systems. DMARC, with the
s= ame exact problems as ADSP, snuck on via an informational status.
Nothing wrong there, but it was pushed as a standard and ventures were
started. Who wins? who loses?

I believe it = would be prudent for the AD to look at the reasons why
the IETF h= as failed with this DKIM Project. If a cog is not for ADSP
but fo= r DMARC with the same problems, then what is that to say about
th= is process? It has not been a fair process to say the least. A lot
of wasted time, money and energy. It has been a long 15+ yrs and has
become very tiring. :-(

Despite the 3rd part= y authorization brush back, the concept has never
gone away. It s= ays a lot and it will never go away under the current
DKIM POLICY= model using the required hash bound Author Domain anchor
as the = forcing function for authorization.

At this point,= I would suggest to give the new generation IETF mail
developers = a new chance at DKIM-based security. Rewrite DKIM as v3.0
as you = guys want it for 3rd party trust. Remove the Author Domain
depend= ency so that the world can nip the Mail tampering bug opened
with= Levine's Rewrite crud.

I wouldn't worry about bac= kward compatibility. Two different streams,
only the newer one wi= ll matter.


--
Hector Sant= os,


__________________________________________= _____
dmarc mailing list
dmarc@ietf.org

--9cd6bcd0e0704e8294750d388c49e74b-- From nobody Mon Aug 17 02:47:02 2020 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 6A3503A1467 for ; Mon, 17 Aug 2020 02:47:00 -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=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 pM1REWo7Xuqw for ; Mon, 17 Aug 2020 02:46:58 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id B229A3A1466 for ; Mon, 17 Aug 2020 02:46:58 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 64E819F1F7 for ; Mon, 17 Aug 2020 02:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597657617; bh=AdpCeCc/DdeoqQLrqNTFDQmwj7ueXC5LYqLn9mexZXg=; h=From:Subject:Date:References:To:In-Reply-To:From; b=ohGER0XVOGGiGtJfqis1OpIHG/ku9Qp9tcCoOd8yoSvs8Z2U6zUuH2G4vEj31SJJw rPljQ55fdZwVQGo54A6FnZaxWx/qsI3B+5zi2F1H6rB8LDpCukWH4HUiZsFDXXBqJx fzkC+nsclNGiH+MwhDyeAyGjKuJZEESoYLl3CcFo= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_7CAFD694-E4E4-4D87-A922-6BBFACE3F7E6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 17 Aug 2020 10:46:55 +0100 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> To: IETF DMARC WG In-Reply-To: Message-Id: <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 09:47:00 -0000 --Apple-Mail=_7CAFD694-E4E4-4D87-A922-6BBFACE3F7E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Aug 2020, at 19:16, John R Levine wrote: >=20 > On Sun, 16 Aug 2020, Alessandro Vesely wrote: >>>>> If I put my gmail address into the from field, there is no = pretending, no matter what platform I am using. >>>> That conflicts with the coarse-grained authentication strategy, = established at the FTC Email Authentication Summit in November >>>> 2004, as Doug^W Michael recalled. > >>> 1. I was making a semantic point, not a technical or technical = policy one. >>=20 >> They have to match at some point. >=20 > Sorry, that's just wrong. There's no technical reason a mail message = can't have any identifiers the sender wants. >=20 >>> 2. There was nothing 'established' at that event. There were = interesting discussions, but that's all. >>=20 >> I wasn't there. Can't it be considered the historic event that = marked domain-level authentication as the promising strategy to counter = email abuse? >=20 > No, it was just some political theatre. We were already working on = SPF and DKIM. I don=E2=80=99t remember much focus on domain-level authentication at = the event. Authentication was one small piece of the discussion but not = even a focus. My recollection is that the 3 days were mostly about = scoping the spam problem, not solving it.=20 The forum page is off the FTC website, but the document links are still = accessible:=20 = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day1.pdf = = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day2.pdf = = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day3.pdf = >> DMARC took that strategy to the extremes. A number of users and = operators seem to have accepted it. Why cannot we accept it too? >=20 > Please review the previous bazillion messages on this topic. There=E2=80=99s a difference between accepting it and working around the = damage it causes to let users continue to use mailing lists. Consumer = mailbox providers deciding their users couldn=E2=80=99t participate in = mailing lists was and is a problem. Companies preventing their employees = from participating in work related forums was and is a problem.=20 laura --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_7CAFD694-E4E4-4D87-A922-6BBFACE3F7E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16 Aug 2020, at 19:16, John R Levine <johnl@taugh.com> = wrote:

On Sun, 16 Aug 2020, Alessandro Vesely wrote:
If I put my gmail address into the from field, there is no = pretending, no matter what platform I am using.
That conflicts with the coarse-grained = authentication strategy, established at the FTC Email Authentication = Summit in November
2004, as Doug^W Michael recalled. = >
1. I was making a semantic point, not a = technical or technical policy one.

They have to match at some point.

Sorry, that's just wrong. =  There's no technical reason a mail message can't have any = identifiers the sender wants.

2. There = was nothing 'established' at that event.  There were interesting = discussions, but that's all.

I = wasn't there.  Can't it be considered the historic event that = marked domain-level authentication as the promising strategy to counter = email abuse?

No, it was just = some political theatre.  We were already working on SPF and = DKIM.

I don=E2=80=99t remember much focus on = domain-level authentication at the event. Authentication was one small = piece of the discussion but not even a focus. My recollection is that = the 3 days were mostly about scoping the spam problem, not solving = it. 

The forum page is off the = FTC website, but the document links are still = accessible: 



DMARC took that strategy to the extremes.  A number of = users and operators seem to have accepted it.  Why cannot we accept = it too?

Please review the = previous bazillion messages on this topic.

There=E2=80=99s a difference between accepting it = and working around the damage it causes to let users continue to use = mailing lists. Consumer mailbox providers deciding their users = couldn=E2=80=99t participate in mailing lists was and is a problem. = Companies preventing their employees from participating in work related = forums was and is a problem. 

laura

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_7CAFD694-E4E4-4D87-A922-6BBFACE3F7E6-- From nobody Mon Aug 17 02:58:00 2020 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 A278C3A1473 for ; Mon, 17 Aug 2020 02:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 wrBO4f4FTC0F for ; Mon, 17 Aug 2020 02:57:57 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 369F93A146F for ; Mon, 17 Aug 2020 02:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597658274; bh=yt+eoysYM8S3MhIM8pOOumRDtTDOdl6t5gIaKm2QmjQ=; l=4122; h=To:Cc:References:From:Date:In-Reply-To; b=CriJD8Vm/ySfiyzE0QtCqryunx7kI3y332OAQI2DwRiFj6CU9r+Z+jRNn5JouaiC8 qay3s86XelpwPQ//qmLaratHgk0YVXA802HHp/8pEJN1jko5azMWJ5ulCudHVPRym2 t259cY8ZlIPZt0/0XTG9ieJR/HEbH5l1TIA2ZHJ6k4x8wbPvlti3pt0WPJDNy Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC026.000000005F3A54A1.00006FC7; Mon, 17 Aug 2020 11:57:53 +0200 To: dcrocker@bbiw.net Cc: IETF DMARC WG References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <1703e878-e20a-8ae2-09e8-25470c0cf5f8@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Mon, 17 Aug 2020 11:57:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <1703e878-e20a-8ae2-09e8-25470c0cf5f8@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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 09:57:59 -0000 On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: > >>>>> If I put my gmail address into the from field, there is no >>>>> pretending, no matter what platform I am using. >>>> >>>> >>>> That conflicts with the coarse-grained authentication strategy, >>>> established at the FTC Email Authentication Summit in November >>>> 2004, as Doug^W Michael recalled >>> >>> 1. I was making a semantic point, not a technical or technical >>> policy one. >> >> They have to match at some point. > > it would be nice, wouldn't it? > > but that's separate from the factual statement I made. Separate but related. >>> 2. There was nothing 'established' at that event.  There were >>> interesting discussions, but that's all. >> >> >> I wasn't there.  Can't it be considered the historic event that >> marked domain-level authentication as the promising strategy to >> counter email abuse? > > Reference to that event as if it 'established' anything is misguided, > at best.  The meetings were helpful, but not definitive.  And the > efforts at domain level authentication were wholly independent of > these events. Would it be still correct to mention that summit as a conspicuous event that testifies the emergence of domain-level authentication around the early 2000s? > As already noted on this list, the events served as a plea from the > government and, therefore, a signal that the government was concerned. A noteworthy historical detail. >>>> Your gmail address needs to be authenticated by gmail. >>> >>> Good grief, no.  There is no system rule to that effect.  DMARC >>> created that, but no policy before it was in place, never mind >>> accepted. >> >> >> DMARC took that strategy to the extremes.  A number of users and >> operators seem to have accepted it.  Why cannot we accept it too? > > That DMARC does something and that some people use it is quite > different from claiming that there was some grand change in the > semantics and operational policy of email.  Why can't THAT be accepted? There's been a combination of events, from IETF's reluctant laissez-faire to Yahoo/AOL adoption, which brought up the illusion that email authentication can provide a global means to counter spoofing. To believe that such illusion will come true makes for a strong motivation. Couldn't we meet somewhere halfway? I can see that you, John, Herr Hammer, and other relevant participants don't accept that domain-level authentication is semantically mandatory. What d'you reckon about the possibility that such grand semantic change can be made official within the next 10~20 years? I think that by just spelling the technical means /as if/ such change is going to happen, we can design a consistent authentication protocol. >>>> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and >>>> whitelisted as yet another domain (songbird.com) can hardly be >>>> verified.  There is no "pretending", since it's you, but it is not >>>> formally distinguishable from spoof, is it? >>> >>> Whether valid and invalid uses can be distinguished does not alter >>> the fact that valid uses are valid. >> >> The problem is to find the technical means that allow receivers and >> recipients to verify such validity. > > Of course.  But when it's at the expense of valid use that has worked > for 45 years, then those means are problematic.  Highly. It seems to me most expenses have been paid already, for example this mailing list is applying From: rewriting. We don't need to propose further restrictions. To the opposite, there are means on the table[*] that can enable us to sketch a time horizon where From: rewriting can cease. 16 years have passed since the FTC event, which is 1/3 of those 45. What I see looks much like a very mild shift. Lazy operators have plenty of time before the semantic change is established, at some point in the medium-term future, if ever. Best Ale -- [*] For MLMs to resume traditional address usage, the most promising I-D's is dkim-transform, IMHO. From nobody Mon Aug 17 03:24:55 2020 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 95F863A09F8 for ; Mon, 17 Aug 2020 03:24:53 -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=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 sKpCWdQTGuTo for ; Mon, 17 Aug 2020 03:24:51 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 97B263A09EA for ; Mon, 17 Aug 2020 03:24:51 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 591E39F1F7 for ; Mon, 17 Aug 2020 03:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597659890; bh=UJHoBnKtzF0Gjv0Km3Zkbw6fQMF80V+p32mStNukkyI=; h=From:Subject:Date:References:To:In-Reply-To:From; b=pNsIMklp+IzHsZHZzXqm0Xg5Me+nGpRYLqnNMMObH6v4nI1rRvZ5OVaZsFbJVjlmt BvfXdIU6WiRK3xbSC4jkM81ENpEiMuc2d0EqKfqUCjPAgnJsaz4tV62NhvbNgRE/gy vcu3wUYi5aa15M810AAGXWEYBlrJlG3x2Et/OYdQ= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_465B689B-12B9-409D-A4B1-D7DC59241B33" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 17 Aug 2020 11:24:48 +0100 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <1703e878-e20a-8ae2-09e8-25470c0cf5f8@dcrocker.net> To: IETF DMARC WG In-Reply-To: Message-Id: <3AFAA767-9CC1-4722-80FB-5C4F9BE1FC05@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 10:24:54 -0000 --Apple-Mail=_465B689B-12B9-409D-A4B1-D7DC59241B33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Aug 2020, at 10:57, Alessandro Vesely wrote: >=20 > On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: >>>>>> If I put my gmail address into the from field, there is no = pretending, no matter what platform I am using. >>>>>=20 >>>>>=20 >>>>> That conflicts with the coarse-grained authentication strategy, = established at the FTC Email Authentication Summit in November >>>>> 2004, as Doug^W Michael recalled >>> >>>> 1. I was making a semantic point, not a technical or technical = policy one. >>>=20 >>> They have to match at some point. >> it would be nice, wouldn't it? >> but that's separate from the factual statement I made. >=20 >=20 > Separate but related. >=20 >=20 >>>> 2. There was nothing 'established' at that event. There were = interesting discussions, but that's all. >>>=20 >>>=20 >>> I wasn't there. Can't it be considered the historic event that = marked domain-level authentication as the promising strategy to counter = email abuse? >> Reference to that event as if it 'established' anything is misguided, = at best. The meetings were helpful, but not definitive. And the = efforts at domain level authentication were wholly independent of these = events. >=20 >=20 > Would it be still correct to mention that summit as a conspicuous = event that testifies the emergence of domain-level authentication around = the early 2000s? As someone who participated in the forum, that is not how I=E2=80=99d = characterize it at all. You can read=20 >> As already noted on this list, the events served as a plea from the = government and, therefore, a signal that the government was concerned. >=20 > A noteworthy historical detail. Maybe? This was part of the drafting of CAN SPAM. If you look at what = CAN SPAM was concerned with, authentication didn=E2=80=99t show up.=20 >=20 >>>>> Your gmail address needs to be authenticated by gmail.=20 >>>>=20 >>>> Good grief, no. There is no system rule to that effect. DMARC = created that, but no policy before it was in place, never mind accepted. >>>=20 >>>=20 >>> DMARC took that strategy to the extremes. A number of users and = operators seem to have accepted it. Why cannot we accept it too? >> That DMARC does something and that some people use it is quite = different from claiming that there was some grand change in the = semantics and operational policy of email. Why can't THAT be accepted? >=20 >=20 > There's been a combination of events, from IETF's reluctant = laissez-faire to Yahoo/AOL adoption, which brought up the illusion that = email authentication can provide a global means to counter spoofing. To = believe that such illusion will come true makes for a strong motivation. >=20 > Couldn't we meet somewhere halfway? I can see that you, John, Herr = Hammer, and other relevant participants don't accept that domain-level = authentication is semantically mandatory. What d'you reckon about the = possibility that such grand semantic change can be made official within = the next 10~20 years? I think that by just spelling the technical means = /as if/ such change is going to happen, we can design a consistent = authentication protocol. What issue will only domain-level authentication solve?=20 The DMARC proponents have asserted that DMARC prevents domain specific = spoofing and phishing. The amount of harm DMARC authentication has = caused, however, seems disproportional to this small benefit. Phishing = is still happening using cousin domains (and even random domains). = Departments inside companies avoid DMARC mandates buy buying cousin and = =E2=80=9Ccampaign specific=E2=80=9D domains which trains users to be = phishing targets for those domains. Companies have tried to cut down on = this by saying DMARC must be done for all those domains as well. = Unfortunately, those =E2=80=9Cfrom above=E2=80=9D decrees have often = created more problems than they solved.=20 Mailing lists have coped by rewriting from addresses, but that has = caused a lot of issues. Two of the big ones are members can no longer = search for =E2=80=9Cmail from this list member=E2=80=9D and cannot = easily create filters acting on mail from other participants.=20 laura=20 >>>>> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and = whitelisted as yet another domain (songbird.com) can hardly be verified. = There is no "pretending", since it's you, but it is not formally = distinguishable from spoof, is it? >>>>=20 >>>> Whether valid and invalid uses can be distinguished does not alter = the fact that valid uses are valid. >>>=20 >>> The problem is to find the technical means that allow receivers and = recipients to verify such validity. >> Of course. But when it's at the expense of valid use that has worked = for 45 years, then those means are problematic. Highly. >=20 > It seems to me most expenses have been paid already, for example this = mailing list is applying From: rewriting. We don't need to propose = further restrictions. To the opposite, there are means on the table[*] = that can enable us to sketch a time horizon where From: rewriting can = cease. >=20 > 16 years have passed since the FTC event, which is 1/3 of those 45. = What I see looks much like a very mild shift. Lazy operators have = plenty of time before the semantic change is established, at some point = in the medium-term future, if ever. >=20 > Best > Ale > --=20 >=20 > [*] For MLMs to resume traditional address usage, the most promising = I-D's is dkim-transform, IMHO. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_465B689B-12B9-409D-A4B1-D7DC59241B33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 Aug 2020, at 10:57, Alessandro Vesely <vesely@tana.it> = wrote:

On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
If I put my gmail = address into the from field, there is no pretending, no matter what = platform I am using.


That conflicts with the coarse-grained authentication = strategy, established at the FTC Email Authentication Summit in = November
2004, as Doug^W Michael recalled >>>
1. I was making a semantic point, not a = technical or technical policy one.

They have to match at some point.
it= would be nice, wouldn't it?
but that's separate from the = factual statement I made.


Separate but related.


2. There was nothing = 'established' at that event.  There were interesting discussions, = but that's all.


I= wasn't there.  Can't it be considered the historic event that = marked domain-level authentication as the promising strategy to counter = email abuse?
Reference to that event as if it = 'established' anything is misguided, at best.  The meetings were = helpful, but not definitive.  And the efforts at domain level = authentication were wholly independent of these events.


Would it be still = correct to mention that summit as a conspicuous event that testifies the = emergence of domain-level authentication around the early 2000s?

As = someone who participated in the forum, that is not how I=E2=80=99d = characterize it at all. You can read 

As already noted on this list, the events = served as a plea from the government and, therefore, a signal that the = government was concerned.

A = noteworthy historical detail.

Maybe? = This was part of the drafting of CAN SPAM. If you look at what CAN SPAM = was concerned with, authentication didn=E2=80=99t show = up. 


Your gmail address needs = to be authenticated by gmail.

Good grief, no.  There is no system rule to that = effect.  DMARC created that, but no policy before it was in place, = never mind accepted.


DMARC took that strategy to the extremes.  A number of = users and operators seem to have accepted it.  Why cannot we accept = it too?
That DMARC does something and that = some people use it is quite different from claiming that there was some = grand change in the semantics and operational policy of email.  Why = can't THAT be accepted?


There's been a combination of events, from IETF's reluctant = laissez-faire to Yahoo/AOL adoption, which brought up the illusion that = email authentication can provide a global means to counter spoofing. =  To believe that such illusion will come true makes for a strong = motivation.

Couldn't we = meet somewhere halfway?  I can see that you, John, Herr Hammer, and = other relevant participants don't accept that domain-level = authentication is semantically mandatory.  What d'you reckon about = the possibility that such grand semantic change can be made official = within the next 10~20 years?  I think that by just spelling the = technical means /as if/ such change is going to happen, we can design a = consistent authentication protocol.

What = issue will only domain-level authentication solve? 

The DMARC proponents have asserted that DMARC = prevents domain specific spoofing and phishing. The amount of harm DMARC = authentication has caused, however, seems disproportional to this small = benefit. Phishing is still happening using cousin domains (and even = random domains). Departments inside companies avoid DMARC mandates buy = buying cousin and =E2=80=9Ccampaign specific=E2=80=9D domains which = trains users to be phishing targets for those domains. Companies have = tried to cut down on this by saying DMARC must be done for all those = domains as well. Unfortunately, those =E2=80=9Cfrom above=E2=80=9D = decrees have often created more problems than they = solved. 

Mailing lists have = coped by rewriting from addresses, but that has caused a lot of issues. = Two of the big ones are members can no longer search for =E2=80=9Cmail = from this list member=E2=80=9D and cannot easily create filters acting = on mail from other participants. 

laura 

Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and = whitelisted as yet another domain (songbird.com) can hardly be verified.  There is no = "pretending", since it's you, but it is not formally distinguishable = from spoof, is it?

Whether = valid and invalid uses can be distinguished does not alter the fact that = valid uses are valid.

The = problem is to find the technical means that allow receivers and = recipients to verify such validity.
Of = course.  But when it's at the expense of valid use that has worked = for 45 years, then those means are problematic.  = Highly.

It seems to me most expenses have = been paid already, for example this mailing list is applying From: = rewriting.  We don't need to propose further restrictions.  To = the opposite, there are means on the table[*] that can enable us to = sketch a time horizon where From: rewriting can = cease.

16 years have passed since the = FTC event, which is 1/3 of those 45. What I see looks much like a very = mild shift.  Lazy operators have plenty of time before the semantic = change is established, at some point in the medium-term future, if = ever.


Best
Ale
--

[*] For = MLMs to resume traditional address usage, the most promising I-D's is = dkim-transform, IMHO.



























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

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_465B689B-12B9-409D-A4B1-D7DC59241B33-- From nobody Mon Aug 17 04:25:47 2020 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 9AF263A14C6 for ; Mon, 17 Aug 2020 04:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Xyl8dzkJIRmy for ; Mon, 17 Aug 2020 04:25:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 451FD3A14C0 for ; Mon, 17 Aug 2020 04:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597663539; bh=TlNbAEnhbJb9zFKweeDSdBGPLulEP6AkVB0vvrLJQA0=; l=1509; h=To:References:From:Date:In-Reply-To; b=B+zkmFxRXHa9vUNs6djSDsENshfYfI1uFctZIUOYnELjbyepPh00QkIwls62x3YD8 rac57nrZZ7ekqkvHRxB+X28jSFwF3bFFcXBbQebCM9cymYhgAOhhfKCwIIqwvpd8dM suhaszh5A2bBx4YFGjdJV9o2pzlgCBXR11siP0Ovsq25NLBLjb9AbfmpYFLzz Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F3A6932.000078CE; Mon, 17 Aug 2020 13:25:38 +0200 To: dmarc@ietf.org References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> From: Alessandro Vesely Message-ID: Date: Mon, 17 Aug 2020 13:25:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 11:25:46 -0000 On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > The forum page is off the FTC website, but the document links are > still accessible: A copy is here: https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/ A sentence says: The Report, however, identified domain-level authentication as a promising technological development that would enable Internet Service Providers (‘‘ISPs’’) and other domain holders to better filter spam, and that would provide law enforcement with a potent tool for locating and identifying spammers. > https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf > https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf > https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf Thanks. Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf: It doesn't require that one day everyone turns it on and we begin to drop the rest of the e-mail and break e-mail. If a domain decides to turn it on, then they've prevented forgery for their domain and they're protected. For persons that have not turned it on, then their e-mail still flows but they are not able to stop people from forging messages from their domain. So, I think it's something useful and can be deployed incrementally. It seems we're still stuck midstream... Best Ale -- From nobody Mon Aug 17 05:22:21 2020 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 EDDF63A1509 for ; Mon, 17 Aug 2020 05:22:18 -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=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 vhYpYGtI1Od5 for ; Mon, 17 Aug 2020 05:22:17 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id E1FAD3A1500 for ; Mon, 17 Aug 2020 05:22:16 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id D2A0E9F1F7 for ; Mon, 17 Aug 2020 05:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597666936; bh=FcoTahrux9+NXKzjN3ZCx6XA3KO9bJFSIpLGPWXoj0M=; h=From:Subject:Date:References:To:In-Reply-To:From; b=ZMV6SNtmJpK1MwVYRT4OB170FP0+M/ksFqTcS7jJTAXFr3j5V/CVUWEk/iK65mIwu k/BBgsYWWGTCjy55+fMHvpm1ZKtjoS12VbUDXT+xLkqQ8IFcnZQAqzSv3TDf7syRhX 70SU8QqZiArLEUtGLPL01USDrTEv41Myqm+Kjubk= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_64F5919D-36C3-4556-8B43-3ECC828BEB85" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 17 Aug 2020 13:22:14 +0100 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 12:22:19 -0000 --Apple-Mail=_64F5919D-36C3-4556-8B43-3ECC828BEB85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: >=20 > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: >>=20 >> The forum page is off the FTC website, but the document links are=20 >> still accessible: >=20 >=20 > A copy is here: > = https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/worksho= ps/e-authentication/ >=20 > A sentence says: >=20 > The Report, however, identified domain-level authentication as a > promising technological development that would enable Internet > Service Providers (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and = other domain holders to better > filter spam, and that would provide law enforcement with a potent > tool for locating and identifying spammers. And, 17 years on, we know that domain level authentication doesn=E2=80=99t= actually help filter spam nor does it provide law enforcement with a = potent tool for locating and identifying spammers. It was promising, it = didn=E2=80=99t live up to the promise.=20 There were a lot of thrown at the wall during those 3 days of talks. One = of them was domain level opt-out. Another was a global opt-out list = similar to the postal opt-outs run by the DMA. Another was a technology = called TEOS. HashCash. The list of things we discussed as promising = solutions was extensive. Just because we discussed a particular kind of = solution does not mean that anything was decided. It also doesn=E2=80=99t = mean that any particular solution mentioned was workable.=20 >> = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day1.pdf >> = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day2.pdf >> = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day3.pdf >=20 >=20 > Thanks. Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf: >=20 > It doesn't require that one day everyone turns it on and we begin > to drop the rest of the e-mail and break e-mail. If a domain > decides to turn it on, then they've prevented forgery for their > domain and they're protected. For persons that have not turned it > on, then their e-mail still flows but they are not able to > stop people from forging messages from their domain. So, I think > it's something useful and can be deployed incrementally. We know, now, that turning on domain level protection does not stop = phishing attacks against that company. It stops direct spoofing of the = domain, but the phishers simply use a completely different domain. Just = this weekend I got a PayPal phish. PayPal who helped invent DMARC are = still getting spoofed and phished. Sure, the phishers aren=E2=80=99t = using the paypal.com domain, but that doesn=E2=80=99t= seem to have any effect on their success at stealing money from people.=20= > It seems we're still stuck midstream... Stuck at what? Many of the people who were at that conference are still = working in the field and understand both the purpose and what came out = of the forum. I=E2=80=99d also say that most of what happened there is a = nice bit of history but is also irrelevant to addressing the spam = problem as it is now. Email has evolved significantly in the last 5 = years, much less the last 15. We can use the discussion as history to = say =E2=80=9Cwe looked at this and it didn=E2=80=99t work=E2=80=9D but I = don=E2=80=99t really see a lot of value in saying =E2=80=9Clet=E2=80=99s = retread things from a decade and a half ago that didn=E2=80=99t work.=E2=80= =9D laura >=20 >=20 > Best > Ale > --=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_64F5919D-36C3-4556-8B43-3ECC828BEB85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 Aug 2020, at 12:25, Alessandro Vesely <vesely@tana.it> = wrote:

On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:

The forum = page is off the FTC website, but the document links are
still accessible:

A copy is here:
https://web.archive.org/web/20120603201012/https://www.ftc.gov/= bcp/workshops/e-authentication/

A = sentence says:

   The = Report, however, identified domain-level authentication as a
   promising technological development that = would enable Internet
   Service Providers = (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and other domain holders to = better
   filter spam, and that would = provide law enforcement with a potent
=    tool for locating and identifying spammers.

And, 17 = years on, we know that domain level authentication doesn=E2=80=99t = actually help filter spam nor does it provide law enforcement with a = potent tool for locating and identifying spammers. It was promising, it = didn=E2=80=99t live up to the promise. 

There were a lot of thrown at the wall during = those 3 days of talks. One of them was domain level opt-out. Another was = a global opt-out list similar to the postal opt-outs run by the DMA. = Another was a technology called TEOS. HashCash. The list of things we = discussed as promising solutions was extensive. Just because we = discussed a particular kind of solution does not mean that anything was = decided. It also doesn=E2=80=99t mean that any particular solution = mentioned was workable. 

https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day1.pdf
https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day2.pdf
https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day3.pdf


Thanks.  Let me quote a paragraph by Paul = Q. Judge, from the 3rd pdf:

=    It doesn't require that one day everyone turns it on = and we begin
   to drop the rest of the = e-mail and break e-mail.  If a domain
=    decides to turn it on, then they've prevented forgery = for their
   domain and they're protected. =  For persons that have not turned it
=    on, then their e-mail still flows but they are not = able to
   stop people from forging = messages from their domain.  So, I think
=    it's something useful and can be deployed = incrementally.

We know, now, that turning on domain level = protection does not stop phishing attacks against that company. It stops = direct spoofing of the domain, but the phishers simply use a completely = different domain. Just this weekend I got a PayPal phish. PayPal who = helped invent DMARC are still getting spoofed and phished. Sure, the = phishers aren=E2=80=99t using the paypal.com domain, but that doesn=E2=80=99t seem to = have any effect on their success at stealing money from = people. 

It seems we're still stuck = midstream...

Stuck at what? Many of the people who were at that = conference are still working in the field and understand both the = purpose and what came out of the forum. I=E2=80=99d also say that most = of what happened there is a nice bit of history but is also irrelevant = to addressing the spam problem as it is now. Email has evolved = significantly in the last 5 years, much less the last 15. We can use the = discussion as history to say =E2=80=9Cwe looked at this and it didn=E2=80=99= t work=E2=80=9D but I don=E2=80=99t really see a lot of value in saying = =E2=80=9Clet=E2=80=99s retread things from a decade and a half ago that = didn=E2=80=99t work.=E2=80=9D

laura




Best
Ale
--
















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

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_64F5919D-36C3-4556-8B43-3ECC828BEB85-- From nobody Mon Aug 17 05:39:08 2020 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 7D2723A1513 for ; Mon, 17 Aug 2020 05:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 7SeIu8GKFnn1 for ; Mon, 17 Aug 2020 05:39:04 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 C26443A1506 for ; Mon, 17 Aug 2020 05:39:04 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id p4so14796396qkf.0 for ; Mon, 17 Aug 2020 05:39:04 -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=6c81h8A5JblDMoX58iHuEfSYTWMg3B0fpEbBphi0BbU=; b=eg3MbNQt6WQigq45FnEaZg3yzsKxavhmWko29T99yCLBl6XpyYqE3Lm8FhSXqBQU2R mFaoVwGSzB8OpJKKzggL051MlafQg3YuekTF9hUP0tlRDvQmxDwkyOZTdd+ypSPELpcn iLakM5Mzt5ZkkDPsLjJ3fxDuOu2cwAF/4pugsvFGUsleR10BQvz65f4bt8SaHaBEgPTS 0ZiS/bRKJbZTvyPdziejSpA5qWyZUwbqT3JvqkZtU5TZehJDi5vYR++3ppkrazMqyUqN Ud1k22Q+oTPyOi8EI1rN+YBPit1jYTwmWb04dflz2eOL6BI8+6bCngkNj4FPi8JIYssM 0ixQ== 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=6c81h8A5JblDMoX58iHuEfSYTWMg3B0fpEbBphi0BbU=; b=VQY0b8VuHfvLgYkCGIy+xkKi+fL5DTTn4MTVRHDIHXuIe7qgB6bJXDGRo8Fkb3EW09 evgkFQsEhmbLWTsbm/Vcm+r+PKSVDjIsPEYvRGo3BW0znmN+P+boJsQ00VcXdcjneoXr eoFa3yBOGX+y1vHvHoiquPh4rllfGIhe/GpX9EFZ707TAeHOr+/5rMWM7Lr15aMRPj4B cCYO4n9vuvZDulUvFM+ffEVE2lN5t0NFncebRgA3zS6txUzC7yerrY4wD6V2640S1R9p 50gzYQPTDt0NHjZLRc9+DqJmoyFP+Oblnl2ybmpoOeTOVs2m3osrvJgFhqtrCUamw81+ N+rw== X-Gm-Message-State: AOAM531TQt5WTkJdHKFrT6jCr9PSko8AWnelOGUVt+AyITRiEZNIFyip +XJ9jjDHCyVRmAF99eZUwbDHKN/4gsoERyKYzt/TubZ1 X-Google-Smtp-Source: ABdhPJy9YjOsepE5NIgs2shVWBi652V2TYhA/NTHti9tDsktO5CU7cNKZlgV1FIyGkbRqL0ASPIc/9XSuNJ/vNq0IDo= X-Received: by 2002:ae9:e902:: with SMTP id x2mr12688000qkf.66.1597667943725; Mon, 17 Aug 2020 05:39:03 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> In-Reply-To: From: Dotzero Date: Mon, 17 Aug 2020 08:38:51 -0400 Message-ID: To: Dave CROCKER Cc: Alessandro Vesely , John Levine , IETF DMARC WG , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="00000000000041407305ad120eea" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 12:39:08 -0000 --00000000000041407305ad120eea Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 11:31 AM Dave Crocker wrote: > > > 2. There was nothing 'established' at that event. There were > interesting discussions, but that's all. > In fact, some of the most interesting discussions took place outside the formal event. > > 3. I'm not finding the reference in any of Doug's notes that your are > relying on. Please be specific about it. > > > > Doug recalled. Your gmail address needs to be authenticated by gmail. > > Good grief, no. There is no system rule to that effect. DMARC created > that, but no policy before it was in place, nevermind accepted. > We need to be very careful in asserting what DMARC does or does not do. DMARC does not prevent spoofing within an email domain. So continuing the gmail example, DMARC would not prevent dcrocker@gmail.com from pretending to be dotzero@gmail.com within the gmail system. There are other mechanisms for preventing this, but DMARC is not that solution. > > > > Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and > > whitelisted as yet another domain (songbird.com) can hardly be > > verified. There is no "pretending", since it's you, but it is not > > formally distinguishable from spoof, is it? > > Whether valid and invalid uses can be distinguished does not alter the > fact that valid uses are valid. > What are valid uses constitutes a key part of the discussion. At one end of the discussion is "We have always done it this way so go away". At the other end of the discussion is "Tough noogies, thing change". An interesting question is who gets to determine what is a valid use? Another aspect is whether such determinations are technical, political, legal, social or ? Part of the difficulty we are having with our discussions here is that people are conflating the various aspects of the problem space. Michael Hammer --00000000000041407305ad120eea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 16, 2020 at 11:31 AM Dave= Crocker <dhc@dcrocker.net> w= rote:


2. There was nothing 'established' at that event.=C2=A0 There were =
interesting discussions, but that's all.

In fact, some of the most=C2=A0interesting discussions took place out= side the formal event.

3. I'm not finding the reference in any of Doug's notes that your a= re
relying on.=C2=A0 Please be specific about it.


> Doug recalled.=C2=A0 Your gmail address needs to be authenticated by g= mail.

Good grief, no.=C2=A0 There is no system rule to that effect.=C2=A0 DMARC c= reated
that, but no policy before it was in place, nevermind accepted.

We need to be very careful in asserting what DMARC= does or does not do. DMARC does not prevent spoofing within an email domai= n. So continuing the gmail example, DMARC would not prevent dcrocker@gmail.com from pretending to be dotzero@gmail.com within the gmail system= . There are other=C2=A0mechanisms for preventing this, but DMARC is not tha= t solution.


> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and
> whitelisted as yet another domain (songbird.com) can hardly be
> verified.=C2=A0 There is no "pretending", since it's you= , but it is not
> formally distinguishable from spoof, is it?

Whether valid and invalid uses can be distinguished does not alter the
fact that valid uses are valid.

What ar= e valid uses constitutes a key part of the discussion.=C2=A0 At one end of = the discussion is "We have always done it this way so go away". A= t the other end of the discussion is "Tough noogies, thing change"= ;. An interesting question is who gets to determine what is a valid use? An= other aspect is whether such determinations are technical, political, legal= , social or ? Part of the difficulty we are having with our discussions her= e is that people are conflating the various aspects of the problem space.

Michael Hammer
--00000000000041407305ad120eea-- From nobody Mon Aug 17 05:48:49 2020 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 0FC783A0BAB for ; Mon, 17 Aug 2020 05:48:47 -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, 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 a-Z3vVb-VJJM for ; Mon, 17 Aug 2020 05:48:45 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 3A8FC3A0BAA for ; Mon, 17 Aug 2020 05:48:45 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id j187so14759497qke.11 for ; Mon, 17 Aug 2020 05:48:45 -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; bh=5OtQtfd8MAfzJgWsSaR8YFfBz/wmKVJ91FclSW9H3tY=; b=XFlSrC5Se4yhHtQMYDLuoFKZ/6Gd0Wccu5KNqOYyTCS8flfvsLhJTJgDvdy8PdHRxD 4yEZE3jUsilr9gaNUtcDmqrwi2R/oxxxdfA03WDikO9HtBb6MfO89Y2eDyUnOvf/OMQe 9Rxx52gQws08aGjBDo1BEqKbQGUdX2hlVXREhBWrwetsvIHWtr/dij9KGz+lIQSewnt9 pFctpTeQHe1uROsypAZQ/z1xMbGl0W6XWHZCGPTXTafpeY927IGHVALy4MljQ/gcvu8V fC+dvlRl8bst2PnqY8bWfyA+QEKg2p7miJRJpduHWzdeo1HTtn4aVdkZjFNWPquwS9G/ bh6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5OtQtfd8MAfzJgWsSaR8YFfBz/wmKVJ91FclSW9H3tY=; b=ZUO24Xmqtemo557TBAjeoJDB+NgDv+9K8s7i6JGqwxSgg/glk8oVlwQHneHKn13hqt IyHzS7FAblNAKTO3FkUB+hjkNOJzpGCQNiUxQt5vaGf1qBV/b9zP3VCAqMladB3LXPYe LXCO7Kx5A5HSpqH/kgzHmxs5tf2jLfxNqEHZ6TuldIdvg+atqeegRz4W6K7MA6c/Q0tK BDrcVARyMP2KH37AU16Zywj5rtYnP7scQV+iQ15B85yk5u9xnCLK+cyAX46Ye4QctAbF YENHPISQzJ7liH+3ddP6tvC4Mu9WOFjJR7zn3Sr9fXN3FPtqMs20/ancJQxOKEUI0ppc JX8g== X-Gm-Message-State: AOAM530IsHd4m1oyXBbEKkxVRqfh7Mv0Idm9tRVJpgkuCdPeNgh99QAg GQJjwqrrs7Xp+WmsENsi8uA01vnv7P4PvdWBJbjcz7uj X-Google-Smtp-Source: ABdhPJzAZtaFYJ2hB4i97+3ptG+kbMTzR+xXqr6XgnjZX3izAbgM6vxdvOZmh87xMieR1W7H8zJxP5Rpe0PuNnrveoQ= X-Received: by 2002:a37:9f0a:: with SMTP id i10mr13194814qke.368.1597668522452; Mon, 17 Aug 2020 05:48:42 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> In-Reply-To: <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> From: Dotzero Date: Mon, 17 Aug 2020 08:48:31 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bfed1105ad123055" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 12:48:47 -0000 --000000000000bfed1105ad123055 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely wrote: > > >> That conflicts with the coarse-grained authentication strategy, > >> established at the FTC Email Authentication Summit in November > >> 2004, as Doug^W Michael recalled. > > > There was no such strategy established regardless of what one person remembers. > > > > > 2. There was nothing 'established' at that event. There were > > interesting discussions, but that's all. > Agreed. > > > I wasn't there. Can't it be considered the historic event that marked > domain-level authentication as the promising strategy to counter email > abuse? > Nope. It was one of many things presented/disccussed. > > https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E > > > >> Your gmail address needs to be authenticated by gmail. > > > > Good grief, no. There is no system rule to that effect. DMARC > > created that, but no policy before it was in place, never mind accepted. > Just to reiterate, DMARC, SPF and DKIM operate at the domain level granularity, not at the individual email address level granularity. > > > DMARC took that strategy to the extremes. A number of users and > operators seem to have accepted it. Why cannot we accept it too? > DMARC does one thing and one thing only, and that is to mitigate direct domain abuse. It was not intended to stop phishing, spam or anything but direct domain abuse. The issues with uses such as mailing lists were identified and noted. > > > >> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and > >> whitelisted as yet another domain (songbird.com) can hardly be > >> verified. There is no "pretending", since it's you, but it is not > >> formally distinguishable from spoof, is it? > > > > Whether valid and invalid uses can be distinguished does not alter the > > fact that valid uses are valid. > > > The problem is to find the technical means that allow receivers and > recipients to verify such validity. > > > >>> This continuing practice of characterizing valid use as if it were > >>> spoofing or pretending has been a major impediment to constructive > >>> discussion in the industry. > >> > >> A system that is able to recognize all your domains and affiliations > >> in order to authenticate messages does cost several orders of > >> magnitude more than a simple "mechanical" verifier. That way, > >> requiring too much flexibility is a push toward oligopoly. > > > > I have no idea what you are referring it. > > > Gmail has a visual perspective that allows them to know each and every > email domain worldwide, and employs a number of people who help > continuously upgrading domain reputation. In order to enjoy such > technology, medium-small domains can get a G Suite account. That's > oligopoly. If the technology were simpler and clearer, running one's > own mail server could be a valid alternative. > Setting aside DMARC, running email servers has always had a bit of complexity that is beyond the ability of the average person. I'm not sure what your point here is. Michael Hammer --000000000000bfed1105ad123055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 16, 2020 at 2:03 PM Aless= andro Vesely <vesely@tana.it> w= rote:

>> That conflicts with the coarse-grained authentication strategy, >> established at the FTC Email Authentication Summit in November
>> 2004, as Doug^W Michael recalled. >

Th= ere was no such strategy established regardless of what one person remember= s.



> 2. There was nothing 'established' at that event.=C2=A0 There = were
> interesting discussions, but that's all.

=
Agreed.=C2=A0


I wasn't there.=C2=A0 Can't it be considered the historic event tha= t marked
domain-level authentication as the promising strategy to counter email
abuse?

Nope. It was one of many things = presented/disccussed.=C2=A0

https://mailarchive.ietf.org/= arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E


>> Your gmail address needs to be authenticated by gmail.
>
> Good grief, no.=C2=A0 There is no system rule to that effect.=C2=A0 DM= ARC
> created that, but no policy before it was in place, never mind accepte= d.

Just to reiterate, DMARC, SPF and DK= IM operate at the domain level granularity, not at the individual=C2=A0emai= l address level granularity.=C2=A0


DMARC took that strategy to the extremes.=C2=A0 A number of users and
operators seem to have accepted it.=C2=A0 Why cannot we accept it too?
<= /blockquote>

DMARC does one thing and one thing only, an= d that is to mitigate direct domain abuse. It was not intended to stop phis= hing, spam or anything but direct domain abuse. The issues with uses such a= s mailing lists were identified and noted.=C2=A0=C2=A0


>> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and
>> whitelisted as yet another domain (songbird.com) can hardly be
>> verified.=C2=A0 There is no "pretending", since it's= you, but it is not
>> formally distinguishable from spoof, is it?
>
> Whether valid and invalid uses can be distinguished does not alter the=
> fact that valid uses are valid.


The problem is to find the technical means that allow receivers and
recipients to verify such validity.


>>> This continuing practice of characterizing valid use as if it = were
>>> spoofing or pretending has been a major impediment to construc= tive
>>> discussion in the industry.
>>
>> A system that is able to recognize all your domains and affiliatio= ns
>> in order to authenticate messages does cost several orders of
>> magnitude more than a simple "mechanical" verifier.=C2= =A0 That way,
>> requiring too much flexibility is a push toward oligopoly.
>
> I have no idea what you are referring it.


Gmail has a visual perspective that allows them to know each and every
email domain worldwide, and employs a number of people who help
continuously upgrading domain reputation.=C2=A0 In order to enjoy such
technology, medium-small domains can get a G Suite account.=C2=A0 That'= s
oligopoly.=C2=A0 If the technology were simpler and clearer, running one= 9;s
own mail server could be a valid alternative.

Setting aside DMARC, running email servers has always had a bit of c= omplexity that is beyond the ability of the average person. I'm not sur= e what your point here is.

Michael Hammer=C2=A0
--000000000000bfed1105ad123055-- From nobody Mon Aug 17 05:54:08 2020 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 438333A0BD7 for ; Mon, 17 Aug 2020 05:54:07 -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, 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 ZzMonbhXpHPX for ; Mon, 17 Aug 2020 05:54:06 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 F0E773A0BB3 for ; Mon, 17 Aug 2020 05:54:05 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id y11so7683499qvl.4 for ; Mon, 17 Aug 2020 05:54:05 -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=VvZWvdq2hjhTiMiCs4bnFUE4kYUsQlszs3o6b8U4O0s=; b=iaQCbGbtK3wu02NOdrFBfpwxpGu21phiRDFirXxxP07AcaP1Yz3nBXw4PJPhDd92s5 iuAL9K3nVHXDtdonKPN4w8Arf0aYPv9njWEf53sX5qgz1EKmpw8a4m+72NVyji2kl0VT mTUClbRYVOEENC0RvrfsHugz5IiQSOblCcl6yqg8G7UUL8fXnm0TehQZCIV7d2n5OfWq 7UsmdUcjkqqS8QInWoiamC14p0wpZyaPIyl+g/QHjKqdLBJE6WP5msNLkQp2WEDlHx5G lfu5KMV1llWckW/b0LZKyZdX7kqX5814DbE28S1WBmVWA68ZY1vplXU7CLzqA12XPzGY nm3w== 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=VvZWvdq2hjhTiMiCs4bnFUE4kYUsQlszs3o6b8U4O0s=; b=UCeeIB4mfQsouR6nMNnTAE9+RIcxkqfnKpwyN2UfSjQnSf9oUqCA0lYNh8IEoV08lK Yr4btAdWgPNFyI7FOZRoKPKThPYdhDtmkOTCTrYiNI2Ey+YPyKzm0I2HHxDqeJMhqmQi j3nPLPesBKNZaRAhBehLEQxUz2AHqTJvL5IpuM/C6Lnmtv/wzjv+ozzKGdRG/IrB728U 9lnl1hqjRFvjPkHcz9T1jZltysb2izOV+0IUNKWUsvXLPE2oho1gRN5FXx4Z+yEAm/in i99cgKwndMEB6inrSx3pUP5LAFuIM4H5C7MuAo+rKylKfmsi65M/cdJmVg63YcAff6Ti Wi4Q== X-Gm-Message-State: AOAM532es+7Ubz1SRHN186Q4NFCGco0lqOySWbiXPMe2kwdJPo+e6lOS OT8IyUT4uF39xSLv4nVed5TiXP/JVMheSSwJZNi4QOl+ X-Google-Smtp-Source: ABdhPJzyx+QNUM4NQUulAO3DQY5UTI1l/4GlaqCV74S7n8TL08VGLDIkHcOAgHf2Z7MvyEqaeoWEWcXtP7zE/BqwyEw= X-Received: by 2002:a0c:ffc6:: with SMTP id h6mr14411083qvv.251.1597668845051; Mon, 17 Aug 2020 05:54:05 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> In-Reply-To: From: Dotzero Date: Mon, 17 Aug 2020 08:53:54 -0400 Message-ID: To: John R Levine Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fa632505ad1243c3" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 12:54:07 -0000 --000000000000fa632505ad1243c3 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 2:17 PM John R Levine wrote: > > No, it was just some political theatre. We were already working on SPF > and DKIM. > DKIM didn't exist until that approximate time frame. There was Domain Keys (DK) and there was Internet Identified Mail (IIM) > > > DMARC took that strategy to the extremes. A number of users and > operators > > seem to have accepted it. Why cannot we accept it too? > > Please review the previous bazillion messages on this topic. > Are those bazillion messages authenticated? ;-) Michael Hammer --000000000000fa632505ad1243c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 16, 2020 at 2:17 PM John = R Levine <johnl@taugh.com> wro= te:

No, it was just some political theatre.=C2=A0 We were already working on SP= F
and DKIM.

DKIM didn't exist=C2=A0 u= ntil that approximate time frame. There was Domain Keys=C2=A0(DK) and there= was Internet Identified Mail (IIM)

> DMARC took that strategy to the extremes.=C2=A0 A number of users and = operators
> seem to have accepted it.=C2=A0 Why cannot we accept it too?

Please review the previous bazillion messages on this topic.

Are those bazillion messages=C2=A0authenticated? ;-)<= /div>

Michael Hammer
--000000000000fa632505ad1243c3-- From nobody Mon Aug 17 06:05:03 2020 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 4303F3A1528 for ; Mon, 17 Aug 2020 06:05:00 -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, 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 29RU6Oo-Z7Fd for ; Mon, 17 Aug 2020 06:04:52 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 A89DA3A152C for ; Mon, 17 Aug 2020 06:04:52 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 2so14791758qkf.10 for ; Mon, 17 Aug 2020 06:04:52 -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=YXTZOVY8N2V66ZFYvX1qDaccKyOMp1kyRrV+XYcuuo8=; b=LP/5/pgYoEyonfSnoKEZLqQo9feCC7lvw5AwTnKIEkhJhGPuznJ/+MkbDLDWMDWMEh Y1spmlQPxTZzSgdrxOhDUMyJ6QVflEN8g+3e94F+f3q8LDBMb6d0ZP/718DNFuDZaHZL ZlxSFCivQoOYBdS4pgwQZ4ryVS8zuCryVQjdGnzsDBT13dKJd5b/HXGRocgd1DELox1h YbmbwuktWX5W7/SoiLXJmKFuj2cUlf8z0LjMEmWjZVCOsjVUevYbNK5bpgBaV2nOMqU/ 5lmvtvqKMOOUTiyhy/6OjyetCy2ahEYqORey38nR/vHPJcwTtUbtFZ+RzQnoYAxvNR3S wLtw== 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=YXTZOVY8N2V66ZFYvX1qDaccKyOMp1kyRrV+XYcuuo8=; b=eLCQuHuEtUqPPQ2sXkyXytdTq8eMONNNx9/jn7YlhXX3D368JfA8Hh2RUNJttb16zR RnCjwn/4xhpFugWTHGi3gurF42Y+zgrLGeRakZXousJIrKnK9IzZSPfIOr92V7sO9qv4 hHV7iF3+rp+KdyfRSsjJLKqXqFIZmJK032K3juv1plnPmqU8nw+MrcJUatEiM4GGFGHa zlIWSzDO7a6EsYywM6xrZim/S3GO2PmDC3OMiaaDrl75UZqmbHziD0bwPnsuE5EaWSPk sAgCvVkGrs4CkhMzRtN6jNW4oVa+l1ctFbp/RwyEC14xuK3SAB+BCoaZ9AICt+9C2Cnp gnLw== X-Gm-Message-State: AOAM532rJV1v3LnNf+svzb4ggOHTpixu1g6Bkq6/1L2TiXCa0OnNcwf9 wm+or1rbysJmjVj/WU0pn9H7qJPxRPDrNg1oS+HBZjew X-Google-Smtp-Source: ABdhPJxLjuub/Qpg3QKq9202X0ekliLrhGHm7sVvhjAAvO+/FbZv2GxoivptZNw5Q/2aT7gdvVvdNiOHrmtZlv5Ibmg= X-Received: by 2002:ae9:e902:: with SMTP id x2mr12775606qkf.66.1597669491656; Mon, 17 Aug 2020 06:04:51 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <1703e878-e20a-8ae2-09e8-25470c0cf5f8@dcrocker.net> In-Reply-To: From: Dotzero Date: Mon, 17 Aug 2020 09:04:40 -0400 Message-ID: To: Alessandro Vesely Cc: Dave CROCKER , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000084cc2e05ad126ab7" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:05:00 -0000 --00000000000084cc2e05ad126ab7 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 5:58 AM Alessandro Vesely wrote: > On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: > > > >>>>> If I put my gmail address into the from field, there is no > >>>>> pretending, no matter what platform I am using. > >>>> > >>>> > >>>> That conflicts with the coarse-grained authentication strategy, > >>>> established at the FTC Email Authentication Summit in November > >>>> 2004, as Doug^W Michael recalled >>> > >>> 1. I was making a semantic point, not a technical or technical > >>> policy one. > >> > >> They have to match at some point. > > > > it would be nice, wouldn't it? > > > > but that's separate from the factual statement I made. > > > Separate but related. > > > >>> 2. There was nothing 'established' at that event. There were > >>> interesting discussions, but that's all. > >> > >> > >> I wasn't there. Can't it be considered the historic event that > >> marked domain-level authentication as the promising strategy to > >> counter email abuse? > > > > Reference to that event as if it 'established' anything is misguided, > > at best. The meetings were helpful, but not definitive. And the > > efforts at domain level authentication were wholly independent of > > these events. > > > Would it be still correct to mention that summit as a conspicuous > event that testifies the emergence of domain-level authentication > around the early 2000s? > > As someone who was there, I would be reticent to make such a statement. > > > As already noted on this list, the events served as a plea from the > > government and, therefore, a signal that the government was concerned. > > > A noteworthy historical detail. > I think myself and many others considered it more of an ultimatum to the private sector than a plea. > > > >>>> Your gmail address needs to be authenticated by gmail. > >>> > >>> Good grief, no. There is no system rule to that effect. DMARC > >>> created that, but no policy before it was in place, never mind > >>> accepted. > >> > >> > >> DMARC took that strategy to the extremes. A number of users and > >> operators seem to have accepted it. Why cannot we accept it too? > > > > That DMARC does something and that some people use it is quite > > different from claiming that there was some grand change in the > > semantics and operational policy of email. Why can't THAT be accepted? > I think this is one of those areas that where you sit dictates where you stand on the issue. When we talk about the evolution of the Internet we could also go back to the days of AUP and talk about changes. Just saying. > > There's been a combination of events, from IETF's reluctant > laissez-faire to Yahoo/AOL adoption, which brought up the illusion > that email authentication can provide a global means to counter > spoofing. To believe that such illusion will come true makes for a > strong motivation. > We really do need to stop using the word "spoofing" when we talk about intermediaries such as MLMs. > > Couldn't we meet somewhere halfway? I can see that you, John, Herr > Hammer, and other relevant participants don't accept that domain-level > authentication is semantically mandatory. What d'you reckon about the > possibility that such grand semantic change can be made official > within the next 10~20 years? I think that by just spelling the > technical means /as if/ such change is going to happen, we can design > a consistent authentication protocol. > Could people please stop referring to me as Herr Hammer. I am neither German nor a Herr. > It seems to me most expenses have been paid already, for example this > mailing list is applying From: rewriting. We don't need to propose > further restrictions. To the opposite, there are means on the > table[*] that can enable us to sketch a time horizon where From: > rewriting can cease. > > 16 years have passed since the FTC event, which is 1/3 of those 45. > What I see looks much like a very mild shift. Lazy operators have > plenty of time before the semantic change is established, at some > point in the medium-term future, if ever. > Notwithstanding my position on the issues being discussed, I think it is unfair and inappropriate to refer to those opposed to changing semantics as "lazy operators". Just because you want a change and they are against such change does not make them lazy. Michael Hammer --00000000000084cc2e05ad126ab7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 5:58 AM Aless= andro Vesely <vesely@tana.it> w= rote:
On Sun 16/= Aug/2020 20:16:17 +0200 Dave Crocker wrote:
>
>>>>> If I put my gmail address into the from field, there i= s no
>>>>> pretending, no matter what platform I am using.
>>>>
>>>>
>>>> That conflicts with the coarse-grained authentication stra= tegy,
>>>> established at the FTC Email Authentication Summit in Nove= mber
>>>> 2004, as Doug^W Michael recalled >>>
>>> 1. I was making a semantic point, not a technical or technical=
>>> policy one.
>>
>> They have to match at some point.
>
> it would be nice, wouldn't it?
>
> but that's separate from the factual statement I made.


Separate but related.


>>> 2. There was nothing 'established' at that event.=C2= =A0 There were
>>> interesting discussions, but that's all.
>>
>>
>> I wasn't there.=C2=A0 Can't it be considered the historic = event that
>> marked domain-level authentication as the promising strategy to >> counter email abuse?
>
> Reference to that event as if it 'established' anything is mis= guided,
> at best.=C2=A0 The meetings were helpful, but not definitive.=C2=A0 An= d the
> efforts at domain level authentication were wholly independent of
> these events.


Would it be still correct to mention that summit as a conspicuous
event that testifies the emergence of domain-level authentication
around the early 2000s?


As someone who was there, I would be r= eticent to make such a statement.=C2=A0

> As already noted on this list, the events served as a plea from the > government and, therefore, a signal that the government was concerned.=


A noteworthy historical detail.

I think= myself and many others considered it more of an ultimatum to the private s= ector than a plea.=C2=A0


>>>> Your gmail address needs to be authenticated by gmail. >>>
>>> Good grief, no.=C2=A0 There is no system rule to that effect.= =C2=A0 DMARC
>>> created that, but no policy before it was in place, never mind=
>>> accepted.
>>
>>
>> DMARC took that strategy to the extremes.=C2=A0 A number of users = and
>> operators seem to have accepted it.=C2=A0 Why cannot we accept it = too?
>
> That DMARC does something and that some people use it is quite
> different from claiming that there was some grand change in the
> semantics and operational policy of email.=C2=A0 Why can't THAT be= accepted?

I think this is one of those= areas that where you sit dictates where you stand on the issue. When we ta= lk about the evolution of the Internet we could also go back to the days of= AUP and talk about changes. Just saying.=C2=A0
=C2=A0

There's been a combination of events, from IETF's reluctant
laissez-faire to Yahoo/AOL adoption, which brought up the illusion
that email authentication can provide a global means to counter
spoofing.=C2=A0 To believe that such illusion will come true makes for a strong motivation.

We really do need to= stop using the word "spoofing" when we talk about intermediaries= such as MLMs.=C2=A0

Couldn't we meet somewhere halfway?=C2=A0 I can see that you, John, Her= r
Hammer, and other relevant participants don't accept that domain-level =
authentication is semantically mandatory.=C2=A0 What d'you reckon about= the
possibility that such grand semantic change can be made official
within the next 10~20 years?=C2=A0 I think that by just spelling the
technical means /as if/ such change is going to happen, we can design
a consistent authentication protocol.

C= ould people please stop referring to me as Herr Hammer. I am neither German= nor a Herr.=C2=A0
=C2=A0
It seems to me most expenses have been paid already, for ex= ample this
mailing list is applying From: rewriting.=C2=A0 We don't need to propos= e
further restrictions.=C2=A0 To the opposite, there are means on the
table[*] that can enable us to sketch a time horizon where From:
rewriting can cease.

16 years have passed since the FTC event, which is 1/3 of those 45.
What I see looks much like a very mild shift.=C2=A0 Lazy operators have plenty of time before the semantic change is established, at some
point in the medium-term future, if ever.

Notwithstanding my position on the issues being discussed, I think it is= unfair and inappropriate to refer to those opposed to changing semantics a= s "lazy operators". Just because you want a change and they are a= gainst such change=C2=A0does not make them lazy.=C2=A0=C2=A0

=
Michael Hammer
--00000000000084cc2e05ad126ab7-- From nobody Mon Aug 17 06:17:44 2020 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 6D00E3A1542 for ; Mon, 17 Aug 2020 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 xQasITCSfDmK for ; Mon, 17 Aug 2020 06:17:41 -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 758C83A1541 for ; Mon, 17 Aug 2020 06:17:41 -0700 (PDT) Received: from [10.0.0.178] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07HDKQUs016362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2020 06:20:27 -0700 To: Alessandro Vesely Cc: IETF DMARC WG References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <1703e878-e20a-8ae2-09e8-25470c0cf5f8@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <06858bda-d3e2-aa71-88a8-e7401f267842@dcrocker.net> Date: Mon, 17 Aug 2020 06:17:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:17:43 -0000 On 8/17/2020 2:57 AM, Alessandro Vesely wrote: >> Reference to that event as if it 'established' anything is misguided, >> at best.  The meetings were helpful, but not definitive.  And the >> efforts at domain level authentication were wholly independent of >> these events. > > > Would it be still correct to mention that summit as a conspicuous event > that testifies the emergence of domain-level authentication around the > early 2000s? No. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 17 06:19:05 2020 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 EF14B3A1518 for ; Mon, 17 Aug 2020 06:19:03 -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, 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 TYcufi3OxP1w for ; Mon, 17 Aug 2020 06:19:02 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 11F053A14E7 for ; Mon, 17 Aug 2020 06:19:01 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id n129so14863805qkd.6 for ; Mon, 17 Aug 2020 06:19:01 -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=/xmjlRSY0ECSmpsazv61UGKuAZq5dR/kBQIIOp3N9QI=; b=b8toshMq/3VgswzQIfu5bSUb0n7JG9nKGwaaafXd0557cQ6IAt3CKnNTg3SKpkV622 m2b1BSxviUUxqgMDJbATj0Qa6ubU5O/r/BJNpmdoRECWdZGFIVpmzMx3kIUVC0NDBlFf f8S9KVu8BW7/rB/wmwOfV57FCtZbXpaI9jJ1Q1lv3jVK0z8oj78nVXNSVWk0hymuJE6e +XazPpxjlGwzYxGMWlB5UM6xS1mf1G9qI8MUmZxYklARxg79eZcwiNh/X49Z6EtZAjNI P/w1k57mP+UwuZjClMrrlYs0DOawIAOQuY0c/ouI7MfBrSosCuQ3oWBywfHmONYoOUjO RDkw== 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=/xmjlRSY0ECSmpsazv61UGKuAZq5dR/kBQIIOp3N9QI=; b=dVwmlPsbGAMwaOdE512YKKsJAHPocEyXTxBl3O9AZXF2AXTU8NO2LGr2oL7y08VoV7 B83oBq9ZrTF//NunfNZH63aSbKFubHQlGuP4SjTnyNFRYq4K1RGkSO57j+hYDic4XvTs SrxDFVK5mYQ6rW/hT3l0a+MrbI69qYQMKUWNPNgAoMCtSZsS5eBEwSMACt0ujurOo08T YicEJN7r4hjWovhwWxDMFJfjAg8tQzGk0Q5qSBTf5p0c7GGFEfEVW0Nai+pHXFhPEt5z JzefYgVSN93uoz8Z9KsalAUgO5AmpwWQ6HGibkE0CFeDLt5RvHN9+uW1YV8K1+omVyyF tRtw== X-Gm-Message-State: AOAM533Br81uaMiOV5zGzefVIuh4RQ1t63aQvbIPtMFhvRmHiUaiLHsA dsLO5AILG81NXLxAqqmhtaMZt7auZwts2fuSGVB7L4NS X-Google-Smtp-Source: ABdhPJwDbmaCcmlYETP4m6Ca1gdTjVUQXWphXJ8Sp6RsXQlvXtBC5BZwsPUftEWGUdJWNSGnZ9+FqXE5Iix1aPvfoJo= X-Received: by 2002:a05:620a:545:: with SMTP id o5mr12242274qko.187.1597670341048; Mon, 17 Aug 2020 06:19:01 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> In-Reply-To: <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> From: Dotzero Date: Mon, 17 Aug 2020 09:18:50 -0400 Message-ID: To: Laura Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000025808b05ad129d07" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:19:04 -0000 --00000000000025808b05ad129d07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2020 at 8:22 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: > > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > > The forum page is off the FTC website, but the document links are > still accessible: > > > > A copy is here: > > https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/worksh= ops/e-authentication/ > > A sentence says: > > The Report, however, identified domain-level authentication as a > promising technological development that would enable Internet > Service Providers (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and other= domain holders to better > filter spam, and that would provide law enforcement with a potent > tool for locating and identifying spammers. > > > And, 17 years on, we know that domain level authentication doesn=E2=80=99= t > actually help filter spam nor does it provide law enforcement with a pote= nt > tool for locating and identifying spammers. It was promising, it didn=E2= =80=99t > live up to the promise. > > There were a lot of thrown at the wall during those 3 days of talks. One > of them was domain level opt-out. Another was a global opt-out list simil= ar > to the postal opt-outs run by the DMA. Another was a technology called > TEOS. HashCash. The list of things we discussed as promising solutions wa= s > extensive. Just because we discussed a particular kind of solution does n= ot > mean that anything was decided. It also doesn=E2=80=99t mean that any par= ticular > solution mentioned was workable. > > > https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-= forum/transcript_day1.pdf > > https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-= forum/transcript_day2.pdf > > https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-= forum/transcript_day3.pdf > > > > Thanks. Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf: > > It doesn't require that one day everyone turns it on and we begin > to drop the rest of the e-mail and break e-mail. If a domain > decides to turn it on, then they've prevented forgery for their > domain and they're protected. For persons that have not turned it > on, then their e-mail still flows but they are not able to > stop people from forging messages from their domain. So, I think > it's something useful and can be deployed incrementally. > > > We know, now, that turning on domain level protection does not stop > phishing attacks against that company. It stops direct spoofing of the > domain, but the phishers simply use a completely different domain. Just > this weekend I got a PayPal phish. PayPal who helped invent DMARC are sti= ll > getting spoofed and phished. Sure, the phishers aren=E2=80=99t using the > paypal.com domain, but that doesn=E2=80=99t seem to have any effect on th= eir > success at stealing money from people. > You raise an interesting point, Laura. Whatever "solutions" we put in place, the abusers/bad guys will evolve. One of the problems for the good guys (for some definition of good) is that standards work takes years (decades?) while the bad guys change their tactics at will. Crime existed before the Internet and will continue long after we are all dead and buried= . > It seems we're still stuck midstream... > > > Stuck at what? Many of the people who were at that conference are still > working in the field and understand both the purpose and what came out of > the forum. I=E2=80=99d also say that most of what happened there is a nic= e bit of > history but is also irrelevant to addressing the spam problem as it is no= w. > Email has evolved significantly in the last 5 years, much less the last 1= 5. > We can use the discussion as history to say =E2=80=9Cwe looked at this an= d it > didn=E2=80=99t work=E2=80=9D but I don=E2=80=99t really see a lot of valu= e in saying =E2=80=9Clet=E2=80=99s retread > things from a decade and a half ago that didn=E2=80=99t work.=E2=80=9D > I think the most useful thing we can say about the FTC workshops is that they were a forcing mechanism that instigated a lot of effort and innovation in the space. Some of those efforts fell by the wayside and some still persist. Michael Hammer --00000000000025808b05ad129d07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 8:22 AM Laura= Atkins <laura@wordtothewise.= com> wrote:


On 17 Aug 2020, at 12:25, Alessandro Vesely <vesely@tana.it> wrote:
=
On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:

The forum page is off the FTC website, but the do= cument links are
still accessible:


A copy is he= re:
https://web.archiv= e.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication= /

A sentence says:

=C2=A0=C2=A0=C2=A0The Report, however= , identified domain-level authentication as a
=C2=A0=C2=A0=C2=A0promisi= ng technological development that would enable Internet
=C2=A0=C2=A0=C2= =A0Service Providers (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and other d= omain holders to better
=C2=A0=C2=A0=C2=A0filter spam, and that would p= rovide law enforcement with a potent
=C2=A0=C2=A0=C2=A0tool for locatin= g and identifying spammers.

And,= 17 years on, we know that domain level authentication doesn=E2=80=99t actu= ally help filter spam nor does it provide law enforcement with a potent too= l for locating and identifying spammers. It was promising, it didn=E2=80=99= t live up to the promise.=C2=A0

There were a lot o= f thrown at the wall during those 3 days of talks. One of them was domain l= evel opt-out. Another was a global opt-out list similar to the postal opt-o= uts run by the DMA. Another was a technology called TEOS. HashCash. The lis= t of things we discussed as promising solutions was extensive. Just because= we discussed a particular kind of solution does not mean that anything was= decided. It also doesn=E2=80=99t mean that any particular solution mention= ed was workable.=C2=A0

<= div>
https://www.ftc.gov/sites/default/files/documents/public_even= ts/ftc-spam-forum/transcript_day1.pdf
https://www.ftc.gov/sites/default/files/documents/p= ublic_events/ftc-spam-forum/transcript_day2.pdf
https://www.ftc.gov/sites/default/files/d= ocuments/public_events/ftc-spam-forum/transcript_day3.pdf


Thanks.=C2=A0 Let me quote a paragraph by Paul Q. Judge, from th= e 3rd pdf:

=C2=A0=C2=A0=C2=A0It doesn't require that one day ev= eryone turns it on and we begin
=C2=A0=C2=A0=C2=A0to drop the rest of t= he e-mail and break e-mail.=C2=A0 If a domain
=C2=A0=C2=A0=C2=A0decides= to turn it on, then they've prevented forgery for their
=C2=A0=C2= =A0=C2=A0domain and they're protected.=C2=A0 For persons that have not = turned it
=C2=A0=C2=A0=C2=A0on, then their e-mail still flows but they = are not able to
=C2=A0=C2=A0=C2=A0stop people from forging messages fro= m their domain.=C2=A0 So, I think
=C2=A0=C2=A0=C2=A0it's something = useful and can be deployed incrementally.
=
We know, now, that turning on domain level protection does n= ot stop phishing attacks against that company. It stops direct spoofing of = the domain, but the phishers simply use a completely different domain. Just= this weekend I got a PayPal phish. PayPal who helped invent DMARC are stil= l getting spoofed and phished. Sure, the phishers aren=E2=80=99t using the = paypal.com=C2=A0domain,= but that doesn=E2=80=99t seem to have any effect on their success at steal= ing money from people.=C2=A0

<= div>You raise an interesting point, Laura. Whatever "solutions" w= e put in place, the abusers/bad guys will evolve. One of the problems for t= he good guys (for some definition of good) is that standards work takes yea= rs (decades?)=C2=A0 while the bad=C2=A0 guys change their tactics at will. = Crime existed before the Internet and will continue long after we are all d= ead and buried.
<= div>It seems we're still stuck midstream...

Stuck at what? Many of the people who were at that con= ference are still working in the field and understand both the purpose and = what came out of the forum. I=E2=80=99d also say that most of what happened= there is a nice bit of history but is also irrelevant to addressing the sp= am problem as it is now. Email has evolved significantly in the last 5 year= s, much less the last 15. We can use the discussion as history to say =E2= =80=9Cwe looked at this and it didn=E2=80=99t work=E2=80=9D but I don=E2=80= =99t really see a lot of value in saying =E2=80=9Clet=E2=80=99s retread thi= ngs from a decade and a half ago that didn=E2=80=99t work.=E2=80=9D

I think the most=C2=A0
=C2=A0useful thing we can say about the FTC workshops is that they were a = forcing mechanism that instigated a lot of effort and innovation in the spa= ce. Some of those efforts fell by the wayside and some still persist.=

Michael Hammer
--00000000000025808b05ad129d07-- From nobody Mon Aug 17 06:45:22 2020 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 CBFAB3A1563 for ; Mon, 17 Aug 2020 06:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=columbia.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 G8edCo_LzjdO for ; Mon, 17 Aug 2020 06:45:18 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 0D68F3A1562 for ; Mon, 17 Aug 2020 06:45:17 -0700 (PDT) Received: from pps.filterd (m0167068.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07HDdQv1007057 for ; Mon, 17 Aug 2020 09:45:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : content-type; s=pps01; bh=r5j/qZ6soOttOuM8Bya4jboFDOFTW8rFz7lP8Zo3AoY=; b=qL/9H6eiXn90Ca3Wu/r0kIXCISSSw3OWDpDwl1GbN/aCczIGPb4jVEAto/r2EgqmOwXC DX8UtypwB1N7vtT6leYTAEoMLM9/SJHoc5BxlpiY45D45ALOl65R+aQ8zIfF0/4vzjoT d5Yd0OomCrCI+2rowXxYjdukpS8WngleIfurU+Hg6udLuAVXg9Vvoj+kG0lHJXGzd/IR FkmX88RpXDb3PSlkOd4+TQBE2UiioQZWr4WkE4u6UoBFVNuhuFDf/SqDJfXf2cwz179q fh/WkAK/wU1yy9JV9ZCvriPSLBGEyn1TFZgAZ9vL6rlGSWXjmoNLoWYa1RE34Rg23Blz xw== Received: from sendprodmail11.cc.columbia.edu (sendprodmail11.cc.columbia.edu [128.59.72.19]) by mx0a-00364e01.pphosted.com with ESMTP id 32x9ywrspk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Aug 2020 09:45:17 -0400 Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by sendprodmail11.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 07HDjFIu001527 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 17 Aug 2020 09:45:16 -0400 Received: by mail-io1-f71.google.com with SMTP id f22so9861552iof.20 for ; Mon, 17 Aug 2020 06:45:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=r5j/qZ6soOttOuM8Bya4jboFDOFTW8rFz7lP8Zo3AoY=; b=VJklxLFh33lQs4NLv0tkr3tqPdrWwclje+64Woj/MIg0PDI9D680zOUPHV9YYSGIPp uPNwPTGmFG/oWO6/nzBDyxdjpD+aLhEoZg2VGuLmVyesiq0WdruC1CkdiLjMdQTmIK+6 XpS9ABSLPVJ3UszzLhKlw0xI2+4/SXK6SQKHTu30AsaGZrKBOs3mnJNLh79F7uS+nD/x VnPXMiXXIMCq8Es1eOAwAE+P3g1CChhmWgm1iMYi2s4hQD34RzULtKcKc3/OMOXnSc3W RH7mVe+yJQ7CX0zwJM9WLosY02/tL26N3cJUlb+dxeJQxo4F5ryWqiexKi0Ozf2yZ8oZ 6ENA== X-Gm-Message-State: AOAM5304BkAjl3B8qTeGU/WHImANe7vha93hsBvhLk+1+3NgOiGwOfgr KEVqvzYRcJ8HDNi9oHpRtsUslvmye53kfkKGmoJscLBia2gWwz/URD5EbnJLOo7GFzC4UanjLFj 3YAGh/+1xQVMqD1V7kp+ti41FB/ZRlQ== X-Received: by 2002:a92:d843:: with SMTP id h3mr5039762ilq.197.1597671914500; Mon, 17 Aug 2020 06:45:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3OJAcQ9BDzMCdCK5YHgxyb0AYCXv72zFVmykStPJZ7VFgIkbGAlQhmv+6GtZQliFkoMPFaOOf0qJgfHlCa6g= X-Received: by 2002:a92:d843:: with SMTP id h3mr5039745ilq.197.1597671914198; Mon, 17 Aug 2020 06:45:14 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <1703e878-e20a-8ae2-09e8-25470c0cf5f8@dcrocker.net> <3AFAA767-9CC1-4722-80FB-5C4F9BE1FC05@wordtothewise.com> In-Reply-To: <3AFAA767-9CC1-4722-80FB-5C4F9BE1FC05@wordtothewise.com> From: Joseph Brennan Date: Mon, 17 Aug 2020 09:45:03 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ea038b05ad12fa1c" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_09:2020-08-17, 2020-08-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:45:20 -0000 --000000000000ea038b05ad12fa1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2020 at 6:24 AM Laura Atkins wrote: > > > The DMARC proponents have asserted that DMARC prevents domain specific > spoofing and phishing. The amount of harm DMARC authentication has caused= , > however, seems disproportional to this small benefit. Phishing is still > happening using cousin domains (and even random domains). Departments > inside companies avoid DMARC mandates buy buying cousin and =E2=80=9Ccamp= aign > specific=E2=80=9D domains which trains users to be phishing targets for t= hose > domains. Companies have tried to cut down on this by saying DMARC must be > done for all those domains as well. Unfortunately, those =E2=80=9Cfrom ab= ove=E2=80=9D > decrees have often created more problems than they solved. > > Mailing lists have coped by rewriting from addresses, but that has caused > a lot of issues. Two of the big ones are members can no longer search for > =E2=80=9Cmail from this list member=E2=80=9D and cannot easily create fil= ters acting on > mail from other participants. > Well said (I liked the poetic indentation too) The fact is that DMARC has disrupted the flow of ordinary legitimate email. Actors not involved or interested in DMARC have had to spend time and money developing ways to work around DMARC in order to keep mailing lists and forwarding working, or else they have had to spend time and money on the alternative of informing their customers that legitimate practices they have done for years no longer work reliably and have to be discontinued. Adding more complexity does not make a broken thing less broken. I think the proposed standard should simply spell out in plain words that the purpose of DMARC is to protect transactional mail, e.g. about bank and credit accounts or purchase confirmations, and that it is not for mail from ordinary end users. Given that I think more sending systems would be willing to publish p=3Dreject and more receiving systems would be willing t= o honor it. It won't be the end of spoofs, but it would reduce the disruption to people outside the DMARC club. --- Joseph Brennan --000000000000ea038b05ad12fa1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Aug 17, 2020 at 6:24 AM Laura Atk= ins <laura@wordtothewise.com<= /a>> wrote:


The DMARC proponents have = asserted that DMARC prevents domain specific spoofing and phishing. The amo= unt of harm DMARC authentication has caused, however, seems disproportional= to this small benefit. Phishing is still happening using cousin domains (a= nd even random domains). Departments inside companies avoid DMARC mandates = buy buying cousin and =E2=80=9Ccampaign specific=E2=80=9D domains which tra= ins users to be phishing targets for those domains. Companies have tried to= cut down on this by saying DMARC must be done for all those domains as wel= l. Unfortunately, those =E2=80=9Cfrom above=E2=80=9D decrees have often cre= ated more problems than they solved.=C2=A0

Mailing= lists have coped by rewriting from addresses, but that has caused a lot of= issues. Two of the big ones are members can no longer search for =E2=80=9C= mail from this list member=E2=80=9D and cannot easily create filters acting= on mail from other participants.

<= /div>
Well said (I liked the poetic indentation too)

The fact is that DMARC has disrupted the flow of ordinary legitimate= email. Actors not involved or interested in DMARC have had to spend time a= nd money developing ways to work around DMARC in order to keep mailing list= s and forwarding working, or else they have had to spend time and money on = the alternative of informing their customers that legitimate practices they= have done for years no longer work reliably and have to be discontinued.

Adding more complexity does not make a broken thing= less broken. I think the proposed standard should simply spell out in plai= n words that the purpose=C2=A0of DMARC is to protect transactional mail, e.= g. about bank and credit accounts or purchase confirmations, and that it is= not for mail from ordinary end users. Given that I think more sending syst= ems would be willing to publish p=3Dreject and more receiving systems would= be willing to honor it. It won't be the end of spoofs, but it would re= duce the disruption to people outside the DMARC club.

<= div>
---
Joseph Brennan

<= /div> --000000000000ea038b05ad12fa1c-- From nobody Mon Aug 17 06:52:19 2020 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 C42BE3A156C for ; Mon, 17 Aug 2020 06:52:18 -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, 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 INoVHQ8HaFBE for ; Mon, 17 Aug 2020 06:52:16 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 797F63A156A for ; Mon, 17 Aug 2020 06:52:16 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id i20so749112qkk.8 for ; Mon, 17 Aug 2020 06:52:16 -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=pLFeqC+pLBHGBry7YQfO0qwoXcTn7o9NGngjKCbJswc=; b=X0QxFfpJfciz8TkgwX/shtL9DVZsj4A/OVB0IDjJ8MRYL7lkP89dvziIicQU1JRJTB pD5fDEXm5jQepkVVpV5tA01GfjPJa4tHdjXXUht0hKtpFGGHfBc2s9bpZg0BkBxwwA+r IuFLZUuRyjphIsmSiYogH1P9yxUKb8rPAm6hZw7HPUeLNK5VCRrI0kEppBs8QxeTwqsY TX8HmBX5ckjWEvyniLeWZDqk7Ts4RbMYM0IgWXBxIXuYnaKXD55tsGvE/7WSDLwjTxbu nIhB+NLAEprHwmqWVcPIxQe9PIMsnrCe6fV3ysuAq7ynqImMpTMD2/yYYSe0W/mr3i7W npTQ== 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=pLFeqC+pLBHGBry7YQfO0qwoXcTn7o9NGngjKCbJswc=; b=fKgLIrf1YiLWxVahsN1ksAdLUyKsCExFZtwtRzboclEzKXNUlmpgd68GKCvuOmaHHo q5IwfSh9hzYhqPmQYgcsnnIHWGY233wJYJkuB6hUvpQ+f5t+Fwd0jck21e1zevHZx8Md 2fUrFwS2q/1L/7mWuQFd+I070HLPEG46QAidhjhZhbzbPa6dTwMQhyj71l0sIImpV4+o I76yE18QJHNVoAqYXnXxEtUQKfp6IgTNPgzQa/Di5Pbk6KQ9FqW822GGNOpiqfRmZYiz 9PtMpUmNbTXT0Lv3yje8fDcfTiVSThTVYYb8roO1hRGECMlD3bQqNRh8sAqhKInArYir 6kaQ== X-Gm-Message-State: AOAM531mL6+rCNuQt0roAmZoKB3RUgkI9AOw5VCJrVRuZ+G6Hdxd9X00 YM8StUaT0FB/BndWcIeMwM1nqPv8xHgg254LttA= X-Google-Smtp-Source: ABdhPJzIs5ls5mLAN7YJiQASFE1C0H4jrZ+Asowy5f4dOWitYViUKLDi78w0P69/IzujcUVMnLEbmKzVcaXZYubdNOo= X-Received: by 2002:a37:9f0a:: with SMTP id i10mr13448173qke.368.1597672335418; Mon, 17 Aug 2020 06:52:15 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> In-Reply-To: <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> From: Dotzero Date: Mon, 17 Aug 2020 09:52:04 -0400 Message-ID: To: "Douglas E. Foster" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000005280405ad13142b" Archived-At: Subject: Re: [dmarc-ietf] Time for a change X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:52:19 -0000 --00000000000005280405ad13142b Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster wrote: > > The reality is that IETF has mostly provided followership, not leadership, > on matters of security. This forum is replicating history. As has been > mentioned in the historical review, SPF, DKIM, and DMARC were independently > successful projects, as was SSL. IETF provided after-the-fact blessing. > It is time to follow the same model. > Doug, as someone who has been involved in this space for decades, I think you are sorely mistaken in your understanding of things. Many of the people involved in the email authentication space interact with each other in other places, both online and in person and have been doing so for a very long time. We don't always agree on the path forward but that is because we come from different perspectives. IETF did not provide "after-the-fact" blessing. SPF was experimental for a very long time. DMARC is still informational. One of the mantras for IETF is "running code and rough consensus". There is running code for DMARC but what we are lacking so far is rough consensus. If there is an opportunity to accelerate DMARC adoption, I think it is in > the area of third-party authentication, presumably based on ATSP. To move > the possibility forward, we need to move off this list. The target > audience for this capability will be organizations that are non-DMARC or > DMARC p=none specifically because DKIM delegation is an obstacle. I have > no idea whether that category is a trivial or non-trivial group, so we > would need to find out. Major ESPs are successfully implementing DKIM > scope delegation to comply with DMARC, so maybe it is not the issue. DKIM > delegation creates complexity which becomes an obstacle to new entrants, so > big ESPs may like the status quo just fine. These are all things need to > be assessed, and are more important than writing a new specification. > You can move anywhere you want and write any specification you want but you still have to attract meaningful interest and adoption in order for it to become a standard. > > Then, we need to expand the base of participants to include people who > would be willing to implement the third-party authentication scheme after > it is defined. I think that list would need to look something like this: > > > - A national government representative to ensure that any new proposal > is not vetoed, > > What? Which national government are you referring to? Do you understand that the IETF is international in it's participation? If you are referring to the U.S. Government, can you show me a single example of the government vetoing a technical standard? > > - A financial services industry representative > - An Email Service Provider industry representative > - A large organization that is holding back on DMARC p=reject because > DKIM delegation is an obstacle. > - One or more commercial product representatives > - I would love to have Verizon Media participate, but I have asked and > had no response. > > and why would you expect them to respond to you? > If you want to participate, send me a direct email. More importantly, > if you have connections with people who could play the role of influencers, > reach out to them. > > If there are other topics that would move DMARC forward, we can put them > up for consideration. If you want to discuss special treatment for mailing > lists, you are specifically disinvited. > > > Doug Foster > Or you could apply for M3AAWG membership where all of those constituencies participate already. I wish you luck in your endeavors but I think you are doomed to failure. Michael Hammer --00000000000005280405ad13142b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 16, 2020 at 3:09 PM Dougl= as E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:

The reality is that IETF has mostl= y provided followership, not leadership, on matters of security.=C2=A0 This= forum is replicating history. =C2=A0 As has been mentioned in the historic= al review, SPF, DKIM, and DMARC were independently successful projects, as = was SSL.=C2=A0 IETF provided after-the-fact blessing. =C2=A0 It is time to = follow the same model.

Doug, as= someone who has been involved in this space for decades, I think you are s= orely mistaken in your understanding of things. Many of the people involved= in the email authentication space interact with each other in other places= , both online and in person and have been doing so for a very long time.
We don't always agree on the path forward but that is because w= e come from different perspectives. IETF did not provide "after-the-fa= ct" blessing. SPF was experimental=C2=A0for a very long time. DMARC is= still informational. One of the mantras for IETF is "running code and= rough consensus". There is running code for DMARC but what we are lac= king so far is rough consensus.

=
If there is an opportunity to accelerate DMARC adoption, I think it is= in the area of third-party authentication, presumably based on ATSP. =C2= =A0 To move the possibility forward, we need to move off this list.=C2=A0 T= he target audience for this capability will be organizations that are non-D= MARC or DMARC p=3Dnone specifically because DKIM delegation is an obstacle.= =C2=A0 =C2=A0I have no idea whether that category is a trivial or non-triv= ial group, so we would need to find out.=C2=A0 Major ESPs are successfully = implementing DKIM scope delegation to comply with DMARC, so maybe it is not= the issue. =C2=A0 DKIM delegation creates complexity which becomes an obst= acle to new entrants, so big ESPs may like the status quo just fine. =C2=A0= These are all things need to be assessed, and are more important than writ= ing a new specification.

You ca= n move anywhere you want and write any specification you want but you still= have to attract meaningful interest and adoption in order for it to become= a standard.=C2=A0

=C2=A0

Then, we need to expand the base of participants = to include people who would be willing to implement the third-party authent= ication scheme after it is defined. =C2=A0 I think that list would need to = look something like this:

  • A national government= representative to ensure that any new proposal is not vetoed,=C2=A0
What? Which national government=C2=A0are you ref= erring to? Do you understand that the IETF is international in it's par= ticipation? If you are referring to the U.S. Government, can you show me a = single example of the government vetoing a technical standard?
  • A financial services industry representative
    • An Email Service Provider industry representative
  • A large organiz= ation that is holding back on DMARC p=3Dreject because DKIM delegation is a= n obstacle.
  • One or more commercial product representatives
  • = I would love to have Verizon Media participate, but I have asked and had no= response.
and why would you expect them t= o respond to you?
=C2=A0
If you = want to participate, send me a direct email. =C2=A0 =C2=A0More importantly,= if you have connections with people who could play the role of influencers= , reach out to them.

If there are other topics tha= t would move DMARC forward, we can put them up for consideration.=C2=A0 If = you want to discuss special treatment for mailing lists, you are specifical= ly disinvited.


Doug Foster

Or you could apply for M3AAWG membershi= p where all of those constituencies participate already.=C2=A0=C2=A0
<= div>
I wish you luck in your endeavors but I think you are do= omed to failure.

Michael Hammer
--00000000000005280405ad13142b-- From nobody Mon Aug 17 07:00:50 2020 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 4B9CB3A0C4E for ; Mon, 17 Aug 2020 07:00:48 -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=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 8-8mCKSNmwCG for ; Mon, 17 Aug 2020 07:00:46 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id CA8CD3A0C4D for ; Mon, 17 Aug 2020 07:00:45 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 9F6889F1F7 for ; Mon, 17 Aug 2020 07:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597672845; bh=Jhvk7nM/r8SMWu8qg1fG4PJgIHsu9ke6tx56CBji+yw=; h=From:Subject:Date:References:To:In-Reply-To:From; b=cBIQ65kegzJ4fSXBcbKK5Q7uD4kWnvrKa0r5COBWPvjThPvY8wwqd8oyyiX3HKTKF z5Yh+QoATClSgHPHH/3RQqpkpLUmtkEBjv5A1lYT/leLVT0ugebkt8ZSFShSS6KRdl fj6uUzBviRi557QRlcAbLtihxKNvaZuKrXJJNkSY= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_9E76CEDB-B27D-43BE-8887-382079BF8849" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 17 Aug 2020 15:00:42 +0100 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:00:48 -0000 --Apple-Mail=_9E76CEDB-B27D-43BE-8887-382079BF8849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Aug 2020, at 14:18, Dotzero wrote: >=20 > And, 17 years on, we know that domain level authentication doesn=E2=80=99= t actually help filter spam nor does it provide law enforcement with a = potent tool for locating and identifying spammers. It was promising, it = didn=E2=80=99t live up to the promise.=20 >=20 > There were a lot of thrown at the wall during those 3 days of talks. = One of them was domain level opt-out. Another was a global opt-out list = similar to the postal opt-outs run by the DMA. Another was a technology = called TEOS. HashCash. The list of things we discussed as promising = solutions was extensive. Just because we discussed a particular kind of = solution does not mean that anything was decided. It also doesn=E2=80=99t = mean that any particular solution mentioned was workable.=20 >=20 >>> = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day1.pdf = >>> = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day2.pdf = >>> = https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-f= orum/transcript_day3.pdf = >>=20 >>=20 >> Thanks. Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf: >>=20 >> It doesn't require that one day everyone turns it on and we begin >> to drop the rest of the e-mail and break e-mail. If a domain >> decides to turn it on, then they've prevented forgery for their >> domain and they're protected. For persons that have not turned it >> on, then their e-mail still flows but they are not able to >> stop people from forging messages from their domain. So, I think >> it's something useful and can be deployed incrementally. >=20 > We know, now, that turning on domain level protection does not stop = phishing attacks against that company. It stops direct spoofing of the = domain, but the phishers simply use a completely different domain. Just = this weekend I got a PayPal phish. PayPal who helped invent DMARC are = still getting spoofed and phished. Sure, the phishers aren=E2=80=99t = using the paypal.com domain, but that doesn=E2=80=99t= seem to have any effect on their success at stealing money from people.=20= >=20 > You raise an interesting point, Laura. Whatever "solutions" we put in = place, the abusers/bad guys will evolve. One of the problems for the = good guys (for some definition of good) is that standards work takes = years (decades?) while the bad guys change their tactics at will. = Crime existed before the Internet and will continue long after we are = all dead and buried. Totally agreed. The issue here is that DMARC is a fundamentally flawed = model for preventing phishing. Phishers were adapting to mailbox = provider filters even before DMARC and there was a lot of cousin and = non-look-alike domain phishing even during the initial discussions. I = know these issues were brought up during discussion of the protocol. = Unfortunately, they weren=E2=80=99t sufficiently addressed and now = we=E2=80=99re at a point where, to my mind, DMARC doesn=E2=80=99t fix = anything while also breaking a lot of ways folks use mail. It=E2=80=99s a little late now to go back. I think this is an = opportunity to think about the underlying technical problems as well as = a chance to revisit the assumptions about how email is used. Discussing = things like Dave=E2=80=99s drafts will give us a chance to talk about = how people actually use email to communicate with one another. And how = we can allow brands what they want without breaking email too much for = the rest of us.=20 >> It seems we're still stuck midstream... >=20 > Stuck at what? Many of the people who were at that conference are = still working in the field and understand both the purpose and what came = out of the forum. I=E2=80=99d also say that most of what happened there = is a nice bit of history but is also irrelevant to addressing the spam = problem as it is now. Email has evolved significantly in the last 5 = years, much less the last 15. We can use the discussion as history to = say =E2=80=9Cwe looked at this and it didn=E2=80=99t work=E2=80=9D but I = don=E2=80=99t really see a lot of value in saying =E2=80=9Clet=E2=80=99s = retread things from a decade and a half ago that didn=E2=80=99t work.=E2=80= =9D >=20 > I think the most=20 > useful thing we can say about the FTC workshops is that they were a = forcing mechanism that instigated a lot of effort and innovation in the = space. Some of those efforts fell by the wayside and some still persist. You think? I=E2=80=99m not sure I=E2=80=99d agree. I saw the workshop as = mostly a political (and educating the politicians) exercise. The effort = and innovation were already there and being done by a lot of people who = weren=E2=80=99t there. I=E2=80=99m kinda bemused by the importance folks = have assigned to it in relation to the vastly different email ecosystem = we have today. laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_9E76CEDB-B27D-43BE-8887-382079BF8849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 Aug 2020, at 14:18, Dotzero <dotzero@gmail.com> = wrote:

And, 17 years on, we know that domain level = authentication doesn=E2=80=99t actually help filter spam nor does it = provide law enforcement with a potent tool for locating and identifying = spammers. It was promising, it didn=E2=80=99t live up to the = promise. 

There were a lot of thrown at the wall during those 3 days of = talks. One of them was domain level opt-out. Another was a global = opt-out list similar to the postal opt-outs run by the DMA. Another was = a technology called TEOS. HashCash. The list of things we discussed as = promising solutions was extensive. Just because we discussed a = particular kind of solution does not mean that anything was decided. It = also doesn=E2=80=99t mean that any particular solution mentioned was = workable. 

https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day1.pdf
https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day2.pdf
https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day3.pdf


Thanks.  Let me quote a paragraph by Paul = Q. Judge, from the 3rd pdf:

=    It doesn't require that one day everyone turns it on = and we begin
   to drop the rest of the = e-mail and break e-mail.  If a domain
=    decides to turn it on, then they've prevented forgery = for their
   domain and they're = protected.  For persons that have not turned it
=    on, then their e-mail still flows but they are not = able to
   stop people from forging = messages from their domain.  So, I think
=    it's something useful and can be deployed = incrementally.

We know, now, that turning on domain = level protection does not stop phishing attacks against that company. It = stops direct spoofing of the domain, but the phishers simply use a = completely different domain. Just this weekend I got a PayPal phish. = PayPal who helped invent DMARC are still getting spoofed and phished. = Sure, the phishers aren=E2=80=99t using the paypal.com domain, but that = doesn=E2=80=99t seem to have any effect on their success at stealing = money from people. 
You raise an interesting point, Laura. = Whatever "solutions" we put in place, the abusers/bad guys will evolve. = One of the problems for the good guys (for some definition of good) is = that standards work takes years (decades?)  while the bad  = guys change their tactics at will. Crime existed before the Internet and = will continue long after we are all dead and = buried.

Totally agreed. The issue here is that DMARC is a = fundamentally flawed model for preventing phishing. Phishers were = adapting to mailbox provider filters even before DMARC and there was a = lot of cousin and non-look-alike domain phishing even during the initial = discussions. I know these issues were brought up during discussion of = the protocol. Unfortunately, they weren=E2=80=99t sufficiently addressed = and now we=E2=80=99re at a point where, to my mind, DMARC doesn=E2=80=99t = fix anything while also breaking a lot of ways folks use = mail.

It=E2=80=99s a little late now = to go back. I think this is an opportunity to think about the underlying = technical problems as well as a chance to revisit the assumptions about = how email is used. Discussing things like Dave=E2=80=99s drafts will = give us a chance to talk about how people actually use email to = communicate with one another. And how we can allow brands what they want = without breaking email too much for the rest of us. 

It seems we're still stuck = midstream...

Stuck at what? Many of the people who = were at that conference are still working in the field and understand = both the purpose and what came out of the forum. I=E2=80=99d also say = that most of what happened there is a nice bit of history but is also = irrelevant to addressing the spam problem as it is now. Email has = evolved significantly in the last 5 years, much less the last 15. We can = use the discussion as history to say =E2=80=9Cwe looked at this and it = didn=E2=80=99t work=E2=80=9D but I don=E2=80=99t really see a lot of = value in saying =E2=80=9Clet=E2=80=99s retread things from a decade and = a half ago that didn=E2=80=99t = work.=E2=80=9D

I think the most 
 useful thing we can say about the FTC workshops is that = they were a forcing mechanism that instigated a lot of effort and = innovation in the space. Some of those efforts fell by the wayside and = some still persist.

You think? I=E2=80=99m not sure I=E2=80=99d agree. = I saw the workshop as mostly a political (and educating the politicians) = exercise. The effort and innovation were already there and being done by = a lot of people who weren=E2=80=99t there. I=E2=80=99m kinda bemused by = the importance folks have assigned to it in relation to the vastly = different email ecosystem we have today.

laura 
-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_9E76CEDB-B27D-43BE-8887-382079BF8849-- From nobody Mon Aug 17 07:27:05 2020 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 BEE1E3A156C for ; Mon, 17 Aug 2020 07:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 X73v4uYT5qNG for ; Mon, 17 Aug 2020 07:27:03 -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 168FA3A0C54 for ; Mon, 17 Aug 2020 07:27:02 -0700 (PDT) Received: from [10.0.0.178] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07HETm4R024678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2020 07:29:48 -0700 To: Laura Atkins , IETF DMARC WG References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5e4c9533-52cb-5923-54b3-fcc2bf80bc20@dcrocker.net> Date: Mon, 17 Aug 2020 07:26:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> Content-Type: multipart/alternative; boundary="------------094C40A936E19C1D4957F3D6" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:27:05 -0000 This is a multi-part message in MIME format. --------------094C40A936E19C1D4957F3D6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/17/2020 7:00 AM, Laura Atkins wrote: >> I think the most >>  useful thing we can say about the FTC workshops is that they were a >> forcing mechanism that instigated a lot of effort and innovation in >> the space. Some of those efforts fell by the wayside and some still >> persist. > > You think? I’m not sure I’d agree. I saw the workshop as mostly a > political (and educating the politicians) exercise. The effort and > innovation were already there and being done by a lot of people who > weren’t there. I’m kinda bemused by the importance folks have assigned > to it in relation to the vastly different email ecosystem we have today. > This might be quibbling, but I think it kicked a bit more energy into the anti-abuse industry.  So, as a moment to mark in time, it I think it was useful.  But no, not fundamentally for the creation and development of email anti-abuse work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------094C40A936E19C1D4957F3D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/17/2020 7:00 AM, Laura Atkins wrote:
I think the most 
 useful thing we can say about the FTC workshops is that they were a forcing mechanism that instigated a lot of effort and innovation in the space. Some of those efforts fell by the wayside and some still persist.

You think? I’m not sure I’d agree. I saw the workshop as mostly a political (and educating the politicians) exercise. The effort and innovation were already there and being done by a lot of people who weren’t there. I’m kinda bemused by the importance folks have assigned to it in relation to the vastly different email ecosystem we have today.


This might be quibbling, but I think it kicked a bit more energy into the anti-abuse industry.  So, as a moment to mark in time, it I think it was useful.  But no, not fundamentally for the creation and development of email anti-abuse work.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------094C40A936E19C1D4957F3D6-- From nobody Mon Aug 17 07:33:55 2020 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 0E2CB3A0C66 for ; Mon, 17 Aug 2020 07:33:54 -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, 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 WTOTMAH6R1EL for ; Mon, 17 Aug 2020 07:33:52 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 D36F63A0C58 for ; Mon, 17 Aug 2020 07:33:51 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id b79so15098222qkg.9 for ; Mon, 17 Aug 2020 07:33:51 -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=QdwQQqefJErz6vHbEbS4p87QnHYNxMRhZc5u1FlAoNc=; b=UIPSlqfV1oSX7r5RARL54ySOFNxx64FqBUFEjSax69E/5X7xZzr49nXpSdB4p6DaQt cp1JcPJIY5qpNE9f/ePVyF8DwgyIo3+kDAB6ZK43vXPYD+76ANZkCLknGmPIRLbueuhs YUARfJxRUNNITKdesgGwze99Rfzj52aEf5R+W8sQrslcAdZgQZhAjEqHMLJVM4NjG6c0 0HO/srHiuaVylSE9avstPlUmMIN9tAeW2qMlf8ov0mIjB0Fj52C2V5J7+mAh8mYjYBVs zw39z2rJjxdlMbbU/uVNAh2msQAAQDEYQyJ1HXFFeLb7tTUVUAuhJ85NvtYnk4WDcR43 6/3Q== 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=QdwQQqefJErz6vHbEbS4p87QnHYNxMRhZc5u1FlAoNc=; b=ibWDOI7ZzUrNlF8iW30gqKnSZC7U0RwSWPD+XLV/8fR+yeCqAUt6JI4o5xlE9H+CGE mpdhMJn9e45UO037sseSF6VRSsliujqTVGA8fIMnFaCVzq7v3GYEaPPq7tP7VRD9YTFc aFpPVIbv5Oj5g0FtyrokeXhxRu2J3AC5eEXlAUTlwC4F47bGB4rrLRNUQ588XuAU0BY1 IoYx17PJpC0bqTvACPsul6PxCQMarnk4N+zzojAnI2CSOuq+ec0RCLCJtsVk21AFwIwi flkllu+xDBErZajjGDQ0Owr4uFh0x5z8AfH92qX3r1UF4pQIrkIEff1MWoF6ohxm+rp3 QGxQ== X-Gm-Message-State: AOAM533Ws3JsSzurCpVEU0IDPdfhgdYQualufEKbGpeF0i53c1DVtAvT sq6ATAX/SshTdkMj2ebKNE09JTj/MH5z/IOQr8M= X-Google-Smtp-Source: ABdhPJzPUyADk6M4hOdVtl9jsXqPAKdtP8cNBBsp1pj/nC9COULD2srb/q1Hm8NzfWQqZ+iIuntXFIxqJ7XGzvORuQU= X-Received: by 2002:ae9:e902:: with SMTP id x2mr13116217qkf.66.1597674830706; Mon, 17 Aug 2020 07:33:50 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> In-Reply-To: <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> From: Dotzero Date: Mon, 17 Aug 2020 10:33:39 -0400 Message-ID: To: Laura Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c056fe05ad13a80d" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:33:54 -0000 --000000000000c056fe05ad13a80d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2020 at 10:01 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 14:18, Dotzero wrote: > >> >> And, 17 years on, we know that domain level authentication doesn=E2=80= =99t >> actually help filter spam nor does it provide law enforcement with a pot= ent >> tool for locating and identifying spammers. It was promising, it didn=E2= =80=99t >> live up to the promise. >> >> There were a lot of thrown at the wall during those 3 days of talks. One >> of them was domain level opt-out. Another was a global opt-out list simi= lar >> to the postal opt-outs run by the DMA. Another was a technology called >> TEOS. HashCash. The list of things we discussed as promising solutions w= as >> extensive. Just because we discussed a particular kind of solution does = not >> mean that anything was decided. It also doesn=E2=80=99t mean that any pa= rticular >> solution mentioned was workable. >> >> >> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam= -forum/transcript_day1.pdf >> >> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam= -forum/transcript_day2.pdf >> >> >> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam= -forum/transcript_day3.pdf >> >> >> >> Thanks. Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf: >> >> It doesn't require that one day everyone turns it on and we begin >> to drop the rest of the e-mail and break e-mail. If a domain >> decides to turn it on, then they've prevented forgery for their >> domain and they're protected. For persons that have not turned it >> on, then their e-mail still flows but they are not able to >> stop people from forging messages from their domain. So, I think >> it's something useful and can be deployed incrementally. >> >> >> We know, now, that turning on domain level protection does not stop >> phishing attacks against that company. It stops direct spoofing of the >> domain, but the phishers simply use a completely different domain. Just >> this weekend I got a PayPal phish. PayPal who helped invent DMARC are st= ill >> getting spoofed and phished. Sure, the phishers aren=E2=80=99t using the >> paypal.com domain, but that doesn=E2=80=99t seem to have any effect on t= heir >> success at stealing money from people. >> > > You raise an interesting point, Laura. Whatever "solutions" we put in > place, the abusers/bad guys will evolve. One of the problems for the good > guys (for some definition of good) is that standards work takes years > (decades?) while the bad guys change their tactics at will. Crime exist= ed > before the Internet and will continue long after we are all dead and buri= ed. > > > Totally agreed. The issue here is that DMARC is a fundamentally flawed > model for preventing phishing. Phishers were adapting to mailbox provider > filters even before DMARC and there was a lot of cousin and non-look-alik= e > domain phishing even during the initial discussions. I know these issues > were brought up during discussion of the protocol. Unfortunately, they > weren=E2=80=99t sufficiently addressed and now we=E2=80=99re at a point w= here, to my mind, > DMARC doesn=E2=80=99t fix anything while also breaking a lot of ways folk= s use mail. > > DMARC fixes one thing and one thing only, direct domain abuse. Not cousin domains, not homoglyphs and not a whole bunch of other things. It was successful in achieving its intended purpose. It was initially developed and deployed privately as a "private club". The intent in making it a public standard was to enable any domain, regardless of size or connections to be able to participate if that domain needed to fight direct domain abuse, noting the caveats regarding individual user accounts vs transactional email. It=E2=80=99s a little late now to go back. I think this is an opportunity t= o think > about the underlying technical problems as well as a chance to revisit th= e > assumptions about how email is used. Discussing things like Dave=E2=80=99= s drafts > will give us a chance to talk about how people actually use email to > communicate with one another. And how we can allow brands what they want > without breaking email too much for the rest of us. > > It seems we're still stuck midstream... >> >> >> Stuck at what? Many of the people who were at that conference are still >> working in the field and understand both the purpose and what came out o= f >> the forum. I=E2=80=99d also say that most of what happened there is a ni= ce bit of >> history but is also irrelevant to addressing the spam problem as it is n= ow. >> Email has evolved significantly in the last 5 years, much less the last = 15. >> We can use the discussion as history to say =E2=80=9Cwe looked at this a= nd it >> didn=E2=80=99t work=E2=80=9D but I don=E2=80=99t really see a lot of val= ue in saying =E2=80=9Clet=E2=80=99s retread >> things from a decade and a half ago that didn=E2=80=99t work.=E2=80=9D >> > > I think the most > useful thing we can say about the FTC workshops is that they were a > forcing mechanism that instigated a lot of effort and innovation in the > space. Some of those efforts fell by the wayside and some still persist. > > > You think? I=E2=80=99m not sure I=E2=80=99d agree. I saw the workshop as = mostly a > political (and educating the politicians) exercise. The effort and > innovation were already there and being done by a lot of people who weren= =E2=80=99t > there. I=E2=80=99m kinda bemused by the importance folks have assigned to= it in > relation to the vastly different email ecosystem we have today. > > I think this is a matter of perspective. DK was gaining traction because...Yahoo! SPF was not that widely deployed (yet). I wrote about the FTC being a forcing mechanism because of the threat of regulation. The threat wasn't formal and it wasn't specific as to what it meant, but it certainly got people's attention. Michael Hammer --000000000000c056fe05ad13a80d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 10:01 AM Laur= a Atkins <laura@wordtothewise= .com> wrote:


On 17 Aug 2020, at 14:18, Dotzero <dotzero@gmail.com> wrote:

And, 17 years on, we know that= domain level authentication doesn=E2=80=99t actually help filter spam nor = does it provide law enforcement with a potent tool for locating and identif= ying spammers. It was promising, it didn=E2=80=99t live up to the promise.= =C2=A0

There were a lot of thrown at the wall duri= ng those 3 days of talks. One of them was domain level opt-out. Another was= a global opt-out list similar to the postal opt-outs run by the DMA. Anoth= er was a technology called TEOS. HashCash. The list of things we discussed = as promising solutions was extensive. Just because we discussed a particula= r kind of solution does not mean that anything was decided. It also doesn= =E2=80=99t mean that any particular solution mentioned was workable.=C2=A0<= /div>

https://w= ww.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/trans= cript_day1.pdf
https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-= forum/transcript_day2.pdf
https://www.ftc.gov/sites/default/files/documents/public_events= /ftc-spam-forum/transcript_day3.pdf


Thanks.=C2= =A0 Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:

= =C2=A0=C2=A0=C2=A0It doesn't require that one day everyone turns it on = and we begin
=C2=A0=C2=A0=C2=A0to drop the rest of the e-mail and break= e-mail.=C2=A0 If a domain
=C2=A0=C2=A0=C2=A0decides to turn it on, the= n they've prevented forgery for their
=C2=A0=C2=A0=C2=A0domain and = they're protected.=C2=A0 For persons that have not turned it
=C2=A0= =C2=A0=C2=A0on, then their e-mail still flows but they are not able to
= =C2=A0=C2=A0=C2=A0stop people from forging messages from their domain.=C2= =A0 So, I think
=C2=A0=C2=A0=C2=A0it's something useful and can be = deployed incrementally.

We = know, now, that turning on domain level protection does not stop phishing a= ttacks against that company. It stops direct spoofing of the domain, but th= e phishers simply use a completely different domain. Just this weekend I go= t a PayPal phish. PayPal who helped invent DMARC are still getting spoofed = and phished. Sure, the phishers aren=E2=80=99t using the paypal.com=C2=A0domain, but that doesn= =E2=80=99t seem to have any effect on their success at stealing money from = people.=C2=A0

You raise a= n interesting point, Laura. Whatever "solutions" we put in place,= the abusers/bad guys will evolve. One of the problems for the good guys (f= or some definition of good) is that standards work takes years (decades?)= =C2=A0 while the bad=C2=A0 guys change their tactics at will. Crime existed= before the Internet and will continue long after we are all dead and burie= d.

Totally agreed. = The issue here is that DMARC is a fundamentally flawed model for preventing= phishing. Phishers were adapting to mailbox provider filters even before D= MARC and there was a lot of cousin and non-look-alike domain phishing even = during the initial discussions. I know these issues were brought up during = discussion of the protocol. Unfortunately, they weren=E2=80=99t sufficientl= y addressed and now we=E2=80=99re at a point where, to my mind, DMARC doesn= =E2=80=99t fix anything while also breaking a lot of ways folks use mail.


DMARC fixes= one thing and one thing only, direct domain abuse. Not cousin domains, not= homoglyphs and not a whole bunch of other things. It=C2=A0
was s= uccessful in achieving its intended purpose. It was initially developed and= deployed privately as a "private club". The intent in making it = a public standard was to enable any domain, regardless of size or connectio= ns to be able to participate if that domain needed to fight direct domain a= buse, noting the caveats regarding individual user accounts vs transactiona= l email.

It=E2=80= =99s a little late now to go back. I think this is an opportunity to think = about the underlying technical problems as well as a chance to revisit the = assumptions about how email is used. Discussing things like Dave=E2=80=99s = drafts will give us a chance to talk about how people actually use email to= communicate with one another. And how we can allow brands what they want w= ithout breaking email too much for the rest of us.=C2=A0

It seems we're still stuck midstream...

Stuck at what? Many of the people who were at = that conference are still working in the field and understand both the purp= ose and what came out of the forum. I=E2=80=99d also say that most of what = happened there is a nice bit of history but is also irrelevant to addressin= g the spam problem as it is now. Email has evolved significantly in the las= t 5 years, much less the last 15. We can use the discussion as history to s= ay =E2=80=9Cwe looked at this and it didn=E2=80=99t work=E2=80=9D but I don= =E2=80=99t really see a lot of value in saying =E2=80=9Clet=E2=80=99s retre= ad things from a decade and a half ago that didn=E2=80=99t work.=E2=80=9D

I think the most=C2=A0
=C2=A0useful thing we can say about the FTC workshops is that they w= ere a forcing mechanism that instigated a lot of effort and innovation in t= he space. Some of those efforts fell by the wayside and some still persist.=

You think? I=E2=80= =99m not sure I=E2=80=99d agree. I saw the workshop as mostly a political (= and educating the politicians) exercise. The effort and innovation were alr= eady there and being done by a lot of people who weren=E2=80=99t there. I= =E2=80=99m kinda bemused by the importance folks have assigned to it in rel= ation to the vastly different email ecosystem we have today.

=
I think this is a matter of perspective= . DK was gaining traction=C2=A0because...Yahoo! SPF was not that widely dep= loyed (yet). I wrote about the FTC being a forcing mechanism because of the= threat of regulation. The threat wasn't formal and it wasn't speci= fic as to what it meant, but it certainly got people's attention.
=

=C2=A0Michael Hammer
--000000000000c056fe05ad13a80d-- From nobody Mon Aug 17 07:37:40 2020 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 EB4B73A16BD for ; Mon, 17 Aug 2020 07:37:38 -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, 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 7Kk4UOrsXriR for ; Mon, 17 Aug 2020 07:37:37 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 94C6E3A16A9 for ; Mon, 17 Aug 2020 07:37:30 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id s23so12507966qtq.12 for ; Mon, 17 Aug 2020 07:37:30 -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=fE73BaZlms6rFQ6nQjGRKiOdUL+Cuc9bztwVNfK1Vk4=; b=phLJtqvpPov8AB4gc7qsb8AZx4NqqnAEB5XwmNzMqcHjEXYoXbqzU1ZFSTOoqWqXDr g0LMGFw075fshVgeHwWR+cG5eQvWWXYmkBIWr7ov8xLXRBefZz/pcsFNOKURsu9//MyX G7ISJCMZlX8L5KUBNBuXxpMQS1Hcvi/uFKUxcRDwOwENigigiEwM2ZV34+AJXJm+HOid S++PTxHqVZUzW5EVva4Vb+u0qSTP5nvsRBGnITYFkieudARMN3820jEerMydFqylCESK nZtSS4WEFuIjqPmq6Zcls01G5fc4BTwAgxdlt2Bgoh9937vgcMNWurp0Kj0tU1qslrvP L5sA== 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=fE73BaZlms6rFQ6nQjGRKiOdUL+Cuc9bztwVNfK1Vk4=; b=fcGRNpwD1EG2gc33Q36pO5Ifs3vsSRikbvKhm6qnlbO7uJfgGrBCmSxsY3Njgb8pqD l3S+wrep/dWv+/Mh/8mkp6WuMnVcvIhz3XE1B11CnZt2gZZvQ1ieow/xmkCbQZUkeuUE jlvzUWngOwhJJChnhg3CZfwRPDWrdT4V4aQH/7zPKlGeg4DIcc6K9Sddq3HfuglVoA+i CRtjTMs2n7RquWsnvWIVBI6gDepzxemioMKbCBhB+GgPTefD5YtYUTZjVvpjmkB1Zo0a kOtcsG7HF6rgIoLRVUp0yz1PWCEJ7WNXL8S86eV6ux5Z5vey7fv35uth2IPr+6EV4KBO BzUw== X-Gm-Message-State: AOAM532hRl5sLDaosbmdDfdd0PZ9QoZlDMf6s55qTOR8rykEhPQuKAJX bVmAPgd6ew5DD8LfIVUy7/CCufSM8Nrsh5muwQw= X-Google-Smtp-Source: ABdhPJzBGRUEPqV0lsCwW3pGYlSHD8+Uu8gZ7/04rfdV9GziM/n8/XvUxDDobjDox6r9Keyl0rl0DiC3XgB4SL7fQMU= X-Received: by 2002:aed:2258:: with SMTP id o24mr13898727qtc.220.1597675049751; Mon, 17 Aug 2020 07:37:29 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> <5e4c9533-52cb-5923-54b3-fcc2bf80bc20@dcrocker.net> In-Reply-To: <5e4c9533-52cb-5923-54b3-fcc2bf80bc20@dcrocker.net> From: Dotzero Date: Mon, 17 Aug 2020 10:37:18 -0400 Message-ID: To: Dave CROCKER Cc: Laura Atkins , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ce9a0d05ad13b58b" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:37:39 -0000 --000000000000ce9a0d05ad13b58b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2020 at 10:27 AM Dave Crocker wrote: > On 8/17/2020 7:00 AM, Laura Atkins wrote: > > I think the most > useful thing we can say about the FTC workshops is that they were a > forcing mechanism that instigated a lot of effort and innovation in the > space. Some of those efforts fell by the wayside and some still persist. > > > You think? I=E2=80=99m not sure I=E2=80=99d agree. I saw the workshop as = mostly a > political (and educating the politicians) exercise. The effort and > innovation were already there and being done by a lot of people who weren= =E2=80=99t > there. I=E2=80=99m kinda bemused by the importance folks have assigned to= it in > relation to the vastly different email ecosystem we have today. > > > This might be quibbling, but I think it kicked a bit more energy into the > anti-abuse industry. So, as a moment to mark in time, it I think it was > useful. But no, not fundamentally for the creation and development of > email anti-abuse work. > > d/ > Exactly. +1 Michael Hammer --000000000000ce9a0d05ad13b58b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 10:27 AM Dave= Crocker <dhc@dcrocker.net> w= rote:
=20 =20 =20
On 8/17/2020 7:00 AM, Laura Atkins wrote:
I think the most=C2=A0
=C2=A0useful thing we can say about the FTC workshops is that they were a forcing mechanism that instigated a lot of effort and innovation in the space. Some of those efforts fell by the wayside and some still persist.

You think? I=E2=80=99m not sure I=E2=80=99d agree. I saw the wor= kshop as mostly a political (and educating the politicians) exercise. The effort and innovation were already there and being done by a lot of people who weren=E2=80=99t there. I=E2=80=99m kinda bemused by t= he importance folks have assigned to it in relation to the vastly different email ecosystem we have today.


This might be quibbling, but I think it kicked a bit more energy into the anti-abuse industry.=C2=A0 So, as a moment to mark in time, = it I think it was useful.=C2=A0 But no, not fundamentally for the creati= on and development of email anti-abuse work.

d/


Exactly.=C2=A0+1=C2=A0<= /div>

Michael Hammer=C2=A0
--000000000000ce9a0d05ad13b58b-- From nobody Mon Aug 17 07:37:59 2020 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 F13D93A0406 for ; Mon, 17 Aug 2020 07:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 eDByGDA8DUau for ; Mon, 17 Aug 2020 07:37:54 -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 C545A3A053E for ; Mon, 17 Aug 2020 07:37:54 -0700 (PDT) Received: from [10.0.0.178] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07HEedFk025687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2020 07:40:40 -0700 To: Dotzero References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> Cc: IETF DMARC WG Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <15597ef0-9057-b21e-8d4a-88bd777216c7@dcrocker.net> Date: Mon, 17 Aug 2020 07:37:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4A457E63DA9E43A16C559E33" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:37:59 -0000 This is a multi-part message in MIME format. --------------4A457E63DA9E43A16C559E33 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/17/2020 7:33 AM, Dotzero wrote: > DMARC fixes one thing and one thing only, direct domain abuse. It does no such thing.  Domains can still be 'directly' abused in all sorts of ways that DMARC does not affect. A continuing and in my view fundamental problem with discussion in this space is the lack of careful and precise language when talking about actions and effects. So... DMARC fixes abuse of rfc5322.From field domains. THAT is the only thing it does. And it does it at the expense of breaking some legitimate uses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------4A457E63DA9E43A16C559E33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/17/2020 7:33 AM, Dotzero wrote:
DMARC fixes one thing and one thing only, direct domain abuse.


It does no such thing.  Domains can still be 'directly' abused in all sorts of ways that DMARC does not affect. 

<rant>

A continuing and in my view fundamental problem with discussion in this space is the lack of careful and precise language when talking about actions and effects.

</rant>

So...

DMARC fixes abuse of rfc5322.From field domains. 

THAT is the only thing it does.

And it does it at the expense of breaking some legitimate uses.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------4A457E63DA9E43A16C559E33-- From nobody Mon Aug 17 07:47:09 2020 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 800FB3A0E76 for ; Mon, 17 Aug 2020 07:47:07 -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, 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 aPxcEtNlh_qk for ; Mon, 17 Aug 2020 07:47:06 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 330E93A0E73 for ; Mon, 17 Aug 2020 07:47:06 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id d14so15136319qke.13 for ; Mon, 17 Aug 2020 07:47:06 -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=g7edJ1XK6VkppeoH3zxbCRjsvbNerdY6vMDTFCwDzmc=; b=YsYaE8Ju1GUc2rForlejsQGggANQ8bnj5dfWR6LPUJRDN1sq0lkUmTOvSwx9qUB4o0 Cz9Nksc4xjf7UiaQHDbgBCK6LpN/5KNkX+3X9VVJs/0i5OoPxpm/AeN9NEcSw0HFoj9g 9gk4Bifiedcf9dTCkYkt95dWU5vA/1awga1YXZErQEAbw3zVktn8wbGrTP7anqbXN+2+ zBBUXyvcBqrBYZPXZpnj8D5D0ehv/qqkNmaP1YZBhkfaRF+GWy6KM17WQ6CEB62XEW+h WSGUzU08l3l93z8JXt89fi8EyFQi8eVSIub3YD9Cm+niGrUEZT6fmzy8JBVJIIiuUS9E z0aQ== 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=g7edJ1XK6VkppeoH3zxbCRjsvbNerdY6vMDTFCwDzmc=; b=JWB/KZetRyG63lbxSLEmMbBENEkfReV3ellDXM7bA1Sh5A76ONBIVA2Q4arOPBXrYm lAGnglm1TWw/XE/W/yKNeiF1VUyEoUM2s5nURy/Zj07vjjvjL25s4NmP7OTfLQeCtxHy tMh40jv0kK7MDTmRvAGM1u8NZmjXn6Tfrr40QTZ3JxH60M6Z8iRD8MQGydtCyY0MUIa+ y0ImYi+EHuDWbzfLd/qkz9Ac6o7YcrV5ey5UIOa7jITwdVCdNHqkhohFJ1oQW2VRSJ2m B4zYW10Bh9bjvzwPFNQNPThAjg1RZlZsVKji/11wyorde2/HVXUX15GIDIAhZde/jXD4 YbeA== X-Gm-Message-State: AOAM530dmIU7cCVTyfPlBA9IhGMGfBFwPCFSVwGw2nAgnN1JlJT6ClFT lk8VTZJl0vbvg4guQ4t21kWqO19T0oZir4dXI0H1679q X-Google-Smtp-Source: ABdhPJzi7TeMBghsnpun8szkPmgRYeRJ/f12Hpj/RaTftFhkz8CJssaVRCQG0JCgBtvip0UvN3w26EMkiqisVwdGCIY= X-Received: by 2002:a37:9f0a:: with SMTP id i10mr13668817qke.368.1597675625369; Mon, 17 Aug 2020 07:47:05 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> <15597ef0-9057-b21e-8d4a-88bd777216c7@dcrocker.net> In-Reply-To: <15597ef0-9057-b21e-8d4a-88bd777216c7@dcrocker.net> From: Dotzero Date: Mon, 17 Aug 2020 10:46:54 -0400 Message-ID: To: Dave CROCKER Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001dd6e505ad13d8fe" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:47:08 -0000 --0000000000001dd6e505ad13d8fe Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker wrote: > On 8/17/2020 7:33 AM, Dotzero wrote: > > DMARC fixes one thing and one thing only, direct domain abuse. > > > It does no such thing. Domains can still be 'directly' abused in all > sorts of ways that DMARC does not affect. > Mea Culpa. You are correct that it only does so in the context of SPF and DKIM validation which protects rfc5322 From field domains and aligned rfc5321 Mail From domains (SPF). > > > A continuing and in my view fundamental problem with discussion in this > space is the lack of careful and precise language when talking about > actions and effects. > > > > So... > > DMARC fixes abuse of rfc5322.From field domains. > > THAT is the only thing it does. > See above. I was even more specific than you were in terms of what DMARC does. > And it does it at the expense of breaking some legitimate uses. > Only when it is used in domains where there are individual user accounts and not (only) transactional mail uses. If I use a hammer (no pun intended) to pound in a screw, it doesn't make it the right tool for the job. Michael Hammer (Inaccurately referred to by you as Herr Hammer) --0000000000001dd6e505ad13d8fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 10:37 AM Dave= Crocker <dhc@dcrocker.net> w= rote:
=20 =20 =20
On 8/17/2020 7:33 AM, Dotzero wrote:
DMARC fixes one thing and one thing only, direct domain abuse.


It does no such thing.=C2=A0 Domains can still be 'directly'= abused in all sorts of ways that DMARC does not affect.=C2=A0


Mea Culpa. You are correct that it only does = so in the context of SPF and DKIM validation which protects rfc5322 From fi= eld domains and aligned rfc5321 Mail From domains (SPF).

<rant>

A continuing and in my view fundamental problem with discussion in this space is the lack of careful and precise language when talking about actions and effects.

</rant>

So...

DMARC fixes abuse of rfc5322.From field domains.=C2=A0

THAT is the only thing it does.

See above= . I was even more specific than you were in terms of what DMARC does.=C2=A0=

And it does it at the expense of breaking some legitimate uses.
<= /p>

Only when it is used in domains where there are = individual user accounts and not (only) transactional mail uses. If I use a= hammer (no pun intended) to pound in a screw, it doesn't make it the r= ight tool for the job.

Michael Hammer (Inaccuratel= y referred to by you as Herr Hammer)


--0000000000001dd6e505ad13d8fe-- From nobody Mon Aug 17 10:48:39 2020 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 6AC0F3A0D89 for ; Mon, 17 Aug 2020 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Hm2hqLOLSLRk for ; Mon, 17 Aug 2020 10:48:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 3592F3A0DDA for ; Mon, 17 Aug 2020 10:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597686510; bh=FNs9SlZvVffxsuRTkO+NNgArOwea0agYTml3Rvtu1F4=; l=1016; h=To:References:From:Date:In-Reply-To; b=BBIvmVdo1jeLcJ6Neu77Hj8Yc9kfyuElRC72PjrwGQhiSwwHeZ+bNgjw+LmYiJl+2 N8wlVpVtnvBaYw7IW5qg8y1O0uPBUt2bHi9/CyS+1J/1dbHeUBiovlluHRxARG0ZvY DVZIwQ/xi81pMf1gipXPMrBCHyBD+VXOdfnuO/F6MR0LXUaBM/Ym9u25XasWC Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F3AC2ED.0000229E; Mon, 17 Aug 2020 19:48:29 +0200 To: dmarc@ietf.org References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> From: Alessandro Vesely Message-ID: <8eb896bd-9b97-df16-241f-64ce9ed7297e@tana.it> Date: Mon, 17 Aug 2020 19:48:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 17:48:39 -0000 On Mon 17/Aug/2020 14:48:31 +0200 Dotzero wrote: > On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely wrote: >> >> Gmail has a visual perspective that allows them to know each and every >> email domain worldwide, and employs a number of people who help >> continuously upgrading domain reputation. In order to enjoy such >> technology, medium-small domains can get a G Suite account. That's >> oligopoly. If the technology were simpler and clearer, running one's >> own mail server could be a valid alternative. >> > > Setting aside DMARC, running email servers has always had a bit of > complexity that is beyond the ability of the average person. I'm not sure > what your point here is. Having very many autonomous MTAs is better than oligopoly, from a dynamic social stability point of view. As spam elimination is the most prominent complexity that cause giving up private MTAs, global DMARC adoption might have the potential to stabilize communications. Best Ale -- From nobody Mon Aug 17 11:23:46 2020 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 084A33A154D for ; Mon, 17 Aug 2020 11:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 lagzmVMAn1sG for ; Mon, 17 Aug 2020 11:23:43 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 7B8223A158C for ; Mon, 17 Aug 2020 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597688617; bh=81DKwHIIMpb9VLqgqyUmCOQhQ10iibMk4TUXjcdytDo=; l=1928; h=To:References:From:Date:In-Reply-To; b=DWoI53mg3r+US4cCxpBGH1UlFWidatgg4w5SLThLz9I4+lk/pxERJNLt50yOpN60C j10WSICsEU3wWqczhaq63P0p3gs9vLr8V2MT1U8rOeVVjeB2/bAPGTAnlTo+jGzbHY au30taA8Yxe87bWRxnNmT4y9XyT5kvGnqQtQs196BWKtGrfS/JND/LQ/bm5pS Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.62]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BB.000000005F3ACB29.00002667; Mon, 17 Aug 2020 20:23:37 +0200 To: dmarc@ietf.org References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> From: Alessandro Vesely Message-ID: <9a42b8d1-250c-1e90-5f40-0a2a82f94f49@tana.it> Date: Mon, 17 Aug 2020 20:23:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7C25FA42-6C6B-45B9-8476-B74F2455EDDC@wordtothewise.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:23:45 -0000 On Mon 17/Aug/2020 16:00:42 +0200 Laura Atkins wrote: >> On 17 Aug 2020, at 14:18, Dotzero wrote: >> >> >> You raise an interesting point, Laura. Whatever "solutions" we put in place, the abusers/bad guys will evolve. One of the problems for the good guys (for some definition of good) is that standards work takes years (decades?) while the bad guys change their tactics at will. Crime existed before the Internet and will continue long after we are all dead and buried. > > Totally agreed. The issue here is that DMARC is a fundamentally flawed model for preventing phishing. Phishers were adapting to mailbox provider filters even before DMARC and there was a lot of cousin and non-look-alike domain phishing even during the initial discussions. I know these issues were brought up during discussion of the protocol. Unfortunately, they weren’t sufficiently addressed and now we’re at a point where, to my mind, DMARC doesn’t fix anything while also breaking a lot of ways folks use mail. > > It’s a little late now to go back. That's what I meant by being stuck midstream. Neither forward nor backward... > I think this is an opportunity to think about the underlying technical problems as well as a chance to revisit the assumptions about how email is used. Discussing things like Dave’s drafts will give us a chance to talk about how people actually use email to communicate with one another. And how we can allow brands what they want without breaking email too much for the rest of us. We have to fix the defects that cause DMARC collateral damage, if I may so roughly summarize our charter. We have two ways to do that: Forward: Solve each specific problem. For example, apply dkim-transform to MLM messages. Backward: Kill DMARC expansion. For example, reaffirm that domains which host personal mailboxes must not publish strict policies. Best Ale -- From nobody Mon Aug 17 11:26:28 2020 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 89DBF3A1548 for ; Mon, 17 Aug 2020 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=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 IFb7usqW8KtL for ; Mon, 17 Aug 2020 11:26:23 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9B93A146C for ; Mon, 17 Aug 2020 11:26:22 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 4BVjDD3Zthz2qF17; Mon, 17 Aug 2020 20:26:20 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx10.mailtransaction.com 4BVjDD3Zthz2qF17 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1597688780; bh=tMRzmHw6sh81QRYToWnTdbua0ocftbvJ+l1PT2YxHEU=; h=Subject:From:Date:Message-Id:To:From; b=P6A0IC8MeNVuOxEGInFurhTGn/1YuIO/vvz5dHqTGO6qfvBsz/hbowja4/dDLB9CI IjF1Z9+a3MhZk1yakIp5j1/T4/ffixx7YKRWhl/z//rVFALIy9cyXnI21TaG0TflKh x0n4qpvsNDSJv054Lf3x8s2KqgTu4Ufwap9WF4T4= Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx14.mailtransaction.com (Postfix) with ESMTPS id 4BVjDC3cHNz2qF15; Mon, 17 Aug 2020 20:26:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 305A14223A3; Mon, 17 Aug 2020 20:26:19 +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 DQZaNjjFzShK; Mon, 17 Aug 2020 20:26:19 +0200 (CEST) Received: from [192.168.178.86] (a82-161-205-136.adsl.xs4all.nl [82.161.205.136]) by tiger.sonnection.nl (Postfix) with ESMTPSA id EE4254223A2; Mon, 17 Aug 2020 20:26:18 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-274AD373-7A3E-4701-A72E-F67F598C9C8C Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: "Rolf E. Sonneveld" In-Reply-To: Cc: Dave CROCKER , IETF DMARC WG Date: Mon, 17 Aug 2020 20:26:17 +0200 Message-Id: References: To: Dotzero X-Mailer: iPad Mail (17F80) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:26:27 -0000 --Apple-Mail-274AD373-7A3E-4701-A72E-F67F598C9C8C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> On 17 Aug 2020, at 16:47, Dotzero wrote: > =EF=BB=BF >=20 >=20 >>> On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker wrote: >>>>> On 8/17/2020 7:33 AM, Dotzero wrote: >>>> DMARC fixes one thing and one thing only, direct domain abuse. >>>=20 >>> It does no such thing. Domains can still be 'directly' abused in all so= rts of ways that DMARC does not affect. =20 >>>=20 >>=20 >> Mea Culpa. You are correct that it only does so in the context of SPF and= DKIM validation which protects rfc5322 =46rom field domains and aligned rfc= 5321 Mail =46rom domains (SPF). >> >>=20 >> A continuing and in my view fundamental problem with discussion in this s= pace is the lack of careful and precise language when talking about actions a= nd effects. >>=20 >> >>=20 >> So... >>=20 >> DMARC fixes abuse of rfc5322.=46rom field domains. =20 >>=20 >> THAT is the only thing it does. >>=20 > See above.. I was even more specific than you were in terms of what DMARC d= oes.=20 >> And it does it at the expense of breaking some legitimate uses. >>=20 > Only when it is used in domains where there are individual user accounts a= nd not (only) transactional mail uses. If I use a hammer (no pun intended) t= o pound in a screw, it doesn't make it the right tool for the job. >=20 > Michael Hammer (Inaccurately referred to by you as Herr Hammer) Talking about precise language, Dave, I think you owe Michael an apology ;-)= /rolf= --Apple-Mail-274AD373-7A3E-4701-A72E-F67F598C9C8C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 17 Aug 2020, at 16:47, Dotzer= o <dotzero@gmail.com> wrote:

=EF=BB=BF

<= /div>
On= Mon, Aug 17, 2020 at 10:37 AM Dave Crocker <dhc@dcrocker.net> wrote:
=20 =20 =20
On 8/17/2020 7:33 AM, Dotzero wrote:
DMARC fixes one thing and one thing only, direct domain abuse.


It does no such thing.  Domains can still be 'directly' abused i= n all sorts of ways that DMARC does not affect. 


Mea Culpa. You are correct that it only does so= in the context of SPF and DKIM validation which protects rfc5322 =46rom fie= ld domains and aligned rfc5321 Mail =46rom domains (SPF).

<rant>

A continuing and in my view fundamental problem with discussion in this space is the lack of careful and precise language when talking about actions and effects.

</rant>

So...

DMARC fixes abuse of rfc5322.=46rom field domains. 

THAT is the only thing it does.

See above.= . I was even more specific than you were in terms of what DMARC does. <= /div>

And it does it at the expense of breaking some legitimate uses.

Only when it is used in domains where there are in= dividual user accounts and not (only) transactional mail uses. If I use a ha= mmer (no pun intended) to pound in a screw, it doesn't make it the right too= l for the job.

Michael Hammer (Inaccurately referre= d to by you as Herr Hammer)

Talking about precise language, Dave, I think you owe Michael an apology ;= -)

/rolf
= --Apple-Mail-274AD373-7A3E-4701-A72E-F67F598C9C8C-- From nobody Mon Aug 17 11:28:18 2020 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 52BBD3A1574 for ; Mon, 17 Aug 2020 11:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 BX5VVPJnmxHG for ; Mon, 17 Aug 2020 11:28:16 -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 1E6EA3A1572 for ; Mon, 17 Aug 2020 11:28:16 -0700 (PDT) Received: from [10.0.0.178] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07HIV0JP020298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2020 11:31:00 -0700 To: "Rolf E. Sonneveld" , Dotzero Cc: IETF DMARC WG References: Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0b88f963-13a9-ef3f-f970-7455418b55e6@dcrocker.net> Date: Mon, 17 Aug 2020 11:28:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:28:17 -0000 On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote: >> Michael Hammer (Inaccurately referred to by you as Herr Hammer) > > Talking about precise language, Dave, I think you owe Michael an apology ;-) to mix languages, au contraire. I was being formal, as well as precise... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 17 11:53:27 2020 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 A7C6E3A0962 for ; Mon, 17 Aug 2020 11:53:25 -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, 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 XSSAqTAXD4so for ; Mon, 17 Aug 2020 11:53:24 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 AA9563A09D1 for ; Mon, 17 Aug 2020 11:53:17 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id k18so13225759qtm.10 for ; Mon, 17 Aug 2020 11:53:17 -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=Hw7WJ8URoKNwFv8a+5Tn9SVe7svaf1YaxmdcuewLzow=; b=hd7zvPz1LWojE1mwUS3xse8f4b9RYFGfznLINt+DfbAyd1LVoN0EeeCiQmZBZmqRir XA2xNrGgrFzr35qfNcx5v0v+a6WSgh827ReI3U4oMy96ZDsenO4sKsqkL2m3jcqiAXLQ 4pUvh51MPBiUsQJEyaITGSRiCkSQYrJEZFpAiU5HZRUEyv5z7WicKy443QN0WNn9GUOg RM2CdNR8FGpZSLfaWJMpBkeTbjY1lH69EkDg2TwYr7ypkFGIB5QXEJzw5I6yidY/sNUs rhCzUBy/nh1nlKQ/1kqn6SY+LSZiYUPDkjrZdeIupAZ0Uz9x3ivadrFAhxp4taP2FOt3 VwTw== 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=Hw7WJ8URoKNwFv8a+5Tn9SVe7svaf1YaxmdcuewLzow=; b=L8mKGG+zfm4RJ6LBdyle77qmLcZF0h2i1kzHOLJHFAsaAQ6hii+xy6PfZcRJ5L4gxs 6nGoe+/duAr9BjjGZlhYBIcYGpVIZyJPq1DWvqRF4sEFLEVPbOP5mR/skLA4KKwks05S GPOFpai8rqVl7nBkQxHNFjBp4BLyYiCUJZfBX7cpTiLdOcxTycIhRvHOfP2UI3y7qQWo pSlsbB+kzpNS/QNff+84/OpDc75oaUBe38fQwNV3/57ZE+86fzWiqU6WBXOPkIeYvUnA UezZmLPics9n4kHKb6PU/p+4el8TbRbQwILsRhHx7uN7XK6DpyUmCbquHHusLJOvy9yQ k17A== X-Gm-Message-State: AOAM531mqFlzxbN+VnnwU7eyo2BAjA640XO+fXGLAYOK7F/zMzFJ3m1Z r9FF50WU6g3YXujgMA++M75J1gt2/nyC0E7K05VhNEqN8H8= X-Google-Smtp-Source: ABdhPJw9rhS4cNRh6eL84rSvEZxCmg2Wm6rHsAPLegyEK+X+yqAMlRrNlzflVCRLT/pcOxFrTP13iiOnLtCHy/9PHiA= X-Received: by 2002:ac8:660f:: with SMTP id c15mr15070103qtp.34.1597690396724; Mon, 17 Aug 2020 11:53:16 -0700 (PDT) MIME-Version: 1.0 References: <0b88f963-13a9-ef3f-f970-7455418b55e6@dcrocker.net> In-Reply-To: <0b88f963-13a9-ef3f-f970-7455418b55e6@dcrocker.net> From: Dotzero Date: Mon, 17 Aug 2020 14:53:05 -0400 Message-ID: To: Dave CROCKER Cc: "Rolf E. Sonneveld" , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008ed1ed05ad1748bf" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:53:26 -0000 --0000000000008ed1ed05ad1748bf Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 2:28 PM Dave Crocker wrote: > On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote: > >> Michael Hammer (Inaccurately referred to by you as Herr Hammer) > > > > Talking about precise language, Dave, I think you owe Michael an apology > ;-) > > > to mix languages, au contraire. I was being formal, as well as precise... > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net Apology accepted. ;-) Michael Hammer --0000000000008ed1ed05ad1748bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 2:28 PM Dave = Crocker <dhc@dcrocker.net> wr= ote:
On 8/17/202= 0 11:26 AM, Rolf E. Sonneveld wrote:
>> Michael Hammer (Inaccurately referred to by you as Herr Hammer) >
> Talking about precise language, Dave, I think you owe Michael an apolo= gy ;-)


to mix languages, au contraire.=C2=A0 I was being formal, as well as precis= e...

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--0000000000008ed1ed05ad1748bf-- From nobody Mon Aug 17 12:01:49 2020 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 CDA9E3A0A83 for ; Mon, 17 Aug 2020 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=bbiw.net header.b=zuOq5E9a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AshtWyrW 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 CtA1xSL-QM5h for ; Mon, 17 Aug 2020 12:01:42 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3E33A16FA for ; Mon, 17 Aug 2020 12:00:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B4CF45C00FE; Mon, 17 Aug 2020 15:00:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 17 Aug 2020 15:00:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=P XdVZiSCDx3mKcanvdg6k3nwowgnMjiKUjYiVW9wAU0=; b=zuOq5E9ad2GxP5zOE 8cscJhFk76BdHKbvGZ96p7Lt5ZNQ9GbO4GNrKxbD7vPyUJ0MxyfXMUO2kK3mbsr+ VHj2ggV69ajsKkJfTEmQl3Y+3K6IMpsyHcxJz8HLdC6Ke0tLkqwRjUFp+Kk9gSy+ kkRVSwlJgi1GebWjxtIunOoOoJYsDp1d5TeDejwelpZUx3bIiwata1FsrDpyICLi bMZLZnkzf/YEPzzUooK0R4vV+ZA4yFNVmMv/NX9nYsypE7LS4/IWHd0TmSBXSpgp 5dJwY1eueFAMGAUNIfbCnSV0PKC1EEpxW/BlC3Od1bNHo4ysCUE8KKBtZ2Xn/WyD dSfVw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=PXdVZiSCDx3mKcanvdg6k3nwowgnMjiKUjYiVW9wA U0=; b=AshtWyrW41RNOIcga8pG46VZP65hmDN3FIEXxXAfMMwnGtOAs6ycEx+uc nZTDwxPapKP7NYlvR/FCLKyYnJUCixTA4xmhLke4k76iyExCujPUA8Dl6GJnVfvX USI9UdHki/z96XNB43d3EHOLhC42cGQm7wCyv75T28JZbKKmrhVtijtCWbafLoMx TKv2JorzqqDLLTfCrgPtb7ZRbBeBhDTzsc28ruJfME77gQ+e27GAttebaxCm9XYi nnIORScY5YY78URTrn3NdORwTj8OmZx85dLu0jgfs1av7PLlp+u5qRtWHa75Cii1 bWKaqzR9llqEAH29qRUYc6Fnimj0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtgedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeffrghv vgcuvehrohgtkhgvrhcuoegutghrohgtkhgvrhessggsihifrdhnvghtqeenucggtffrrg htthgvrhhnpeeihfdvuefgjeekffdthfelveelteevfeegteefgeetjeejudejueegheef hefgieenucffohhmrghinhepsggsihifrdhnvghtnecukfhppeejfedrudehkedrvdduje drvdefkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegutghrohgtkhgvrhessggsihifrdhnvght X-ME-Proxy: Received: from [10.0.0.178] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A0E9328005D; Mon, 17 Aug 2020 15:00:30 -0400 (EDT) To: Dotzero Cc: "Rolf E. Sonneveld" , IETF DMARC WG References: <0b88f963-13a9-ef3f-f970-7455418b55e6@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 17 Aug 2020 12:00:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 19:01:48 -0000 On 8/17/2020 11:53 AM, Dotzero wrote: > Apology accepted. ;-) nein. maaf. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 17 13:00:19 2020 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 397A13A0FCF; Mon, 17 Aug 2020 13:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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, FROM_SUSPICIOUS_NTLD=0.498, RCVD_IN_IADB_DK=-0.095, RCVD_IN_IADB_LISTED=-0.001, RCVD_IN_IADB_RDNS=-0.235, RCVD_IN_IADB_SENDERID=-0.001, RCVD_IN_IADB_SPF=-0.059, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=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=lem.click 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 J72R0FFXp4N0; Mon, 17 Aug 2020 13:00:15 -0700 (PDT) Received: from libertad.link (ns1.libertad.link [192.241.161.190]) (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 B183D3A0FAD; Mon, 17 Aug 2020 13:00:11 -0700 (PDT) X-Virus-Scanned: FWTK at libertad.link Authentication-Results: libertad.link; spf=softfail (domain owner discourages use of this host) smtp.mailfrom=lem.click (client-ip=151.181.63.196; helo=[151.181.63.196]; envelope-from=dmarc-ietf.org@lem.click; receiver=) Received: from [172.20.3.65] ([151.181.63.196]) (authenticated bits=0) by libertad.link (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07HK06iL016131 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Aug 2020 20:00:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lem.click; s=s1; t=1597694409; bh=kzJtArUxkIJpF5NCiOWqKLa9RKWPiotiDWazYESKJG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B5c+7LLa0v/cugJ8RLRnosWo26PZGJEKgopeL+RIFk/uYb8pwfL7IbLUbhSO+RMEm KmMpLmPkSd6GWhQbViQKSy071ZGWj/+sWdEgPZz0Wn+WUl1alhwwR4ras1IOQbceM/ gYfHrgsEA+jj1OfuPtC1KPA56YtNsBjXmui79Ls0= From: "Luis E. =?utf-8?q?Mu=C3=B1oz?=" To: "Neil Anuskiewicz" Cc: Dotzero , "IETF DMARC WG" , "Kurt Andersen" , "Doug Foster" Date: Mon, 17 Aug 2020 13:00:06 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> In-Reply-To: References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 20:00:17 -0000 On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote: > Under 50% of companies have any DMARC record. Of those who deploy > DMARC, > about ~2% have p=quarantine and ~5% p=reject, though some industries > such > as finance it looks like it's closer to 15% p=reject. I'm sure these > numbers aren't perfect but what you have likely isn't radically > different. My numbers are inverted regarding quarantine vs reject, as I posted on this list: On 30 Jul 2020, at 18:01, Luis E. Muñoz wrote: > > I am currently observing ~215.5 million domain names. Out of those, > ~64 million have a seemingly _valid_ SPF record and ~113 million with > at least one MX record. > > This is a current breakdown of the (valid) DMARC records I am > observing over the general domain population above. This amounts to an > adoption rate of ~1.7%. > > | p | count | > | :--------- | ------: | > | none | 2715614 | > | quarantine | 238584 | > | reject | 726045 | Numbers have moved a bit since then, but not much. I'm seeing 3:1 reject to quarantine ratio across the board. > Why is adoption low? Is that a big problem? Why so few aggressive > policies? > Is that a big problem? DMARC can be quite useful even with p=none. This use case provides insight on what's going on and sometimes, that's all that is wanted. Moving to more aggressive policies require a degree of control on the mail flows that not all organizations are prepared to exercise, IMO. Best regards -lem From nobody Mon Aug 17 13:16:47 2020 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 049AA3A1064 for ; Mon, 17 Aug 2020 13:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=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=iecc.com header.b=SIIZsMCJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=IiCJPDZA 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 8zcT-H3_o_5T for ; Mon, 17 Aug 2020 13:16:43 -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 8838B3A1062 for ; Mon, 17 Aug 2020 13:16:43 -0700 (PDT) Received: (qmail 61077 invoked from network); 17 Aug 2020 20:16:40 -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=ee93.5f3ae5a8.k2008; bh=Wg4R3eU/5eQsmxf78D4fyKPcbkLOZsQuXiGEQfRb2NM=; b=SIIZsMCJ7FExlJp0LwZas/zK1Fv9ryEFAg06lyzG97HHrOgWrK3IGBf7d3T6fHqN2OfXLwzzxW4NT1kXKaE27uCXZvxvsUbzm/19gu2DXCC9x+LjOiy0a77s0y7DvTqudn2uQ2ECuVTmaH7VWDtJCbXCQRG9CMAzk9tSuve58BxYETw7HVae2JPXlK22AByQIKBrZtFL0DkdFYrZk1SKbAN51CLjWNpmmNJ7KiPuxsf6G2gpCRjyKs7vejmnIRGrJW9IjrGfvC1J/KxjKVOGEZ5emaqxPVIx4qA9fO5pfhgXfuI60ePg+HnddVFGmh6OROmmm6LpZ4jcJdh4xgStWw== 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=ee93.5f3ae5a8.k2008; bh=Wg4R3eU/5eQsmxf78D4fyKPcbkLOZsQuXiGEQfRb2NM=; b=IiCJPDZAVrlqy+Gi+N49VSJVH7yejdmSVp/3WYwvpcQoXNaV72wXg+0faqez82wFcWHW45O7e99zr6oS5SxUzExV/wZrv9VuUrgnT4z4APB6aC611wnHKAzpH6Wj2SFuMGiFh/NE4SB4MuvaDZ2O/AraUJSGerHtZMzkWyIXKYkuY7zRR7VRK3GetO15PuEibvv7JLFgcrlFatQ838Zac1uDlaWwm+lBbh2lgAKowKs9s/7j5O6eURfOyLfnluPG9BdM5PO1ihR0Nb+JoxLFK5qJAXBCittZJL/Md7o4MDy8j8zSZy1HUiV5ODfRIaZ9X8p+b7J5IoRgN8ObJk68zw== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 17 Aug 2020 20:16:39 -0000 Received: by ary.local (Postfix, from userid 501) id 8E7351EE5694; Mon, 17 Aug 2020 16:16:39 -0400 (EDT) Date: 17 Aug 2020 16:16:39 -0400 Message-Id: <20200817201639.8E7351EE5694@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dmarc-ietf.org@lem.click In-Reply-To: <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> 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] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 20:16:45 -0000 In article <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> you write: >> Why is adoption low? Is that a big problem? Why so few aggressive >> policies? Is that a big problem? > >DMARC can be quite useful even with p=none. This use case provides >insight on what's going on and sometimes, that's all that is wanted. >Moving to more aggressive policies require a degree of control on the >mail flows that not all organizations are prepared to exercise, IMO. Quite right. My system publishes DMARC policies for over 100 domains, and they're all p=none execpt that four which don't send mail at all have p=reject. I collect and look at the reports which can be very interesting. From nobody Mon Aug 17 15:52:22 2020 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 49FA73A13FB for ; Mon, 17 Aug 2020 15:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 9IL-EKqYOJyA for ; Mon, 17 Aug 2020 15:52:19 -0700 (PDT) Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 D0B783A13F9 for ; Mon, 17 Aug 2020 15:52:18 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2173.outbound.protection.outlook.com [104.47.59.173]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QF8005EUCV5L810@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 17 Aug 2020 17:52:18 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.17.224218, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.21.5750001, SenderIP=[104.47.59.173] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GyNQclH4edxotWSxxXouVPMQZh0pigocworpquIB0rN+0GmK5xL2ANR/MwdaJdnZ/XHfJd8yK+7p3P3pJs++h5ENZ+JlrDR4I0RPAQOMJzjMJKfF2JmFHhk5ovzSf+RYCKzzXSEIfS1vSGSr09Eg/YZJbRvLAdDgzeG7z71agstdNqUqjzYEpWFYKZ7H/kDFq9WrescwDHh3c2FP6vbyQheU9Sg17boGD0WpGVh0/xBX6W0ESkR4Y7lZV6xKCnDaC5r7POOx8Zn1DsTq31HseX04efCq9vwj133DVWzk2qlCnoHRv+c5W2gw/9A2i9+s8lkXXtjeCUkA1TEHhIHJ0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7GeqTLMhT0Rds39311DarbkTOhPkzeKo9tBdKwkpdq0=; b=aM8huil/JJwBd4XU89U7mSlNhPp9Sw/dbH6ps41d6aVdzpaXxEyAAQ9w0JgVy2qmekCbzFkEzOr+lne98Idd7QvQrfiqSFUtY6FGHw9cMv56Y8XVg0rwmyPrJGgeL6ilzdQeqOLhp0oKrwh0PVhlInPpRjQ2V08VlB+rW4DS7QrrlpFHg8M6Q+MEOv7E2k4sAT9Vp54okkalyC03ZBwoS9vZIjgZSYBQCdc7NyzeMv9WvfEKPWIcqKenMBUhxajd6poO/HmxndeJvkxvMa0CugD8JKC2ou2583Td+XoFT7Nc1yLkbaqSVMmEZnOFCnWHwSwGhCN6BNacfPmQ5H88Lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7GeqTLMhT0Rds39311DarbkTOhPkzeKo9tBdKwkpdq0=; b=gFp8xNwCb8QjDcMaXY6hrK/Z4Kar99mVUqQPUxONd+KMLmP00BuF61tf+Iia4GdaU943GdPJUTK7K/rejitLvbu72xa2zNGO7wp5eghvslzl0nfljUtrOeQE5K9eRxeABW+XomaUjnaGwhSNOzYCaZLYU/yLfbQZpSQOiFgNljs= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB2395.namprd06.prod.outlook.com (2603:10b6:3:59::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.23; Mon, 17 Aug 2020 22:52:17 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50%6]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 22:52:17 +0000 To: dmarc@ietf.org References: <20200807191216.43E971E4014E@ary.qy> <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> From: Jesse Thompson Message-id: <7ce20245-5942-14f3-3220-1faaa2c8ccbb@wisc.edu> Date: Mon, 17 Aug 2020 17:52:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR20CA0020.namprd20.prod.outlook.com (2603:10b6:610:58::30) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR20CA0020.namprd20.prod.outlook.com (2603:10b6:610:58::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15 via Frontend Transport; Mon, 17 Aug 2020 22:52:16 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e27a8794-83f7-4084-aef6-08d8430030b1 X-MS-TrafficTypeDiagnostic: DM5PR06MB2395: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: z1ywZIvamRzThZf36Zrub3ISshYEq9kgXe4dYnZOUoc/wf1pbxPhvdAFPxF4VU6P86bdaRZMQ2tPBMa5CkJ6nSlr2vw95O0uoXLjUnjXqcpkuW6bLMOkHMXVdohtmjkDzf/3zsvXPG7nPP3lJWBs2A5P05OqGCYRAGgGiyrkFZ2zbjvAMUerwwT4y54MdDBG9ukYeQ16i7+jZhCzM2ZwhwAKwUsrTHRVPmxWFXkQ77tCWvY0Yi8pjqw5A2rIV/xvUOldoBFeEcf2NOVDUubLe8OpX3ZdfoqS9tmj94YuVhNjute/2sKbLSc+Y79hAeS5DSsw+HshmMZvF+QgUYogBNj52g1u63+Rd2SsBvcpCQjZjGKyURhEikiAemHok6/RNNy0TgjIG9+n8WSMLDNm/kQ6dgIn5Q5iCqLx9Vp6dW0wcdbjD1lirjIW6RK7658RflJ0w3Niejo/lGHnqmB3xT3WecylmWtgH5V8vaYcPpk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(346002)(376002)(136003)(66476007)(31686004)(8676002)(316002)(6706004)(83380400001)(16526019)(16576012)(31696002)(66556008)(86362001)(786003)(6916009)(6486002)(66946007)(36756003)(2616005)(956004)(75432002)(5660300002)(26005)(44832011)(6666004)(186003)(2906002)(53546011)(8936002)(478600001)(3940600001)(130980200001)(43740500002)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Q9jvP18F+Tu8D0FlTgS9/U1hoImPUZiOxXWAFtHqJ/ddI7RDFMur0wwNjpseOxEzdsbHFCEutlgebwg4Gw+1BxWQesrC4wR2KvtrJedjoOhAXueO4L7XC2lzZkfUjT/B4qSrAZmCzHOBaU7Zw0cvTJBGL1MjPCRT88AqGNN6aseO5WjtGc/Ljhx1RWMyKGmMoOgceDuziXl07LGI/HfK5f6DWdJnLhBuh6bhNMxmMO4XGnz0yGXEjhiRBSZyKHReJ83XdfFkx4kEwXXNnZObBr6NER5LvbXOUPc9h6dYVdsAfxvZAkH5T8csg15cZ0BauMD/MXXoUD+6hfNbUGdGBZ5R9m+Fj0MLXvgtAjtITun+w+wWIEYPkDfnvfQ7V65Pwt6vsMZ4+x6/a2PADDmuWXc1Yfo3aeh6eR4rUBy3brCz6xc/dTwl2j2DmlcOj2Ya2XdLvmEV8P64t7z3MiiIrjkH8cZgyMIsl50Vb/+79wmE/YKXb6+Qsaj2EyR15vu1iVTJ67ahcmojt2X8hZuYSxb/o5crHSCKr1oW8n5jmFpdIE5r1fdj/TxG3xrslmhpoEM/gjtZ0p9PQOTP+PV9tAe8INNgDUt7VrL9t8y+80hZw2DQbL2Ia0epQIPSHW+GxiPOGd3AQYwf1nQ2tJCURQ== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: e27a8794-83f7-4084-aef6-08d8430030b1 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2020 22:52:17.0696 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rkhTMDBrPgjsqIBN1Yot/SjmVHwl6ZNl2oP6SdqfaFehQh/KnDey2cpU+ZD9djC5lxZIXLq4rqMV56MyGYkkkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2395 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 22:52:21 -0000 On 8/13/20 10:03 AM, John R Levine wrote: >> -Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by people setting restrictive DMARC policies without knowing what they're doing. > > If they all talked to you first, we'd be having a very different discussion. With a complex organization the only way to get people to change is to publish a restrictive DMARC policy and then see who comes out of the woodwork sheepishly admitting that they've been ignoring us for years. Normal people sending email (especially those who are working with an ESP, most of which happily send email without any DMARC alignment) do not comprehend the notion that they should be using a subdomain for their transactional messages; even when we directly communicate this fact to them repeatedly. They just don't understand the nuances of email. Similarly, it's only way to find all of the old DMARC-unaware MLMs, most of which haven't been security-patched for years. Forcing them to upgrade to a MLM that can munge the From is a back-door way to get them to patch, or reassess their commitment to running the list in the first place. Enterprise IT/cybersecurity actually want to get better manageability on the email their institution emit. Misdeploying DMARC provides that. Publishing restrictive DMARC on user domains is not always a clueless IT decision. Jesse From nobody Mon Aug 17 16:21:49 2020 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 D4B653A143B for ; Mon, 17 Aug 2020 16:21:47 -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, 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 kL5hygjDtFFL for ; Mon, 17 Aug 2020 16:21:46 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 4DE043A143A for ; Mon, 17 Aug 2020 16:21:46 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id i129so9167933vsi.3 for ; Mon, 17 Aug 2020 16:21:46 -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=ISHBxn4BwaKRg/so6amlJIcs4shzsljJss4pwxt6VfQ=; b=ELDruWGcvZ1dn7DYzi4yIYjjELCvt6wtncyyr11vrv3SrktwVQ/OiigNVi6KsVXNeA yPrrKPpS5dOrzgIUaVX/XbezYl9UccF3SA1z4dIBdVZ6cxQd5fOwkGpIu7+IKV/hdKSb qenkbcK7+f9LjlNXl0spVl82PmKo07WWRn28GDrBZzqyOudBbFLimFFDJbEZW6AjMShd yf0WD2ViZCn1dCz2h1ovS+yZlWPtalr1410yQqbdqcKncgAbAlOTmYsXTYozc7HkxOqM sfWwmZgbh7NyIdzoOoOTkpfEk9B7ZqulWKI3IG+5joRlACXPuacXxMe6EGI2TqKMwgVr 47hw== 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=ISHBxn4BwaKRg/so6amlJIcs4shzsljJss4pwxt6VfQ=; b=iEpHxg1qROqxpFNO28cppyBmupG4sMyA8Txbx4BjJZH4JaO3Kxg14ItH/atj5f15o6 IqBLhzUg/SY93AAOy1foqS1Z0eJwUMIlaj5M17MX8z0Y3/b+PqqLJIsEiMw9zXlAEHsl izqJTJf/kXpp03KPNCVBHgPJKnUjIpSawCpcfpvcanRSooEJhkAGf8BVCi8smDTbER4M bE0bJE4OWi0Ca2VosaLCuo7J+mPngA3EIgHcn5IOVCS6SkJmoLs5AWifCIPvoYhqrbOJ ZzdWwxPSHBKw8JbEx4v9f71F01uq3XSbXiLx4gOs4M+sGVvs7rj/JlDcRaBcN+CJXHwp oVBA== X-Gm-Message-State: AOAM532U2HnXDV0ibdINJxNuQ/HHrC+W4BPiYhQH6+SFfrRUZc7lc/yg z/RHyI7soN5f+Yj1fcX8k2wDCb/Yxw4XAqvEEoQEUSgr X-Google-Smtp-Source: ABdhPJxEX4wEy782dAiEfeiJwbtVyooSI4RDYQ/gHCMi550kjjqeOGtIgAorknmg4lR/nkcjcOoxF3z/gB2/uBPidBU= X-Received: by 2002:a67:87c1:: with SMTP id j184mr4532774vsd.8.1597706504955; Mon, 17 Aug 2020 16:21:44 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> In-Reply-To: <5F396A77.3000109@isdg.net> From: "Murray S. Kucherawy" Date: Mon, 17 Aug 2020 16:21:33 -0700 Message-ID: To: Hector Santos Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000aeeca205ad1b08d9" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 23:21:48 -0000 --000000000000aeeca205ad1b08d9 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 10:19 AM Hector Santos wrote: > I believe it would be prudent for the AD to look at the reasons why > the IETF has failed with this DKIM Project. If a cog is not for ADSP > but for DMARC with the same problems, then what is that to say about > this process? It has not been a fair process to say the least. A lot > of wasted time, money and energy. It has been a long 15+ yrs and has > become very tiring. :-( > > Despite the 3rd party authorization brush back, the concept has never > gone away. It says a lot and it will never go away under the current > DKIM POLICY model using the required hash bound Author Domain anchor > as the forcing function for authorization. > Since this bit is directed at the AD, I finally have to put that hat on. I don't agree that DKIM has been a failure. I believe it succeeds at exactly what it purports to provide, but not more. The industry in general, and the IETF in particular, have chosen not to pursue widespread use of any kind of standards-based third party domain signature policy or reputation system. That's the obvious consensus, and in my opinion the reasons for that fact are sound. Both ATPS (individual submission, experimental, February 2012) and the REPUTE series of documents (working group, standards track, late 2013) saw nearly zero adoption after publication even when free reference implementations were provided. They differ from basic DKIM in that they require non-trivial upkeep, and that appears to be a step function inhibiting adoption among operators. As to your assertion that this process has not been fair, I'm curious as to why you say that. There's nothing I can think of here other than DMARC that didn't go through a consensus process. That means concerns about all of these topics were heard and discussed. People's opinions that were in the rough still got aired; I don't recall that anyone was silenced just for dissenting. As I said before, I'm disappointed that things like ATPS and REPUTE never got a serious attempt, but that's not because they were oppressed or sabotaged. That's just the reality we're in. If you can point to a discussion thread on the old DKIM list or any list since then where procedure wasn't followed, that might be interesting. I still agree that if we could figure out a way to do this third party thing, it would go a long way toward resolving this whole problem space. But in many years of trying, we haven't found a way to do it that scales, is resistant to attack, is easy to implement and reason about, and is likely to achieve any real momentum. That appears to be a taller order than one might think at first blush, fair or not. ARC is the only thing that has achieved consensus and appears to have a chance at non-trivial levels of adoption. I think the IETF did fail here in certain ways -- for example, by not being more helpful to the industry many years ago when the second derivative of spam and phishing was particularly acute -- but that rant is for another day. -MSK, ART AD --000000000000aeeca205ad1b08d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe it would be prudent for= the AD to look at the reasons why
the IETF has failed with this DKIM Project.=C2=A0 If a cog is not for ADSP =
but for DMARC with the same problems, then what is that to say about
this process?=C2=A0 It has not been a fair process to say the least. A lot =
of wasted time, money and energy.=C2=A0 It has been a long 15+ yrs and has =
become very tiring. :-(

Despite the 3rd party authorization brush back, the concept has never
gone away. It says a lot and it will never go away under the current
DKIM POLICY model using the required hash bound Author Domain anchor
as the forcing function for authorization.

<= div>Since this bit is directed at the AD, I finally have to put that hat on= .

I don't agree that DKIM has been a failure.= =C2=A0 I believe it succeeds at exactly what it purports to provide, but no= t more.

The industry in general, and the IETF = in particular, have chosen not to pursue widespread use of any kind of stan= dards-based third party domain signature policy or reputation system.=C2=A0= That's the obvious consensus, and in my opinion the reasons for that f= act are sound.=C2=A0 Both ATPS (individual submission, experimental, Februa= ry 2012) and the REPUTE series of documents (working group, standards track= , late 2013) saw nearly zero adoption after publication even when free refe= rence implementations were provided.=C2=A0 They differ from basic DKIM in t= hat they require non-trivial upkeep, and that appears to be a step function= inhibiting adoption among operators.

As to your a= ssertion that this process has not been fair, I'm curious as to why you= say that.=C2=A0 There's nothing I can think of here other than DMARC t= hat didn't go through a consensus process.=C2=A0 That means concerns ab= out all of these topics were heard and discussed.=C2=A0 People's opinio= ns that were in the rough still got aired; I don't recall that anyone w= as silenced just for dissenting.=C2=A0 As I said before, I'm disappoint= ed that things like ATPS and REPUTE never got a serious attempt, but that&#= 39;s not because they were oppressed or sabotaged.=C2=A0 That's just th= e reality we're in.

If you can point to a disc= ussion thread on the old DKIM list or any list since then where procedure w= asn't followed, that might be interesting.

I still agree that if we could figure out a way to do this third party thi= ng, it would go a long way toward resolving this whole problem space.=C2=A0= But in many years of trying, we haven't found a way to do it that scal= es, is resistant to attack, is easy to implement and reason about, and is l= ikely to achieve any real momentum.=C2=A0 That appears to be a taller order= than one might think at first blush, fair or not.=C2=A0 ARC is the only th= ing that has achieved consensus and appears to have a chance at non-trivial= levels of adoption.

I think the IETF did fail= here in certain ways -- for example, by not being more helpful to the indu= stry many years ago when the second derivative of spam and phishing was par= ticularly acute -- but that rant is for another day.

-MSK, ART AD
--000000000000aeeca205ad1b08d9-- From nobody Mon Aug 17 16:39:37 2020 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 1AF753A1451 for ; Mon, 17 Aug 2020 16:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 YDOXGeFirReC for ; Mon, 17 Aug 2020 16:39:34 -0700 (PDT) Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 8915A3A144F for ; Mon, 17 Aug 2020 16:39:34 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QF80051HF1WVA30@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 17 Aug 2020 18:39:33 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.17.233017, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.55.100] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TrOzhyAgrts8v0LEMjvmsYojVQKeNyPeqrikl8g/rybLqYRZCTvIrPIz3ckdupHyqZc4GamA5SkfQezu6qj0m8xNnqErECYn9XIU65EgoBmCCWWdT+2S6B0X5Kdn9nbWN3aYozzAeempK2/zgDT7tjXlCl/urlvpYwQy7Ys2hGQnUeApi+LfmyKT7RoVhP8kpMzTfaOx6iONYdzn6ybYAyLwIyKilDgClp+jVfVAgmASHME9cF7RAvfIMLGkIe2vkneXjyFCphTUdLN37Y5dy34BcuSryi4XbYWKIX2wbw/MhayVM6+QiS1fm8B7ZhWrCY/XL4JPMFAPhd6mDLRJbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4NrXWCYEWUzekBHmLQzPiyTT6zYoVZHOw+sTG4ET57Q=; b=FB5LlZW0c/s8e7nq4XMfjhPH5Ze8y3qhaELxOSrJNqmYkriE6rQOBAuUcaPUZxX3WysZ3BHkMJNOw0IE+j5DS/OZ5SSNM8m2v46hiDI/x3gzGn1uhrX8qc+fbGcaExPak+OirLKvO/kA3iudx0ZSBygsHSC/VD1pkbzXDCqI1GsWAy++C9isLLXojjPwcJ7hZ2pdTvvBhsYh54Un0ievKEL+PSCjWUhvshuYDba5tWaKIGCFXywpZz84Ipkm8GUn1BnApBZchOmEiigk7+/DlB7IsFs2Tp5dFKbfWrHQuax1srJhuDKIu+fafTFrbXN4atEfoX6djlsT4maQVna3Gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4NrXWCYEWUzekBHmLQzPiyTT6zYoVZHOw+sTG4ET57Q=; b=HmeLNQUGtupBjGs/7BpgHp424rsyYXoJe4nutOIrsU/cMUbt27o9IBNz5OEU5oDe8UEHf9nK70JXDkGbC9Kuob7tglSbjNZj8633dkODI64nGUjohXvOPwoE4llV6/Zk3gHvol08yQ2vwEXchqexBCxK4VxAIENJQJjk4aghjvk= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR06MB3129.namprd06.prod.outlook.com (2603:10b6:4:40::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.26; Mon, 17 Aug 2020 23:39:31 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50%6]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 23:39:31 +0000 To: John Levine , dmarc@ietf.org References: <20200808023259.1D07F1E60C2D@ary.qy> From: Jesse Thompson Message-id: <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> Date: Mon, 17 Aug 2020 18:39:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: <20200808023259.1D07F1E60C2D@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR18CA0052.namprd18.prod.outlook.com (2603:10b6:610:55::32) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR18CA0052.namprd18.prod.outlook.com (2603:10b6:610:55::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Mon, 17 Aug 2020 23:39:30 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1cfa31c6-a743-4518-2e56-08d84306ca18 X-MS-TrafficTypeDiagnostic: DM5PR06MB3129: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: K8smoK4ClcqoCYPViH7xOerh0+XFv6TkX5zIGMeItv3i6FqVuTx52SUQuB9XzhsPzYKnpmb6ftFzuGkZW5apBSSGOikW4Zn+4wk7ysCB2BVILdMkPW1iyFhNFtIb/D5gPJm0I9T4REbLayaVyGrjoHwNtq/jTuAQOj2ZNR9lNcmMDelQXRkTdAms7MvodHTRwzMEuJdkPS1+9YMLx8/y75TI1KUBnlqOZTdv3j3mLgvQGTDZhdlsvTBMT74InDAdyzLOuDBIUS63VeAYMhLF4H76c1Mm9wunpoRv7AgCbY2R7W678+bbxSYBsgL7BvZU0khwv9Kpgc6UwxzQvmMKEWLwxV1oYMNthNYO9lJG1UGDLtnjLnpu9a1X/ViCcp20iO0+MIRkzrVlfCRNYD63uz8sHxVSwGZebEmZ2ez0FDVbJv9JkG1weY2Wl3VPoltAg9gHFFwvsAWwFlUvwaKKnDG4dJjqAQJtsC/GT5EMHwQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(396003)(376002)(346002)(136003)(6706004)(36756003)(316002)(16576012)(186003)(478600001)(5660300002)(66476007)(2616005)(16526019)(53546011)(66946007)(956004)(66556008)(786003)(75432002)(31696002)(26005)(6486002)(86362001)(8676002)(6666004)(2906002)(8936002)(44832011)(83380400001)(31686004)(3940600001)(130980200001)(223123001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 5Nq05ltauOG4Qd5FcMfBj+Sbd1fq0rZMm0iGWiaSyoyoU0SLmmiDnk+EAqTYJq/A4m5vFgWFIiy8TAkK1lYrXyeR4nGpBYsVO6ANC+HEQgHwiq5q509fXPQbuHCGzBb+sdrlLG2hlG3tr91dEIlyw8/JlILtQ4zAT/05wbjd2oLpgbivGWrBcmXG2a3epkLamhZhSSfvoz+uMXmJyhJMaPXrLweU+WU63bARFdMFb67s/4CHCeTRoFAhVGwO/Noe2Oz3ImMdOp/jvIQpSfATqqjgsmGgGvPU7P07yIfEPOmO/KvsfwnMnYZUE5VDxbeyZRGOfz+04wQcELPDbTq7MaxEB5u0gi0gf5gKHhrqdfejoLb4eaEqboA352j0k7U96dnRvjZpvUtrx7FGB94Qcoo2u6F0Ro/t9kiUPsL7VjXbkoahoJtMSSP2MagjJk7cfMTv7c3jSMyR4YIj8x0e9sNlAvNlU1Kx6K5dm1x2218Mxqz/oejUuUHZav0PoA94iOPtGnCiOOnyJMs2IuRQLR0kXP74ntZNhEX/gkyLlTCcCpfQnZigv13VkJJbHphq6Avla95g7VXWoKOsWn3mfwj1KtnF8pm7O4rqy3YY3iHY4fP6XWuo0gC3cnChCkYBp2xYIk6A8UYVDhLEfuSL5w== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 1cfa31c6-a743-4518-2e56-08d84306ca18 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2020 23:39:31.4121 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DPvwxpHdQXrxQqZT+ma+Nz8COib9hr6jlWA3T6tbldIUDl6aStLiKi8I5L2o7aBjg8meH3yOiqvxWA6KuZjJHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3129 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 23:39:36 -0000 On 8/7/20 9:32 PM, John Levine wrote: >> We need spoofing protection for all of our domains without being told we're misdeploying. > > I would be interested to better undertstand the meaning of "need" > here. It is my impression that most people vastly overestimate how > much of a phish target they are. Paypal and big banks certainly are, > other places, a lot less so. (Sorry, I was on a much-needed vacation.) Ok, that's fair, I should have realized that one was over-stated. *Need* would imply that domain-spoofing is more common than it is in reality. Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances. Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC). To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers. Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) * People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed) The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports. It may show up in forensic reports, but it is easily lost in the noise. (SPF macros might be another way to get fine-grained observability, but that's a privacy leakage IMO.) In the end, it still results in: * That person wouldn't end up on our radar for communication * That person wouldn't understand what the message is about, even if we did communicate with them * That person wouldn't comply, even if they understood * Once enforcement is in place, that person will complain and leverage every ounce of their political influence to resist. (It's really fun when your own users threaten lawsuits against you - that doesn't happen in Corporate IT.) I'm kind of rambling now, I see. Hope you find it enlightening, regardless! Jesse From nobody Mon Aug 17 17:36:56 2020 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 CAE713A14EE for ; Mon, 17 Aug 2020 17:36:53 -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, 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 ZBAZbWGWB-yV for ; Mon, 17 Aug 2020 17:36:51 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 3C2663A14ED for ; Mon, 17 Aug 2020 17:36:51 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id a127so2481713vsd.1 for ; Mon, 17 Aug 2020 17:36:51 -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=jeJmAateNPJ5VgNMtTp3XeMvWQPbVgm+P25aT2I68RU=; b=jqmpOdpt28/IB3PYjBjeRYX2Bhaw8d54GTe3w5Gns6v7Ap8CehYRTWhUIyJyCFj64p /neor1gmm4zECodLJ1bKd7H1F6mukK+h4JYwJ9Fh3clOmz3N0jm+BiQ5jYUF+UIPwvvw Q77TlyekhNcdymYiUCUGECbtZO1Tl7GeGMCPoQlMWtCbkywJtIF/cA5Vb3Y+YtrreSMO XtdbG/DXQbD0GL0flLwqzGG44a3nFFkgL0RAv7v0ZeA09g6WVoIfE9iWbkANPQhUSVj8 PDqi3XHOB20O9qNlrfsjMmz2wdhHrsGELkJUleOPhyacy4UEsvDbi0WB/oUR/baDWBUj Wt9w== 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=jeJmAateNPJ5VgNMtTp3XeMvWQPbVgm+P25aT2I68RU=; b=ktZxnXmrSM7j9YuaTzBc9VcHg1CNbge80UUsy5xlZFcZ8djJnSFnN99m0xkhaC4tZF HDcrm+P4UvKweO4++HCWh/tUwY7TFxjb1tlrgWh698A+hhHGPNWfp07HRycUe+zfQzXV IXgNQdWAQZm0+Zs+BjNngmCunHj8Z93eeE+kSG16NcOoGyljRCvRB2zsp04/fi4SVIxX SzZi7RjFpctaC+n7IJOOykqRIX6K0bKZMnSXsVqMhQrFcGVIfNK+/OXCTDtz7RcKjtc2 /GGY0zfI+zaRYc7F4iEg0MuoQ0MqCVJijnyfV5M0p8Me0Hvr3aOirxfurKm748+3hjy+ hXlQ== X-Gm-Message-State: AOAM5335OxuI+noyM2DkTN1+Bcd4qnkhr4sOQhff4DG17eXb42r0ecmM TLxIQUGw5tPgZkDwhaBZiEQCib0kkv5rj3ypM69OSQ4H X-Google-Smtp-Source: ABdhPJxGuFi/fkU0z7sSownGOwUsGG3Zr21ndfnP/telJJOn7uDOCKRfPJlXC4vrbKt9t+8SE3yAF83/NxZ31Cjm/xQ= X-Received: by 2002:a67:eb91:: with SMTP id e17mr9819195vso.7.1597711009961; Mon, 17 Aug 2020 17:36:49 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> In-Reply-To: <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Mon, 17 Aug 2020 17:36:38 -0700 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000033d88005ad1c15c6" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 00:36:54 -0000 --00000000000033d88005ad1c15c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Still as just me: On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster wrote: > Based on the discussions here, it appears that the notion of From address > validation was envisioned from the beginning Sender Authentication > discussions. We have written evidence that Form address validation was > anticipated in the DKIM and ATPS RFCs prior to DMARC. So we have more > than a decade of warnings that From address validation was coming. Whil= e > not everybody has time to read every RFC, the Mailing List trade press mu= st > have should have been reporting on it as something to watch. > I don't follow the logic here. DKIM, as I recall, expressly disavowed any assertion that could've been taken as From address validation. (I think it was in there before RFC 4871, but we collectively decided to remove it.). I don't know how one could have inferred imminence from that. ATPS is an Experimental RFC. It was meant to, in some ways, augment ADSP when we'd already figured out the damage it could cause. The purpose of publishing it was to get everyone (for some value of "everyone") to agree on a protocol to use to provide third-party signature authorizations and see if it was a useful response. The silence was deafening. Even after DMARC was in use, it appears that nobody in the mailing list > community felt inconvenienced until the AOL/Yahoo hack and their decision > to implement DMARC with p=3Dreject. This was the moment of Unhappy > Surprise. Bad guys had obtained many valid email addresses, so one of > the concerns was how to prevent them from spoofing those users to send > spam. They could not use those address in the SMTP address because of > SPF, but only DMARC could prevent those addresses from being misused in t= he > Message From address. It was the obvious thing to do and it would hav= e > been reckless for them to do otherwise. Can you at least admit that the > mailing list community was surprised because they failed to prepare for > this contingency? > I wouldn't characterize it as "failure". If you agree that DMARC's antecedent is ADSP, I believe it had already fallen into disfavor to the point where nobody was really worried about it anymore. But I would agree that nobody anticipated it, especially since DMARC itself and RFC 6377 both warned against its use for this very reason. [...] As a result, mailing list operators really have no standing in this > discussion, although they can certainly speak as unhappy individual users > and on behalf of their unhappy users. > I suggest that's precisely what gives them standing. Consequently, the real problem before us becomes the existence of users who > are unhappy because the From address on some mail does not meet their > preferences. I have to ask why that is a problem worthy of a standards > body? I have about 8 different scenarios in my head where a user migh= t > be have unmet expectations with the format of the From address, or might > experience mailing list deliverability problems because of the email > filtering policy of its domain relative to the addressing practices of hi= s > mailing list. If our requirement is to make every user happy, shall we > head down the path of all 8 problems, not just this one? > If all eight problems have been raised and acknowledged by the chairs, then I imagine the answer to your question is emphatically "yes". Though published as an RFC, DMARC was not an IETF consensus document. The remit of this working group is to come to consensus on a set of changes that qualify it for the standards track. We do that by considering the perspectives and issues raised during that process and coming to consensus on their respective resolutions. > This project was supposed to discuss moving DMARC from informational to > standards track. It has been hijacked by those who, to paraphrase > Shakespeare, =E2=80=9Chave not come to praise DMARC, but to bury it.=E2= =80=9D This has > been abetted by the chair=E2=80=99s assertion that we must square a circl= e =E2=80=93 meet > the MLs requirement for them to impersonate without authorization while > continuing to advance the DMARC requirement to prohibit impersonation > without authorization. > [...] > I have not yet seen any assertion that DMARC needs to be buried. In fact, revisiting its assumptions is a perfectly feasible way to come to consensus on its goals and how they might be achieved. If DMARC was founded on false premises, that plainly needs to be considered and possibly fixed. That can only strengthen it. None of this discussion seems invalid to me. As part of that hijacking, we have been inundated by Mr. Crocker=E2=80=99s > assertions that the message From Address does not matter. All the years = of > theoretical analysis that preceded DMARC and all of the operational succe= ss > from implementations of DMARC are just wrong, simply because he says so. > It's not simply because he says so. At the time DMARC was on the drawing board, the MUA game was different. We talked about this a lot back then, and it was discussed previously in this working group too. These days, there's evidence to suggest that the domain name is rarely visible. If that's true, I claim it's a valid thing to revisit whether DMARC as it's currently designed is providing useful protection especially with respect to the disruption it causes elsewhere. > More importantly, this discussion has failed to address the actual > objective, which is to solve the asserted Mailing List problem as it > relates to AOL/Yahoo/Verizon. That enterprise does not seem to be > involved in this process, and no one has offered reason why they will be > swayed by anything said here. The strategy seems to be that if we tell > these people how stupid they are, that they will do whatever we tell them > they must do, even if the solution is to weaken security for everyone on > the Internet. That is not a winning strategy. > I think this is all a little hyperbolic and not especially constructive. RFC 7489 was co-edited by a Yahoo engineer. I'm pretty sure she's paying attention, either here or in related industry trade groups. The others are probably at least being made aware of it via the latter. The IETF is not the protocol police. If you need evidence of this, simply note that RFC 7489 was deployed despite who participated in its development and how many consensus documents warned against its use in mail flows where Mediators are present. DMARC has been mandated by at least three national governments,, by a > variety of businesses, and by this one consumer-oriented email hosting > service. It is here to stay, and any extensions to the specification wi= ll > need to improve security, not weaken it for the benefit of a special > interest group. > This sounds a lot like an argument from authority. There is no doubt that anti-phishing technologies are critical, and it's no surprise that a protocol characterized as effective against phishing is being widely endorsed. The question being proposed here is whether DMARC actually still fits that bill given the current state of the industry. I suggest that this is a perfectly valid question, and I would really like you to explain why it should be declared moot or off-topic. Instead, we should be anticipating that the U.S. government will begin > mandating DMARC for its contractors, in phases based on contractor > categories. Simply requiring it for Department of Defense contractors > would be sufficient to include most of the major research-oriented > universities. But every school that takes student loan payments is also > considered a government contractor, which covers almost all of them. > Every branch of state and local government also feeds from the federal > trough, and concerns about election meddling means that they are likely > targets for voluntary or required implementation of DMARC. Essentially > every health care institution is also a government contractor, because th= ey > take payments from Medicare or Medicaid, usually both. > Yes. Wouldn't it be an atrocity if they bolted their security stories to a lemon? It is time to begin a discussion rooted in what is feasible, and what is > appropriate for IETF to undertake. > There, we agree. -MSK --00000000000033d88005ad1c15c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Still as just me:

On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster <fos= terd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:

Based on the discussions here, it appears that the notion of From addres= s validation was envisioned from the beginning Sender Authentication discus= sions. =C2=A0 =C2=A0We have written evidence that Form address validation w= as anticipated in the DKIM and ATPS RFCs prior to DMARC. =C2=A0 =C2=A0So we= have more than a decade of warnings that From address validation was comin= g. =C2=A0 While not everybody has time to read every RFC, the Mailing List = trade press must have should have been reporting on it as something to watc= h.

I don't follow the logic here.=C2=A0 DKIM, as = I recall, expressly disavowed any assertion that could've been taken as= From address validation.=C2=A0 (I think it was in there before RFC 4871, b= ut we collectively decided to remove it.). I don't know how one could h= ave inferred imminence from that.

ATPS is an Experimental RFC.=C2=A0 It was meant= to, in some ways, augment ADSP when we'd already figured out the damag= e it could cause.=C2=A0 The purpose of publishing it was to get everyone (f= or some value of "everyone") to agree on a protocol to use to pro= vide third-party signature authorizations and see if it was a useful respon= se.=C2=A0 The silence was deafening.

Even = after DMARC was in use, it appears that nobody in the mailing list communit= y felt inconvenienced until the AOL/Yahoo hack and their decision to implem= ent DMARC with p=3Dreject. =C2=A0 This was the moment of Unhappy Surprise. = =C2=A0 =C2=A0Bad guys had obtained many valid email addresses, so one of th= e concerns was how to prevent them from spoofing those users to send spam. = =C2=A0 They could not use those address in the SMTP address because of SPF,= but only DMARC could prevent those addresses from being misused in the Mes= sage From address. =C2=A0 =C2=A0 It was the obvious thing to do and it woul= d have been reckless for them to do otherwise. =C2=A0 Can you at least admi= t that the mailing list community was surprised because they failed to prep= are for this contingency?

I wouldn't cha= racterize it as "failure".=C2=A0 If you agree that DMARC's an= tecedent is ADSP, I believe it had already fallen into disfavor to the poin= t where nobody was really worried about it anymore.

But I would agree that nobody anticipated it, especially since DMARC itse= lf and RFC 6377 both warned against its use for this very reason.

[...]=C2=A0 As a result, mailing list operators = really have no standing in this discussion, although they can certainly spe= ak as unhappy individual users and on behalf of their unhappy users.=C2=A0 =

I suggest that's precisely what gives t= hem standing.

Consequently, the real problem before us becomes the existe= nce of users who are unhappy because the From address on some mail does not= meet their preferences. =C2=A0 =C2=A0I have to ask why that is a problem w= orthy of a standards body? =C2=A0 =C2=A0 I have about 8 different scenarios= in my head where a user might be have unmet expectations with the format o= f the From address, or might experience mailing list deliverability problem= s because of the email filtering policy of its domain relative to the addre= ssing practices of his mailing list. =C2=A0 If our requirement is to make e= very user happy, shall we head down the path of all 8 problems, not just th= is one?

If all eight problems have been raised a= nd acknowledged by the chairs, then I imagine the answer to your question i= s emphatically "yes".

Though published as an RF= C, DMARC was not an IETF consensus document.=C2=A0 The remit of this workin= g group is to come to consensus on a set of changes that qualify it for the= standards track.=C2=A0 We do that by considering the perspectives and issu= es raised during that process and coming to consensus on their respective r= esolutions.
=C2=A0

This project was supposed to discuss moving DMARC from in= formational to standards track. =C2=A0 It has been hijacked by those who, t= o paraphrase Shakespeare, =E2=80=9Chave not come to praise DMARC, but to bu= ry it.=E2=80=9D =C2=A0 This has been abetted by the chair=E2=80=99s asserti= on that we must square a circle =E2=80=93 meet the MLs requirement for them= to impersonate without authorization while continuing to advance the DMARC= requirement to prohibit impersonation without authorization.
[...]
=

I have not yet seen any assertion that DMARC ne= eds to be buried.=C2=A0 In fact, revisiting its assumptions is a perfectly = feasible way to come to consensus on its goals and how they might be achiev= ed.=C2=A0 If DMARC was founded on false premises, that plainly needs to be = considered and possibly fixed.=C2=A0 That can only strengthen it.
=

None of this discussion seems invalid to me.
<= div>

As pa= rt of that hijacking, we have been inundated by Mr. Crocker=E2=80=99s asser= tions that the message From Address does not matter.=C2=A0 All the years of= theoretical analysis that preceded DMARC and all of the operational succes= s from implementations of DMARC are just wrong, simply because he says so.<= /p>

It's not simply because he says so.=C2=A0 At= the time DMARC was on the drawing board, the MUA game was different.=C2=A0= We talked about this a lot back then, and it was discussed previously in t= his working group too.=C2=A0 These days, there's evidence to suggest th= at the domain name is rarely visible.=C2=A0 If that's true, I claim it&= #39;s a valid thing to revisit whether DMARC as it's currently designed= is providing useful protection especially with respect to the disruption i= t causes elsewhere.
=C2=A0

More importantly, this discussion has failed to a= ddress the actual objective, which is to solve the asserted Mailing List pr= oblem as it relates to AOL/Yahoo/Verizon. =C2=A0 That enterprise does not s= eem to be involved in this process, and no one has offered reason why they = will be swayed by anything said here. =C2=A0 =C2=A0The strategy seems to be= that if we tell these people how stupid they are, that they will do whatev= er we tell them they must do, even if the solution is to weaken security fo= r everyone on the Internet. =C2=A0 =C2=A0That is not a winning strategy.

I think this is all a little hyperbolic and not es= pecially constructive.

RFC 7489 was co-edited by a= Yahoo engineer.=C2=A0 I'm pretty sure she's paying attention, eith= er here or in related industry trade groups.=C2=A0 The others are probably = at least being made aware of it via the latter.

The IETF is not the protocol police.=C2=A0 If you need evidence of this, = simply note that RFC 7489 was deployed despite who participated in its deve= lopment and how many consensus documents warned against its use in mail flo= ws where Mediators are present.

DMARC has been mandated by at least t= hree national governments,, by a variety of businesses, and by this one con= sumer-oriented email hosting service. =C2=A0 It is here to stay, and any ex= tensions to the specification will need to improve security, not weaken it = for the benefit of a special interest group.

Thi= s sounds a lot like an argument from authority.

Th= ere is no doubt that anti-phishing technologies are critical, and it's = no surprise that a protocol characterized as effective against phishing is = being widely endorsed.=C2=A0 The question being proposed here is whether DM= ARC actually still fits that bill given the current state of the industry.= =C2=A0 I suggest that this is a perfectly valid question, and I would reall= y like you to explain why it should be declared moot or off-topic.

Ins= tead, we should be anticipating that the U.S. government will begin mandati= ng DMARC for its contractors, in phases based on contractor categories. =C2= =A0 =C2=A0Simply requiring it for Department of Defense contractors would b= e sufficient to include most of the major research-oriented universities. = =C2=A0 But every school that takes student loan payments is also considered= a government contractor, which covers almost all of them. =C2=A0 =C2=A0Eve= ry branch of state and local government also feeds from the federal trough,= and concerns about election meddling means that they are likely targets fo= r voluntary or required implementation of DMARC. =C2=A0 Essentially every h= ealth care institution is also a government contractor, because they take p= ayments from Medicare or Medicaid, usually both.

Yes.=C2=A0 Wouldn't it be an atrocity if they bolted their security st= ories to a lemon?

It is time to begin a discussion rooted in what is feasi= ble, and what is appropriate for IETF to undertake.

<= div>
There, we agree.

-MSK
 --00000000000033d88005ad1c15c6-- From nobody Mon Aug 17 17:46:08 2020 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 A07183A1600 for ; Mon, 17 Aug 2020 17:45:59 -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, 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 uwK_HmMtgSLY for ; Mon, 17 Aug 2020 17:45:58 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 92B503A1667 for ; Mon, 17 Aug 2020 17:45:53 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id g20so5309409uan.7 for ; Mon, 17 Aug 2020 17:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hws/76rmK3ArrCCD9a0YVrq/alRrtd/VZcHIhIzIEeE=; b=Jcbfga8P8nu8YjizdDEjMxVnxtPWkeUoMzuk1limaEZiteER3kDI7TC0f5D4dk1m+F oUeIhDYQ8GsZmxe2UFgL1oZoqMlGjJZG6SkHyWyQ2SRU8gxssV6iXUngd4ksOBgWuHJK FoBhbcJPp0mbTsmQU7FZecDenGLvCWxT/kGYUXyPjVuqmtEytYqFkLNAqwu2q+7XejYZ JTmjQWmZOD/4WnyKDHpCdoYUe+qnkjGmhZHrnc/h6pYBTw1wWYZm95ABg3HYm4tvUTLw zuTW7EefvK8E2yMPQEitxCBJcXleb2p0Iq7WJ963ojohEgnjLsvm+z2V3EyHJlVSTnQ7 NYxA== 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=Hws/76rmK3ArrCCD9a0YVrq/alRrtd/VZcHIhIzIEeE=; b=kzhOrmPiB93s1KNIx/4t/TKdmiuf+qrGdO9frE2LwF3hAvAKHLBHLljhvBMFHTL4rL 4wau/Q4COCYYw+v5EUikRNfboRX5k21qPdBbw3TRKjIR5niQdSiaTWkp3RxCmrram9Ge dmACSNkGeMqK8U08ksWTHFbZ4kHY5qF8unZROj/uuwZQf6nVn8/Xzm4HX42uxGHrOi+l i2cHXwJDujhSaAebBnxJAei5f1XklpV4ujaq3+TmCA1TNjX26UOOU1ipz/6KLTLXxU6t gQOtL6zarD1HKhFMbUTuKf9tOUG9/2uBzjC7WEul8Cc5olsA1HjjQLVbdNtcV0PQ7xbZ zb/w== X-Gm-Message-State: AOAM530ZogSpTYZTNUekGJxrrOmo4Qw9FIKbplpuPcIiBCKu8Bs7MCDn fPxcf/JGThscCMKn6rFD3JyF/WWdaxL1M9FpbIE= X-Google-Smtp-Source: ABdhPJypV6WDKhPr3H452UewJQxEfGRBOfGv/8Ss2oyV9bUfCmM2YaRbNboskodqNEtz8d7X1wJi9ZFsx+WFjhAzIzI= X-Received: by 2002:ab0:6054:: with SMTP id o20mr8834968ual.87.1597711552415; Mon, 17 Aug 2020 17:45:52 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 17 Aug 2020 17:45:41 -0700 Message-ID: To: Dotzero Cc: "Douglas E. Foster" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000890b2605ad1c3544" Archived-At: Subject: Re: [dmarc-ietf] Time for a change X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 00:46:06 -0000 --000000000000890b2605ad1c3544 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 6:52 AM Dotzero wrote: > On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> The reality is that IETF has mostly provided followership, not >> leadership, on matters of security. This forum is replicating history. >> As has been mentioned in the historical review, SPF, DKIM, and DMARC were >> independently successful projects, as was SSL. IETF provided >> after-the-fact blessing. It is time to follow the same model. >> > > Doug, as someone who has been involved in this space for decades, I think > you are sorely mistaken in your understanding of things. Many of the people > involved in the email authentication space interact with each other in > other places, both online and in person and have been doing so for a very > long time. > We don't always agree on the path forward but that is because we come from > different perspectives. IETF did not provide "after-the-fact" blessing. SPF > was experimental for a very long time. DMARC is still informational. One of > the mantras for IETF is "running code and rough consensus". There is > running code for DMARC but what we are lacking so far is rough consensus. > +1. I would add that SPF and DMARC started outside of the IETF, but DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) that started outside. It underwent significant evolution in the IETF -- not once, but twice. This line of thinking also seems to ignore the troubled path that SPF took to reach the standards track (as RFC 7208). Or you could apply for M3AAWG membership where all of those constituencies > participate already. > I was just going to say that. And, at least the last time I went, most of the same debates happened over there too. -MSK --000000000000890b2605ad1c3544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 17, 2020 at 6:52 AM Dotzero &= lt;dotzero@gmail.com> wrote:
On Sun, Aug 16, 2020 at 3:09 PM Douglas E. Fost= er <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
=
The reality is that = IETF has mostly provided followership, not leadership, on matters of securi= ty.=C2=A0 This forum is replicating history. =C2=A0 As has been mentioned i= n the historical review, SPF, DKIM, and DMARC were independently successful= projects, as was SSL.=C2=A0 IETF provided after-the-fact blessing. =C2=A0 = It is time to follow the same model.

Doug, as someone who has been involved in this space for decades, I t= hink you are sorely mistaken in your understanding of things. Many of the p= eople involved in the email authentication space interact with each other i= n other places, both online and in person and have been doing so for a very= long time.
We don't always agree on the path forward but tha= t is because we come from different perspectives. IETF did not provide &quo= t;after-the-fact" blessing. SPF was experimental=C2=A0for a very long = time. DMARC is still informational. One of the mantras for IETF is "ru= nning code and rough consensus". There is running code for DMARC but w= hat we are lacking so far is rough consensus.

+1.=C2=A0 I would add that SPF and DMARC started outsi= de of the IETF, but DKIM was a synthesis within the IETF of two things (Dom= ainKeys and IIM) that started outside.=C2=A0 It underwent significant evolu= tion in the IETF -- not once, but twice.

This line= of thinking also seems to ignore the troubled path that SPF took to reach = the standards track (as RFC 7208).

Or you could apply for M3AAWG membership where all of those constituencie= s participate already.=C2=A0=C2=A0

<= div>I was just going to say that.=C2=A0 And, at least the last time I went,= most of the same debates happened over there too.

=
-MSK

--000000000000890b2605ad1c3544-- From nobody Mon Aug 17 18:09:32 2020 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 258443A1578 for ; Mon, 17 Aug 2020 18:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.949, 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 88PB6Z90LpMZ for ; Mon, 17 Aug 2020 18:09:29 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D963B3A1577 for ; Mon, 17 Aug 2020 18:09:29 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id 17so9115055pfw.9 for ; Mon, 17 Aug 2020 18:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=yO+JYGHLPW+pMEjcIcrMA0uVmxQL3Nf5Wm6YbpXSvMc=; b=j9lvHwohQlQn0Lu1euSkDALeZ8Id1u9v8/IpB/vZyjo4YvG9VwzjDY66uC2oI4Gv4z SEM6FN3+FTBAF7A36TdY8q4GZd3+3jvy5CNZFQsC0Ygpf4xsRwVEA2xx1qMhbWJwMGWM ieRgbqWN/gHIA1j+GvwPmQXPkZmHoxizzMLjWl2EAw5F5JzHskCoacDV2IWh4s9KH3/e m3mwY47yPJ41l3TVcDyHczHa20Msrq8DjS4IYDIM1bgKHfWmHbkfdxrM9cGxGVtyXEJN XRM2xAJMIi6faCGr1CgTkyOexqzE+IOIGScz871AtNl90FaWcZUA0kE5WzuHkGXBuLsE uHkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yO+JYGHLPW+pMEjcIcrMA0uVmxQL3Nf5Wm6YbpXSvMc=; b=NlI3u6CAVFv8XAdcQm9p89TVPYYYi97XfJqU/7htLS4f7tQt/EmoQ0OTHSzCrwevGr YMtfpNISoXa9B3urzBtRIIjUak5iCBPNio/BuU5mImhJvMWLiQNKhn/pV6IfAFQLGjw9 KJg53Z16AvW5ccotZfGgOjl2CCRIRa44p3Kku8MuVAQzy9GFZ6JGPWUnUFhUeLXXQYhm jg+Fmjl+cRPxMvb8+kds5DpeCqa1Lxw1xM7wEwxO542prdlrUC3i2TzBCYoKsxPuZt7y cBVGQXGAi8BxQGfYdsad93w6ul1GawzI6cFPFOtcPhkDVq9O8oTGtND89gWsT80JWM+E Fsgg== X-Gm-Message-State: AOAM532MY9gyso6/EOdvJYqXnJfFRb9l4AaU8qvhFNIZFQErr1oNGQZu qv6iEzV4RGOrF2ugl01wonAWtb0CRp4= X-Google-Smtp-Source: ABdhPJwoxx/eF2yoovdSe/m0VBxXoDFTqUn5+JxsEuxXyE4UrnKkU7Q9PxXbbr79EMHTIUpWnpwcEQ== X-Received: by 2002:a65:4183:: with SMTP id a3mr11360845pgq.448.1597712969144; Mon, 17 Aug 2020 18:09:29 -0700 (PDT) Received: from [192.168.0.100] (c-73-158-217-238.hsd1.ca.comcast.net. [73.158.217.238]) by smtp.gmail.com with ESMTPSA id b26sm21904074pff.54.2020.08.17.18.09.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2020 18:09:28 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> From: Dave Crocker Message-ID: <20ad2821-f705-d8d6-2921-a419e1bd0554@gmail.com> Date: Mon, 17 Aug 2020 18:09:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0F20488A30C52ABE57C2BB21" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Time for a change X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 01:09:31 -0000 This is a multi-part message in MIME format. --------------0F20488A30C52ABE57C2BB21 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit >  DKIM was a synthesis within the IETF of two things (DomainKeys and > IIM) that started outside.  It underwent significant evolution in the > IETF -- not once, but twice. Actually, it wasn't. The constituent parts were separately proposed, during the same initial IETF discussions, and the IETF said to go away and come back after reconciliation.  That work was done by an ad hoc industry team and there was a complete spec and initial implementations before the IETF was again approached. https://tools.ietf.org/html/draft-allman-dkim-base-00 (and note that in the working group field on the title page, it says "pre-MASS"...) The work in the IETF was a refinement of a complete, integrated spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------0F20488A30C52ABE57C2BB21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
 DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) that started outside.  It underwent significant evolution in the IETF -- not once, but twice.

Actually, it wasn't.

The constituent parts were separately proposed, during the same initial IETF discussions, and the IETF said to go away and come back after reconciliation.  That work was done by an ad hoc industry team and there was a complete spec and initial implementations before the IETF was again approached.

https://tools.ietf.org/html/draft-allman-dkim-base-00

(and note that in the working group field on the title page, it says "pre-MASS"...)

The work in the IETF was a refinement of a complete, integrated spec.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------0F20488A30C52ABE57C2BB21-- From nobody Mon Aug 17 18:15:55 2020 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 555CC3A155C for ; Mon, 17 Aug 2020 18:15:54 -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, 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 bgNAAKbdfkNe for ; Mon, 17 Aug 2020 18:15:52 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 1A07F3A1559 for ; Mon, 17 Aug 2020 18:15:52 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id x6so8785612qvr.8 for ; Mon, 17 Aug 2020 18:15:52 -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=ooV+Td/4/ql4xRBTxPBB8vaBZb1tK1nCmIAWq1XMg1k=; b=ZHx/XtdJRWYAFjMXx0mSWf9kRdeaVyNR24zAz4r65ErdPBcg2+XUfvZkZujjNNyke/ AL73kSHVwMgzQ6hvIWHDJ0wYsAHuQ+bBdUUCUpPNkJH1Y1M1LLl7KnbngWZ4uwQw0MUf w+TW8W07HKOz4jf5u120HeoQUYgrzmTk47lZ/ZoBXCV4Iv5hxcc1UpxQpbCBpAOGha0V +hfBoGzZyc9ylGtlAtA99p+BfCVqg6T76GDw33GPRnEE7f4JuKbuOvLSde12JdOf4DxD 5DO0+75b1JXH6BRVe+ZiZnGEqvCRUY6F3EeRFV4pYBM6m2kC2bbXJEBQwVoaWv25w9Wy 4SSQ== 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=ooV+Td/4/ql4xRBTxPBB8vaBZb1tK1nCmIAWq1XMg1k=; b=Bn6Qz/OseNwYVlt+licMFh0uwIp4KluMSMxQOBByjTba+LspwV8NLMjmyrnP/7Quj7 b/zZG8tDd5w4M/1NKAF3ZQqBCSG8qrX3JdvqhZLtBZ1bVyi1l2cuWWfcgV3mjtR7H/P1 6PlNDNSMqrC4YhHgWm/v2VaywDy5yGPtVg0dxiHYquBgjnCf0SeTxNvdXSva6mtN3FGY W1YKfdHxQD9QwqYZxB4bwhOu7bebD9pxn2M2g1qagvGci+Y1D5c2wNinZrF/IurgCTVd tSH3mdjh1S76xnGBuiWWr4dILxwQVnsuOnsLxZfBoAfWcPZr8X7iKIZ1ePsmc1YeOyZl DLnQ== X-Gm-Message-State: AOAM530EXpfkzUST6A8nvt5ZnMjAF67FTynnEaffOG6Hp1KkOj/Bre5N 93li084h9qNXvoFzMCz/U9jcve1gN6TUgfSKTPI= X-Google-Smtp-Source: ABdhPJy3n1psCVe1XUk9CDMGTrHcoJit7SKrJzLitvS7npgIZKnj1R48mTZLyWo210Yzr1Bovrqhbah2/ioZDqx8mIM= X-Received: by 2002:a0c:f687:: with SMTP id p7mr16382872qvn.249.1597713351157; Mon, 17 Aug 2020 18:15:51 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> <20ad2821-f705-d8d6-2921-a419e1bd0554@gmail.com> In-Reply-To: <20ad2821-f705-d8d6-2921-a419e1bd0554@gmail.com> From: Dotzero Date: Mon, 17 Aug 2020 21:15:40 -0400 Message-ID: To: Dave Crocker Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bfabd705ad1ca0ff" Archived-At: Subject: Re: [dmarc-ietf] Time for a change X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 01:15:54 -0000 --000000000000bfabd705ad1ca0ff Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 9:09 PM Dave Crocker wrote: > > DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) > that started outside. It underwent significant evolution in the IETF -- > not once, but twice. > > Actually, it wasn't. > > The constituent parts were separately proposed, during the same initial > IETF discussions, and the IETF said to go away and come back after > reconciliation. That work was done by an ad hoc industry team and there > was a complete spec and initial implementations before the IETF was again > approached. > > https://tools.ietf.org/html/draft-allman-dkim-base-00 > > (and note that in the working group field on the title page, it says > "pre-MASS"...) > > The work in the IETF was a refinement of a complete, integrated spec. > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.net > > +1 --000000000000bfabd705ad1ca0ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 9:09 PM Dave = Crocker <dcrocker@gmail.com>= ; wrote:
=20 =20 =20

=C2=A0DKIM was a synthesis within the IE= TF of two things (DomainKeys and IIM) that started outside.=C2=A0 It underwent significant evolution in the IETF -- not once, but twice.

Actually, it wasn't.

The constituent parts were separately proposed, during the same initial IETF discussions, and the IETF said to go away and come back after reconciliation.=C2=A0 That work was done by an ad hoc industry team and there was a complete spec and initial implementations before the IETF was again approached.

https://tools.ietf.org/html/draft-allman-dkim-base-00

(and note that in the working group field on the title page, it says "pre-MASS"...)

The work in the IETF was a refinement of a complete, integrated spec.

d/
--=20
Dave Crocker
Brandenburg InternetWorking
bbiw.net
+1=C2=A0
--000000000000bfabd705ad1ca0ff-- From nobody Mon Aug 17 18:56:29 2020 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 AA87D3A15B5 for ; Mon, 17 Aug 2020 18:56:28 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnvZ1g_cKJiO for ; Mon, 17 Aug 2020 18:56:27 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3712E3A15B1 for ; Mon, 17 Aug 2020 18:56:27 -0700 (PDT) X-ASG-Debug-ID: 1597715779-11fa31095e12e20001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id WlTppcmKPDKZJvfb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 17 Aug 2020 21:56:20 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=QTE0LTcteDNRCjfn4GU0A5bYZ3RCA9Feyp2HVb7UNUU=; b=NxWxj3iFdgjAU4E6mb6hjQM8XbpoqC0S+RG7C2B12+RrblhAWzFEJi2XWQJiiQcZE ov8UcFfwPdd/CePH/bSVUQeVEBurZXkqb3UVIOacexQ1P+VOB2EcYKOR7ZwmDlW3u Sv6j2WR6kNHuQtjw9WwLEReI6WKEjVWcN2Hd1Ukv0= From: "Douglas E. Foster" To: Date: Tue, 18 Aug 2020 01:56:12 GMT X-ASG-Orig-Subj: DMARC failure scenarios Reply-To: fosterd@bayviewphysicians.com Message-ID: <0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=7790dd9475c7496ea96a64617302ae8e X-Exim-Id: 0762f9ada48c4c9eaef06e16a49a252c X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597715780 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5587 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83974 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] DMARC failure scenarios X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 01:56:29 -0000 This is a multipart message in MIME format. --7790dd9475c7496ea96a64617302ae8e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Does this scenario correctly characterize how organizations may be unable t= o move past p=3Dnone with breaking things? Before DMARC -------------------- a) A vendor application detects an event, looks up in a database for sender= name (client contact) and recipient list. b) The application connects to a mail server via IMAP, and sends the messag= e using something like application@vendordomain for the SMTP from and cllen= tcontact@clientdomain as the Message from. The client domain becomes esp= ecially important if the recipients are in a different domain than the clie= nt. An example might be an HVAC system operated by a vendor, on behalf of= the building manager, which needs to communicate with the building tenants= . The message passes SPF based on the SMTP From address in the vendor dom= ain. The client domain is not enforced. All of this can be implemented with generic off-the-shelf technology. Then the client wants to implement DMARC ---------------------------------------------------------- d) The client develops a list of all of its third-party mailers and tells t= he third parties to begin applying the client's DKIM signature to their mes= sages. This adds a boatload of complexity to the vendor's application, si= nce he needs a different applied signature for each client. It requires e= ither major changes to the application, a more sophisticated mail server, o= r a special box simply to sit in front of the mail server to detect and app= ly the correct signature. None of these seem like generic off-the-shelf so= lutions. I would not know where to buy that capability if I needed it tod= ay. e) If the client attempts to comply, it may take a long time and add a lot = of cost. If the client cannot comply, switching vendors is also complex a= nd time consuming. So in the end, a hypothetical U.S. government agency may end up telling Hom= eland Security that it cannot meet the DMARC deadline because of an applica= tion that runs in Peoria Illinois which cannot implement DKIM delegation si= gning. Of course, if that does not fly, the p=3Dreject goes into effect a= nyway and the folks in Peoria hope that the intended recipients will implem= ent an exception in their incoming gateway. In sum, DMARC participation is not fully in the control of the organization= that wants to implement it. We need to make DMARC participation a proce= ss where the participating organization has control over its own success an= d carries the costs of becoming compliant. DKIM scope delegation does not= get us there. DF --7790dd9475c7496ea96a64617302ae8e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Does this scenario= correctly characterize how organizations may be unable to move past p=3Dno= ne with breaking things?

Before DMARC
--= ------------------

a) A vendor application detects= an event, looks up in a database for sender name (client contact) and reci= pient list.

b) The application connects to a mail = server via IMAP, and sends the message using something like application@ven= dordomain for the SMTP from and cllentcontact@clientdomain as the Message f= rom.    The client domain becomes especially important if the rec= ipients are in a different domain than the client.   An example might = be an HVAC system operated by a vendor, on behalf of the building manager, = which needs to communicate with the building tenants.   The message pa= sses SPF based on the SMTP From address in the vendor domain.   The cl= ient domain is not enforced.

All of this can be im= plemented with generic off-the-shelf technology.

T= hen the client wants to implement DMARC
-------------------------= ---------------------------------

d) The client de= velops a list of all of its third-party mailers and tells the third parties= to begin applying the client's DKIM signature to their messages.   Th= is adds a boatload of complexity to the vendor's application, since he need= s a different applied signature for each client.   It requires either = major changes to the application, a more sophisticated mail server, or a sp= ecial box simply to sit in front of the mail server to detect and apply the= correct signature.  None of these seem like generic off-the-shelf sol= utions.   I would not know where to buy that capability if I needed it= today.

e) If the client attempts to comply, it ma= y take a long time and add a lot of cost.   If the client cannot compl= y, switching vendors is also complex and time consuming.

So in the end, a hypothetical U.S. government agency may end up tell= ing Homeland Security that it cannot meet the DMARC deadline because of an = application that runs in Peoria Illinois which cannot implement DKIM delega= tion signing.   Of course, if that does not fly, the p=3Dreject goes i= nto effect anyway and the folks in Peoria hope that the intended recipients= will implement an exception in their incoming gateway.


In sum, DMARC participation is not fully in the contro= l of the organization that wants to implement it.    We need to m= ake DMARC participation a process where the participating organization has = control over its own success and carries the costs of becoming compliant. &= nbsp; DKIM scope delegation does not get us there.

DF

--7790dd9475c7496ea96a64617302ae8e-- From nobody Mon Aug 17 19:12:09 2020 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 85AE53A15C6 for ; Mon, 17 Aug 2020 19:12:07 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Fqc8T9zL; dkim=pass (2048-bit key) header.d=taugh.com header.b=IIsNAeEQ 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 oXIyb4xHCVaC for ; Mon, 17 Aug 2020 19:12:06 -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 CE70D3A15C4 for ; Mon, 17 Aug 2020 19:12:05 -0700 (PDT) Received: (qmail 30225 invoked from network); 18 Aug 2020 02:12:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=760f.5f3b38f2.k2008; bh=cky+F9Gcm76NycqKhAZ++PsTsY700lOn5x4+nvISDWI=; b=Fqc8T9zL5L9kz81MlCTuTaCRapvqHXI8Zov43id6ny2Xpk52xYRzbyGql+Wf0a9gpbbPM7bXg8FgftfTEr5kvGR3Ttw5y+qFjcKZmVK3PavuXeOwqPIZh1TI5K5j4Im0SXokO0a0TLnKqoY9b4HeCXj4xkvARt63Biv/afZN6KftmUgcb5//K2UKcK992oS4H5iwkXV0ve2+RpHhkXhfBPtXApuzojo3nb1oSNf+Gsq75VZldqd4ljv/wTmABDozRGUHhPjbRwGjDXXSA5CEG16etpYETAq6qOn3Dhg8sBHRKG89yrJJRnvmbY58YXVOLZEulJVsN1sXFouSGzM39A== 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=760f.5f3b38f2.k2008; bh=cky+F9Gcm76NycqKhAZ++PsTsY700lOn5x4+nvISDWI=; b=IIsNAeEQMMRJj2Cx1SLJEIk2FCPP1tEJ+1JNDnqSGmpF12l+EP+Hxr/S+BESPi/jNP3DI8MVhEggUg/sup8zJed7iJ00VoRNlQjnDkSbAC6vS/JFDSDrDTyM+L8KO5wnZg7Ta5vNlzBl30ua9J3BcN2bDX1CsnQdDGVhhL0Nljo7LnQj2ToENptKo2mnU2tJ6QJSOJ9IuN6YIXfGNNOBxtOKixLKWkERpYFaIHWdtcVkylJZqq/vO24+K9Vs6NWkV7zIsQ7NjNJKf/QUSdJ/OtiMogvZwoVCqMUT++00ctxrei5GkNNgAHVXeQM/VLkS/I/7tBBI6SBgt2i1vXpq4g== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 18 Aug 2020 02:12:02 -0000 Received: by ary.local (Postfix, from userid 501) id E99631EE74E6; Mon, 17 Aug 2020 22:12:01 -0400 (EDT) Date: 17 Aug 2020 22:12:01 -0400 Message-Id: <20200818021201.E99631EE74E6@ary.local> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC failure scenarios X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 02:12:08 -0000 In article <0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> you write: >-=-=-=-=-=- > >Does this scenario correctly characterize how organizations may be unable to move past p=none with breaking things? As far as I can made sense of it, no. >a) A vendor application detects an event, looks up in a database for sender name (client contact) and recipient list. > >b) The application connects to a mail server via IMAP, and sends the message using something like application@vendordomain >for the SMTP from and cllentcontact@clientdomain as the Message from. The client domain becomes especially important if >the recipients are in a different domain than the client. An example might be an HVAC system operated by a vendor, on >behalf of the building manager, which needs to communicate with the building tenants. ... Again, no. You're confusing submission with SMTP. I have a printer that sends me e-mail when it's out of paper, which it does by sending mail to my submission server, not directly to me. If I were checking DMARC on the messages, they would easily pass since the submission server adds DKIM signatures. >Then the client wants to implement DMARC >---------------------------------------------------------- > >d) The client develops a list of all of its third-party mailers and tells the third parties to begin applying the client's >DKIM signature to their messages. This adds a boatload of complexity to the vendor's application, since he needs a >different applied signature for each client. It requires either major changes to the application, a more sophisticated >mail server, or a special box simply to sit in front of the mail server to detect and apply the correct signature. None of >these seem like generic off-the-shelf solutions. I would not know where to buy that capability if I needed it today. Again, no. I believe that devices that send mail do what they've always done, send it to a submission server for further delivery. The "special box" has been there all along. R's, John From nobody Tue Aug 18 01:54:31 2020 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 37AE03A0796 for ; Tue, 18 Aug 2020 01:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 36uuSymy4G8a for ; Tue, 18 Aug 2020 01:54:28 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 A8A173A0789 for ; Tue, 18 Aug 2020 01:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597740866; bh=Zmv4tha4aChw+llF72p/+qrqeyToH9Fn3xj4dvpf5t0=; l=3303; h=To:References:From:Date:In-Reply-To; b=B5TiqDP93QsUUyMFVEj+PkXoCHAqZ346Ynzmvl/gNUicHJR/C9iGPT8M4U05rSGBJ VlGtlf2ukof1QdtwLxS+V96KSFCBI+qA8y7w3DStZCA9IzOvXjbbfHC5wSJVxpNEg9 dIV1myOihCrg7uyTW+w/hkykE0CFk8OKOQz1ab+dRe4iyGHYC4eBGRn5sehOT Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.83.110]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F3B9741.00004DD9; Tue, 18 Aug 2020 10:54:25 +0200 To: Jesse Thompson , dmarc@ietf.org References: <20200808023259.1D07F1E60C2D@ary.qy> <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> From: Alessandro Vesely Message-ID: <59f44f8b-9a7d-2dc2-37d9-ed6b0c40fb40@tana.it> Date: Tue, 18 Aug 2020 10:54:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 08:54:30 -0000 On Tue 18/Aug/2020 01:39:16 +0200 Jesse Thompson wrote: > On 8/7/20 9:32 PM, John Levine wrote: >>> We need spoofing protection for all of our domains without being told we're misdeploying. >> >> I would be interested to better undertstand the meaning of "need" >> here. It is my impression that most people vastly overestimate how >> much of a phish target they are. Paypal and big banks certainly are, >> other places, a lot less so. > > (Sorry, I was on a much-needed vacation.) Much *needed*? Oh, well... > Ok, that's fair, I should have realized that one was over-stated. *Need* would imply that domain-spoofing is more common than it is in reality. Yes, domain spoofing is common. You don't need to be PayPal to be spoofed. Then, one can say it's an innocuous kind of abuse. Since you're not PayPal, it's just noise. Yet, in a perfect word, I'd opt to avoid it. > Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances. Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC). To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers. Nice synthesis. They believe DMARC works as advertised. What does it take to believe that DMARC /could/ work as advertised? > Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: > > * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) This is a good idea even without DMARC concerns. > * People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed) This sound just like an email-client configuration problem. It shouldn't be so hard. > The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports. Why not? If they send to DMARC-compliant receivers, their aggregate reports should show records without the right MSA signature, not even failed, and foreign domain authentications only. That doesn't tell which users misconfigured their client, but gives a good idea of the level of user education one has achieved. It should also show which domains users tend to use for submission, in case an organization wants to automate third-party authorization... Best Ale -- From nobody Tue Aug 18 02:17:30 2020 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 4BD4C3A0825 for ; Tue, 18 Aug 2020 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.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 OMB5LuvfeA7S for ; Tue, 18 Aug 2020 02:17:26 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2126.outbound.protection.outlook.com [40.107.236.126]) (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 392C53A0826 for ; Tue, 18 Aug 2020 02:17:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KyL0yeHstc7J2VWtVX/j11yuKRFQHN9xL2Z0++IrEd4Qs/ECdpw70k7iMrtL/TGQTYQU5+Kh0qJx0rkUSGxrZWtmPembiGqqy4SmdXzO2WBrcpjlTPpd16DJaS7Zme0now1cB+gNSbZH+kKqzzqZ7g9tYYb5Q3HY3N2EllwCDQl4M4clWaN9tRqIgyw3JjrAAlAYNiw3k9dmK7AsEiL/m6r/sofA6c84roGSFfSU5nxh7rkg0TmtuXFVJFQKt5VX9PFcsO7ueIAzKOIHtw9mDDlz+FlXP7PNQCF4V0617ZUnpSIvRWyPQNOB+KUio46OGwIj8k3J5jEEXCeFYVGqpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0d1r1dgNDh9DwlVmHueUFeEi2T5+J9e4yqdAI9djZ4=; b=ns0Xh9xKgBRtg/W9enOk8Y0ti24dpF/r3xZcPYT5O0HaIYu07jLe4tQOQ7iQ0Lg1tXPkWrEl4eicSzbxEkmKZtj+szd9gnQIoRymWe7JlWuhiU+imS+GTwfiysY46teb/ABRokJOaOLjXzuTdqgacNh7QZU7gPvZua9XvzeK0nWzGTXEGpiwrcagH3i/HED+DyU9sjyNC+nzJCqyYJMenk4g8+1UJUBFFfvHmQCBaZKY0BiFdNyXLV60PZTT0Bg2k6O/9gP0vMPWEABfc30nS/kdzVUGNd7DEC0eJE/hEpxYUPR/3+MTccnarNDb114ououZBi5+LOTK9sTE4d67tA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=agari.com; dmarc=pass action=none header.from=agari.com; dkim=pass header.d=agari.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0d1r1dgNDh9DwlVmHueUFeEi2T5+J9e4yqdAI9djZ4=; b=bp3N2Oi/uYHgon16cb7hwPnTwSfVjt7CuCgCtBuh/9gJkUr063L3BDQP3qUzW4CHKrm7FpFlLZvLoglYLq9GfwbKTWDyWKbjyt9vYbf/j+LZ+T5hVQm963S3YIauseJFJ24ddL23MPGKZzHhFc2npUa55qr+H2CfWKcRLNYqvLM= Received: from BY5PR13MB2999.namprd13.prod.outlook.com (2603:10b6:a03:191::27) by BYAPR13MB2743.namprd13.prod.outlook.com (2603:10b6:a03:f6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.15; Tue, 18 Aug 2020 09:17:17 +0000 Received: from BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f]) by BY5PR13MB2999.namprd13.prod.outlook.com ([fe80::1a5:56e5:b660:ec1f%3]) with mapi id 15.20.3305.020; Tue, 18 Aug 2020 09:17:17 +0000 From: Autumn Tyr-Salvia To: Jesse Thompson , John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] non-mailing list use case for differing header domains Thread-Index: AQHWZKh8JcOQ838b0UOee1lvwkySbakcmlWAgAAZV4CABAtZAIAAJAYAgAMr0H6AAONBAIAAILYAgAAgwICAACkyAIAAAbIAgAA2jwCAAoyEgIAACMwAgAALnQCAAY3UgIAANr6AgAJ+BWuAAJt5AIAAVzEAgAAj8oCAD4bHAIAAoGwr Date: Tue, 18 Aug 2020 09:17:16 +0000 Message-ID: References: <20200808023259.1D07F1E60C2D@ary.qy>, <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> In-Reply-To: <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=agari.com; x-originating-ip: [2600:1700:bd50:a670:ccb5:9441:6ab:f4ba] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3fb0124-e4f5-425f-7456-08d843578092 x-ms-traffictypediagnostic: BYAPR13MB2743: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NhFc8c+CsE2JC1DhQKQFMUffWkx4yWIs2ToSdBGU2T59QQhStjZco8Hf22GgKX3RXRLn7l5JbJODVcUSaLWHSBDbb1tRlBk4jzUPdAYs4CqZ0BxLR84XsY5/45o9nJUK851Mm5p0IVS0YkN7U7YOmNsAYj8cqdxBiiqOulgaOyMSn3+QM/+XD5xCyHd7mKy7ieHAhqHGY1KGBp9lvm8jaIWvmkxs0OboxM90jcBE1Ywody1Corv9AF5f/Jdpm8xYhUpG+GHfvWJ3F4fczVzYS36URm+7X1H2WVq2JiyI41zwOM45trdk+I52dPN1eA5DzSjjgcQYDt2r8Sw76HeqfIeMTfYx5Dm6X1OphY7NcHkBTuLeIssKB2G5Uo6/S5QnDJCECKapmX8yFuT6Sycy4EE7JpHAImMWJ3x9M5PvJkLTilziC3jDTwGr1/deRe//NkvZfpIIv5iSGru7/Eyb9G08iOAA+iZihxzfQBufpjc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB2999.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(346002)(396003)(366004)(136003)(66476007)(76116006)(186003)(53546011)(9686003)(7696005)(55016002)(2906002)(166002)(45080400002)(52536014)(83380400001)(33656002)(66556008)(5660300002)(478600001)(8676002)(966005)(64756008)(66446008)(6506007)(8936002)(86362001)(19627405001)(71200400001)(316002)(66946007)(110136005)(223123001)(130980200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /oDdHO9RMxfxDiKyt5SZ+nqWL5BuhKF54WdyJIdjFrVRpNuCbKmUR+XWLrRuG8ejiV9EJofejNtWz15QZoOWDiAQ8pSV70YjOtx/9ByT4DNzynDdo30CXreNvsf7BllyJ77ZQ2hvJOmd8iSMdfT0rRDVOWx7W+R9ZfXVo9P0NhQHeUowcvjIbdh7YqHyq/Np7I9uhQUy2P7DvHmjfEociM4wzu6zV3zBiUW/ZwD6UrROOwr7pBwC6zM7E45OjxRj6mJdmHqtBcgIxqMMG4Bp2wo0JlYcvh92OkciwAXrnYoWApne2HVaX0lWGVtKRzSOY10ctZDvTs+99kvRQLxs9e6kqLlSlbhTFBnRT66SuoziroUHdqnWVkGzWp2k863afwDoXplYbU/VbtDOwwDMIad718poOwnF7nxz8no39gs59kazInHraGpZumt31qkj1ioJTYJ4FjWO5mfRbmpGva+fcTU4DeMh192NXaFrqIvk/bgEbOzkt9veQv4CrWxyB4S3glSFuKrcoXbgsYsirW1T80gBkyWCvAW88/QRzrstn6JtQi+xvThx5UmmEbp1kmSpFr8UmlBxQMqUZKwFo7kVv2PxbRmFk8nK7+FdJZg2fbA+EHJX5+uhz7sC/U9bZBTEnJgEH1J0VQNN1jTGCA95LoIHyLWE6vITgBTLSkUZJcARufspTjbbj6pDs0P2uu4YaoA7X8DCyAnZIlGVKA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB29990BCF8E40BEB37AEEE4AAD75C0BY5PR13MB2999namp_" MIME-Version: 1.0 X-OriginatorOrg: agari.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB2999.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3fb0124-e4f5-425f-7456-08d843578092 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 09:17:17.0013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05773123-385e-420d-844e-f01aee5e37ab X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XwohSf4TgnlYHCHvMZeEr0YewulngvaD9ZYW15BaFVG+haKv2lKF4Ap+HArTWrFKfCl1zy0pRm45jn2peATn3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2743 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 09:17:28 -0000 --_000_BY5PR13MB29990BCF8E40BEB37AEEE4AAD75C0BY5PR13MB2999namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have seen Jesse mention something along these lines a couple of times: * Departments sending transactional email - move them to dedicated subdomai= ns (this is where really complex institutions would benefit from walking th= e domain tree instead of always inheriting from the org domain) Is inheritance walking the domain tree a topic that has already been discus= sed ad nauseam? This seems like an interesting point of discussion, but I a= lso haven't been participating on this list for ten years and don't want to= get into it if this is a topic everyone is tired of or that has no possibi= lity of change. Thanks, Autumn Tyr-Salvia atyrsalvia@agari.com Agari Principal Customer Success Engineer ________________________________ From: dmarc on behalf of Jesse Thompson Sent: Monday, August 17, 2020 4:39 PM To: John Levine ; dmarc@ietf.org Subject: Re: [dmarc-ietf] non-mailing list use case for differing header do= mains On 8/7/20 9:32 PM, John Levine wrote: >> We need spoofing protection for all of our domains without being told we= 're misdeploying. > > I would be interested to better undertstand the meaning of "need" > here. It is my impression that most people vastly overestimate how > much of a phish target they are. Paypal and big banks certainly are, > other places, a lot less so. (Sorry, I was on a much-needed vacation.) Ok, that's fair, I should have realized that one was over-stated. *Need* w= ould imply that domain-spoofing is more common than it is in reality. Cybersecurity-minded folk in EDU tend to equate observed inbound phishing w= ith spoofing (even though most phishing is spoofing the display name and me= ssage bodies, not the domain) and conclude that they *need* DMARC without r= eally understanding the nuances. Given the opportunity that DMARC marketin= g promises, they definitely *want* inbound DMARC enforcement for domain-spo= ofing of inbound mail (they'll defer to the email-minded folk to figure out= the local policy exemptions, ARC, etc), as well as *want* domain policies = that prevent the potential domain spoofing scenarios of owned domains (agai= n, the email-minded folk will figure out how to actually "misdeploy" DMARC)= . To them, it's just a checkmark towards some "maturity" benchmark that th= ey use to compare to their peers. Email-minded folk in EDU, knowing that DMARC doesn't really have much pract= ical application to phishing, like having the observability that DMARC prov= ides, as well as the hammer that moving past p=3Dnone provides as a way to = coerce their complex, decentralized institution into a more sustainable ope= ration: * Departments sending transactional email - move them to dedicated subdomai= ns (this is where really complex institutions would benefit from walking th= e domain tree instead of always inheriting from the org domain) * People sending user email from random places - move them to authenticated= submission (preferably OAuth - since basic authentication is the reason wh= y so many passwords are exposed) The latter scenario is interesting because a single user sending from a ran= dom place doesn't really show up in DMARC aggregate reports. It may show u= p in forensic reports, but it is easily lost in the noise. (SPF macros mig= ht be another way to get fine-grained observability, but that's a privacy l= eakage IMO.) In the end, it still results in: * That person wouldn't end up on our radar for communication * That person wouldn't understand what the message is about, even if we did= communicate with them * That person wouldn't comply, even if they understood * Once enforcement is in place, that person will complain and leverage ever= y ounce of their political influence to resist. (It's really fun when your= own users threaten lawsuits against you - that doesn't happen in Corporate= IT.) I'm kind of rambling now, I see. Hope you find it enlightening, regardless= ! Jesse _______________________________________________ dmarc mailing list dmarc@ietf.org https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Catyrsalvia%40agari.= com%7C07fe631db10e49cfa46508d84306d0b9%7C05773123385e420d844ef01aee5e37ab%7= C0%7C0%7C637333043846011888&sdata=3DGEKpu8y3KvA7Zkt0VJmeKz4KPwvSay51cj5= SDniQAUo%3D&reserved=3D0 --_000_BY5PR13MB29990BCF8E40BEB37AEEE4AAD75C0BY5PR13MB2999namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have seen Jesse mention something along these lines a couple of times:

= * Departments sending transactional email - move them to dedicated subdomain= s (this is where really complex institutions would benefit from walking the= domain tree instead of always inheriting from the org domain)

Is inheritance walking the domain tree a topic that has already been discus= sed ad nauseam? This seems like an interesting point of discussion, but I a= lso haven't been participating on this list for ten years and don't want to= get into it if this is a topic everyone is tired of or that has no possibility of change. 



Thanks,

Autumn Tyr-Salvia
atyrsalvia@agari.com
Agari Principal Customer Success Engineer

From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Jesse Thompson <jesse.thompson=3D40wisc.edu= @dmarc.ietf.org>
Sent: Monday, August 17, 2020 4:39 PM
To: John Levine <johnl@taugh.com>; dmarc@ietf.org <dmarc@ie= tf.org>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing he= ader domains
 
On 8/7/20 9:32 PM, John Levine wrote:
>> We need spoofing protection for all of our domains without being t= old we're misdeploying.
>
> I would be interested to better undertstand the meaning of "need&= quot;
> here. It is my impression that most people vastly overestimate how
> much of a phish target they are. Paypal and big banks certainly are, <= br> > other places, a lot less so.

(Sorry, I was on a much-needed vacation.)

Ok, that's fair, I should have realized that one was over-stated.  *Ne= ed* would imply that domain-spoofing is more common than it is in reality.<= br>
Cybersecurity-minded folk in EDU tend to equate observed inbound phishing w= ith spoofing (even though most phishing is spoofing the display name and me= ssage bodies, not the domain) and conclude that they *need* DMARC without r= eally understanding the nuances.  Given the opportunity that DMARC marketing promises, they definitely *want= * inbound DMARC enforcement for domain-spoofing of inbound mail (they'll de= fer to the email-minded folk to figure out the local policy exemptions, ARC= , etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned dom= ains (again, the email-minded folk will figure out how to actually "mi= sdeploy" DMARC).  To them, it's just a checkmark towards some &qu= ot;maturity" benchmark that they use to compare to their peers.

Email-minded folk in EDU, knowing that DMARC doesn't really have much pract= ical application to phishing, like having the observability that DMARC prov= ides, as well as the hammer that moving past p=3Dnone provides as a way to = coerce their complex, decentralized institution into a more sustainable operation:

* Departments sending transactional email - move them to dedicated subdomai= ns (this is where really complex institutions would benefit from walking th= e domain tree instead of always inheriting from the org domain)

* People sending user email from random places - move them to authenticated= submission (preferably OAuth - since basic authentication is the reason wh= y so many passwords are exposed)

The latter scenario is interesting because a single user sending from a ran= dom place doesn't really show up in DMARC aggregate reports.  It may s= how up in forensic reports, but it is easily lost in the noise.  (SPF = macros might be another way to get fine-grained observability, but that's a privacy leakage IMO.)

In the end, it still results in:
* That person wouldn't end up on our radar for communication
* That person wouldn't understand what the message is about, even if we did= communicate with them
* That person wouldn't comply, even if they understood
* Once enforcement is in place, that person will complain and leverage ever= y ounce of their political influence to resist.  (It's really fun when= your own users threaten lawsuits against you - that doesn't happen in Corp= orate IT.)

I'm kind of rambling now, I see.  Hope you find it enlightening, regar= dless!

Jesse

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://nam12.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flist= info%2Fdmarc&amp;data=3D02%7C01%7Catyrsalvia%40agari.com%7C07fe631db10e= 49cfa46508d84306d0b9%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637333043= 846011888&amp;sdata=3DGEKpu8y3KvA7Zkt0VJmeKz4KPwvSay51cj5SDniQAUo%3D&am= p;amp;reserved=3D0
--_000_BY5PR13MB29990BCF8E40BEB37AEEE4AAD75C0BY5PR13MB2999namp_-- From nobody Tue Aug 18 02:29:43 2020 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 485AB3A0856 for ; Tue, 18 Aug 2020 02:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 i7KoSwPbM0vg for ; Tue, 18 Aug 2020 02:29:41 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 009923A0855 for ; Tue, 18 Aug 2020 02:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597742978; bh=sNlLPiGkV55wY8hcKBP1VEzc960U507ucTx9GclqF8c=; l=1390; h=To:References:From:Date:In-Reply-To; b=Ci72kLboLABbor8m82PbUaCcEowA4QvC11g5NOQ0pb32F64FVHksmTAuQj+qt0BQG SN6jyFM61bPhAgb0wbypooJNZINKlE5GoaXKU4QhADOwUUoJvSQRzZ11Ef4bpd8mAU n8qFqztvktARKxtjvgnCJpODiKSQd3JZ4UUuEVN4icbcc41/jf/f4GXgKyJYQ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.83.110]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F3B9F82.0000515D; Tue, 18 Aug 2020 11:29:38 +0200 To: dmarc@ietf.org References: <0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> From: Alessandro Vesely Message-ID: <1aacc91c-8ed2-9d11-c856-0c013c4135a4@tana.it> Date: Tue, 18 Aug 2020 11:29:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC failure scenarios X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 09:29:42 -0000 On Tue 18/Aug/2020 03:56:12 +0200 Douglas E. Foster wrote: > d) The client develops a list of all of its third-party mailers and > tells the third parties to begin applying the client's DKIM signature > to their messages.   This adds a boatload of complexity to the > vendor's application, since he needs a different applied signature for > each client.   It requires either major changes to the application, a > more sophisticated mail server, or a special box simply to sit in > front of the mail server to detect and apply the correct signature. >  None of these seem like generic off-the-shelf solutions.   I would > not know where to buy that capability if I needed it today. > It doesn't have to add much complexity. My DKIM filter[*] looks up the signing domain in a configured folder where it can find the selector and the private key —actually a symbolic link. The signing domain can be configured to be the domain of the From: field. The app just has to use the client's domain for both the envelop and the header, which is actually simpler than the pre-DMARC case. The client must publish the public key supplied by the vendor and include the vendor's SPF stuff in its record. That's not automated, AFAIK, although dynamic DNS and suitable scripts could do. Best Ale -- [*] http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#signing From nobody Tue Aug 18 03:49:17 2020 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 468C33A083C for ; Tue, 18 Aug 2020 03:49:16 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl2NhSMwce_N for ; Tue, 18 Aug 2020 03:49:14 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A014A3A083B for ; Tue, 18 Aug 2020 03:49:14 -0700 (PDT) X-ASG-Debug-ID: 1597747746-11fa31095e143a0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id SDljHoGNk9EOrCHm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 18 Aug 2020 06:49:06 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=PkFf+pZ3EkLoikZQ4vPSyTb2aicpsliMdCRJQRxbUTU=; b=DuSB7SaF9x7Qsx6DIMFfYWEJzuw0vFuOYafqdyK2LxnkHxF15aZ9DwDuVP22IU4wm MoKEFdVY6/OyvciFf/OBtyIjk7Bob01kTnjHiA/1l+4lPLOH6PUuPxBQtI99zCN7E HuTUPQruGAoamU0JlFxE508Gt9TWYWyxXKKL5xeUw= From: "Douglas E. Foster" To: Date: Tue, 18 Aug 2020 10:48:57 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] DMARC failure scenarios Reply-To: fosterd@bayviewphysicians.com Message-ID: <2a20bd4a3844404a86ac9f38c7336da2@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=c96007fe26204a8384cc94f075cbabe9 In-Reply-To: <20200818021201.E99631EE74E6@ary.local> References: <20200818021201.E99631EE74E6@ary.local> X-Exim-Id: 2a20bd4a3844404a86ac9f38c7336da2 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597747746 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 6613 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83983 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] DMARC failure scenarios X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 10:49:16 -0000 This is a multipart message in MIME format. --c96007fe26204a8384cc94f075cbabe9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You cannot make sense of it, John. I understand the difference between su= bmssion and SMTP. The asserted increase in complexity is not from adding a single signature, = it is the requirement to apply a different signature to every message depen= ding on the generated From domain. Are applications like the one the Alessandro mentioned readily available an= d easily implemented, so that conditional signatures are no hindrance to DM= ARC compliance? If so, is third-party cooperation easily achieved and no = obstacle to DMARC implementation? These are questions for the consultants who have done a lot of this work. DF ---------------------------------------- From: "John Levine" Sent: 8/17/20 10:12 PM To: dmarc@ietf.org Cc: fosterd@bayviewphysicians.com Subject: Re: [dmarc-ietf] DMARC failure scenarios In article <0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> you wri= te: >-=3D-=3D-=3D-=3D-=3D- > >Does this scenario correctly characterize how organizations may be unable = to move past p=3Dnone with breaking things? As far as I can made sense of it, no. >a) A vendor application detects an event, looks up in a database for sende= r name (client contact) and recipient list. > >b) The application connects to a mail server via IMAP, and sends the messa= ge using something like application@vendordomain >for the SMTP from and cllentcontact@clientdomain as the Message from. The = client domain becomes especially important if >the recipients are in a different domain than the client. An example might= be an HVAC system operated by a vendor, on >behalf of the building manager, which needs to communicate with the buildi= ng tenants. ... Again, no. You're confusing submission with SMTP. I have a printer that sends me e-mail when it's out of paper, which it does by sending mail to my submission server, not directly to me. If I were checking DMARC on the messages, they would easily pass since the submission server adds DKIM signatures. >Then the client wants to implement DMARC >---------------------------------------------------------- > >d) The client develops a list of all of its third-party mailers and tells = the third parties to begin applying the client's >DKIM signature to their messages. This adds a boatload of complexity to th= e vendor's application, since he needs a >different applied signature for each client. It requires either major chan= ges to the application, a more sophisticated >mail server, or a special box simply to sit in front of the mail server to= detect and apply the correct signature. None of >these seem like generic off-the-shelf solutions. I would not know where to= buy that capability if I needed it today. Again, no. I believe that devices that send mail do what they've always done, send it to a submission server for further delivery. The "special box" has been there all along. R's, John --c96007fe26204a8384cc94f075cbabe9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
You cannot make se= nse of it, John.   I understand the difference between submssion and S= MTP. 

The asserted increase in complexity is = not from adding a single signature, it is the requirement to apply a differ= ent signature to every message depending on the generated From domain. &nbs= p;  
  • Are applications like the one the Alessandro mention= ed readily available and easily implemented, so that conditional signatures= are no hindrance to DMARC compliance?   
  • If so, is third= -party cooperation easily achieved and no obstacle to DMARC implementation?=    
These are questions for the consultants who ha= ve done a lot of this work.

DF

From: "John Levine" <johnl@taugh.com>
= Sent: 8/17/20 10:12 PM
To: dmarc@ietf.org
<= strong>Cc: fosterd@bayviewphysicians.com
Subject: Re: [dmarc-ietf] DMARC failure scenarios
In article &l= t;0762f9ada48c4c9eaef06e16a49a252c@bayviewphysicians.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>Does this sce= nario correctly characterize how organizations may be unable to move past p= =3Dnone with breaking things?

As far as I can made= sense of it, no.

>a) A vendor application dete= cts an event, looks up in a database for sender name (client contact) and r= ecipient list.
>
>b) The application connects to = a mail server via IMAP, and sends the message using something like applicat= ion@vendordomain
>for the SMTP from and cllentcontact@clientdo= main as the Message from. The client domain becomes especially important if=
>the recipients are in a different domain than the client. An= example might be an HVAC system operated by a vendor, on
>beh= alf of the building manager, which needs to communicate with the building t= enants. ...

Again, no. You're confusing submission= with SMTP. I have a printer
that sends me e-mail when it's out o= f paper, which it does by sending
mail to my submission server, n= ot directly to me. If I were checking DMARC
on the messages, they= would easily pass since the submission server adds
DKIM signatur= es.

>Then the client wants to implement DMARC
>----------------------------------------------------------
>
>d) The client develops a list of all of its third= -party mailers and tells the third parties to begin applying the client's
>DKIM signature to their messages. This adds a boatload of comp= lexity to the vendor's application, since he needs a
>differen= t applied signature for each client. It requires either major changes to th= e application, a more sophisticated
>mail server, or a special= box simply to sit in front of the mail server to detect and apply the corr= ect signature. None of
>these seem like generic off-the-shelf = solutions. I would not know where to buy that capability if I needed it tod= ay.

Again, no. I believe that devices that send ma= il do what they've
always done, send it to a submission server fo= r further delivery. The
"special box" has been there all along.

R's,
John

--c96007fe26204a8384cc94f075cbabe9-- From nobody Tue Aug 18 06:08:31 2020 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 336CB3A09C0 for ; Tue, 18 Aug 2020 06:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_BLOCKED=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 (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 L75Njd-wIA-N for ; Tue, 18 Aug 2020 06:08:27 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 B47AD3A09BD for ; Tue, 18 Aug 2020 06:08:27 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id p4so18148230qkf.0 for ; Tue, 18 Aug 2020 06:08:27 -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=z62PQSVbDLN42iBJ6/NgEaZX/mvHBWssRthP4f756kE=; b=f3ymLGw7kdhEPn/WoTalUDpqVDswjRLLqgqa7twFLweWY4LKskYgvtxTdXy2m24Eg+ 08ktd7JhknTGwdOp+qS8ZGLasQ7zusoUqOSs0mxbOHVec1eirYFG3104/gCIAd9wwHpz VSwfcbRyQzrJngm9glKXf9NPY7vd0sM1bQXbFB329g9/+wkiSe/tRlkqu7N63owhw9uk cBqvxNuoS+feF70LCEi02x+270WfzdNdwYnkzQnfq1GZXX3L94QIec4/sGElkoTWHOqa RA2xJfpSTSsvYS/sx9O+00LLxZZnyQgoWtqQDYrzHZ7Iboulx/ciYs7ND5Nas0g7mttQ 4Y3A== 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=z62PQSVbDLN42iBJ6/NgEaZX/mvHBWssRthP4f756kE=; b=SLhPCmPJ40Z0zAqdH4Bhh17PUfefCvakJOsnR52/KenBJD1j5+uXzFFNqGEj7kZd01 XoiPgKnWpUDd6ybt/EVOFmGF63e9ZFiui2vIuB3SI6hk2hn5Hvu6pvysuw6SKs98AxrO EIWvhBdiV9qB1rZ7Q+KDhP8v6xHSNC1VuXw5Iht10mmrkDyzUxinLtLf90T7j9qbNXpZ bid6Zu0I8Avseq0VqiJpsbwhCYTjzoi9Cf40rHiGcK7yQqsLDKAkfc/GAgGT0wsxhq2Q f85ZFCO3wiPqXulmgBh5wRgX2mKH1/VDBKIWqwKp3IvKgJWu4aWd9FwP+XTtHO5pzXRY H2SA== X-Gm-Message-State: AOAM533zSxdokfMfFnfWVRBOItwvoICsj0Qj85CQ1NeaA0AltW51M6PX Nn5xt8TYwrHwU9cEGRSprmswY7/DDv/DhPnZMNw= X-Google-Smtp-Source: ABdhPJxdqmpp54GoBuSFrWZK8uuGn+dAWLlGMXstvcWett7H+MM6S1M6AQiu6727lLsGU5U8SW4MlKuYuXr4lJ8jKXo= X-Received: by 2002:a05:620a:545:: with SMTP id o5mr16426134qko.187.1597756106693; Tue, 18 Aug 2020 06:08:26 -0700 (PDT) MIME-Version: 1.0 References: <20200818021201.E99631EE74E6@ary.local> <2a20bd4a3844404a86ac9f38c7336da2@bayviewphysicians.com> In-Reply-To: <2a20bd4a3844404a86ac9f38c7336da2@bayviewphysicians.com> From: Dotzero Date: Tue, 18 Aug 2020 09:08:15 -0400 Message-ID: To: "Douglas E. Foster" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002d613105ad2695d4" Archived-At: Subject: Re: [dmarc-ietf] DMARC failure scenarios X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 13:08:29 -0000 --0000000000002d613105ad2695d4 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 18, 2020 at 6:49 AM Douglas E. Foster wrote: > You cannot make sense of it, John. I understand the difference between > submssion and SMTP. > > The asserted increase in complexity is not from adding a single signature, > it is the requirement to apply a different signature to every message > depending on the generated From domain. > > - Are applications like the one the Alessandro mentioned readily > available and easily implemented, so that conditional signatures are no > hindrance to DMARC compliance? > - If so, is third-party cooperation easily achieved and no obstacle to > DMARC implementation? > > These are questions for the consultants who have done a lot of this work. > > DF > Not as a 3rd party, but we were doing ad-hoc signing for a large number of domains (hundreds) at our outbound border MTAs at scale -10s of millions of messages an hour, with the ability to scale much much larger for holiday peaks. This was done with both Ironport and MessgeSystems implementations. It's literally a very little bit of logic and code. As long as you have the private keys it's as simple as choosing the path to the correct signing key based on having the From domain. This was at various points done in Python and Lua. Michael Hammer --0000000000002d613105ad2695d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 18, 2020 at 6:49 AM Dougl= as E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
You cannot make sense of it, John. =C2=A0 I under= stand the difference between submssion and SMTP.=C2=A0

=
The asserted increase in complexity is not from adding a single signat= ure, it is the requirement to apply a different signature to every message = depending on the generated From domain. =C2=A0 =C2=A0
  • Are appl= ications like the one the Alessandro mentioned readily available and easily= implemented, so that conditional signatures are no hindrance to DMARC comp= liance? =C2=A0=C2=A0
  • If so, is third-party cooperation easily achie= ved and no obstacle to DMARC implementation? =C2=A0 =C2=A0
Th= ese are questions for the consultants who have done a lot of this work.

DF

Not as= a 3rd party, but we were=C2=A0 doing ad-hoc signing for a large number=C2= =A0of domains (hundreds) at our outbound border MTAs at scale -10s of milli= ons of messages an hour,=C2=A0with the ability to scale much much larger fo= r holiday peaks. This was done with both Ironport and MessgeSystems=C2=A0im= plementations. It's literally a very little bit of logic and code. As l= ong as you have the private keys it's as simple as choosing the path to= the correct signing key based on having the From domain. This was at vario= us points done in Python and Lua.

Michael Hammer
--0000000000002d613105ad2695d4-- From nobody Tue Aug 18 09:39:49 2020 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 2767E3A0F4E for ; Tue, 18 Aug 2020 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=krpC/GrC; dkim=pass (2048-bit key) header.d=taugh.com header.b=H0A5gEPd 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 IuVXCYq-dnqD for ; Tue, 18 Aug 2020 09:39:46 -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 08EF93A0F4A for ; Tue, 18 Aug 2020 09:39:45 -0700 (PDT) Received: (qmail 11553 invoked from network); 18 Aug 2020 16:39:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2d1e.5f3c0450.k2008; i=johnl-iecc.com@submit.iecc.com; bh=9tunOPnXPg8CvQhMK9HWqf8D0KeWdVrl/btLYlA/TbI=; b=krpC/GrCNGXtlWUsDvUEM24MhFq4tYeFTYL/ABu2GQjOb8vyoQHlOAe9Q8lSPSbEsRtWO7X/NIcnXDZB6zi3otFJ/6NilTONabBPuVB4+Gd5UJZNwXi3dTGI71k8uw0FY1Q0UeX1wZMmPb17X2Dk7PYXpA0YezbLUeartY/BCa43JwqkszZ03YB19OxkkUeTpsb02OyXthlgizz6LyPfRU82i4WpYJ++065QGT7PeuuoutVO+yYyNNg/qv2Qar4uLL0dYd4Sua/OBhgpu2oeDl4cgK+I0UBuxdYHVwE2OIr4iN/LqnoujtuZveR/3AfDljiu0j2VjdItGuotS7kMyg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2d1e.5f3c0450.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=9tunOPnXPg8CvQhMK9HWqf8D0KeWdVrl/btLYlA/TbI=; b=H0A5gEPd2DbemTsYbcS8smYsMzyDpwncSA8z5cp9hZKlihSbBaIG0bDd5xXQgfQLTuSpNdUwn87HnjmMir+VUSZnjJ4RxByr9O780VCsuXLs+q5VPn0iFn3nkmIHSjMgmEXsVWSzWNf+lh3BceTeOkxWqhlmNRQbcReDbPwlIPMEkUu3slHuocImFwSjMKDsXRSqjq8M0rUbCZo5S48znRto7TUk0E6o8bPZBHro7vT4zEI0aF/QNxHueuwetsPESn8c2VrRlpbJftVan7wy39i67JJo/sbGwXAIM50W9FV7WNBk50Ffz/aTbYURmMUvzUb2DIfdaWWpKAJk5Q0JpA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 18 Aug 2020 16:39:43 -0000 Date: 18 Aug 2020 12:39:43 -0400 Message-ID: <585c222c-e288-5328-ea36-4d554234c838@taugh.com> From: "John R Levine" To: "Autumn Tyr-Salvia" , "dmarc@ietf.org" In-Reply-To: References: <20200808023259.1D07F1E60C2D@ary.qy>, <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] finer grained org domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:39:48 -0000 On Tue, 18 Aug 2020, Autumn Tyr-Salvia wrote: > * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) > > Is inheritance walking the domain tree a topic that has already been discussed ad nauseam? This seems like an interesting point of discussion, but I also haven't been participating on this list for ten years and don't want to get into it if this is a topic everyone is tired of or that has no possibility of change. We've spun our wheels a lot trying to figure out a better way to find the organizational domain than for everyone to download the Mozilla PSL, but not about changing it to a tree walk. If we could come up with a better way for domains to publish their own boundaries (see https://github.com/jrlevine/bound) then that would be easy. 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 Aug 18 09:43:35 2020 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 9CADD3A0F53 for ; Tue, 18 Aug 2020 09:43:33 -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, 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 VxYcuIRLhlNn for ; Tue, 18 Aug 2020 09:43:32 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::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 09AED3A0D02 for ; Tue, 18 Aug 2020 09:43:31 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id k4so18480272oik.2 for ; Tue, 18 Aug 2020 09:43:31 -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=fDJYK39dN+ZIWDZkmjtQ6jAtr6VsOQQDgx4lDQMR/8Q=; b=ZW6jDoaPgaHZnae5aSNOMYq/n8YcuWmOJdKwWNWIU647tcln6uxGD7S3JuOfPcbXJP FlVUqqofb7jWvtS27ObHXTbsndPoCPCBCxVI46Thi1OfH4DNoQ+WtqOmCeoE0oYX03dY 2KEMbY3mLmRsilpJilPgZGC6i1calOg9AuUWUv2zAfHxRcKds//794HD2VYd1JIxKFNB Y/VN0SquB/BLn25lcmAxyLbd++jBLjsjGIlVqACJObtLejCceWJ96YVKfWtUJ14KUULM 7/pr+EnnL0T+F7Gjy0bpeVRbqcV/Mpob4AHirqMIoQQhNUF0IpLf+OUNd8Lxoh0ZlFZe +l6Q== 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=fDJYK39dN+ZIWDZkmjtQ6jAtr6VsOQQDgx4lDQMR/8Q=; b=XcSL0Q0DTOpT641YgY/Eze26Vzc3mOiMxHIf5848VHTFea/6IwqlnP21NL4vgpgoZJ G8DK3D3vYRCl+haJNxtjRru+MMgkhCt8qrtHIYtCjtde3oi4EI1n6K0TjTRLPsCtQxm6 h9F9tCrMHKHFYysdX0FT5h98odaD7pivcZzltzezIIhYftfvFV8poehUg/kgNURippe/ UhqTBe8p3Jrlw4RpManEzPJHBeYTbMCQQcPigQxOT3jS1c8uS129kFMQqHnWXhhNyOr6 TDoaTWRmkyKfv75g/g5lIAaJcxj/IlPgLfcLEMHXJZtN8/QvZ2VFKbtCkmPvjgRa6Dli MVBw== X-Gm-Message-State: AOAM530FkxHFmKESItE0FqMSnzBuGpDdgtwMCei5LjDB8MalFauXfqBJ VSiE6TyNRBWrY0o7HCvRkl5EckNnnlSIVj8zycY= X-Google-Smtp-Source: ABdhPJyVa5bdsaDETn4dWZ7CrJBojVnqS6mtLbuGqZvEF0NxN1Fg3IVTqmAokTBVdi8zDvByKhEe3XJghmkcUks4qaE= X-Received: by 2002:aca:4a49:: with SMTP id x70mr591666oia.173.1597769011194; Tue, 18 Aug 2020 09:43:31 -0700 (PDT) MIME-Version: 1.0 References: <20200808023259.1D07F1E60C2D@ary.qy> <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> <585c222c-e288-5328-ea36-4d554234c838@taugh.com> In-Reply-To: <585c222c-e288-5328-ea36-4d554234c838@taugh.com> From: Tim Wicinski Date: Tue, 18 Aug 2020 12:43:20 -0400 Message-ID: To: John R Levine Cc: Autumn Tyr-Salvia , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000058712c05ad299648" Archived-At: Subject: Re: [dmarc-ietf] finer grained org domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:43:34 -0000 --00000000000058712c05ad299648 Content-Type: text/plain; charset="UTF-8" Speaking not as a chair... I do think the tree walk deserves another look. Years back when it was brought up, there was lots of talk of overloading resolvers. But as someone who spent the past several years looking at the DNS query data of good sized SaaS domains, DMARC lookups (or even DMARC NXDOMAINs) were on the low end of the spectrum. Nowadays, all web properties point to CDNs, et al with 30 second TTLs. tim On Tue, Aug 18, 2020 at 12:39 PM John R Levine wrote: > On Tue, 18 Aug 2020, Autumn Tyr-Salvia wrote: > > * Departments sending transactional email - move them to dedicated > subdomains (this is where really complex institutions would benefit from > walking the domain tree instead of always inheriting from the org domain) > > > > Is inheritance walking the domain tree a topic that has already been > discussed ad nauseam? This seems like an interesting point of discussion, > but I also haven't been participating on this list for ten years and don't > want to get into it if this is a topic everyone is tired of or that has no > possibility of change. > > We've spun our wheels a lot trying to figure out a better way to find the > organizational domain than for everyone to download the Mozilla PSL, but > not about changing it to a tree walk. > > If we could come up with a better way for domains to publish their own > boundaries (see https://github.com/jrlevine/bound) then that would be > easy. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000058712c05ad299648 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking not as a chair...

I do think the tree walk deserves another look.=C2=A0 =C2= =A0Years back when it was brought up,
there was lots of talk of overloading resolver= s. But as someone who spent the past=C2=A0
several years looking at the DNS query da= ta of good sized SaaS domains, DMARC lookups
(or even DMARC NXDOMAINs) were on the l= ow end of the spectrum.=C2=A0 Nowadays, all web=C2=A0
properties point to CDNs, et a= l with 30 second TTLs.=C2=A0 =C2=A0

tim


On Tue, Aug 18, 2020 at 12:39 PM John R Levin= e <johnl@taugh.com> wrote:
=
On Tue, 18 Aug 2020= , Autumn Tyr-Salvia wrote:
> * Departments sending transactional email - move them to dedicated sub= domains (this is where really complex institutions would benefit from walki= ng the domain tree instead of always inheriting from the org domain)
>
> Is inheritance walking the domain tree a topic that has already been d= iscussed ad nauseam? This seems like an interesting point of discussion, bu= t I also haven't been participating on this list for ten years and don&= #39;t want to get into it if this is a topic everyone is tired of or that h= as no possibility of change.

We've spun our wheels a lot trying to figure out a better way to find t= he
organizational domain than for everyone to download the Mozilla PSL, but not about changing it to a tree walk.

If we could come up with a better way for domains to publish their own
boundaries (see https://github.com/jrlevine/bound) then that wo= uld be
easy.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000058712c05ad299648-- From nobody Tue Aug 18 09:43:54 2020 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 2B1A73A0F7B for ; Tue, 18 Aug 2020 09:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 6vv6gMD8c4fK for ; Tue, 18 Aug 2020 09:43:42 -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 C58B43A0F78 for ; Tue, 18 Aug 2020 09:43:40 -0700 (PDT) Received: from [192.168.0.101] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07IGkQMu002249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Aug 2020 09:46:27 -0700 To: "dmarc@ietf.org" References: <20200808023259.1D07F1E60C2D@ary.qy> <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> <585c222c-e288-5328-ea36-4d554234c838@taugh.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <4261f4bd-8e43-464b-7e9b-91c26ba55e83@dcrocker.net> Date: Tue, 18 Aug 2020 09:43:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <585c222c-e288-5328-ea36-4d554234c838@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] finer grained org domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:43:53 -0000 On 8/18/2020 9:39 AM, John R Levine wrote: > We've spun our wheels a lot trying to figure out a better way to find > the organizational domain than for everyone to download the Mozilla > PSL, but not about changing it to a tree walk. > > If we could come up with a better way for domains to publish their own > boundaries (see https://github.com/jrlevine/bound) then that would be > easy. And for completeness:     DNS Perimeter Overlay https://tools.ietf.org/id/draft-dcrocker-dns-perimeter-01.html (John thinks it's the same as his, but it's not...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 18 09:49:01 2020 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 7D9D53A0F68 for ; Tue, 18 Aug 2020 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 CnNSuBJitp0T for ; Tue, 18 Aug 2020 09:48:53 -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 7D1463A0F65 for ; Tue, 18 Aug 2020 09:48:53 -0700 (PDT) Received: from [192.168.0.101] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07IGpdnM002632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Aug 2020 09:51:39 -0700 To: Tim Wicinski Cc: "dmarc@ietf.org" References: <20200808023259.1D07F1E60C2D@ary.qy> <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> <585c222c-e288-5328-ea36-4d554234c838@taugh.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 18 Aug 2020 09:48:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------432A9C91FAE01C6D8996AB2B" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] finer grained org domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:49:00 -0000 This is a multi-part message in MIME format. --------------432A9C91FAE01C6D8996AB2B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/18/2020 9:43 AM, Tim Wicinski wrote: > I do think the tree walk deserves another look.   Years back when it > was brought up, > there was lots of talk of overloading resolvers. But as someone who > spent the past > several years looking at the DNS query data of good sized SaaS > domains, DMARC lookups > (or even DMARC NXDOMAINs) were on the low end of the spectrum.  > Nowadays, all web > properties point to CDNs, et al with 30 second TTLs. To be entirely obvious: badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.yougetheidea.example.com produces a possible denial of service attack.  hence, no tree-walking. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------432A9C91FAE01C6D8996AB2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/18/2020 9:43 AM, Tim Wicinski wrote:
I do think the tree walk deserves another look.   Years back when it was brought up,
there was lots of talk of overloading resolvers. But as someone who spent the past 
several years looking at the DNS query data of good sized SaaS domains, DMARC lookups
(or even DMARC NXDOMAINs) were on the low end of the spectrum.  Nowadays, all web 
properties point to CDNs, et al with 30 second TTLs.   

To be entirely obvious:

     badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.yougetheidea.example.com

produces a possible denial of service attack.  hence, no tree-walking.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------432A9C91FAE01C6D8996AB2B-- From nobody Tue Aug 18 09:59:23 2020 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 4C8FA3A0FF1 for ; Tue, 18 Aug 2020 09:59:22 -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 (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moWzeitfbWLU for ; Tue, 18 Aug 2020 09:59:19 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 53F653A1005 for ; Tue, 18 Aug 2020 09:59:19 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id x5so16882488wmi.2 for ; Tue, 18 Aug 2020 09:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3RBLFf7tmromE9hNs+aYVsKSDNfgDJNHF7iUMU63CTw=; b=Vd5raXyxkgqowHyAZ3MwMApAcB0h035y8/21RbXfJfin7J+fblZJ91ggkn3WzUwLyH m8BodiVaxHoldiSJpKTkn3fjtFrMCjv3LCbFbJCrAGhUpO5+JgnHi6VN3GCIWTY1Rf3R 7T7XbSY4+hTOTVEbhNm/fFEGDaWaETyAVPbhuko2ZvWC6GeOqgA8gmuPP5qFfG1aUGKr auiwLCvg2B8cUnMg8Z+vo1jTV5bPr3nnYlPooM/l+MgpLP6M6/Lfj+55pzyjPhnkr1qQ 8B/9RkRk6Ln0GCgCXzQ9KamYt5S9Uw+5TulcrSzOWc87gpq4arCJjN1vCrH8u/W2S6ul xltQ== 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=3RBLFf7tmromE9hNs+aYVsKSDNfgDJNHF7iUMU63CTw=; b=ciPXmE3kqohdCXpwnUPiqTzEN2DmSdCYNiPyGb/0SWjHl88HE4zj4FVfCSfgnB0J/d kal1V3CpAPpOGvTjmnOGuOvRwcLk0huyeca7juAIvYgMTmgFkrEoHAlhO9nSw1hBzK89 BzSUKRe8eODNfkQr0+goL5mAaarUV22s9A6RvA3BIaCQCmZdCIZRy/FgJCqEn4N56ZCL DEl/hYLvXwz8iE6j8w0KaWusYGdnkwV2o2gYI2USR9wLcp7MfD8ERo9XF8xRGiCbuKmQ 2Z52ugALIKTOaS1oHErLeAkEqSmAaWvSZ/fnfVHhHg75CCPHUKmySca7FDGOLCZEVQex ePhA== X-Gm-Message-State: AOAM531OOUdzSGCcZpEbZTAfpXXA7GXZfXCFeabi1jCuo3h2qxC8IKbK 9978xbfMkqnUPP3DkRWllL662gNjsQUOL1Fa4Lgr9Q== X-Google-Smtp-Source: ABdhPJwcd7/lQvajihSNAnRmMZuJ9iPaUVhFV3Y5YyJBKWD5bvPkxX+wtJKOFqfjWY1ZfX1cXj/7UiniEKy5hLiYyIU= X-Received: by 2002:a1c:9e11:: with SMTP id h17mr814878wme.106.1597769957571; Tue, 18 Aug 2020 09:59:17 -0700 (PDT) MIME-Version: 1.0 References: <20200808023259.1D07F1E60C2D@ary.qy> <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> <585c222c-e288-5328-ea36-4d554234c838@taugh.com> In-Reply-To: From: Seth Blank Date: Tue, 18 Aug 2020 09:59:06 -0700 Message-ID: To: Dave Crocker Cc: Tim Wicinski , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c117ef05ad29ced7" Archived-At: Subject: Re: [dmarc-ietf] finer grained org domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:59:22 -0000 --000000000000c117ef05ad29ced7 Content-Type: text/plain; charset="UTF-8" There is a ticket for tree walk: https://trac.ietf.org/trac/dmarc/ticket/68 Please hold the conversation until the chairs open that thread. Seth, as Chair On Tue, Aug 18, 2020 at 9:49 AM Dave Crocker wrote: > On 8/18/2020 9:43 AM, Tim Wicinski wrote: > > I do think the tree walk deserves another look. Years back when it was > brought up, > there was lots of talk of overloading resolvers. But as someone who spent > the past > several years looking at the DNS query data of good sized SaaS domains, > DMARC lookups > (or even DMARC NXDOMAINs) were on the low end of the spectrum. Nowadays, > all web > properties point to CDNs, et al with 30 second TTLs. > > To be entirely obvious: > > badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.yougetheidea.example.com > > produces a possible denial of service attack. hence, no tree-walking. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 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. --000000000000c117ef05ad29ced7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a ticket for tree walk:=C2=A0https://trac.ietf.org/trac/dmarc/ticket/= 68

Please hold the conversation until the chairs ope= n that thread.

Seth, as Chair

On Tue, Aug 18,= 2020 at 9:49 AM Dave Crocker <dhc@d= crocker.net> wrote:
=20 =20 =20
On 8/18/2020 9:43 AM, Tim Wicinski wrote:
I do think the tree walk deserves another look.=C2=A0 =C2=A0Years back w= hen it was brought up,
there wa= s lots of talk of overloading resolvers. But as someone who spent the past=C2=A0
several years looking at the DNS query data of good sized SaaS domains, DMARC lookups
(or even DMARC NXDOMAINs) were on the low end of the spectrum.=C2=A0 Nowaday= s, all web=C2=A0
properti= es point to CDNs, et al with 30 second TTLs.=C2=A0 =C2=A0

To be entirely obvious:

=C2=A0=C2=A0=C2=A0=C2=A0 badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.= yougetheidea.example.com

produces a possible denial of service attack.=C2=A0 hence, no tree-walking.

d/

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


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion 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 include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--000000000000c117ef05ad29ced7-- From nobody Tue Aug 18 10:33:06 2020 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 6E7663A0882 for ; Tue, 18 Aug 2020 10:33:04 -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 PatGV8856KJi for ; Tue, 18 Aug 2020 10:33:02 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355993A0881 for ; Tue, 18 Aug 2020 10:33:01 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id r13so13909472iln.0 for ; Tue, 18 Aug 2020 10:33:01 -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=dcApEWYSdHYzh9m3XXesELXFOBYlIWselA6v8cefS+w=; b=GxEbm7HhPhZj39AiiWetc0Qk8Rnjrn84YGo+KtQ4PCnp/a4diss/67Rkl21KUupx6m M1zQXYQw+RpTkXrSZRqU7tBjHXlV447J5kPjNbpHrGS+3HoAtVJx50c3FcNwxpd21SFx 2vh63NustRNh6dryIsD9mXlk3qzDQY5BH5O/w= 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=dcApEWYSdHYzh9m3XXesELXFOBYlIWselA6v8cefS+w=; b=gkzc019KHJDX/OSTdFCl9w+6ImzGy33p/T5/U9v0Z5kHCCvpv59cr2XjvjI4tQQmEX XtGJ7cNfff2FLqlmAQCkzD+OeUf7GuF/k/7RFrP6FJlsnkn1CSSlc99YdTH2N+PrDOqP Z9ydLzw3mapWSRMk1+9Zc37IDBowZ61Y4cE/Mb8JlbEL5wNBs7zQ/khX1EE1EZMXQWGn HBeKz+76Z9+2RrYJr1pBE4YRJsN7UtgBj7ijyGHtcBYADxMFO/HyYnEgYA0OAQlhbUbS iYW5JM9mEaVW9B81P6Vz5ZehV1H+z60wh/4TzE/RF7vgrQ9IV8OX9QM46kC7Yq8kx9ko VoXg== X-Gm-Message-State: AOAM532LZ1GRYuLilY0kuu8QDKM+m0dHchiiuYkIOhTyb2RUuFrqIpUs XtssYJFxfUPD1m9VESJYHrU8Ld3sBQQEw6+Fo7SDQCOlXxrFBA== X-Google-Smtp-Source: ABdhPJxK+qPNa+U6FvssJu02+67ir2QbAtIzMDg/Xv9Rk8Nsi6TVKMBmmPNlhAZEWLBzXLAx78qjSDjBQL6PjySMHsA= X-Received: by 2002:a92:85c8:: with SMTP id f191mr19473836ilh.242.1597771980265; Tue, 18 Aug 2020 10:33:00 -0700 (PDT) MIME-Version: 1.0 References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> In-Reply-To: <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> From: Neil Anuskiewicz Date: Tue, 18 Aug 2020 10:32:23 -0700 Message-ID: To: =?UTF-8?B?THVpcyBFLiBNdcOxb3o=?= Cc: Dotzero , IETF DMARC WG , Kurt Andersen , Doug Foster Content-Type: multipart/alternative; boundary="00000000000050e77505ad2a47ed" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 17:33:04 -0000 --00000000000050e77505ad2a47ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2020 at 1:00 PM Luis E. Mu=C3=B1oz wrote: > On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote: > > Under 50% of companies have any DMARC record. Of those who deploy > > DMARC, > > about ~2% have p=3Dquarantine and ~5% p=3Dreject, though some industrie= s > > such > > as finance it looks like it's closer to 15% p=3Dreject. I'm sure these > > numbers aren't perfect but what you have likely isn't radically > > different. > > My numbers are inverted regarding quarantine vs reject, as I posted on > this list: > > On 30 Jul 2020, at 18:01, Luis E. Mu=C3=B1oz wrote: > > > > I am currently observing ~215.5 million domain names. Out of those, > > ~64 million have a seemingly _valid_ SPF record and ~113 million with > > at least one MX record. > > > > This is a current breakdown of the (valid) DMARC records I am > > observing over the general domain population above. This amounts to an > > adoption rate of ~1.7%. > > > > | p | count | > > | :--------- | ------: | > > | none | 2715614 | > > | quarantine | 238584 | > > | reject | 726045 | > > Numbers have moved a bit since then, but not much. I'm seeing 3:1 reject > to quarantine ratio across the board. > > > Why is adoption low? Is that a big problem? Why so few aggressive > > policies? > > Is that a big problem? > > DMARC can be quite useful even with p=3Dnone. This use case provides > insight on what's going on and sometimes, that's all that is wanted. > Moving to more aggressive policies require a degree of control on the > mail flows that not all organizations are prepared to exercise, IMO. > > Yes, I completely agree, p=3Dnone is useful. It's helped me help the clie= nt (I'm basically an IT freelancer) make sure all their email sources' DKIM and SPF's squared away. More interesting, DMARC's found things that have surprised clients. Wait, who's using ESP X? Some detective work and a few days later... Okay, it's the such and such office or sometimes even individuals. And there's oh right we do use Y. Let's get that authenticated= . So it's legit sources that need to be authenticated, semi-legit sources that either need to be authenticated and viewed as fully legit or told to stop and there's sources that are legit but have been running on autopilot. Let's think about whether we need this or what changes we can make to it. This aspect serves as a sort of internal audit of email sources and authentication. DMARC's been very, very useful for that. Then there's discovering spoofing sometimes, of course. Neil --00000000000050e77505ad2a47ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 1:00 PM Luis = E. Mu=C3=B1oz <dmarc-ietf.org=3D40lem.click@dmarc.ietf.org&= gt; wrote:
On 14= Aug 2020, at 12:47, Neil Anuskiewicz wrote:
>=C2=A0 Under 50% of companies have any DMARC record. Of those who deplo= y
> DMARC,
> about ~2% have p=3Dquarantine and ~5% p=3Dreject, though some industri= es
> such
> as finance it looks like it's closer to 15% p=3Dreject. I'm su= re these
> numbers aren't perfect but what you have likely isn't radicall= y
> different.

My numbers are inverted regarding quarantine vs reject, as I posted on
this list:

On 30 Jul 2020, at 18:01, Luis E. Mu=C3=B1oz wrote:
>
> I am currently observing ~215.5 million domain names. Out of those, > ~64=C2=A0 million have a seemingly _valid_ SPF record and ~113 million= with
> at least one MX record.
>
> This is a current breakdown of the (valid) DMARC records I am
> observing over the general domain population above. This amounts to an=
> adoption rate of ~1.7%.
>
> |=C2=A0 =C2=A0 p=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 count=C2=A0 |
> | :--------- | ------: |
> | none=C2=A0 =C2=A0 =C2=A0 =C2=A0| 2715614 |
> | quarantine |=C2=A0 238584 |
> | reject=C2=A0 =C2=A0 =C2=A0|=C2=A0 726045 |

Numbers have moved a bit since then, but not much. I'm seeing 3:1 rejec= t
to quarantine ratio across the board.

> Why is adoption low? Is that a big problem? Why so few aggressive
> policies?
> Is that a big problem?

DMARC can be quite useful even with p=3Dnone. This use case provides
insight on what's going on and sometimes, that's all that is wanted= .
Moving to more aggressive policies require a degree of control on the
mail flows that not all organizations are prepared to exercise, IMO.
Yes, I completely agree, p=3Dnone is useful. It's he= lped me help the client (I'm basically an IT freelancer) make sure all = their email sources' DKIM and SPF's squared=C2=A0away. More interes= ting, DMARC's found things that have surprised clients. Wait, who's= using ESP X? Some detective work and a few days later... Okay, it's th= e such and such office or sometimes even individuals. And there's oh ri= ght we do use Y. Let's get that authenticated.

So it's legit sources that need to be authenticated, semi-legit source= s that either need to be authenticated and viewed as fully legit or told to= stop and there's sources that are legit but have been running on autop= ilot. Let's think about whether we need this or what changes we can mak= e to it. This aspect serves as a sort of internal audit of email sources an= d authentication. DMARC's been=C2=A0very, very useful for that.

Then there's discovering spoofing sometimes, of cours= e.

Neil
--00000000000050e77505ad2a47ed-- From nobody Tue Aug 18 11:05:52 2020 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 D31DB3A099B for ; Tue, 18 Aug 2020 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 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, GB_PHARMACY=1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 dqvqn5WVncFp for ; Tue, 18 Aug 2020 11:05:47 -0700 (PDT) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 53F5F3A09A3 for ; Tue, 18 Aug 2020 11:05:47 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2177.outbound.protection.outlook.com [104.47.55.177]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QF900R7AU91HZG0@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 18 Aug 2020 13:05:25 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.18.180018, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.55.177] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TGv3PtoXgAUqDMxcd2g7jBsIZty2NI4EZX403uNZJkRCsYFpP6L4P3V3F0AcIzFFYhUcWUVwz2Dv6nUBs40uQ8dL5lagg36t25V0p9Xgd2kxMrwsLeBJJoM5TWPHCZk5BBUMwUkuoI4jLCgaG1HwK3rBMjwsMzMKQNluOgmEGN3rmWACozBOSpOtAce4gd8ZxNAfMQ8ffxDKwy1odsh3TC8I0ZLZArkdJqScNjl2ZYgEhhxweOixBr42jc4wPNJchiG4Mpj2Miw1y68loRa/RPdBZEhAcgfxeAdUyU3n+L6Rx1Pc5JJh5dMdpLtKS/zZ7jC3rTDP9BiQ283o3kBvBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E5UbmJQQGEd6qMKFsXmmtj6QDUJk99/WzMXBgYdwi7A=; b=FWXKYXMIGtABUDGAzJeRahdlujCMq6nTXlQIETqPws6fK3iPRI1pNgYCksngpl+ZVX8WR73leID2ZyNtytWfm+6vITltZ0+S/CAI1mxtALAj5XO+K1shvT7Ex6XvSXlkdamLhyv/Qw4KyBJuGPu+tBhGewbMfzGR+6Pq/dp4q+NnmUcOc/uButgunHtqZsqTum2fWWVt7UBFZ44n76BtD4kHy34k18N+22gCHH6gsBKokzvmmU3vzh7HVkhO24cBLzqhw+Vy59vsbjfcZT7y2DqHiG1FjEjFPA+EH8KuiQJRWf6hqncBHe+8hDYqQ8/j/vCQ7fiBIJTFAejLR70qwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E5UbmJQQGEd6qMKFsXmmtj6QDUJk99/WzMXBgYdwi7A=; b=MqQt/C7/THyYW1OktmaZqkCDpvz8xJSw2wL9JjaWQKQAV6WXIOzoDUNrjrksrlx0AAmF9zBuTMumlOV4Nd5wEuySBx9V5dpC+rsfahuozaDJo32uky5xSG9uvoJri1vPHRTXFIocNcc7s0jGwKFF9G8tx357HKC7T3WUA+kC4OU= Received: from CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) by CY4PR06MB2918.namprd06.prod.outlook.com (2603:10b6:903:13c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.22; Tue, 18 Aug 2020 18:05:24 +0000 Received: from CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::d873:6271:eb77:2ef7]) by CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::d873:6271:eb77:2ef7%6]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 18:05:24 +0000 To: dmarc@ietf.org References: <20200808023259.1D07F1E60C2D@ary.qy> <977bbb4f-c393-0314-df72-17f342f2f975@wisc.edu> <59f44f8b-9a7d-2dc2-37d9-ed6b0c40fb40@tana.it> From: Jesse Thompson Message-id: Date: Tue, 18 Aug 2020 13:05:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: <59f44f8b-9a7d-2dc2-37d9-ed6b0c40fb40@tana.it> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR07CA0005.namprd07.prod.outlook.com (2603:10b6:610:20::18) To CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR07CA0005.namprd07.prod.outlook.com (2603:10b6:610:20::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Tue, 18 Aug 2020 18:05:23 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5664a0d1-3194-4f55-59c7-08d843a14769 X-MS-TrafficTypeDiagnostic: CY4PR06MB2918: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: F7T+ZA4Pxe7eM613ZZAhyLFMvuwoO8/d0UPjtuRdezcxs1Un84Hl/MIZcg2wuHmyBhUwBs3mkX33Y1DjD41qu6FNp4FJhaDGra8eLG/+dDpTPbfeV4ZLQfiK8lxENi93D/uWSaHJUtjq2YoeGrheItjCVgOgQs1ZWvivp9EK9L6a8KOzn+60X0/P/ofymB892Qet5Bc/LxdT3QcScxsqgK3xVIWNuQbDUt8sVbebhq9VHReeXVW4dODyIwKa0kgCf/MhENGEuD9sdwy4XcscxsAvbbuow0lm5k8S9U/HXwi84z2JLPC4Xa1fzLQgv6T7Z94yg3pzbypr0wsSgxnS/XYP9Ya3H4osu0+fHd3J5A/aZtTGz6DaPuM+RV8nHDVwMu10wxNVAy/1s5+VdH6k3C0p+INvo3uFuB3yIO9OTtWMwkgRMnHAuGIuGOOvbyY0 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0601MB3668.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(366004)(39860400002)(136003)(6916009)(36756003)(66556008)(2906002)(5660300002)(8676002)(66476007)(31696002)(66946007)(86362001)(6486002)(75432002)(478600001)(6666004)(31686004)(16576012)(44832011)(8936002)(16526019)(956004)(26005)(786003)(316002)(186003)(53546011)(2616005)(83380400001)(43740500002)(130980200001)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: GA9NvxcwoYNdhvErkcokijc85UBOhqAcrpWbF9JARKTohxE1B82RKWAobqKxuUbNR7hARQ25EqpyOlpxT1ff+XAZuIHLhYw5XvYrFySnnQgAV8WvtBmY9WYxlsP4LyYLpeSQF7Qy2TLm97xcN44yYNMpGcjDQ5kzV348rHT3QPcNDYmsj3asId6nMTVLm50pT8/eIZLyWeyRayFCOcJ2nugACvsElTaWJY39cbqMmxiicQjrSLACuRZ13G3YGzXLC6eE/6viAbQ5Rd/a2XpE1EWP6i7gURk5kFtw67xccu52UF1jTMEih7DggBm0/0PVt5RleVzfHq2VsRrPmDh1s5hjVAXyqu1U1OrCHU278sbsmTi/SXcaY2L00ilbm4h/C6yQRErljmZf+Vky2KDfPmLJA9qE20Rl9KcaUaGRzgTMK0X2tItdlEc95JgPwG6R9vrKZR1Sr536A/cqcXu23KKFfdWehp2vMzyOx6ti/370yxImJOV9t3v2/eZOGYYMBxX46zA4+iB1fCo3SIQlyNvt8BEfxX2WBFt4oCkYorRFlNs24Ic0vrMYuvpy8coSbIZSCSAXfid+QE8IeFRLHvZp5gkMkVUN9pR4sHRJJFs/ZOgZqf2wEVHCgqz5/A4fxc1DeRuGtvzyNP2dJ+0ERg== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 5664a0d1-3194-4f55-59c7-08d843a14769 X-MS-Exchange-CrossTenant-AuthSource: CY4PR0601MB3668.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 18:05:24.2206 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7Q234jUwaUjiI+W7g7Gexvf8T4Ok5kEXRSUxL7xmb61r0+8x/PeaHJJjsw84rx1E/M0HpR7syq3JBuE7SXjZIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2918 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 18:05:51 -0000 On 8/18/20 3:54 AM, Alessandro Vesely wrote: > On Tue 18/Aug/2020 01:39:16 +0200 Jesse Thompson wrote: >> On 8/7/20 9:32 PM, John Levine wrote: >>>> We need spoofing protection for all of our domains without being told we're misdeploying. >>> >>> I would be interested to better undertstand the meaning of "need" >>> here. It is my impression that most people vastly overestimate how >>> much of a phish target they are. Paypal and big banks certainly are, >>> other places, a lot less so. >> >> (Sorry, I was on a much-needed vacation.) > > > Much *needed*? Oh, well... Anecdotally. My family can attest, if that helps ;-) >> Ok, that's fair, I should have realized that one was over-stated. *Need* would imply that domain-spoofing is more common than it is in reality. > > > Yes, domain spoofing is common. You don't need to be PayPal to be spoofed. Then, one can say it's an innocuous kind of abuse. Since you're not PayPal, it's just noise. Yet, in a perfect word, I'd opt to avoid it. Yes, I just can't prove it to the extent that the people saying we're "misdeploying" DMARC would expect me to. How do I tell the difference between a faculty member innocently using Gmail to send from their personal address within our domain vs. a bad actor doing the same to send spear phishing to a peer at another university? In my mind, I should just assume that it's a problem, or is potentially a problem, so I'd rather nip it in the bud by deploying DMARC on domains used by users. >> Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances. Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC). To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers. > > > Nice synthesis. They believe DMARC works as advertised. What does it take to believe that DMARC /could/ work as advertised? It seems like we're close. I am glad that you are pushing back (in the other thread) on the notion that DMARC shouldn't be useful for all types of domains. >> Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: >> >> * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) > > > This is a good idea even without DMARC concerns. Yes, and those departments that we have converted to subdomains seem to be happy with the result. It usually takes some convincing, however. People tend to have a strong preference to associate with the brand of the org domain (which is where we have our users). >> * People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed) > > > This sound just like an email-client configuration problem. It shouldn't be so hard. Gmail is the most common "client" allowing users to submit mail outside of our supported submission pathways. In theory, Google could make some improvements to Gmailify (to support more OAuth scenarios) and actively transition their legacy users to reconfigure their Gmail settings to properly use our domain, but it's not a high priority for Google (paraphrasing Brandon; hopefully accurately) It's not much different than people innocently using any random ESP to send newsletters from their personal address. Because all of these "clients" allow non-authenticated submission of our domain, users have come to expect it to work and they don't want to be told otherwise. >> The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports. > > > Why not? If they send to DMARC-compliant receivers, their aggregate reports should show records without the right MSA signature, not even failed, and foreign domain authentications only. That doesn't tell which users misconfigured their client, but gives a good idea of the level of user education one has achieved. Right, you only get metrics indicating a relative volume of users who may fall into various camps. It is complicated when the domain is also used for transactional mail; which is something that happens entirely out of our control specifically because DMARC enforcement wasn't in place when email was invented. This is where the DMARC reporting analysis services come into play, since they do a good job at identifying the ESPs (from the raw data) that are sending the non-compliant mail. But again, aggregate reports don't show the left hand side of the address, so they can't be used to identify specific users. To get that, you need forensic reports, or use SPF macros; both options having their pitfalls. > It should also show which domains users tend to use for submission, in case an organization wants to automate third-party authorization... Yes, aggregate reports are great at identifying which of our domains have successfully isolated transactional mail and have set up third-party authorization. If we see from aggregates that pharmacy.wisc.edu is using an ESP but have neglected setting up SPF/DKIM per the ESP's instructions, then we know who to reach out to and how to help them. They're already on the right track, anyway. That's the happy path. There are many other scenarios. Jesse From nobody Tue Aug 18 11:14:07 2020 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 2114E3A08EE for ; Tue, 18 Aug 2020 11:14:05 -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, 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 KPu1umwafO9g for ; Tue, 18 Aug 2020 11:14:03 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 5F0583A08EC for ; Tue, 18 Aug 2020 11:14:03 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id q200so4530253vke.6 for ; Tue, 18 Aug 2020 11:14:03 -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=N3enU1ojCBS+ZVIzcz/JmE+WkgEciQN+9q+lcG6uUBA=; b=BAMU5K6oGCiz3cuI7LSwrSE/DQYwcfAc7MV91S4hSyOsMVbz3C5K/AZk5xtRPaA/sd 3EqJP+DuxzlgEEWxa4malRj0Hq+w6dSJ4NAHJaK2nOat8l/ois/1CwwCTpTlKDAhG83y er8iraB+qYzKlV+wDlsQqNvvk/LgDlUNxWDEmRKM57PHr9N6xT6VFcNABURNbQSf2dNN eWC9jsR74voc3xyhkFglsAf0cg5fbCsfMxPNQUZ4LdIG/RTliywPsXtZ2c6AXVVZoCbw mYhr8TXVaVALmzL1dwtR4ISW2VfmAisU7x/+aWioKSgEbKy2ZoTF14JCYqU571D5QSoc 0qmA== 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=N3enU1ojCBS+ZVIzcz/JmE+WkgEciQN+9q+lcG6uUBA=; b=r/vWgduhxMSTWkIewmYrV1an+2fWex99DTa/uS1sArWMnaQzfo6EM613dPwjxl43kn Oyas4m97512Lkk/cVT+yloPNBw1zLsNzXbBjDupS4GDnL4/Gcr8wug+qGz8/F0N7nbyk Ax1S6qqC4rcWpst1bGT59jJbVXsM7VeIKekdeGP6pDPyFbAhuXCUYbdLoP8Nor5US+zW 5u9UJFpnOH0MRx0IBA4kLXGBPOcF/baLG+F3jx5pHu7OC33lt0EUUoSWY4SXrk3oA3E1 nvy4jQPLZ65oAiFPdn0lp5Cuvjln9UmbXGh7K40gNqL/B/HHtAB3kcIes0znN7rtACFs us3Q== X-Gm-Message-State: AOAM533qk1rO5JPpxmM1wLIFv1UuvQbeEaWWGNA6GvyYLLZJClmlyzFA 6NNj8HSXuCsmiEbg6wGTkEZlShwoC7l0sSZ+s4E= X-Google-Smtp-Source: ABdhPJwloArzlIR61Ux66YBmESN8mYHvSOnXTa9lVSb9VKtEHOamTolrQrWttT6K2DGfqOtyAbsGdky2UosdJ7nw4ug= X-Received: by 2002:a1f:f8c5:: with SMTP id w188mr12188833vkh.15.1597774442260; Tue, 18 Aug 2020 11:14:02 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <366e50ed8bda41cb879fa245e2d7c27a@bayviewphysicians.com> <20ad2821-f705-d8d6-2921-a419e1bd0554@gmail.com> In-Reply-To: <20ad2821-f705-d8d6-2921-a419e1bd0554@gmail.com> From: "Murray S. Kucherawy" Date: Tue, 18 Aug 2020 11:13:51 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000fef7805ad2ada6b" Archived-At: Subject: Re: [dmarc-ietf] Time for a change X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 18:14:05 -0000 --0000000000000fef7805ad2ada6b Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 6:09 PM Dave Crocker wrote: > DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) > that started outside. It underwent significant evolution in the IETF -- > not once, but twice. > > Actually, it wasn't. > > The constituent parts were separately proposed, during the same initial > IETF discussions, and the IETF said to go away and come back after > reconciliation. That work was done by an ad hoc industry team and there > was a complete spec and initial implementations before the IETF was again > approached. > Yep, I still have the t-shirt. > https://tools.ietf.org/html/draft-allman-dkim-base-00 > > (and note that in the working group field on the title page, it says > "pre-MASS"...) > > The work in the IETF was a refinement of a complete, integrated spec. > But it was quite a bit of refinement -- I would even say 'evolution" -- in comparison to how little SPF and DMARC changed before publication. -MSK --0000000000000fef7805ad2ada6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 17, 2020 at 6:09 PM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
=C2=A0DKIM was a synthesis within the IE= TF of two things (DomainKeys and IIM) that started outside.=C2=A0 It underwent significant evolution in the IETF -- not once, but twice.

Actually, it wasn't.

The constituent parts were separately proposed, during the same initial IETF discussions, and the IETF said to go away and come back after reconciliation.=C2=A0 That work was done by an ad hoc industry team and there was a complete spec and initial implementations before the IETF was again approached.

Yep, I still have the t-shirt.

https://tools.ietf.org/html/draft-allman-dkim-base-00

(and note that in the working group field on the title page, it says "pre-MASS"...)

The work in the IETF was a refinement of a complete, integrated spec.

But it was quite a bit of refine= ment -- I would even say 'evolution" -- in comparison to how littl= e SPF and DMARC changed before publication.

-M= SK
--0000000000000fef7805ad2ada6b-- From nobody Tue Aug 18 12:34:34 2020 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 F17CA3A09DF for ; Tue, 18 Aug 2020 12:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 1o52IWPd8zQP for ; Tue, 18 Aug 2020 12:34:30 -0700 (PDT) Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 228783A0994 for ; Tue, 18 Aug 2020 12:34:30 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QF900220YDG7NG0@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 18 Aug 2020 14:34:29 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.18.192419, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.58.168] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4aeE/zYSbTmuA4TGbIOn8euZeCzBdJ8b0UAy+Qewf1SGxMuyMw7ipRoppugHGM9mXUKcVrIyI/VXh7hHy488lvKiVHpzHbeyN644j3//CEFQukwihxNcDEYEQ378EvBsTdB++mQtQPvWi3eL6p/khUIE8qJpuIeM01RF9ljUZyAXX2aVWlklImyzVZsaDV+CyLgXTlv7FsclpZVk5UQs/dkTmpdXEs6noDb41GSyKhcZnHYTo3C8oavPTqpAOTk630f9t1RM5ItWhZ4NxjxXKKLdD7wOgczZIikwsOvOu8TWw+Egwc77wa2u2ASa+HYCOft6CsZ/xbXZl+m+joBQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2z+tQDj80iZmQKSAA84ZaGMnGI4uRaSYP4J7hiDbKRY=; b=DCRSlEHckED4iPMRWq3NPaa02KxgEtVR1XClzw3BrInElifC4Qk1NiS1EbCjp/bFw5Sdc75fbeqNw0GCU5tbAMQr9TSDi47bs4n0GYOK0jq4fqJ2azM+OHsHcQTNNAlXto99RCm870ITv7hcH4LHmsDgAzg1VY36PVOQAvJ/7dbKrOraxWG+hFpJoOd4fXiimvgkan5X8r897zftc+mxifR3vImj7eZmf7Om5F7W+SsU2bkCm8XRAioyPjf+VkZUlDpNJCH3s3htxhyCG/4TJxmvd9AnIWcd6l+hzvJGr1IoR/cYT03cc2UBz428a76dXBVfjsHVi5SdkA8m03yVew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2z+tQDj80iZmQKSAA84ZaGMnGI4uRaSYP4J7hiDbKRY=; b=KwgNYJ3pikzbqb9YjCSoVVJraxEvIuSSij5WaxWTo2KIPphRRjpS4k+gKhauDc1DSvJu/bj7nZbk441dEnjmeaAycuHtJI+cvBL337E/NzfZL/lR8fZWQfOINHDS2lVXOrr0on5m2kuzGgQaIgJerUPakv5OnVpIkpDKr3EExfY= Received: from CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) by CY4PR0601MB3748.namprd06.prod.outlook.com (2603:10b6:910:95::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.22; Tue, 18 Aug 2020 19:34:27 +0000 Received: from CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::d873:6271:eb77:2ef7]) by CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::d873:6271:eb77:2ef7%6]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 19:34:27 +0000 To: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> From: Jesse Thompson Message-id: Date: Tue, 18 Aug 2020 14:34:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR16CA0016.namprd16.prod.outlook.com (2603:10b6:610:50::26) To CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR16CA0016.namprd16.prod.outlook.com (2603:10b6:610:50::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18 via Frontend Transport; Tue, 18 Aug 2020 19:34:27 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1294f11c-a8f0-492d-7d9d-08d843adb862 X-MS-TrafficTypeDiagnostic: CY4PR0601MB3748: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Q2uUtAzmFJoNvSiLzjH+J9yFK0wxYcTzUKtLTnMWKg8raMxLUoSaA52RX7QogVbZ9r4RxsL1A/7NomSg7sszC/S9JfDjRbuq7l56AV/nDIxA0Y7J3SqusyBldkAwVbpcGMAbf2NqfXI19EwyuPVftrL5e/7ZAqMhGCilT7Sjv6A0OEjOMsXtDnE419XfAiM3N/Qt6gCBj1RlZPQiXnDHws3/FpBj+jtpmOGcvO5ue+V5v0sOuGo/vyJdO8RCvb/2szaOmdSp/C+WE0oSKo6MyBhryw9TnDCISgfFjUZiVwrVt696XFxwV8QgcAKKOc2GPCHWTDI278TMiae6p9EUGxMf1fNfNkKlyOwt4UfGmzUbsMvfHvTf2/RDweHJHVXM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0601MB3668.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39860400002)(136003)(396003)(346002)(2906002)(6666004)(5660300002)(86362001)(6486002)(31686004)(956004)(2616005)(16526019)(186003)(83380400001)(16576012)(316002)(786003)(26005)(31696002)(44832011)(478600001)(53546011)(6916009)(36756003)(8936002)(66946007)(66476007)(66556008)(75432002)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 6KISHyNM2jtOrjSrR5pYSLbeLMScAI1ixkKYb3mlQyXJjDxZzA3OL/ohxI2MfXX65X63aoHLjOEMWdlUdLJ+V2q7tQ4femxWjxs49FCOusjSpAqVrZpqSJoshQJlV82s5XvfQlSwXDWvaNnNrXxPFu89Vq8rOAmBTzid243s53JHIlPbnRYHJqUad/rGvbxQQ8xij0nKT9afleooTilNJvEwM0d0wJWEmP+0zKHQegj1+n41NI+exJk0V6nqRGeEOlbD3xQrnQCGeFJTSk8DKsPOqG7fM63SqJUMIIosMeK/AF/hM+KiCd9giDnP5fJREZLZMUSwNXuzv8ukiD2OmKHGrxBMKyxnW60bjDVsBbaHxCLwLUToFbhOjyFblFNf9iTwGydNeGpDy1/mSdyBa6Fo8ZIlfXt5eRmv89ncJ7rJ0JMrt0qiDhhqgSj+oD9Y69/f7vgiB2sWainwL90SXWt0nZEYQF6enWFxIJtxUvt2laSr2F8+RpC2lSFGx3+Alq5t0sSDCEy94ditpqdg+7RFIzVi43GY+KAugS9geIMxHhTohhPY1yXNjYjuLLnLDcf4vZw0FEd5A9WY35oNam1wMqdjU8zgV7wkGDOtSR2/Ov9ztFQMqSWjExVhlHdLt9Lr+X6vrAUKe2QdilY4Nw== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 1294f11c-a8f0-492d-7d9d-08d843adb862 X-MS-Exchange-CrossTenant-AuthSource: CY4PR0601MB3668.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 19:34:27.6529 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9HM6xpSIAmuLnDYoXKr2qxFJ5GyVcDVYP5ytqfjJGKonlyYH3X8oi3OhS3ZFDjiR3q6Ze5PBwT0lU1IcbeY2jg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0601MB3748 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:34:33 -0000 On 8/13/20 4:53 PM, dotzero@gmail.com wrote: > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years ago it was difficult to find vendors who were willing to deal with DKIM and able to do a good job in implementing. The common mantra was "how does this fit into my business model". These days I would consider it table stakes. DKIM, DMARC policy conformance, or any practical email functionality are rarely considered in procurement decisions. Only recently did I manage to get some of these requirements into our organization's RFP templates. It really hasn't made any impact on procurement decisions, which are made by people who don't understand the nuances of email to the extend that they can tell if the vendor actually meets the requirements. Even if I were included on the evaluation team for every procurement (a job I do not want) it would be rare that lack of DKIM support would be enough to weigh negatively on a decision. People like me only get called in after the system is deployed in production and they run into problems getting email delivered. For one recently-procured (inventory management software) vendor, I had to coach a poor sysadmin through how to set up Postfix to relay-rewrite their own application's email so that it wasn't able to outright spoof (for lack of a better term) the address of any end-user-free-hand-inputted address. Their own app dev team didn't feel like it was important enough to learn about DKIM/SPF/DMARC and kept confusing the changes they needed to make for email authentication with TLS 1.0 deprecation. "It's in our next release" they kept saying. Companies like that will just check the "we support DMARC" on the procurement form because they don't know enough to understand that they don't. Jesse From nobody Tue Aug 18 12:43:14 2020 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 645183A0B3D for ; Tue, 18 Aug 2020 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 gCmUWrfnEvcC for ; Tue, 18 Aug 2020 12:43:07 -0700 (PDT) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 1BF093A09D8 for ; Tue, 18 Aug 2020 12:43:07 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2171.outbound.protection.outlook.com [104.47.56.171]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QF902HHZYREELE0@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 18 Aug 2020 14:42:51 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.18.193917, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.7.23.5750001, SenderIP=[104.47.56.171] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=POZZwD2fD1pLleSYDEFpKxvxsaJ9hI2BbGqTQsHo8psdNi5QKpDOsZIN/JnFpxuB+Y4eT1m7+2Z0/+NLAJCak1kSZ/VCCFWSDRZLR6Pk3dtNQSPFPYW2dyzH9lrBQ24PkARJLHgbvbi7J+NGrhEZBZyp1DlXZNT5+fkMLPl3+op9wvEz1sqO3HVI96QJz/iBPGywzKRtFpEIF5zCk1IsqYPgAMoYRHFaTiZAdP1JgWLrwTbin4drFCD+hmhfAZyREPPTrKq2/um7t7/qPSihksXrUAtzJdXTav17SyH0ni+FKsyQ3nab9KYtXllIyT4Zow7Q71ZXRr2hpHBtNngRaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pt7mRNuEjph1KeAWzKMFOAQ6ppbnedmpjNFFoiCpqSg=; b=TJ8JpVgbO64dqIRrqsiUL3/YbI0VDymmofnj5R6wIZEbBZpBF/mpDm4O1vqJtciSvnXDLnHFB2DKB/PSdR/edyFn+WV7yMO6n4OnPeBjRexCMDfGvOK2ahJdRGeORzu3m654W0CdChw9xfdNbHxGUfvMjFMDVH8wOfX3kkmKpuDjLSrb8zi1a74mAdiBaCMsKkWG+zqGrrnyOJaMu/sr0Icv6VYPSG10/jXUKutPxQ8cd6uzLtopDR65tV8rYWHfJh78mJfW3x7EsaqbyOg5g8AEsWsCeoHh+Zcu43EEEjHbOxtdZmIPtVHaDs13eOyqxHSdL7iJJZE3cEgNX/I8Qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pt7mRNuEjph1KeAWzKMFOAQ6ppbnedmpjNFFoiCpqSg=; b=mwkK2PtWKLoRTgnoNJSdFL/Hn/DPkEd3UvqY7Ye4N6uwI5B7fworcil/7r31Sh/l9LSgU5ARKEb0ByuYdgs1n+lPXBlH/wD2YH+i065OFtKApihGQL21rtVQ6FlwpeLAIDNPVsAAZwPvaOenGA0ZtRJNbCo0PaV1qiAjMAR9tkg= Received: from CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) by CY4PR06MB3144.namprd06.prod.outlook.com (2603:10b6:910:57::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Tue, 18 Aug 2020 19:42:49 +0000 Received: from CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::d873:6271:eb77:2ef7]) by CY4PR0601MB3668.namprd06.prod.outlook.com ([fe80::d873:6271:eb77:2ef7%6]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 19:42:49 +0000 To: dmarc@ietf.org References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> From: Jesse Thompson Message-id: Date: Tue, 18 Aug 2020 14:42:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0a1 In-reply-to: <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR10CA0027.namprd10.prod.outlook.com (2603:10b6:610:4c::37) To CY4PR0601MB3668.namprd06.prod.outlook.com (2603:10b6:910:91::31) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR10CA0027.namprd10.prod.outlook.com (2603:10b6:610:4c::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Tue, 18 Aug 2020 19:42:49 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: eddb2241-0e15-49fb-79b5-08d843aee381 X-MS-TrafficTypeDiagnostic: CY4PR06MB3144: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: u50UAWzkxqxHp6On0u+NS+7WbNApfGcFRGaU834sYzH4RAbxo7PSJ8Rni+3zrN/2cBr60atJ5AEhD0xTx10CZl+5SAcFNF/u3EuoLByZ5C3sdeHYxRQHPnG+SdsmgsT9EYLDQQMEhJnz66ZcfoFtUrdN49cO26+S1wGoxb/afixuqvnhTfhZDPl750ZNmjXn3lO1KoLK+j0QRryXWa6XOhwkHlJNXMdCgKIdD/4mQ6l3GaVX/2UAqfcbGTObRQ6mVM8PuEhZuKlMnJcAyVpYwKsm4V7EVVzC7exILYtsYMZsIpRDecAs+QJvmi2eVKlzYD2MLPopLz/9olImtysOb7WeV1mc4hACD2OV5ymKPuigH5UPsTXfk4LYc9KuwIKz X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0601MB3668.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(396003)(346002)(376002)(36756003)(16526019)(75432002)(956004)(186003)(31686004)(4744005)(26005)(2906002)(5660300002)(44832011)(66574015)(2616005)(8936002)(83380400001)(6666004)(16576012)(316002)(66556008)(66946007)(6916009)(86362001)(8676002)(31696002)(478600001)(53546011)(786003)(6486002)(66476007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: kRNmXundAop29nad0XJWYI7GFj3YLt5bweHkihtqG/VlQYz5cDdFdpdAEzq5YpKjpkNm1LQXHYuJt7/BsdLtvryGscea5Vb2CDlN0fCIXY6ixgz0sSnMPtidC7bqHi9XMXIv+3T9ezqrDZnNLikkPiH/mFpmOpl75Vknt/gIWya5JWJ6/GoD39sSAiVggq/MlWg1a/E+v84UYIiUDP3X0PC2z/oaJtGQ+X7B5fodRB151o5AaMa/MHL3KePjdJ+Wno73fEzkyN3Ygbwu/EhhY3ksq0rsiUJcluoZ1RxAIyXZoVXdB0UNFBG8bZuP9gy66mj9nxmi9UTP9XZrEC5p0Jy5IFgWLDrWTeAkouNsdhG8tEdjgZZ2mjXn8OeyVOy5BncvRwoEEYH4E9/t3xiQHGuVMiQqHSMCbaqqVZUwY8qo2J4g7U3jWpOrZrW7uZMYOrojEORsbKVNugqYq8BR2sPGnNa54ZAAEOs2t0+dRjFPvOrkiNlRfmcEIrUJIW5AXKgfC/KEqIAHQiz2jt+mwvL7tChTgUMO27S45a1wyyCP4ZUsnksIKu2AIUrywuoCTjRLp0w1T2d01XH8agJdO9PeIoHqHYCTxbE68on/+DXRYLFnASx8RjBaflrtyUxNYBNtNK3jpCl++lUA7tJG+w== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: eddb2241-0e15-49fb-79b5-08d843aee381 X-MS-Exchange-CrossTenant-AuthSource: CY4PR0601MB3668.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 19:42:49.5387 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: aHn1lQC/8iYtI6hxkYwMHEX4wmsJXQkiWyYPYaXVkweZhN1kCcR0L+s4VebskSEUwGWL2DT9WE09Fa9IcuUXuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3144 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:43:10 -0000 On 8/17/20 3:00 PM, Luis E. Muñoz wrote: > DMARC can be quite useful even with p=none. Agreed. People commonly request that we accept-list their IP/domain from inbound spam scanning. We now tell them to send DMARC-aligned mail (SPF or DKIM pass, aligned with From), and we'll use that as criteria to accept mail from the domain, regardless of what policy they actually publish. Jesse From nobody Tue Aug 18 12:49:02 2020 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 DFD463A0A3B for ; Tue, 18 Aug 2020 12:49:00 -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 (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDTOVHIYL2LH for ; Tue, 18 Aug 2020 12:48:58 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 7E1E93A09EC for ; Tue, 18 Aug 2020 12:48:58 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id s15so10164197qvv.7 for ; Tue, 18 Aug 2020 12:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=ZpqtUBup9f3kCNfBSxQoxyeq2hTE8zvM1FFPoDRG2Pw=; b=C1Y2443VBYenXTtKE6DlVE52o4fTprCpsnFdXo3JLjqUn6WXWq2a7e7ovpn+iv/lLK h/vME7HXIitxqHCCZsZT90On0L5PIiRazYDpm8MROOZMC6w0Ii62UCkLl0kybWC70uV4 Xw7n/v8csTc0ZIAw1++mGnC4QSlSoTitJ7J7HtPn1iPFSCZQ1ekf+JCadH15SAhJFtZ+ 1Sjry/yThzGNPWhzCFBabASk2+O1GJMR58WKJiOLvJvOS0ws1zbQ4FxjiOYxxDhAhRC0 smBsXRNCPWPUGXJ7ZLfsp2i4QyzKGt7XQCeMl7nKW5UewqSEuYdjWCZ1bljq1bwOV+xx YYAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZpqtUBup9f3kCNfBSxQoxyeq2hTE8zvM1FFPoDRG2Pw=; b=MFEh59ddx+lBAOaztI14q3OcughvH3rnC54rOgTkT0mrcTBhnlUjVZ1t+LVDlw7SVM uH7LIS9DaefnJ8w9xaqBtHvINtXpULHYKYgZ5/EOpwrroRy5qwF5goQvKmIcuap2QKFF yEC2EW61aJnbFn//mtToXrQdtX/dp2jw/N8Oe7h2E37T7lLjpoHQEu/jwGg8F8QWrn+I D12qIVuX2YXeyRN7Tw9oRqoS4qoE6xtDL2oYY/6z/vBDJjuM7hsfWEywgVQ4P5w8Pwlk qoQm5v4oDvKGdNZA0Feng4BpZkHM1KVa79n3D0IVSXhkj4BCN4C4+rmLM/a0q7xxx7Zz 0XQA== X-Gm-Message-State: AOAM531mqJvvXLCTfz9lUdmg8HuM3ifaNkMnm4a8CM/QMOR39IhXlSgD heXPMOJZwpFmD+2roBX+Cka12SjPBANC6IVSnS9hWDrryoromA== X-Google-Smtp-Source: ABdhPJzWJ0k9vDlK1xPY26UsRSGBL158h0LO4tKBK0Jl4NNLzn606smo6ggLEjQmTBPltK+3wFrbBpLARm4wTCFYZw0= X-Received: by 2002:a0c:ab16:: with SMTP id h22mr20876447qvb.72.1597780137084; Tue, 18 Aug 2020 12:48:57 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Tue, 18 Aug 2020 15:48:46 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000080216505ad2c2d5c" Archived-At: Subject: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:49:01 -0000 --00000000000080216505ad2c2d5c Content-Type: text/plain; charset="UTF-8" Greetings. I want to revisit something that was originally discussed in the "non-mailing list use case for differing header domains" thread, because I don't think there was any sort of consensus reached, and because I think it's pretty important in determining whether or not the proposed document will achieve any level of successful adoption. If this topic was discussed in a different thread, please forgive me for beating what I'm sure must be a dead horse. Section 5.2, Determine Handling Policy, reads in part: The steps are as follows: 1. Sender: Extract the RFC5322.Sender domain from the message. Query the DNS for a DMARC policy record. Perform remaining, numbered steps, if one is found and it contains an "snd" tag. AND From: Extract the RFC5322.From domain from the message. Query the DNS for a DMARC policy record Perform remaining, numbered steps, if one is found. Terminate: Otherwise terminate DMARC evaluation. 2. Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature. Crocker Expires January 28, 2021 [Page 6]Internet-Draft DMARC July 2020 3. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check. 4. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment. If one or more of the Authenticated Identifiers align with the RFC5322.From (or with the RFC5322.Sender field, if permitted by the domain owner) domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures. 5. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 6.3 for details. The race condition here is in item 5, "Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner", specifically when both the Sender and From headers are present, the domains are different, both publish DMARC policies, and only one of the two domains passes DMARC validation checks for that message. In that case, the question of "Which policy to apply?", or more precisely, "Which validation check should be honored?" will really matter to the disposition of the message; if, for example, the From domain is at p=reject and fails, while the Sender domain publishes a policy with the required "snd" tag and passes, should the message be rejected or accepted? When I first posed this, the answers I got were along the lines of "Receivers will do what they want, like they've always done", and that's certainly true if the behavior isn't mandated in the RFC (and maybe even if it is). That's cool and all, but doesn't "Receiver's Choice" risk continued, or perhaps even worse, breakage of the primary problem that this document is trying to fix? Unless I'm misunderstanding things, a primary idea behind the Sender header with the DMARC policy is to make things easier for intermediaries, like this mailing list. I'm posting to this list from a domain that publishes a p=reject policy, and so to allow my post to make it to all subscribers, the MLM rewrites the From address something that looks kind of VERP-ish (todd.herr=40valimail.com@dmarc.ietf.org), DKIM signs it using the ietf.org domain, and sends it along with a MAIL FROM domain ending in ietf.org. If this change becomes standard, then I imagine that future mail sent through this MLM will look something like this: From: todd.herr@valimail.com Sender: list@dmarc.ietf.org DKIM-Signature domain (d=ietf.org) Return-Path domain: ietf.org There may still be a DKIM signature header with d=valimail.com attached to the message, but DMARC for valimail.com won't validate because of the footer attached to the message, and so we'll be in a situation at best where the Sender DMARC check passes and the From DMARC check fails, with the From domain being at p=reject. What if the receiver bounces the message because of this failure of DMARC validation on the From field? We're playing "Receiver's Choice" here, so there's nothing to stop them from doing so, right? If the spec doesn't mandate behavior in cases where there are conflicting DMARC validation results, then it doesn't seem to achieve the goal it set out to accomplish: If: * the original From: field is covered by DMARC, and * the message goes through a Mediator that breaks aligned authentication, and * the receiving DMARC engine only uses the original version of DMARC, then it will produce a DMARC fail. It does not appear to be possible to handle this case safely, except by modifying the From: header field so that it does not trigger an alignment failure. Unless there comes a time at which concern for this case is eliminated, Mediators will continue to have to deal with this, such as by modifying the From: field. To that end, this version of the specification has been modified, to make Sender: an _additional_ DMARC alignment possibility, rather than an alternative one. In the absence of spec guidance that states, for example, DMARC validation passes override failures when conflicts occur[*], I guess an answer here could be universal adoption of ARC, to mean that all mediators record authentication results in ARC header sets (something this MLM doesn't yet do, as far as I can tell) and that all receivers ingest and make proper use of ARC header sets (for some definition of "proper"). However, with a universal adoption of ARC, is there a need for additional DMARC alignment possibilities? [*] Such guidance would likely open up quite a number of abuse vectors, so let's not speak of the idea of inserting such guidance for now. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 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. --00000000000080216505ad2c2d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I want to revisit some= thing that was originally discussed in the "non-mailing list use case = for differing header domains" thread, because I don't think there = was any sort of consensus reached, and because I think it's pretty impo= rtant in determining=C2=A0whether or not the proposed document will achieve= any level of successful adoption. If this topic was discussed in a differe= nt thread, please forgive me for beating what I'm sure must be a dead h= orse.

Section 5.2, Determine Handling Policy, reads in p= art:

The steps are as follows:

   1.

       Sender:   Extract the RFC5322.Sender domain from the message.

          Query the DNS for a DMARC policy record.

          Perform remaining, numbered steps, if one is found and it
          contains an "snd" tag.

       AND

       From:   Extract the RFC5322.From domain from the message.

          Query the DNS for a DMARC policy record

          Perform remaining, numbered steps, if one is found.

       Terminate:   Otherwise terminate DMARC evaluation.

   2.  Perform DKIM signature verification checks.  A single email could
       contain multiple DKIM signatures.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       value of the "d=3D" tag from each checked DKIM signature.

Crocker        =
         Expires January 28, 2021                [Page 6]
Internet-Draft =
                   DMARC                        July 2020

   3.  Perform SPF validation checks.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       domain name used to complete the SPF check.

   4.  Conduct Identifier Alignment checks.  With authentication checks
       and policy discovery performed, the Mail Receiver checks to see
       if Authenticated Identifiers fall into alignment.  If one or more
       of the Authenticated Identifiers align with the RFC5322.From (or
       with the RFC5322.Sender field, if permitted by the domain owner)
       domain, the message is considered to pass the DMARC mechanism
       check.  All other conditions (authentication failures, identifier
       mismatches) are considered to be DMARC mechanism check failures.

   5.  Apply policy.  Emails that fail the DMARC mechanism check are
       disposed of in accordance with the discovered DMARC policy of the
       Domain Owner.  See Section 6.3 for details.

The race condition here is in item 5, "Emails that fail the DMARC mec= hanism check are disposed of in accordance with the discovered DMARC policy= of the Domain Owner", specifically=C2=A0when both the Sender and From= headers are present, the domains are different, both publish DMARC policie= s, and only one of the two domains passes DMARC validation checks for that = message. In that case, the question of "Which policy to apply?", = or more precisely, "Which validation check should be honored?" wi= ll really matter to the disposition of the message; if, for example, the Fr= om domain is at p=3Dreject and fails, while the Sender domain publishes a p= olicy with the required "snd" tag and passes, should the message = be rejected or accepted?

When I first posed this, = the answers I got were along the lines of "Receivers will do what they= want, like they've always done", and that's certainly true if= the behavior isn't mandated in the RFC (and maybe even if it is). That= 's cool and all, but doesn't "Receiver's Choice" risk= continued, or perhaps even worse, breakage of the primary problem that thi= s document is trying to fix?

Unless I'm misund= erstanding things, a primary idea behind the Sender header with the DMARC p= olicy is to make things easier for intermediaries, like this mailing list. = I'm posting to this list from a domain that publishes a p=3Dreject poli= cy, and so to allow my post to make it to all subscribers, the MLM rewrites= the From address something that looks kind of VERP-ish (todd.herr=3D40valimail.com@dmarc.ietf.org), DKIM signs it using the ietf.org domain= , and sends it along with a MAIL FROM domain ending in ietf.org.

If this change becomes stand= ard, then I imagine that future mail sent through this MLM will look someth= ing like this:

=C2=A0 Sender: list@dmarc.ietf.org
=C2= =A0 DKIM-Signature domain (d=3Dietf.org)
=C2=A0 Return-Path domain: ietf.org=

There may still be a DKIM signature header with d= =3Dvalimail.com attached to the message= , but DMARC for valimail.com won't = validate because of the footer attached to the message, and so we'll be= in a situation at best where the Sender DMARC check passes and the From DM= ARC check fails, with the From domain being at p=3Dreject.

What if the receiver bounces the message because of this failure o= f DMARC validation on the From field? We're playing "Receiver'= s Choice" here, so there's nothing to stop them from doing so, rig= ht?

If the spec doesn't mandate behavior in ca= ses where there are conflicting DMARC validation results, then it doesn'= ;t seem to achieve the goal it set out to accomplish:

<= div>
      If:

      *  the original From: field is covered by DMARC, and

      *  the message goes through a Mediator that breaks aligned
         authentication, and

      *  the receiving DMARC engine only uses the original version of
         DMARC,

      then it will produce a DMARC fail.

      It does not appear to be possible to handle this case safely,
      except by modifying the From: header field so that it does not
      trigger an alignment failure.  Unless there comes a time at which
      concern for this case is eliminated, Mediators will continue to
      have to deal with this, such as by modifying the From: field.

      To that end, this version of the specification has been modified,
      to make Sender: an _additional_ DMARC alignment possibility,
      rather than an alternative one.
In the absence of spec guidance that states, for example, DMARC valid= ation passes override failures when conflicts occur[*], I guess an answer h= ere could be universal adoption of ARC, to mean that all mediators record a= uthentication results in ARC header sets (something this MLM doesn't ye= t do, as far as I can tell) and that all receivers ingest and make proper u= se of ARC header sets (for some definition of "proper"). However,= with a universal adoption of ARC, is there a need for additional DMARC ali= gnment possibilities?=C2=A0

[*] Such guidance woul= d likely open up quite a number of abuse vectors, so let's not speak of= the idea of inserting such guidance for now.

--

Todd Herr= | Sr. Technical Program Manager
e: <= a href=3D"mailto:todd.herr@valimail.com" target=3D"_blank">todd.herr@valima= il.com
p: 703.2= 20.4153

=


This email and all data transmitted with it c= ontains 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, co= pying or distribution of the information included in this transmission is p= rohibited and may be unlawful. Please immediately notify the sender by repl= ying to this email and then delete it from your system.

--00000000000080216505ad2c2d5c-- From nobody Tue Aug 18 14:53:58 2020 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 86B243A0DD6 for ; Tue, 18 Aug 2020 14:53:56 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=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=iecc.com header.b=QLeWpYAs; dkim=pass (2048-bit key) header.d=taugh.com header.b=kqwFp7ne 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 OChbFUcuZLuc for ; Tue, 18 Aug 2020 14:53:55 -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 9D17B3A0DD7 for ; Tue, 18 Aug 2020 14:53:28 -0700 (PDT) Received: (qmail 85724 invoked from network); 18 Aug 2020 21:53:26 -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=14eda.5f3c4dd6.k2008; bh=hgzgR/qYQ90vgY2LwmbZ6N0Kaz7IO+B+Y5RwSJSWBGg=; b=QLeWpYAs6k2vq2tYKx60ptf4J33ltRsfJslQdNuKZZkarkwmkrgBJkYVNXSDfyZQevX0lftrv6km96dIP8a+gi5wwHhw2F3wrj93mfzAeTxuo72STCuEVlXHsuggjzGP0wi6NO8w1nQLzjW+4kuMNDv1R+lYfXFtKDOxr9AR/iT3ZJIx00NVNbLAdCwjS/V+dZmri3WkZ56fxaxHuyrTT5or5B8yq9nphlP/wS+GdZd1BMnpB16yOZMZmAUKavEGIgkOie7Xcw2GpcasMyWm3SvIRlExDGfpp9sM8w4r9jbQRrL+FD8NPe44I1fAzbegvdIWKkpMi293/Z6kPpk+7A== 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=14eda.5f3c4dd6.k2008; bh=hgzgR/qYQ90vgY2LwmbZ6N0Kaz7IO+B+Y5RwSJSWBGg=; b=kqwFp7ne/nqn8sqtvrnLfvONxgECrG9XO7OxwT1NOQjnedGcAV9SIRaBEFd4ihJouBnIoOQs7VJSo8tJn6q8MpDZos4eXGf8eN5KpknwqL0+TnkRIdYM8YGeIYo5RctlWsMNURWCgxtZeFC8X6ebMWDCqDhjX/AGhjlPykq6vhk6/OgIFNZZlvWdJ9rUr3dn63MbgUJerz3hM93bY+KulFRtOicOkUjvbjSjitBpnMZwgfdQMSIQvYYmCRI8N4vy8UBetNgzmg21kywV+HqidD0NonyLQrj9deFyNaH9g/YLxU3znPby3MS0cQIge4u0T+X4fXkOD8DhnXo6aHhVKg== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 18 Aug 2020 21:53:26 -0000 Received: by ary.local (Postfix, from userid 501) id 0CCFE1EEC88D; Tue, 18 Aug 2020 17:53:26 -0400 (EDT) Date: 18 Aug 2020 17:53:26 -0400 Message-Id: <20200818215326.0CCFE1EEC88D@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:53:57 -0000 In article you write: >[What to do when From and Sender DMARC have different results ?] > >When I first posed this, the answers I got were along the lines of >"Receivers will do what they want, like they've always done", and that's >certainly true if the behavior isn't mandated in the RFC (and maybe even if >it is). That's cool and all, but doesn't "Receiver's Choice" risk >continued, or perhaps even worse, breakage of the primary problem that this >document is trying to fix? You're right, the sender tweak only makes sense if the sender result is preferred. Otherwise a sender result can only make it less likely that a message is delivered, and that wouldn't be very useful. As always, a successful result doesn't mean not spam, it just means it didn't fail DMARC. I expect some non-normative advice would be helpful, pointing out that this is useful for third party senders, and recipient systems will have to come up with their own idea about which third parties are credible. It occurs to me it's likely to be the same list of third parties whose ARC seals are credible. R's, John From nobody Tue Aug 18 15:05:20 2020 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 CEE833A0E12; Tue, 18 Aug 2020 15:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_BLOCKED=0.001, 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 MDu_gsaqwL4H; Tue, 18 Aug 2020 15:05:16 -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 3AFAA3A0BF4; Tue, 18 Aug 2020 15:05:16 -0700 (PDT) Received: from [192.168.0.101] (c-73-158-217-238.hsd1.ca.comcast.net [73.158.217.238]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07IM82dk006503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Aug 2020 15:08:02 -0700 To: Todd Herr , IETF DMARC WG References: Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 18 Aug 2020 15:05:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 22:05:19 -0000 On 8/18/2020 12:48 PM, Todd Herr wrote: > The race condition here is in item 5, "Emails that fail the DMARC > mechanism check are disposed of in accordance with the discovered > DMARC policy of the Domain Owner", specifically when both the Sender > and From headers are present, the domains are different, both publish > DMARC policies, and only one of the two domains passes DMARC > validation checks for that message. In that case, the question of > "Which policy to apply?", or more precisely, "Which validation check > should be honored?" will really matter to the disposition of the > message; if, for example, the From domain is at p=reject and fails, > while the Sender domain publishes a policy with the required "snd" tag > and passes, should the message be rejected or accepted? So, yeah, the text for that needs significant changes.  Thanks for raising this. I was under some time pressure and merely copied that from the existing DMARC spec.  In fact, I think that text in the DMARC spec isn't very good, so this would be a nice excuse for thinking through reasonable language carefully. The basic issue, which creates the language challenge, is the receivers actually can and do do whatever they want.  Language that pretends to dictate receiver action for this is unrealistic. So the language should be cast in terms of the semantics of the information it is tossing into the receiver's analysis engine, rather than claiming to dictate receiver disposition of the message.  IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 18 16:14:19 2020 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 8A9863A0F31 for ; Tue, 18 Aug 2020 16:14:18 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 A77_rwN_-CHY for ; Tue, 18 Aug 2020 16:14:15 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 7DD023A0F33 for ; Tue, 18 Aug 2020 16:14:15 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id e5so16476558qth.5 for ; Tue, 18 Aug 2020 16:14:15 -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=8CZfAYlAeROd1jqgnJ7XNGSl4fZK8EAJUVhVMc5877U=; b=o/A7I0xomCmlhFLkkk4ZugumJL6bmjWSWoGWlm5O2aM/bccKJ3kwWEcNkLsfa9YLs9 8PryRtXv/wo/iYBAljKBfgLh+tFJkVbLuaJRYiJi4hFY+585HVx2bgfrn/cxbhZxJTLg IJcPoiy97MXcFjt8wHHayDEt3aoDBzdd5KudOS+lMlnwkXIzlgZdoZYQ965gO4iot1Sq ZMYaypBP3ejPn5tNGbRBubK3YVfTMFikkN2iTebtBqhLd7TRpQEnG5skGGzNYsGjZxA5 M6pHcvgZ1ybtmaLLrHcKgf0QApiHVOoD58prBYHcX7NweaYgIHwWhd+du8m7DGJyWuWR Y/mw== 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=8CZfAYlAeROd1jqgnJ7XNGSl4fZK8EAJUVhVMc5877U=; b=lN5lWVv60HCkvbtFIdXDWK72rLYOdMVIRAbAuMAT5tr6gW0N+K5m/SlAZc5UjYIpo9 HmOLcoMBvB9J3AKhVBkhWGUfGt20mTEJokyli8opXcpSIFBtXOjpKDvTAo6BD4I+X9J9 7qmdVo+F36shBH9Bp0XUzA6EhTvY18VSAAnVn2hXwwQwHgxlVHOR4Vumy+wJpQKFA7X9 FiYKI5QX6QP39rv+oaVkxy8XKpNXHTGV4SBqMyeQMeuxsfXbiGcCF9D0cFA+h8Qt0b0/ CYrxm3ymlNCCYN1ncuTChiy7TysiswC6nb/gZRWmXlhk1ANUMCEG0GgjgDz370DgRhv8 NZmQ== X-Gm-Message-State: AOAM532XSRpBFWRx6V7Q/JXXbP/CoI3UQw6NhmF2beUxvX8tBXO+kvSA 15COp/OsX1Z7XT0pPEmXZxFbVVKCl5fxwGREXMw= X-Google-Smtp-Source: ABdhPJxCeoYFpQxWzEc5zvtOzazv+oSmCMQir7c0W9pA8iMMy+6ikAhlSB2etLMRZ3Oo7cqMGNAHRtumVbX0QMXbL40= X-Received: by 2002:ac8:1948:: with SMTP id g8mr20649451qtk.354.1597792454526; Tue, 18 Aug 2020 16:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:fcd0:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 16:14:14 -0700 (PDT) In-Reply-To: References: From: Dotzero Date: Tue, 18 Aug 2020 19:14:14 -0400 Message-ID: To: "dcrocker@bbiw.net" Cc: Todd Herr , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ad4bbc05ad2f0b9e" Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 23:14:19 -0000 --000000000000ad4bbc05ad2f0b9e Content-Type: text/plain; charset="UTF-8" On Tuesday, August 18, 2020, Dave Crocker wrote: > On 8/18/2020 12:48 PM, Todd Herr wrote: > >> The race condition here is in item 5, "Emails that fail the DMARC >> mechanism check are disposed of in accordance with the discovered DMARC >> policy of the Domain Owner", specifically when both the Sender and From >> headers are present, the domains are different, both publish DMARC >> policies, and only one of the two domains passes DMARC validation checks >> for that message. In that case, the question of "Which policy to apply?", >> or more precisely, "Which validation check should be honored?" will really >> matter to the disposition of the message; if, for example, the From domain >> is at p=reject and fails, while the Sender domain publishes a policy with >> the required "snd" tag and passes, should the message be rejected or >> accepted? >> > > > So, yeah, the text for that needs significant changes. Thanks for raising > this. > > I was under some time pressure and merely copied that from the existing > DMARC spec. In fact, I think that text in the DMARC spec isn't very good, > so this would be a nice excuse for thinking through reasonable language > carefully. > > The basic issue, which creates the language challenge, is the receivers > actually can and do do whatever they want. Language that pretends to > dictate receiver action for this is unrealistic. > > So the language should be cast in terms of the semantics of the > information it is tossing into the receiver's analysis engine, rather than > claiming to dictate receiver disposition of the message. IMO. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > This is just wrong. While I appreciate the enthusiasm for using the Sender field, unless there is a mechanism for establishing a relationship between the From domain and the Sender domain then we have basically broken DMARC. Using what has been described above, any malicious actor can bypass the wishes of the From domain and send whatever they want. I fail to see how this would be considered a feature. It is precisely why I proposed a separate signature of the Sender field by the From domain to at least provide a way to show a relationship between the Two domains. There currently is no race condition because Sender is not currently a part of DMARC. It appears that people want to introduce the same problem that existed in SenderID and PRA. Please don't. Michael Hammer --000000000000ad4bbc05ad2f0b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tuesday, August 18, 2020, Dave Crocker <dhc@dcrocker.net> wrote:
On 8/18/2020 12:48 PM, Todd Herr wrote:
The race condition here is in item 5, "Emails that fail the DMARC mech= anism check are disposed of in accordance with the discovered DMARC policy = of the Domain Owner", specifically=C2=A0when both the Sender and From = headers are present, the domains are different, both publish DMARC policies= , and only one of the two domains passes DMARC validation checks for that m= essage. In that case, the question of "Which policy to apply?", o= r more precisely, "Which validation check should be honored?" wil= l really matter to the disposition of the message; if, for example, the Fro= m domain is at p=3Dreject and fails, while the Sender domain publishes a po= licy with the required "snd" tag and passes, should the message b= e rejected or accepted?


So, yeah, the text for that needs significant changes.=C2=A0 Thanks for rai= sing this.

I was under some time pressure and merely copied that from the existing DMA= RC spec.=C2=A0 In fact, I think that text in the DMARC spec isn't very = good, so this would be a nice excuse for thinking through reasonable langua= ge carefully.

The basic issue, which creates the language challenge, is the receivers act= ually can and do do whatever they want.=C2=A0 Language that pretends to dic= tate receiver action for this is unrealistic.

So the language should be cast in terms of the semantics of the information= it is tossing into the receiver's analysis engine, rather than claimin= g to dictate receiver disposition of the message.=C2=A0 IMO.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


This is just wrong. While I appreciate the= enthusiasm for using the Sender field, unless there is a mechanism for est= ablishing a relationship between the From domain and the Sender domain then= we have basically broken DMARC. Using what has been described above, any m= alicious actor can bypass the wishes of the From domain and send whatever t= hey want. I fail to see how this would be considered a feature. It is preci= sely why I proposed a separate signature of the Sender field by the From do= main to at least provide a way to show a relationship between the Two domai= ns.

There currently is no race condition because S= ender is not currently a part of DMARC. It appears that people want to intr= oduce the same problem that existed in SenderID and PRA. Please don't.<= /div>

Michael Hammer
--000000000000ad4bbc05ad2f0b9e-- From nobody Tue Aug 18 16:22:06 2020 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 B6DE93A0F30 for ; Tue, 18 Aug 2020 16:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 CQGRBesUH6tW for ; Tue, 18 Aug 2020 16:22:03 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 1446E3A0F33 for ; Tue, 18 Aug 2020 16:22:03 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id g13so8641713ioo.9 for ; Tue, 18 Aug 2020 16:22:03 -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=dc+GaS7FYNNiZ4HYK2SjbgAYzyWh7u9rVlur9Z9eNUM=; b=FDi5cM8YzgEXFXpHdM8+5LsZv0ltNycJlPxN8XorztITLHZJJn3/gdvufN9AVY70c0 pzgRhBw8eV6++BQxOft1afvZgo32VD9qytva9FkG53LUMF8bWIUw4oc06C3t0LnftZgm 3Z+MnZKfMZtAaxN2GmEBnNUebO4IzDOkmnPaiwEW2a/dIzMm/HqjLbNVi06O/iyYKDut SNCBaDzhXKQUWm0bCcAOo0vAqfYytHyTKBZDTJWuW4PQEXjqD5N/aS7dqi2CypjwQn37 CJtlwbk1jUcjio0eFPAlWG8pvlnXDH8txD1oOVuUmkoHnjjasr8WPFoKquNnv83GPWZj JozQ== 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=dc+GaS7FYNNiZ4HYK2SjbgAYzyWh7u9rVlur9Z9eNUM=; b=fHDILvU2ZiC7IEJFhHhjsvr/t1HDJxjS/ShSaqHCuYCGtqMqa8+rka7CRcWG0iA+5u 5lpk0RGj3RW7T8Ss7mkeuBX4TXR8zG46m22xQpNVQ5q5AIHYr9dVIjABtIcpYQnh8m+W gdJ+i1K4o4oOFyCHAJqqNsF+lz+fGj1lNOpqJSyCVyltNEiqlq77QUhUoEdI8CvztfHg rxH7yu1ROz62ZVgd+plp+gJQ1OA1Burh8T9L4bF43tNA1rkLPQw3ghZ5QtZtZRynE25T VSKVn/XvrQnxa2FHuY3uZBu+BPJDOAfvRO+wOCuX6YRPlTpq87IzT463olzqrh2SyH33 D82Q== X-Gm-Message-State: AOAM5328Lig2oV8AAodFDFNDNH1ugGFtCYbyMIAW0fE2JqzJrYqqTeIV fabM/E6TZVdKlPoIzZclfwHUhGvXFl7n4lz79SQ00bBsHA== X-Google-Smtp-Source: ABdhPJwQyl8K+VjC2WF2rnA/nSRKGboOTlSPHp/w3L5HdEVIKGrHnA7WhMbWq78+2ldqKRZD515jmb6M9uFPDygYmDM= X-Received: by 2002:a02:7786:: with SMTP id g128mr20637097jac.45.1597792922011; Tue, 18 Aug 2020 16:22:02 -0700 (PDT) MIME-Version: 1.0 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> In-Reply-To: <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> From: Brandon Long Date: Tue, 18 Aug 2020 16:21:47 -0700 Message-ID: To: Laura Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008b072305ad2f2732" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 23:22:05 -0000 --0000000000008b072305ad2f2732 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2020 at 5:22 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: > > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > > The forum page is off the FTC website, but the document links are > still accessible: > > > > A copy is here: > > https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/worksh= ops/e-authentication/ > > A sentence says: > > The Report, however, identified domain-level authentication as a > promising technological development that would enable Internet > Service Providers (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and other= domain holders to better > filter spam, and that would provide law enforcement with a potent > tool for locating and identifying spammers. > > > And, 17 years on, we know that domain level authentication doesn=E2=80=99= t > actually help filter spam nor does it provide law enforcement with a pote= nt > tool for locating and identifying spammers. It was promising, it didn=E2= =80=99t > live up to the promise. > I don't understand this. Virtually every spam rule we write these days depends on information attached to the domain level authentication of an email message. I mean, it's not some simple binary thing, but it also very clearly helps us filter spam. We know, now, that turning on domain level protection does not stop > phishing attacks against that company. It stops direct spoofing of the > domain, but the phishers simply use a completely different domain. Just > this weekend I got a PayPal phish. PayPal who helped invent DMARC are sti= ll > getting spoofed and phished. Sure, the phishers aren=E2=80=99t using the > paypal.com domain, but that doesn=E2=80=99t seem to have any effect on th= eir > success at stealing money from people. > Do we have stats on that? I know that we've increased our resources towards anti-phishing over the years, so there's no apples to apples comparison here, and it would be hard to tease out the specifics anyways... but we've certainly had success in catching more of it. Brandon --0000000000008b072305ad2f2732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 17, 2020 at 5:22 AM Laura= Atkins <laura@wordtothewise.= com> wrote:


On 17 Aug 2020, at 12:25, Alessandro Vesely <vesely@tana.it> wrote:
=
On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:

The forum page is off the FTC website, but the do= cument links are
still accessible:


A copy is he= re:
https://web.archiv= e.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication= /

A sentence says:

=C2=A0=C2=A0=C2=A0The Report, however= , identified domain-level authentication as a
=C2=A0=C2=A0=C2=A0promisi= ng technological development that would enable Internet
=C2=A0=C2=A0=C2= =A0Service Providers (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and other d= omain holders to better
=C2=A0=C2=A0=C2=A0filter spam, and that would p= rovide law enforcement with a potent
=C2=A0=C2=A0=C2=A0tool for locatin= g and identifying spammers.

And,= 17 years on, we know that domain level authentication doesn=E2=80=99t actu= ally help filter spam nor does it provide law enforcement with a potent too= l for locating and identifying spammers. It was promising, it didn=E2=80=99= t live up to the promise.=C2=A0

I don't understand this.=C2=A0 Virtually every spam rule we write thes= e days depends on information attached to the domain level authentication o= f an email message.

I mean, it's not some simp= le binary thing, but it also very clearly helps us filter spam.
<= br>
We know, now, that turning on domain le= vel protection does not stop phishing attacks against that company. It stop= s direct spoofing of the domain, but the phishers simply use a completely d= ifferent domain. Just this weekend I got a PayPal phish. PayPal who helped = invent DMARC are still getting spoofed and phished. Sure, the phishers aren= =E2=80=99t using the paypal= .com=C2=A0domain, but that doesn=E2=80=99t seem to have any effect on t= heir success at stealing money from people.=C2=A0

Do we have stats on that?

I know that we've increased our resources towards anti-phishing over t= he years, so there's no apples to apples comparison here, and it would = be hard to tease out the specifics anyways... but we've certainly had s= uccess in catching more of it.

Brandon=C2=A0
=
--0000000000008b072305ad2f2732-- From nobody Tue Aug 18 17:47:57 2020 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 6E4683A1071 for ; Tue, 18 Aug 2020 17:47:55 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=WXBS63Oq; dkim=pass (2048-bit key) header.d=taugh.com header.b=Mvqsx8la 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 O8jnOVWLFxb0 for ; Tue, 18 Aug 2020 17:47:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A180A3A106F for ; Tue, 18 Aug 2020 17:47:27 -0700 (PDT) Received: (qmail 21032 invoked from network); 19 Aug 2020 00:47:25 -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=5226.5f3c769d.k2008; bh=hj7GtyByzwWgG+5iWfBdxq00cKx3evc/9G+Po6fhojs=; b=WXBS63OqP9f5md0DbCVT8DKm+WcU+csacv42/z9iVuz58LWIUQOgx2wvW7q0qUH7j+FCxjocul6n+5YJg78NvXw2wzwrN2xiZbLeye9JfTwoiFzBe+03mc8PACsjtkDQnsXRS7ziNXbCyAS1SdMiRv2Vt6+xojG7aEQN2trs9L1dHRJxCt8ReXH53iBLup6HwzEsfB5MRmQVD98onDlpsB3ucnxRrH3PZ/fCAkqg90ex35TZg3ABgMTgkpNQWdSypdr+QGF6YbxZ7JaJPrjygjERgjVvwAy/p50driVqfbpjQzgu323ajZI7Z+qudzhXyeG2gX+9uUZa5uk06n9HJA== 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=5226.5f3c769d.k2008; bh=hj7GtyByzwWgG+5iWfBdxq00cKx3evc/9G+Po6fhojs=; b=Mvqsx8laHB/ytd4O96wgpcPVOUmE8pjS9jucSrPOF9CWQKbozXP6hrjDDFqutCJiZ10Ek0tdlG+lvGGkHwqugf/b4fj7M5NgdrTgKSaQ9DJxmwKd63BDtEGhiqDg++teQAgiB4SPirzMKTSCNAgDmksXL8oto9JM/jSKLcQgvNEcCxMsa+KXUz4ifEjDm2wQnRJuqBETm4pY4d9eatLs+l7NIOOqM1B11yUY1GZE4amgcvQItG5vpNqfMrWMfIzT2GHJOfXiQyWNfIoiDzhRTitfEJIMvWSrVt0P05J49CUZo+P6pDOiVk/iBp1KG/6XMOwL4HaPyXY6KEqk/PyASw== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 19 Aug 2020 00:47:24 -0000 Received: by ary.local (Postfix, from userid 501) id 16EE11EED520; Tue, 18 Aug 2020 20:47:24 -0400 (EDT) Date: 18 Aug 2020 20:47:24 -0400 Message-Id: <20200819004724.16EE11EED520@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dotzero@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 00:47:55 -0000 In article you write: >This is just wrong. While I appreciate the enthusiasm for using the Sender >field, unless there is a mechanism for establishing a relationship between >the From domain and the Sender domain then we have basically broken DMARC. >Using what has been described above, any malicious actor can bypass the >wishes of the From domain and send whatever they want. Aw, come on. Surely you of all people know that DMARC aligned doesn't mean it's not spam. the whole reason we're here is that we have abundant evidence that at least where mailing lists are involved, the policy published in DMARC often doesn't express the actual wishes of the domain publishing it. R's, John From nobody Wed Aug 19 01:34:05 2020 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 505D03A11DE for ; Wed, 19 Aug 2020 01:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Sy8iiT9pz8kN for ; Wed, 19 Aug 2020 01:34:02 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 0AF033A11DD for ; Wed, 19 Aug 2020 01:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597826037; bh=t9e5qAcEsWpae97NQBRX4VxzalYOSm8+LIhJLIDIdX8=; l=1228; h=To:References:From:Date:In-Reply-To; b=BgJcLu/vzbFqNCB6lEyE4OcARQ9kitBtYeCJKWhwbftmGXBie1hQGqoOJOm3xsQmA dG/4zuB0oruXB7ZjQHDbvf3C3Hiqb50BRofZku5lJnzEZqHyR9yuKGXY9X1cnu9tyl gXM9AXr5iDk/p3/Rg7VvEY+NXskfFjH+aJrHLGzoELzdgiscl0yRaNmAoKk/N Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.68.187]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F3CE3F4.00003F8F; Wed, 19 Aug 2020 10:33:56 +0200 To: dmarc@ietf.org References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> From: Alessandro Vesely Message-ID: <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> Date: Wed, 19 Aug 2020 10:33:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 08:34:03 -0000 On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > The industry in general, and the IETF in particular, have chosen not > to pursue widespread use of any kind of standards-based third party > domain signature policy or reputation system.  That's the obvious > consensus, and in my opinion the reasons for that fact are sound. Based (also) on the following quoted paragraphs, I wouldn't call this state of affairs a choice or a consensus. It's just a series of failures. > Both ATPS (individual submission, experimental, February 2012) and the > REPUTE series of documents (working group, standards track, late 2013) > saw nearly zero adoption after publication even when free reference > implementations were provided.  They differ from basic DKIM in that > they require non-trivial upkeep, and that appears to be a step > function inhibiting adoption among operators. > > [...] As I said before, I'm disappointed that things like ATPS and > REPUTE never got a serious attempt, but that's not because they > were oppressed or sabotaged. That's just the reality we're in. We can still try again. In particular, the non-trivial upkeep seems to be a valid diagnosis. Best Ale -- From nobody Wed Aug 19 02:27:03 2020 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 611F93A16D7 for ; Wed, 19 Aug 2020 02:27:02 -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=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 bSITHFq7NlsR for ; Wed, 19 Aug 2020 02:27:00 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 624B83A16CF for ; Wed, 19 Aug 2020 02:27:00 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1AB6B9F1F7 for ; Wed, 19 Aug 2020 02:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597829219; bh=QmHANxeDaU3bqiGfFlSTCjU9774mYUUisBVBVDzXbb8=; h=From:Subject:Date:References:To:In-Reply-To:From; b=UxBCHW+3RMYiBvs56oaKCiYBDNR/V4eI4gOWQM2V9lgvBx8YGMJjKUCzDtkqxeBY+ ZNK6OsKQpY0WNLU2AxHSbRbZqsZBhxjakDl6gRq5FOpFAAEXf/rsgo9R7YTG5mZA5I x/X15kK+Vn3Chr60tRSzWthnU0xAIaYeyzwmnhMQ= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_5B7114DD-6844-4049-A8F6-CCCECF42B302" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 19 Aug 2020 10:26:56 +0100 References: <20200814164237.313071E971DB@ary.local> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <6358f3da-806b-f4eb-b9a0-8ee8ce4121d7@dcrocker.net> <4e549ca6-6047-6ff2-325c-fe8d7247e157@tana.it> <13a0ed72-2c5a-8ba6-84ab-b857e29403f1@tana.it> <8CCCBF0C-8651-4298-BB29-457381655D1D@wordtothewise.com> <7FC8E909-1A13-4682-B3D8-EAD76F2B02BB@wordtothewise.com> To: IETF DMARC WG In-Reply-To: Message-Id: <15CFB97A-FC78-4EAF-AC41-92ABCC0F8C9B@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 09:27:02 -0000 --Apple-Mail=_5B7114DD-6844-4049-A8F6-CCCECF42B302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Aug 2020, at 00:21, Brandon Long = wrote: >=20 >=20 >=20 > On Mon, Aug 17, 2020 at 5:22 AM Laura Atkins > wrote: >=20 >=20 >> On 17 Aug 2020, at 12:25, Alessandro Vesely > wrote: >>=20 >> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: >>>=20 >>> The forum page is off the FTC website, but the document links are=20 >>> still accessible: >>=20 >>=20 >> A copy is here: >> = https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/worksho= ps/e-authentication/ = >>=20 >> A sentence says: >>=20 >> The Report, however, identified domain-level authentication as a >> promising technological development that would enable Internet >> Service Providers (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and = other domain holders to better >> filter spam, and that would provide law enforcement with a potent >> tool for locating and identifying spammers. >=20 > And, 17 years on, we know that domain level authentication doesn=E2=80=99= t actually help filter spam nor does it provide law enforcement with a = potent tool for locating and identifying spammers. It was promising, it = didn=E2=80=99t live up to the promise.=20 >=20 > I don't understand this. Virtually every spam rule we write these = days depends on information attached to the domain level authentication = of an email message. I was thinking more that simply adding authentication doesn=E2=80=99t do = anything to identify spam vs. not-spam. Authentication give you a valid = identifier to hang a reputation on, but spammers are great at = implementing authentication. =20 > I mean, it's not some simple binary thing, but it also very clearly = helps us filter spam. You are correct and I wasn=E2=80=99t thinking.=20 > We know, now, that turning on domain level protection does not stop = phishing attacks against that company. It stops direct spoofing of the = domain, but the phishers simply use a completely different domain. Just = this weekend I got a PayPal phish. PayPal who helped invent DMARC are = still getting spoofed and phished. Sure, the phishers aren=E2=80=99t = using the paypal..com domain, but that doesn=E2=80=99= t seem to have any effect on their success at stealing money from = people.=20 >=20 > Do we have stats on that? Stats, no. But the fact that they=E2=80=99re still doing it tells me it = still works. If it wasn=E2=80=99t making them some level of money, = they=E2=80=99d move on to something else.=20 > I know that we've increased our resources towards anti-phishing over = the years, so there's no apples to apples comparison here, and it would = be hard to tease out the specifics anyways... but we've certainly had = success in catching more of it. No argument here. But as much of the world=E2=80=99s email you handle = you don=E2=80=99t handle all of it. And I have spoken with some of the = less savory end of mailers who actively avoid mailing your network and = target folks outside of it.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_5B7114DD-6844-4049-A8F6-CCCECF42B302 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 19 Aug 2020, at 00:21, Brandon Long <blong=3D40google.com@dmarc.ietf.org> wrote:



On Mon, Aug 17, 2020 at 5:22 AM Laura Atkins <laura@wordtothewise.com> wrote:


On 17 = Aug 2020, at 12:25, Alessandro Vesely <vesely@tana.it> wrote:

On Mon 17/Aug/2020 11:46:55 +0200 Laura = Atkins wrote:

The forum page is off the FTC website, but the document links = are
still accessible:


A copy is here:
https://web.archive.org/web/20120603201012/https://www.ftc.gov/= bcp/workshops/e-authentication/

A = sentence says:

   The = Report, however, identified domain-level authentication as a
   promising technological development that = would enable Internet
   Service Providers = (=E2=80=98=E2=80=98ISPs=E2=80=99=E2=80=99) and other domain holders to = better
   filter spam, and that would = provide law enforcement with a potent
=    tool for locating and identifying spammers.

And, 17 years on, we know that domain level = authentication doesn=E2=80=99t actually help filter spam nor does it = provide law enforcement with a potent tool for locating and identifying = spammers. It was promising, it didn=E2=80=99t live up to the = promise. 

I don't understand this.  = Virtually every spam rule we write these days depends on information = attached to the domain level authentication of an email = message.

I was thinking more that simply adding = authentication doesn=E2=80=99t do anything to identify spam vs. = not-spam. Authentication give you a valid identifier to hang a = reputation on, but spammers are great at implementing authentication. =  

I = mean, it's not some simple binary thing, but it also very clearly helps = us filter spam.

You are correct and I wasn=E2=80=99t = thinking. 

We know, now, = that turning on domain level protection does not stop phishing attacks = against that company. It stops direct spoofing of the domain, but the = phishers simply use a completely different domain. Just this weekend I = got a PayPal phish. PayPal who helped invent DMARC are still getting = spoofed and phished. Sure, the phishers aren=E2=80=99t using the paypal..com domain, but that doesn=E2=80=99t seem to = have any effect on their success at stealing money from = people. 

Do we have stats on = that?

Stats, = no. But the fact that they=E2=80=99re still doing it tells me it still = works. If it wasn=E2=80=99t making them some level of money, they=E2=80=99= d move on to something else. 

I know that we've increased our = resources towards anti-phishing over the years, so there's no apples to = apples comparison here, and it would be hard to tease out the specifics = anyways... but we've certainly had success in catching more of = it.

No argument = here. But as much of the world=E2=80=99s email you handle you don=E2=80=99= t handle all of it. And I have spoken with some of the less savory end = of mailers who actively avoid mailing your network and target folks = outside of it. 

laura 


-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_5B7114DD-6844-4049-A8F6-CCCECF42B302-- From nobody Wed Aug 19 02:41:55 2020 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 BAC4F3A16F9 for ; Wed, 19 Aug 2020 02:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 F268ZY4wGTRb for ; Wed, 19 Aug 2020 02:41:38 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 D54863A16FC for ; Wed, 19 Aug 2020 02:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597830094; bh=1PzkFPijgBi5KykhAwVOYwHnZIQgjoIRkWEGEgN5gwk=; l=4291; h=To:References:From:Date:In-Reply-To; b=BBCVEMI+o4F66DXFVBuU3lt6GmOB7y5qxswVvmPDYRs9YdejashKcXa22U2FsT48/ yvGYH915QObP6Ezx/Jn/JXEkkOUD91426EeR1OnzEuWHC1bbKEFKF8/GK7vKu+KaTk Q2Sre0Vf4zJGaowFCqLaI7XWYZYkdKA+PvdkzAbDyAVoa+7pbcaKSvNrUlemp Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.68.187]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F3CF3CE.00004771; Wed, 19 Aug 2020 11:41:33 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Wed, 19 Aug 2020 11:41:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 09:41:54 -0000 On Tue 18/Aug/2020 21:48:46 +0200 Todd Herr wrote: > Section 5.2, Determine Handling Policy, reads in part: > > The steps are as follows: > > 1. > > Sender: Extract the RFC5322.Sender domain from the message. > > Query the DNS for a DMARC policy record. > > Perform remaining, numbered steps, if one is found and it > contains an "snd" tag. > [...] > > 5. Apply policy. Emails that fail the DMARC mechanism check are > disposed of in accordance with the discovered DMARC policy of the > Domain Owner. See Section 6.3 for details. > > > The race condition here is in item 5, "Emails that fail the DMARC mechanism > check are disposed of in accordance with the discovered DMARC policy of the > Domain Owner", specifically when both the Sender and From headers are > present, the domains are different, both publish DMARC policies, and only > one of the two domains passes DMARC validation checks for that message. In > that case, the question of "Which policy to apply?", or more precisely, > "Which validation check should be honored?" will really matter to the > disposition of the message; if, for example, the From domain is at p=reject > and fails, while the Sender domain publishes a policy with the required > "snd" tag and passes, should the message be rejected or accepted? I fully agree with Michael on this point. Check #1 above is completely useless. What is it worth publishing the "snd" for? Do we aim at running statistics about how many domains plan to sign as Sender:? Instead, the "snd" tag should appear on the From: domain's DMARC record, so that, in the case described, a receiver can check whether that domain authorizes the Sender:. Better yet, the value of snd= should somehow relate the two domains, so that not /any/ Sender: can send on behalf of a given From:. IOW, the From: domain still has control. > When I first posed this, the answers I got were along the lines of > "Receivers will do what they want, like they've always done", and that's > certainly true if the behavior isn't mandated in the RFC (and maybe even if > it is). That's cool and all, but doesn't "Receiver's Choice" risk > continued, or perhaps even worse, breakage of the primary problem that this > document is trying to fix? Indeed, if all receivers knew what they want to do based on domains or IP addresses, why would senders publish policies at all? > > Unless I'm misunderstanding things, a primary idea behind the Sender header > with the DMARC policy is to make things easier for intermediaries, like > this mailing list. I'm posting to this list from a domain that publishes a > p=reject policy, and so to allow my post to make it to all subscribers, the > MLM rewrites the From address something that looks kind of VERP-ish > (todd.herr=40valimail.com@dmarc.ietf.org), DKIM signs it using the ietf.org > domain, and sends it along with a MAIL FROM domain ending in ietf.org. > > If this change becomes standard, then I imagine that future mail sent > through this MLM will look something like this: > > From: todd.herr@valimail.com > Sender: list@dmarc.ietf.org > DKIM-Signature domain (d=ietf.org) > Return-Path domain: ietf.org > > There may still be a DKIM signature header with d=valimail.com attached to > the message, but DMARC for valimail.com won't validate because of the > footer attached to the message, and so we'll be in a situation at best > where the Sender DMARC check passes and the From DMARC check fails, with > the From domain being at p=reject. There is clearly a gap. The list can send as above when all, or at least most aggregate reports say that they *would have accepted* the messages based on Sender: *even if From: weren't rewritten*. Current aggregate report format doesn't provide for that. > [...] > > It does not appear to be possible to handle this case safely, > except by modifying the From: header field so that it does not > trigger an alignment failure. Unless there comes a time at which > concern for this case is eliminated, Mediators will continue to > have to deal with this, such as by modifying the From: field. This kind of considerations suggest that the spec be well integrated with DMARC core, IMHO. Best Ale -- From nobody Wed Aug 19 03:30:25 2020 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 C206E3A174E for ; Wed, 19 Aug 2020 03:30:23 -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, 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 Qxx3rtT-LCsB for ; Wed, 19 Aug 2020 03:30:19 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 754FB3A0846 for ; Wed, 19 Aug 2020 03:30:19 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id h21so17337357qtp.11 for ; Wed, 19 Aug 2020 03:30:19 -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=1Eq5ZzO7125doyckTsgSQ10C/T07NjSn+Cx6MS2Verg=; b=PH/NXrad42/KtTAB6jCEmpHiC6Ay/Oevd/zqghIv2A46Ey5CnN8Iiz42d82kk9BdBH 1bOa9u2zhT7hRsKdVw2hfhxqyJVVnsl6IbaMb6QMv/SFZuT0nTuMkGJHAY9UQOTORkJY 44Ich6nH2rcBh8Xyi24ia5e0bM3ODwCYDMJLKUE5rtFZqEFcqz111N6Fk8tZH4BSqASG ELqHsL0HeWpSrSqM09wtj+QOURU2F3OS5Yh5JSwLyNQ5uXr0xNqxU/kuyX/2m0OplIlH gM22p9FqL50dDq98FUdulPeAapaWiAvz+v9tza11eBLQwrylUa4cgm+Qvdv5gDiJqcuz zWHA== 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=1Eq5ZzO7125doyckTsgSQ10C/T07NjSn+Cx6MS2Verg=; b=por10nbkzmWEEehI3I62nO8H/c5Mn/ZUlqppNuZVg6hf5BMPr8zDcJUlLKDp6BhQZu QW1CR+baftTjX846+wqyE063paVp3S3qnphQOQW3LkiVaJElc4a2SPDMRwqys86O7+Ue phCabhxkIl16ZhjOXB+Kv8NkFX5kmB0hu/fK2VX0GQz/9joMAQQ8MRGACtWQtJJ/4Yy1 7S9lhhc9GIqmKGCf6yP7CXX0IHFKmYeliHtdKmbLg4nIGBgLyFI5m3BK3PMkXWl36udC 2kgL4vzKjm5j1O/uXbCFwyn0J9h+Wnjg9BczhW5LDJVVdOvjp8vHtCwxXYQkMkohNSlo pr4g== X-Gm-Message-State: AOAM531VMOIQdYll3GxVopl7E20MmoeRBXRgavVdVci5yOLb3BSbpUXs x9MERIhnNHJjHCkkzBhdb+0MYD+X2o3Kgesib/lW0Qv+rKE= X-Google-Smtp-Source: ABdhPJyQw5wYc24W8GErc/XggGHZNlgQEMWIiEHhFOBg6xOSiG/4eaxBIna0VYjZu3jCZCLlN9GWDLNIrVfF92fKtCQ= X-Received: by 2002:ac8:660f:: with SMTP id c15mr22315145qtp.34.1597833018455; Wed, 19 Aug 2020 03:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:fcd0:0:0:0:0:0 with HTTP; Wed, 19 Aug 2020 03:30:17 -0700 (PDT) In-Reply-To: <20200819004724.16EE11EED520@ary.local> References: <20200819004724.16EE11EED520@ary.local> From: Dotzero Date: Wed, 19 Aug 2020 06:30:17 -0400 Message-ID: To: John Levine Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000079b96905ad387db2" Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 10:30:24 -0000 --00000000000079b96905ad387db2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, August 18, 2020, John Levine wrote: > In article mail.gmail.com> you write: > >This is just wrong. While I appreciate the enthusiasm for using the Send= er > >field, unless there is a mechanism for establishing a relationship betwe= en > >the From domain and the Sender domain then we have basically broken DMAR= C. > >Using what has been described above, any malicious actor can bypass the > >wishes of the From domain and send whatever they want. > > Aw, come on. Surely you of all people know that DMARC aligned doesn't me= an > it's not spam. > > Aw, come on. Surely you of all people know that DMARC broken doesn't mean it's good and real. =F0=9F=A4=94 You are presenting a false dichotomy that = centers only on mailing lists. > the whole reason we're here is that we have abundant evidence that at > least where mailing lists are involved, the policy published in DMARC > often doesn't express the actual wishes of the domain publishing it. You paint with a broad brush. As one of the creators of DMARC, I fully intended that ANY messages purporting to be from the domains I set p=3Dreje= ct for to be rejected if they failed to pass either aligned DKIM or SPF. No user accounts at those domains other than direct support accounts and billions of emails served with no intermediary problems other than a few vanity domains on the receiver side. Our position from the beginning was that they are not authorized by us to use our domains in that manner. For us,protecting end users,most who were not even our customers was much more important than the small fraction of a percentage of dropped mail. And yes, we tracked all sorts of metrics on an ongoing basis. Please don't tell me that our published policy did not represent our actual wishes. Your representation that you know better than ALL people/domains which publish DMARC what they wish is akin to saying you know better than all people screwing up their DNS records what they actually want. You sidestep a lot of important issues by reducing everything to the one edge case you are concerned about. If the people you claim don't want the outcome they have as a result of the DMARC policy that they published then maybe they should publish a different policy. Have you considered contracting them, any of them, to tell them you know their wishes better than they do? Michael Hammer --00000000000079b96905ad387db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tuesday, August 18, 2020, John Levine <johnl@taugh.com> wrote:
In article <CAJ4XoYcue16VU6otKOzQBFy_59nD8DGcDQb8H=3DZ0MsX-XLah8w@mail.gmail.com>= ; you write:
>This is just wrong. While I appreciate the enthusiasm for using the Sen= der
>field, unless there is a mechanism for establishing a relationship betw= een
>the From domain and the Sender domain then we have basically broken DMA= RC.
>Using what has been described above, any malicious actor can bypass the=
>wishes of the From domain and send whatever they want.

Aw, come on.=C2=A0 Surely you of all people know that DMARC aligned doesn&#= 39;t mean
it's not spam.


Aw, come on. Surely you of all people = know that DMARC broken doesn't mean it's good and real. =F0=9F=A4= =94 You are presenting a false dichotomy that centers only on mailing lists= .
=C2=A0
the whole reason we're here is that we have abundant evidence that at least where mailing lists are involved, the policy published in DMARC
often doesn't express the actual wishes of the domain publishing it.

You paint with a broad brush. As one of the c= reators of DMARC, I fully intended that ANY messages purporting to be from = the domains I set p=3Dreject for to be rejected if they failed to pass eith= er aligned DKIM or SPF. No user accounts at those domains other than direct= support accounts and billions of emails served with no intermediary proble= ms other than a few vanity domains on the receiver side. Our position from = the beginning was that they are not authorized by us to use our domains in = that manner. For us,protecting end users,most who were not even our custome= rs was much more important than the small fraction of a percentage of dropp= ed mail. And yes, we tracked all sorts of metrics on an ongoing basis.

Please don't tell me that our published policy did= not represent our actual wishes. Your representation that you know better = than ALL people/domains which publish DMARC what they wish is akin to sayin= g you know better than all people screwing up their DNS records what they a= ctually want. You sidestep a lot of important issues by reducing everything= to the one edge case you are concerned about.

If = the people you claim don't want the outcome they have as a result of th= e DMARC policy that they published then maybe they should publish a differe= nt policy. Have you considered contracting them, any of them, to tell them = you know their wishes better than they do?

Michael= Hammer
--00000000000079b96905ad387db2-- From nobody Wed Aug 19 07:53:50 2020 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 44E7D3A09ED for ; Wed, 19 Aug 2020 07:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=UiMlNwgZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=KkG5rfoG 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 gy1gIDO0yVQU for ; Wed, 19 Aug 2020 07:53:47 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9005A3A0A22 for ; Wed, 19 Aug 2020 07:53:47 -0700 (PDT) Received: (qmail 92045 invoked from network); 19 Aug 2020 14:53:42 -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; s=1678b.5f3d3cf6.k2008; i=johnl-iecc.com@submit.iecc.com; bh=b+BtigArQQsyvmsAHnoepuB3ffkxfXhazfABCXfAHAQ=; b=UiMlNwgZUvkwA7mylfTfjnkRSV1eUQIAPxzb3D2Irjgb7rE1ndGMkTkm+iSYyxBEK7onFSWqh47umzwkousJtPjAPqX/zhzynAtCyry517TNLufwBb0MOmXSX2/LcC0MoIaVU2Rk8nfBUCA7eubSLZoJ1bXWUi4Psg+KpcjPtlBF7P8islY93p+qS9j9XJA6N/7qfk4MJiPBHzOYfqFiTHVNZTPTnzrSiPbcH84mKvwK3FQa8ikbAdt41YLhbGBWr+8qEffHDCx0TNlcx+L1aShjcPmnbxwyXjUj8MnP6AbJj4GjgRbuBlRJDqCpYrrG+9awRTXIo0UVkKcUm+iNmg== 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; s=1678b.5f3d3cf6.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=b+BtigArQQsyvmsAHnoepuB3ffkxfXhazfABCXfAHAQ=; b=KkG5rfoG7Jq3pbacMCLmVJizjNO0Ar84TYI+Yb40+sZGoIKq3gaJOtzW37p5jFCKLRrlU059IGwIP99FFmUHhq/bbe44wq7mo3RhEP0yeaZ2QjujNFrH6LDD5geMBmv9b8kj6II7M/kfbm/NYZ2VolcPy9E6NvVM+sIvuIG6al049e5qb1UIHGKMD8AdXN7haydNdjpJkYWEIAAoSv3Z1wZOX6vaEc+aj7ZPQ3WqtERU93EzRO9mlwuCdJSZ5fPYZkqfAHB7VleU6MonFh4JQKQyox03Ym2pGhfJkdT6VGtCG7MaQxJKQ6rFfGF02gyicYqLoLmc/ze2HQCC5VVx0Q== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Aug 2020 14:53:41 -0000 Date: 19 Aug 2020 10:53:41 -0400 Message-ID: <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> From: "John R Levine" To: "Dotzero" Cc: "dmarc@ietf.org" In-Reply-To: References: <20200819004724.16EE11EED520@ary.local> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 14:53:49 -0000 On Wed, 19 Aug 2020, Dotzero wrote: > If the people you claim don't want the outcome they have as a result of the > DMARC policy that they published then maybe they should publish a different > policy. Have you considered contracting them, any of them, to tell them you > know their wishes better than they do? Ericsson publishes p=reject over the objections of their employees, some fairly high in the hierarchy, who they subsidize to participate in the IETF and its mailing lists. I've coached some of them on what to say, didn't help. Of course you personally know what DMARC policies mean and what they imply. But every time a list has to rewrite a From line, we have evidence that someone else doesn't or at best doesn't care.* R's, John * - I have on excellent authority that when Yahoo published p=reject to outsource the costs of their security breaches, Marissa Meyer said she knew it would break everyone's mailing lists and she didn't care. From nobody Wed Aug 19 09:27:15 2020 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 E0E4D3A0CE3 for ; Wed, 19 Aug 2020 09:27:13 -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, 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 upMOko9HX6MU for ; Wed, 19 Aug 2020 09:27:12 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 884E83A0CDA for ; Wed, 19 Aug 2020 09:27:12 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id x7so11538280qvi.5 for ; Wed, 19 Aug 2020 09:27:12 -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=nFZ0yZ8LA5i5DXxXBqGI3soSWEkrCjr/JN8cqQ+yWkY=; b=BEBuedplDOfel6LaDDqjHyX6HfRaTL1ZMEgbIxNi5KDX/QITldUJXEhHVrAp0uI/zV VbDi999k2Wrs+0qVzXBn5+lo3fCqgYbJeUO1qXfBypbmVq6ezNdKVWm4YOeeqAOnp8ja ACe4u/ZthsxUWc0hHwodXDJ3cAtlPsRk8ohkyIOzmWbCbJyGrMLCZcloH7zyifQKBya2 JFufxtC513hGdRBwZFafHKyEn0L6gs4VjYznt/j1CYBQAxZLkt8N0oVICKUpVnHWwo0k 1KfkliTReQLAagitavPVOXuVUso3X9KF5MemSB2NrwDwmxGUZBNMZ07XrVU0MA5hXPMc 0kRw== 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=nFZ0yZ8LA5i5DXxXBqGI3soSWEkrCjr/JN8cqQ+yWkY=; b=o/7+kmRYidlHbU+S950rmM9DcxK8WhoLg5stHBr/K7btpDeLAbijLToFNuavDPsNcm 53hLikrlHGvW6Iez3Z8ts6JBmkW+9Nmw1ykFJ/tYfN3zrSadyNx520yZBLbJoTARExUc 5U28gcKhsFJKEAIPrwxxr6ReTjfF/EU10lFh3wV5WoTxeO/mon/vZkl25F8gdu7UJS6N qlfDfYfGa4lOWZlet6cyhfIL/pFmgBJv2Tj9vEpEccNEjEWNs3SzN5XoCS59vnhxsvW5 BjvdtArvA4llSqwixEvp7juLTvuLeZabf8IjljiEO6o/yhkTNM7hO2ujH+0z0vid2Sim 6uOA== X-Gm-Message-State: AOAM533A4XP/o8zAsJDYS+BphXnOBTKlLgXHEW/Gs0etZLwl7ZibpZlj 4blpJD4LYFTksDLQjXwAdV3CR0TgGDhHE4fnCJjG1sMfHxs= X-Google-Smtp-Source: ABdhPJzgI5V4/LXTf/QBuxi9WMmM5iKE8EkwhVi2nz59mSkE9qKKB5hOgDWlSm8f6a5g37dMn3nrhKi+Eaxy5j6aNxg= X-Received: by 2002:ad4:438e:: with SMTP id s14mr23977963qvr.18.1597854431597; Wed, 19 Aug 2020 09:27:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:fcd0:0:0:0:0:0 with HTTP; Wed, 19 Aug 2020 09:27:10 -0700 (PDT) In-Reply-To: <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> From: Dotzero Date: Wed, 19 Aug 2020 12:27:10 -0400 Message-ID: To: John R Levine Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cc59b705ad3d7918" Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 16:27:14 -0000 --000000000000cc59b705ad3d7918 Content-Type: text/plain; charset="UTF-8" On Wednesday, August 19, 2020, John R Levine wrote: > On Wed, 19 Aug 2020, Dotzero wrote: > >> If the people you claim don't want the outcome they have as a result of >> the >> DMARC policy that they published then maybe they should publish a >> different >> policy. Have you considered contracting them, any of them, to tell them >> you >> know their wishes better than they do? >> > > Ericsson publishes p=reject over the objections of their employees, some > fairly high in the hierarchy, who they subsidize to participate in the IETF > and its mailing lists. I've coached some of them on what to say, didn't > help. Then Ericcson as an organization has made a decision regardless of the objections of those employees. The correct thing for Ericcson as an organization to do is to publish an internal policy that employees should not use company mail for participating in mailing lists. An alternative to that would be for them to hire someone to help them come up with a workable approach. We both know plenty of people who could help them. > > Of course you personally know what DMARC policies mean and what they > imply. But every time a list has to rewrite a From line, we have evidence > that someone else doesn't or at best doesn't care.* I'm going to guess that more often than not it is the latter. *I heard the same. Too big to care? > R's, > John > > * - I have on excellent authority that when Yahoo published p=reject to > outsource the costs of their security breaches, Marissa Meyer said she knew > it would break everyone's mailing lists and she didn't care. > Michael Hammer --000000000000cc59b705ad3d7918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wednesday, August 19, 2020, John R Levine <johnl@taugh.com> wrote:
On Wed, 19 Aug 2020, Dotzero wrote:
If the people you claim don't want the outcome they have as a result of= the
DMARC policy that they published then maybe they should publish a different=
policy. Have you considered contracting them, any of them, to tell them you=
know their wishes better than they do?

Ericsson publishes p=3Dreject over the objections of their employees, some = fairly high in the hierarchy, who they subsidize to participate in the IETF= and its mailing lists.=C2=A0 I've coached some of them on what to say,= didn't help.

Then Ericcson as an organ= ization has made a decision regardless of the objections of those employees= . The correct thing for Ericcson as an organization to do is to publish an = internal policy that employees should not use company mail for participatin= g in mailing lists. An alternative to that would be for them to hire someon= e to help them come up with a workable approach. We both know plenty of peo= ple who could help them.=C2=A0

Of course you personally know what DMARC policies mean and what they imply.= =C2=A0 But every time a list has to rewrite a From line, we have evidence t= hat someone else doesn't or at best doesn't care.*

I'm going to guess that more often than not it is the l= atter. *I heard the same. Too big to care?
=C2=A0
R's,
John

* - I have on excellent authority that when Yahoo published p=3Dreject to o= utsource the costs of their security breaches, Marissa Meyer said she knew = it would break everyone's mailing lists and she didn't care.

=C2=A0Michael Hammer
--000000000000cc59b705ad3d7918-- From nobody Wed Aug 19 09:33:27 2020 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 95F6C3A0CE9 for ; Wed, 19 Aug 2020 09:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=MlYWJwZ1; dkim=pass (2048-bit key) header.d=taugh.com header.b=W6ayNwIW 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 zvfsRK9Za8zK for ; Wed, 19 Aug 2020 09:33:24 -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 B5E9E3A0CE6 for ; Wed, 19 Aug 2020 09:33:23 -0700 (PDT) Received: (qmail 11413 invoked from network); 19 Aug 2020 16:33:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=2c93.5f3d5450.k2008; i=johnl-iecc.com@submit.iecc.com; bh=LQVqtieZhfm5s7/+9Xm9YH4n4F+j8KlOVIccGhe26to=; b=MlYWJwZ1IJOgglvkMHsh2OGWttOGL/dOfAIhmfHexd/TWai90Qq9E7PxyG7WiIFekTERnMHmr8VUjF25dQ9PinK9l9sPKkihcHA4pr7aeoWi5x+o1tj7Wyz7OOybnFBVI2b9NjVm/bKq0h0iMHPZ8tywFm3IcB30/J0Jdg6fKnxk5rJ52uOqxOTsqQyhpIeA8FeZhIiQTJk0PI/nTA8VMnuGwIptnjuBfl1U0L6eeufHHtoWhoVxLLSU58daldalxUAVEPx2tPhQiY7/0nQGhqFL1VjslQ7YY2zMHB/mYu77m3+ZdCa9gMFfwFWCg/B9dr29XVy9y0Z/4wO8f0XE5Q== 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; s=2c93.5f3d5450.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=LQVqtieZhfm5s7/+9Xm9YH4n4F+j8KlOVIccGhe26to=; b=W6ayNwIW1QdHTDCsTaZ+6p4e8ijTyEWvY9Aud4VBDVMMIAUfeJxpChuxpLLEUsFlb8ux1CdsShSDbGtsBA8Ckl/OGywDje0bGAlHPBSNSWXJJPpm6n8mxfDiUsAouCAvt6buvUHnkJYz07xR/4AkIAX4EcF5VABKmZsYf5thHCAcRROmdmvOTJdv6RvOjg4G4msibJx1Jbl027ZuuDcuT3Pl1QvEtGjodbQUspG9UHzV2ZgXTLAppIEctdMr7icSRtAYcFQkR0BKJ4gAujGZkACe6vIQ3EAA2cNG4hQyqms7BtXYYIxEjeh4vGR4q6K/040rEmBhqM4FOHYFfYRVFg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Aug 2020 16:33:20 -0000 Date: 19 Aug 2020 12:33:19 -0400 Message-ID: <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> From: "John R Levine" To: "Dotzero" Cc: "dmarc@ietf.org" In-Reply-To: References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 16:33:26 -0000 On Wed, 19 Aug 2020, Dotzero wrote: > Then Ericcson as an organization has made a decision regardless of the > objections of those employees. The correct thing for Ericcson as an > organization to do is to publish an internal policy that employees should > not use company mail for participating in mailing lists. An alternative to > that would be for them to hire someone to help them come up with a workable > approach. We both know plenty of people who could help them. No doubt, but they're not going to do that. They want their employees to work on the IETF, the publish p=reject and they apparenty believe the contradiction is not their problem. So we're stuck with it. >> Of course you personally know what DMARC policies mean and what they >> imply. But every time a list has to rewrite a From line, we have evidence >> that someone else doesn't or at best doesn't care.* > > I'm going to guess that more often than not it is the latter. *I heard the > same. Too big to care? Yup. They want phishes, or in Yahoo's case expensive user complaints, to go away, they don't care about discussion lists one way or the other Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Aug 19 10:07:34 2020 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 2D6793A0D3F for ; Wed, 19 Aug 2020 10:07:31 -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, 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 RYOGaUIiFAam for ; Wed, 19 Aug 2020 10:07:29 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 833873A0972 for ; Wed, 19 Aug 2020 10:07:29 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id x69so22272205qkb.1 for ; Wed, 19 Aug 2020 10:07:29 -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=ftgotU/o5nDvp1Xft99YyNctxDC2cRDTXIJz5HzU/t8=; b=usQH4fBq77Vs76fSjkqiH21WCTODLkilB7dvVTU3ZgXZUTm5j1PfeLG18FqQq1JHnb INsDp29PWFIn8hdzAW4MfZRliKmYBC9EIRdxWBQzK6COAyxB1wgMp0P4x/a8OGpDVXsq EqWoIq9PF2FTSbSCErv8Of4+HN2SvxlAPioLlmcU+5fqpgV4NSqqlkxT5HO+Hk2Cw8Im hQGF8AKih64dM8LbmnkgDTRaQRl+8Td4zyAVCH7g+BUgKd+Ukwid2Xjcbp6E2o9xKZXH 3swbj98yDtthyFz31xYm4jk9u4Q4h+WBI8Xf2oNVPcyI5SDWrcipVCFkuS58dca0zSb+ wWGw== 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=ftgotU/o5nDvp1Xft99YyNctxDC2cRDTXIJz5HzU/t8=; b=C+gpBHVrxhFg/tSWB5rnwz7uuGg7PXFAfaYxvSNyhFoiKLrFLnh/zzUIWe6AGVzLYf NOAXFBf/q64pfPkQK1bdOvr3hGbjofIzjm6fYe9wqeGE2g8tad9od8QPJkErDD94f5Fu uiUIH/aDTgnUAmmJcI14ImNybbvGLC67AEdm15UrF9yg1QDjFS8cLugp+23kfvCOT51g vEfJbO9oXMfHbmyzCdende7b9T2tnlyF6NWyhvjWFSSNeMZzdxjrhetvYLLR+X3w+745 qPe30O+vT22DfXO1B5tFzRpGuriVKFnFf7F2WNcC7zO+DcL5oJXKDNNDp2oPqSZiv0eu ryVw== X-Gm-Message-State: AOAM5301hqYesLpE10BTjkevWTPSpdXYmKGzVdrKAU/hX0U8Wxbu6xTy w4U66XAzYiPHWE2sxQ468Ngd3UV7uadjuI/bXIV7xjn8ZpY= X-Google-Smtp-Source: ABdhPJzDCOTdyp/vvYmqA+rn3DjWMhf6QVk63yLxzwoSFuUnUjTwInEnuxbHWPQ4Q/OdAvBSqGTSitzSBZ5uaxEzF2s= X-Received: by 2002:a05:620a:545:: with SMTP id o5mr21601796qko.187.1597856848496; Wed, 19 Aug 2020 10:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:fcd0:0:0:0:0:0 with HTTP; Wed, 19 Aug 2020 10:07:27 -0700 (PDT) In-Reply-To: <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> From: Dotzero Date: Wed, 19 Aug 2020 13:07:27 -0400 Message-ID: To: John R Levine Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db4d4605ad3e09fa" Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 17:07:31 -0000 --000000000000db4d4605ad3e09fa Content-Type: text/plain; charset="UTF-8" On Wednesday, August 19, 2020, John R Levine wrote: > On Wed, 19 Aug 2020, Dotzero wrote: > >> Then Ericcson as an organization has made a decision regardless of the >> objections of those employees. The correct thing for Ericcson as an >> organization to do is to publish an internal policy that employees should >> not use company mail for participating in mailing lists. An alternative to >> that would be for them to hire someone to help them come up with a >> workable >> approach. We both know plenty of people who could help them. >> > > No doubt, but they're not going to do that. They want their employees to > work on the IETF, the publish p=reject and they apparenty believe the > contradiction is not their problem. So we're stuck with it. For some definition of stuck. I happen to believe that validators/receivers SHOULD generally respect policy assertions. Mail list operators should as well. Absent a functional and meaningful mechanism for authorization of specific intermediaries by domains, that is the way to go. If things break and users complain then those users should be told to contact their mail administrator. Just saying. > > Of course you personally know what DMARC policies mean and what they >>> imply. But every time a list has to rewrite a From line, we have >>> evidence >>> that someone else doesn't or at best doesn't care.* >>> >> >> I'm going to guess that more often than not it is the latter. *I heard the >> same. Too big to care? >> > > Yup. They want phishes, or in Yahoo's case expensive user complaints, to > go away, they don't care about discussion lists one way or the other > Perhaps they would care if users/customers complained and or walked. Again, just saying. Michael Hammer --000000000000db4d4605ad3e09fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wednesday, August 19, 2020, John R Levine <johnl@taugh.com> wrote:
On Wed, 19 Aug 2020, Dotzero wrote:
Then Ericcson as an organization has made a decision regardless of the
objections of those employees. The correct thing for Ericcson as an
organization to do is to publish an internal policy that employees should not use company mail for participating in mailing lists. An alternative to<= br> that would be for them to hire someone to help them come up with a workable=
approach. We both know plenty of people who could help them.

No doubt, but they're not going to do that.=C2=A0 They want their emplo= yees to work on the IETF, the publish p=3Dreject and they apparenty believe= the contradiction is not their problem.=C2=A0 So we're stuck with it.<= /blockquote>

For some definition of stuck. I happen to b= elieve that validators/receivers SHOULD generally respect policy assertions= . Mail list operators should as well. Absent a functional and meaningful me= chanism for authorization of specific intermediaries by domains, that is th= e way to go. If things break and users complain then those users should be = told to contact their mail administrator. Just saying.=C2=A0

Of course you personally know what DMARC policies mean and what they
imply.=C2=A0 But every time a list has to rewrite a From line, we have evid= ence
that someone else doesn't or at best doesn't care.*

I'm going to guess that more often than not it is the latter. *I heard = the
same. Too big to care?

Yup.=C2=A0 They want phishes, or in Yahoo's case expensive user complai= nts, to go away, they don't care about discussion lists one way or the = other

Perhaps they would care if users/customers= complained and or walked. Again, just saying.

Mic= hael Hammer=C2=A0
--000000000000db4d4605ad3e09fa-- From nobody Wed Aug 19 10:11:08 2020 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 27A683A0C1B for ; Wed, 19 Aug 2020 10:11:07 -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=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 Fh04FVxHOsAP for ; Wed, 19 Aug 2020 10:11:05 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C5F3A0972 for ; Wed, 19 Aug 2020 10:11:05 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id r13so16879191iln.0 for ; Wed, 19 Aug 2020 10:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z81aKYDbrPL7H+r3tPJuQtV+ir00o950CW+xkt/p1hk=; b=Vycu6eaZwDqXdT5zRifdx+irOcn4aSJqdgeGyDBuZlfI39Apqsj8iSAxG1QOqXMkuF FNFNSv4f3nx3qwBHDwcOwkQswVNpLMp6mhxfyBV+T7kDpUYzyP2rC08KUwazIL5O0aT/ ukL/h92TA7Hxr3GCyiAvEM7ydtprbbovbsFP8= 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=z81aKYDbrPL7H+r3tPJuQtV+ir00o950CW+xkt/p1hk=; b=fvimhCRqZPuPXT9R+Gkm2/KMyRbRdZVzrInpOm8cG525E0plMRL972CvOtEUrKrzUl FHdgYZOau6U2bxPQzjw6bYKikCAr1vFo5R0pBtS/AePjX23ZZKBqv2o14U0dAiEQd62c Gp0d+5lIEWx6RsJpU/bbW67Llq2ofjMbQysx5xlocqm4AIRg8KitNGZBnoBbDBax5VYz QvlmTNPEgFkSrRKFJ3u0BWDid5/LB3WyavXh6kCkkc47fatfwYG3nwwZtVcHlCmC/qhM 0c51sWR7gTX5qC8lz7fxvO8WVENPiciHg4zOXy9Dq7qO6l7NKY9C8befAaGdjRNpXFhy w8jA== X-Gm-Message-State: AOAM5330kH3aVoyQ/JYAaqEiZOkS4ye597FmrlTBkohWoh/iO/E7NqIg DWjb2GAqfwKUvNyXs9VLEvQDQpCKrE7VvrbBR5DOSTzgAjyLWQ== X-Google-Smtp-Source: ABdhPJy63Q9HMrxWDwnchSn40MG9kLjD3gdqbGzFWrBp2mwoIn8yElXKxDt0l+QmKPuUeM+fiLsaL0OG6CoR+U2+8ns= X-Received: by 2002:a92:d1cd:: with SMTP id u13mr21671627ilg.120.1597857064406; Wed, 19 Aug 2020 10:11:04 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> In-Reply-To: <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> From: "Kurt Andersen (b)" Date: Wed, 19 Aug 2020 10:10:21 -0700 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b9e74e05ad3e16e2" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 17:11:07 -0000 --000000000000b9e74e05ad3e16e2 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely wrote: > On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > > The industry in general, and the IETF in particular, have chosen not > > to pursue widespread use of any kind of standards-based third party > > domain signature policy or reputation system. . . > > > Both ATPS (individual submission, experimental, February 2012) and the > > REPUTE series of documents (working group, standards track, late 2013) > > saw nearly zero adoption after publication even when free reference > > implementations were provided. They differ from basic DKIM in that > > they require non-trivial upkeep, and that appears to be a step > > function inhibiting adoption among operators. > > We can still try again. In particular, the non-trivial upkeep seems > to be a valid diagnosis. > Is there anything which has materially changed between 2012-13 and 2020 which would indicate that the anticipated results for such effort would be any different? --Kurt --000000000000b9e74e05ad3e16e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 1:34 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > The industry in general, and the IETF in particular, have chosen not <= br> > to pursue widespread use of any kind of standards-based third party > domain signature policy or reputation system. . .

> Both ATPS (individual submission, experimental, February 2012) and the=
> REPUTE series of documents (working group, standards track, late 2013)=
> saw nearly zero adoption after publication even when free reference > implementations were provided.=C2=A0 They differ from basic DKIM in th= at
> they require non-trivial upkeep, and that appears to be a step
> function inhibiting adoption among operators.

We can still try again.=C2=A0 In particular, the non-trivial upkeep seems <= br> to be a valid diagnosis.

Is there anyth= ing which has materially changed between 2012-13 and 2020 which would indic= ate that the anticipated results for such effort would be any different?

--Kurt=C2=A0
--000000000000b9e74e05ad3e16e2-- From nobody Wed Aug 19 11:37:44 2020 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 4DEF63A086E for ; Wed, 19 Aug 2020 11:37:42 -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, 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 aEWEIP951pfL for ; Wed, 19 Aug 2020 11:37:40 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 9FB7E3A0869 for ; Wed, 19 Aug 2020 11:37:40 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id z12so7182323uam.12 for ; Wed, 19 Aug 2020 11:37:40 -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=xrKocl2LXoZ163o8LPCQbti0+kXnf1OzfF3xv07duBg=; b=M27U5YWB0VEv4+wbfF+X6+uZFD09aOB3H3+MIZ1fj8ah1gwsZnoHTXnDsW1OKSxxJK aFxpLA5jFmLMeoIcOC9u6zxGL4grE652K9j0/S1Sp3EYeFPeBO5k2Y4ifmMxRyRpjgvL bmNPWTxoNkYhCEyEzrbtjd22Crm0bIpIUVoZS1utxNNiCQIQcoxOYiHpSJucPMeLYjiO 6s19kLT2cB4LFKSUivZ2TtZeQfzTOFAubDhWS25fs675evGkvFXosHAS/h5YmpILsRCd hHvcuMI3cWL/KFJ1aFi3fqNFakXSqSz8zK+RzBwksdnr1e2npFs3LH4p1YXvZJg2vYTH Qsuw== 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=xrKocl2LXoZ163o8LPCQbti0+kXnf1OzfF3xv07duBg=; b=Y0AHGwwCvOzu2z1EAWPsflX2LEJn6JIgaTinKkAlnIeFSza7tJZO4RMR815Iq+jfmm wjT28uyanf1Xs42cHXMHgBMXgsVqakTBP+L3jjVinr6HVsJJTvlT49MGzVj1xDSrcAkS dJwQS9FQyG+tGoVd0Krmot5dTQ2dX4r7pdRpC/UWZOLKIZ4pVHaOO81lo7PT6WzFggse pwa0h7Uxxko8x4snuwhHsbEkJwx8O5mWLCt2uyM6cZBzj3dtAYVHnW0PuTlJgnJSlV9w tmC8JB8WKiWkdCPUtZvSVvCZiKL2a3BAbW1IJvc3HicryWPXMyphwIZqXBeuMwYwWcWy mllg== X-Gm-Message-State: AOAM532MspzX+ZfX9bdytgpXPW1MdT4272gwwkQPAz8Gk3kKmioSkof/ ytvAi04D0e6R4YKkLEz0hIwBp25ur0mLPaqhVWA= X-Google-Smtp-Source: ABdhPJz0RzWEtILYZJviuCS5z59WPQRl9JtOFn0Z7G9GceUixDkWOKoq9qpOjw4JXeF3h4qkJ7vhJg/9RLs85nn22WM= X-Received: by 2002:a9f:26a5:: with SMTP id 34mr15806833uay.67.1597862258660; Wed, 19 Aug 2020 11:37:38 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 19 Aug 2020 11:37:27 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Alessandro Vesely , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000053d94105ad3f4ce5" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 18:37:42 -0000 --00000000000053d94105ad3f4ce5 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b) wrote: > On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely wrote: > >> On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: >> > The industry in general, and the IETF in particular, have chosen not >> > to pursue widespread use of any kind of standards-based third party >> > domain signature policy or reputation system. . . >> >> > Both ATPS (individual submission, experimental, February 2012) and the >> > REPUTE series of documents (working group, standards track, late 2013) >> > saw nearly zero adoption after publication even when free reference >> > implementations were provided. They differ from basic DKIM in that >> > they require non-trivial upkeep, and that appears to be a step >> > function inhibiting adoption among operators. >> >> We can still try again. In particular, the non-trivial upkeep seems >> to be a valid diagnosis. >> > > Is there anything which has materially changed between 2012-13 and 2020 > which would indicate that the anticipated results for such effort would be > any different? > +1. If anyone has some kind of creativity in this space that they've been hiding, now's the time. -MSK --00000000000053d94105ad3f4ce5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 10:11 AM Kurt And= ersen (b) <kboth@drkurt.com> = wrote:
On Wed, Aug 19, 2020 at= 1:34 AM Alessandro Vesely <vesely@tana.it> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Tue 18/Aug/2020 01:21:3= 3 +0200 Murray S. Kucherawy wrote:
> The industry in general, and the IETF in particular, have chosen not <= br> > to pursue widespread use of any kind of standards-based third party > domain signature policy or reputation system. . .

> Both ATPS (individual submission, experimental, February 2012) and the=
> REPUTE series of documents (working group, standards track, late 2013)=
> saw nearly zero adoption after publication even when free reference > implementations were provided.=C2=A0 They differ from basic DKIM in th= at
> they require non-trivial upkeep, and that appears to be a step
> function inhibiting adoption among operators.

We can still try again.=C2=A0 In particular, the non-trivial upkeep seems <= br> to be a valid diagnosis.

Is there anyth= ing which has materially changed between 2012-13 and 2020 which would indic= ate that the anticipated results for such effort would be any different?

+1.=C2=A0 If anyone has som= e kind of creativity in this space that they've been hiding, now's = the time.

-MSK
--00000000000053d94105ad3f4ce5-- From nobody Wed Aug 19 11:48:38 2020 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 0B3113A0925 for ; Wed, 19 Aug 2020 11:48:37 -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, 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 jEuvLNGeurQ7 for ; Wed, 19 Aug 2020 11:48:35 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 89DFC3A0882 for ; Wed, 19 Aug 2020 11:48:35 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id e20so7195279uav.3 for ; Wed, 19 Aug 2020 11:48:35 -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=Sp0cxRY8VfiABiO9yPwfQmWwIwEMBpvjhoql3ES+1NM=; b=lwzI3DIUQqdUwg2D13/WrG9teP6T8CY3L9wRjbhT7K22dBw/k8D6cDKWFVMbSU5PAt 0ZTWqOrwxWs0Fd4J+UayzVM3Mp4MRWEHA+dW+A0FjYSUVFMwo7RaI0LPwPuA12KzIe+G 9rdJyf9jNjiCT9yjDTNPZnviRbjIN3Uly/u5BEYC6JkJaDWz9XxIXw/1/hKSunWtJqWm VyYX+RPVm9umuBtwVmtrP9x8S8OWLiAgbV/Vcf5uYWFZ2UHNGjq2rOzLZh8Mv5WjCxVJ wl31S/vcYrxfwGC+4P0Wk1gCL/8BFulAuPEE+I+mRknI91nHB33gQW3/nGotP2oYyJr5 UbYQ== 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=Sp0cxRY8VfiABiO9yPwfQmWwIwEMBpvjhoql3ES+1NM=; b=PR9wDQkOqCr8ac5tpscPc7wKtMNFA0G7L3S2HQS6t3zeg8el7/hZWnUz2bPlN6opFF TeJGpMiA4h4mWW6Y5jLO4Da/810/K//UGKIDlSedV5subGoiUJXdRXoxDGe8wSBXtjFa K/wtYOjYckAnFUIr6yrGwwaJ3z2rKcARmLsSOYhVUXpAM+kEVLronJYuEOFPDu1wKowL WYupOnCB7TZ5Lgyh/ZPe9/IFMN12WE9HERcI8JEbFQcmYh83rYDu45GVrGL1wHxK4Vj0 Dh6MOb5fO+FZUFWYhDDsFkOELflEi9dBQQhOKcot/rK8AOoZkeKIND46ifGVVsUJ+XLL 14PA== X-Gm-Message-State: AOAM532KQT4aTaVEhAdjH1fgxzpHTN1C5k9mL8TREpObzcojdmWP/H9O UpgWBSoOJTVi8x9MfNXbUi6Bx0lqyR+ot+5PWas= X-Google-Smtp-Source: ABdhPJxs1JZzQlzwtfIrcbiXDnw9FyRUp+0EeYJL2z5Vm6BwW/ZHhhuiEjA+DKfVfDmitwcu+dWsGncwMmxfESXygmU= X-Received: by 2002:ab0:31ca:: with SMTP id e10mr14296465uan.76.1597862914457; Wed, 19 Aug 2020 11:48:34 -0700 (PDT) MIME-Version: 1.0 References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 19 Aug 2020 11:48:23 -0700 Message-ID: To: Dotzero Cc: John R Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006a833805ad3f7321" Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 18:48:37 -0000 --0000000000006a833805ad3f7321 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 10:08 AM Dotzero wrote: > On Wednesday, August 19, 2020, John R Levine wrote: > >> On Wed, 19 Aug 2020, Dotzero wrote: >> >>> Then Ericcson as an organization has made a decision regardless of the >>> objections of those employees. The correct thing for Ericcson as an >>> organization to do is to publish an internal policy that employees should >>> not use company mail for participating in mailing lists. An alternative >>> to >>> that would be for them to hire someone to help them come up with a >>> workable >>> approach. We both know plenty of people who could help them. >>> >> >> No doubt, but they're not going to do that. They want their employees to >> work on the IETF, the publish p=reject and they apparenty believe the >> contradiction is not their problem. So we're stuck with it. > > > For some definition of stuck. I happen to believe that > validators/receivers SHOULD generally respect policy assertions.. Mail list > operators should as well. Absent a functional and meaningful mechanism for > authorization of specific intermediaries by domains, that is the way to go. > If things break and users complain then those users should be told to > contact their mail administrator. Just saying. > If this only interfered with Ericsson's users, I might agree. But it recklessly interferes with third parties. To me, that's significant. > Yup. They want phishes, or in Yahoo's case expensive user complaints, to >> go away, they don't care about discussion lists one way or the other >> > > Perhaps they would care if users/customers complained and or walked. > Again, just saying. > Perhaps. But if they don't, is the current status quo implicitly okay? -MSK --0000000000006a833805ad3f7321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 10:08 AM Dotzero = <dotzero@gmail.com> wrote:
On Wednesday, August 19, 2020, John R Levine <johnl@taugh.com> wrote:
On Wed, 19 Aug 2020, Dotzero= wrote:
Then Ericcson as an organization has made a decision regardless of the
objections of those employees. The correct thing for Ericcson as an
organization to do is to publish an internal policy that employees should not use company mail for participating in mailing lists. An alternative to<= br> that would be for them to hire someone to help them come up with a workable=
approach. We both know plenty of people who could help them.

No doubt, but they're not going to do that.=C2=A0 They want their emplo= yees to work on the IETF, the publish p=3Dreject and they apparenty believe= the contradiction is not their problem.=C2=A0 So we're stuck with it.<= /blockquote>

For some definition of stuck. I happen to b= elieve that validators/receivers SHOULD generally respect policy assertions= .. Mail list operators should as well. Absent a functional and meaningful m= echanism for authorization of specific intermediaries by domains, that is t= he way to go. If things break and users complain then those users should be= told to contact their mail administrator. Just saying.=C2=A0

If this only interfered with Ericsson's users,= I might agree.=C2=A0 But it recklessly interferes with third parties.=C2= =A0 To me, that's significant.
=C2=A0
Yup.=C2=A0 They want phishes, or in Yahoo's case expensive user complai= nts, to go away, they don't care about discussion lists one way or the = other

Perhaps they would care if users/customers= complained and or walked. Again, just saying.

Perhaps.=C2=A0 But if they don't, is the= current status quo implicitly okay?

-MSK
--0000000000006a833805ad3f7321-- From nobody Wed Aug 19 12:11:12 2020 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 432AA3A0D46 for ; Wed, 19 Aug 2020 12:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=iecc.com header.b=khVcj3Oc; dkim=pass (2048-bit key) header.d=taugh.com header.b=lT7LhdFf 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 QnvC1tEWA7xe for ; Wed, 19 Aug 2020 12:11:09 -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 78B423A0BF6 for ; Wed, 19 Aug 2020 12:11:09 -0700 (PDT) Received: (qmail 41279 invoked from network); 19 Aug 2020 19:11:07 -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; s=a13c.5f3d794b.k2008; i=johnl-iecc.com@submit.iecc.com; bh=XYpzQNnH2avVSsY8WIuOqjRKrCET6vwbBlFT4I5Lt5g=; b=khVcj3Oc/kMwsHQj0pv9lPF7jcQGLdk2nwoLHacAHR+ARnUJVNOPTYE/UXwhf+fg7ubiz1WUGe+2246cosqZp262+QhLEmVEtCEjQl2nNQ6A1ZYhw8HvBZI0NZGBWXD4ii7nDiuVr9unxyHSbeuQc6CZl7R7ps9pz7O+/ZZ1cGhWKCUNkjZ3WyBB4NPIxLTliVdAFd4NdJrozqUAYhNH0DmSnM1zXCVWfr6BL+43FAgxC/QKaSy/ZcCO+YzfcHbpuDg+rLRBP/CGIsgaYSemezY24mmXlT/xAOYToBcitBI4rhDXfk35iC4s2/YSGagaexm0E8OIdCRSXoLa0XxamQ== 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; s=a13c.5f3d794b.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=XYpzQNnH2avVSsY8WIuOqjRKrCET6vwbBlFT4I5Lt5g=; b=lT7LhdFfBFegs6ENHZ4/FT/f2lqI71g5E3HcPbPa8VzHSbm0fE14hMG3Lm+9ZS834+N8CGvIxbyyQU8EOJXlTh8cvjB9lLVf+elkW1vl8av0UPcyI8lOzkBsBVb4zqEYQ9W3ElkV5vVNf+Rzv1P6JmiOO8gFTMedzPORdR6tOAWDUKANkJG97MKd1+a+VNwF8HGT6q7JetIiRa4sdCAmH+p2szDGjRZeiSbroWY0huJRfZrOa4EPVvbFyG850MJ84YeSbN/gXdwWkf/WQ3ZjPkk6CCg8VAwKN2xkocJwalErhcFpq8lJXLG9NKzRzCCvgfTLnzI3yhG9ahpLxP2n1w== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Aug 2020 19:11:06 -0000 Date: 19 Aug 2020 15:11:06 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" , "Dotzero" Cc: "dmarc@ietf.org" In-Reply-To: References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 19:11:11 -0000 On Wed, 19 Aug 2020, Murray S. Kucherawy wrote: > If this only interfered with Ericsson's users, I might agree. But it > recklessly interferes with third parties. To me, that's significant. Right. >> Yup. They want phishes, or in Yahoo's case expensive user complaints, to >>> go away, they don't care about discussion lists one way or the other >> >> Perhaps they would care if users/customers complained and or walked. >> Again, just saying. Sheesh, we went through this a decade ago. Approximately none of AOL or Yahoo's mail users pay for the service -- they're the product, not the customer. I know a fair number of people with AOL accounts, they're not super thrilled about AOL, but the cost of switching and telling all of their correspondents is huge. It is abundantly clear that Ericsson and AOL and Yahoo do not object to their users sending mail through discussion lists. Ericsson doesn't want their execs to be phished, AOLhoo doesn't want complaints "why am I getting spam from people I know." In each case we know from experience that their published p=reject doesn't describe their actual policy. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Aug 19 14:18:45 2020 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 3DC003A0B33 for ; Wed, 19 Aug 2020 14:18:43 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ_CKR9u1Feh for ; Wed, 19 Aug 2020 14:18:40 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A26B3A09C4 for ; Wed, 19 Aug 2020 14:18:40 -0700 (PDT) X-ASG-Debug-ID: 1597871917-11fa31095e45290001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id YcTh11rr9aNwMYkC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 19 Aug 2020 17:18:37 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=nCt6lrZ2yJsJCJu6+BglcUeILoQzodin4wZHANlexxQ=; b=KTAJAHNqMtM6M6rNkfey6A3irvcg73yUsE+TDON9i0zgFo07+uXQRPmAR0DtZmFkD R3VuzfKsRFBzy/cWHAhoCosP4v9knAXDFJ6XAkDwWayECHJakw42fnN/x7S6Mzbaw GMM73+WmvCMJMrMKyQTFYPoT54aAPxxrr3LFGCnNk= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Wed, 19 Aug 2020 21:18:29 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Reply-To: fosterd@bayviewphysicians.com Message-ID: <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=5ffc7be749d14f31886b80ad85a3530e In-Reply-To: References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> X-Exim-Id: 5d4e48f86ca7479ab4889ddff57a2870 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597871917 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 14207 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84017 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 21:18:43 -0000 This is a multipart message in MIME format. --5ffc7be749d14f31886b80ad85a3530e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My two cents. 1) What has changed since 2012 is DMARC, including the ability through DMAR= C to obtain feedback. "New ATPS" would have to be implemented as a DMARC o= ption, not a new thing. 2) A lot of organizations seem to be stick at p=3Dnone. Maybe that means = they want it that way. Maybe it means that they are being courteous to ma= iling lists. But maybe it means something about DMARC is too hard. I am= assuming that all of the problems with DMARC are related to third-party au= thorization, and something needs to be done to make it easier. 3) Delegation with an ATPS-type email entry seems functionally equivalent t= o DKIM scope delegation, with several benefits: Easier and cheaper for the third-party to implement. The third-party only= needs to apply its own domain's signature. Simpler means quicker impleme= ntation. Private keys are never exchanged. Third-party is only responsible for its own key. A big organization like= Constant Contact or SendGrid could end up holding hundreds of thousands of= DKIM keys, and that becomes an attractive target for attackers. If a dele= gated DKIM key store is stolen from a third party, the attacker knows every= domain that has been compromised. If an ATPS-delegated third party has a= corporate DKIM key stolen, the attacker knows that he has struck pay-dirt,= but he does not have an immediate enumeration of compromised organizations= . That enumeration will require an additional data collection process, wh= ich might buy time for the affected organizations to take evasive measures. An ATPS-type scope delegation could be designated for a specific user, whic= h I assume will represents an application. ("SMTP address must be applicati= onname@vendordomain"). This information is something that the receiving s= ystem can enforce and report. It is a weak enforcement tool, but limiting= scope of delegation seems likely to satisfy some of the auditor concerns a= ssociated with any third-party delegation. This is also a new ideas relati= ve to the original ATPS. Of course, a domain level delegation should also= be an option for situations that the authorizing domain deems appropriate.= ("SMTP address must be *@vendordomain") ATPS-type delegations could be given a pre-defined expire date (if specifie= d with that feature). This would be particularly appropriate where a third= -party authorization is linked to a time-limited contract. When the contr= act lapses, the authorization lapses, unless both the contract and the DNS = entry are renewed. This limits risk associated with the possibility of de= legated-but-forgotten authorizations. DKIM delegations are always good-ti= l-cancelled (by removing the DNS public key). Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS= propagation. DKIM delegation becomes impossible if the third-party is not cooperative. = ATPS-type delegation can be done unilaterally by the owning domain. I a= m thinking of Proofpoint in particular. They violate my DMARC policy when= my users, who are non-clients, respond to a secure message from one of the= ir clients. Author self-copies arrive at my gateway looking like spoof, b= ut I can fix this with local policy. When my user uses reply-all to a mes= sage with many recipients, those other domains will see my p=3Dreject, whic= h may mean that messages are not delivered and my user does not know that i= t happened. Maybe all those other domains will have a Proofpoint exceptio= n as well, impossible to say. Maybe Proofpoint will begin header munging,= but they have not done so yet. So the big benefit for DKIM is the i=3D clause, but I think the sender-limi= ting potential with ATPS is superior to the impersonation-limiting capabili= ty of DKIM. Besides, it seems generally agreed that i=3D has very limited= use. On all other risk-management concerns, an ATPS -type signature seem= s preferable. Implementation obstacles and notes: When a domain implements an ATPS signature, it must set the corresponding D= MARC policy to p=3Dnone. Otherwise, sites that are DMARC-aware but ATPS-bl= ind will block ATPS-authoized transactions. Consequently, this option wil= l only interest organizations that are currently at p=3Dnone or that have n= o DMARC policy. If a new feature such as ATPS is implemented, senders have a problem knowin= g whether their recipients understand it or not. This dilemma would be he= lped if recipients published a DNS token to indicate that they understand t= he new feature. Some will consider this inappropriate information disclos= ure, although I am currently having a hard time seeing the risk in the rele= ase of that information. By and large, senders will want confidence that= the new feature is widely deployed before they will begin depending on it = for outbound delivery. In the absence of recipient reporting, change may= never happen. Doug Foster ---------------------------------------- From: "Murray S. Kucherawy" Sent: 8/19/20 2:38 PM To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing l= ist On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b) wrote= : On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely wrote: On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > The industry in general, and the IETF in particular, have chosen not > to pursue widespread use of any kind of standards-based third party > domain signature policy or reputation system. . . > Both ATPS (individual submission, experimental, February 2012) and the > REPUTE series of documents (working group, standards track, late 2013) > saw nearly zero adoption after publication even when free reference > implementations were provided. They differ from basic DKIM in that > they require non-trivial upkeep, and that appears to be a step > function inhibiting adoption among operators. We can still try again. In particular, the non-trivial upkeep seems to be a valid diagnosis. Is there anything which has materially changed between 2012-13 and 2020 whi= ch would indicate that the anticipated results for such effort would be any= different? +1. If anyone has some kind of creativity in this space that they've been = hiding, now's the time. -MSK --5ffc7be749d14f31886b80ad85a3530e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
My two cents.


1) What has changed since 2012 is DMARC= , including the ability through DMARC to obtain feedback.  "New ATPS" = would have to be implemented as a DMARC option, not a new thing.
=
2) A lot of organizations seem to be stick at p=3Dnone. &nbs= p; Maybe that means they want it that way.   Maybe it means that they = are being courteous to mailing lists.   But maybe it means something a= bout DMARC is too hard.   I am assuming that all of the problems with = DMARC are related to third-party authorization, and something needs to be d= one to make it easier.

3) Delegation with an ATPS-= type email entry seems functionally equivalent to DKIM scope delegation, wi= th several benefits:
  • Easier and cheaper for the third-party to= implement.   The third-party only needs to apply its own domain's sig= nature.   Simpler means quicker implementation.  Private keys are= never exchanged.

  • Third-party is only responsible for its o= wn key.    A big organization like Constant Contact or SendGrid c= ould end up holding hundreds of thousands of DKIM keys, and that becomes an= attractive target for attackers.  If a delegated DKIM key store is st= olen from a third party, the attacker knows every domain that has been comp= romised.   If an ATPS-delegated third party has a corporate DKIM key s= tolen, the attacker knows that he has struck pay-dirt, but he does not have= an immediate enumeration of compromised organizations.   That enumera= tion will require an additional data collection process, which might buy ti= me for the affected organizations to take evasive measures.

    • An ATPS-type scope delegation could be designated for a specific user, whi= ch I assume will represents an application. ("SMTP address must be applicat= ionname@vendordomain").   This information is something that the recei= ving system can enforce and report.   It is a weak enforcement tool, b= ut limiting scope of delegation seems likely to satisfy some of the auditor= concerns associated with any third-party delegation.  This is also a = new ideas relative to the original ATPS.   Of course, a domain level d= elegation should also be an option for situations that the authorizing doma= in deems appropriate.  ("SMTP address must be *@vendordomain")

    =
  • ATPS-type delegations could be given a pre-defined expire date (if= specified with that feature).  This would be particularly appropriate= where a third-party authorization is linked to a time-limited contract. &n= bsp; When the contract lapses, the authorization lapses, unless both the co= ntract and the DNS entry are renewed.   This limits risk associated wi= th the possibility of delegated-but-forgotten authorizations.   DKIM d= elegations are always good-til-cancelled (by removing the DNS public key).<= br>
  • Both DKIM and ATPS can be revoked easily, subject only to t= he limits of DNS propagation.

  • DKIM delegation becomes impos= sible if the third-party is not cooperative.   ATPS-type delegation ca= n be done unilaterally by the owning domain.    I am thinking of = Proofpoint in particular.   They violate my DMARC policy when my users= , who are non-clients, respond to a secure message from one of their client= s.   Author self-copies arrive at my gateway looking like spoof, but I= can fix this with local policy.   When my user uses reply-all to a me= ssage with many recipients, those other domains will see my p=3Dreject, whi= ch may mean that messages are not delivered and my user does not know that = it happened.   Maybe all those other domains will have a Proofpoint ex= ception as well, impossible to say.   Maybe Proofpoint will begin head= er munging, but they have not done so yet.
So the big benefit= for DKIM is the i=3D clause, but I think the sender-limiting potential wit= h ATPS is superior to the impersonation-limiting capability of DKIM.  = Besides, it seems generally agreed that i=3D has very limited use.   = On all other risk-management concerns, an ATPS -type signature seems prefer= able.


Implementation obstacles and = notes:

When a domain implements an ATPS signature,= it must set the corresponding DMARC policy to p=3Dnone.  Otherwise, s= ites that are DMARC-aware but ATPS-blind will block ATPS-authoized transact= ions.   Consequently, this option will only interest organizations tha= t are currently at p=3Dnone or that have no DMARC policy.

If a new feature such as ATPS is implemented, senders have a proble= m knowing whether their recipients understand it or not.   This dilemm= a would be helped if recipients published a DNS token to indicate that they= understand the new feature.   Some will consider this inappropriate i= nformation disclosure, although I am currently having a hard time seeing th= e risk in the release of that information.    By and large, sende= rs will want confidence that the new feature is widely deployed before they= will begin depending on it for outbound delivery.    In the abse= nce of recipient reporting, change may never happen.


Doug Foster



<= /div>

From: "Murray S. Kucherawy" <superuser@gmail.com>
Sent: 8/19/20 2:38 PM
To: "Kurt Andersen (b)" <kb= oth@drkurt.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.= org>, Alessandro Vesely <vesely@tana.it>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Wed, Aug 19, 2020 at 10:11 = AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely <vesely@tana.it> wrote:
On = Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> The indus= try in general, and the IETF in particular, have chosen not
> to purs= ue widespread use of any kind of standards-based third party
> domain= signature policy or reputation system. . .

> Both ATPS (individu= al submission, experimental, February 2012) and the
> REPUTE series o= f documents (working group, standards track, late 2013)
> saw nearly = zero adoption after publication even when free reference
> implementa= tions were provided. They differ from basic DKIM in that
> they requ= ire non-trivial upkeep, and that appears to be a step
> function inhi= biting adoption among operators.

We can still try again. In particu= lar, the non-trivial upkeep seems
to be a valid diagnosis.
<= div>
Is there anything which has materially changed between 2= 012-13 and 2020 which would indicate that the anticipated results for such = effort would be any different?

+1.  If anyone has some kind of creativity in this space that th= ey've been hiding, now's the time.

-MSK
--5ffc7be749d14f31886b80ad85a3530e-- From nobody Wed Aug 19 15:32:10 2020 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 1D85F3A0EB0 for ; Wed, 19 Aug 2020 15:32: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=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 TysEP4hb-uis for ; Wed, 19 Aug 2020 15:32:07 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 B02EF3A0EAE for ; Wed, 19 Aug 2020 15:32:07 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id g14so418309iom.0 for ; Wed, 19 Aug 2020 15:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h5p95sfjuA76Q94y79gwsFPD+CQqaLcoq0Y6ulwiMaE=; b=LOJoyClJTH0+1sMJvV3O7sB8X+J2GJB1qLaUHo03Za8+H8BgMaNE9UrVMpYMNpNjBt rsVZ9kWgc0yH923gqaSJUSRW5+6Dx44erjONgZtZ48iajQ/w6gjBBfYIOK9g4aRpcuFA ySUdK52QhP+xtIbyWNFfzU0bwHaleBqqcsGww= 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=h5p95sfjuA76Q94y79gwsFPD+CQqaLcoq0Y6ulwiMaE=; b=WTBsPVbjIYhkbxL+rdB10fUeBYuZG6Om3t57CpyYYRC4vaWqxCrtv++7empLImF1zL 4KRiLqiHDxPGxqihYifEbeLxArqmqKmFVHpS1xUoqlUZ1HGvkrHDs//DASVZe6sCLt9X ixoX6VNfg1Fn0QhZZSfQ6REaUULzVB9s5wd0P1yKKjpHFh1CQQQA6O61p2lt7TZFnLC8 JPtG9mWlCeJ0/85jcLMMQlt+a+19U/jGlyu+LUWqwYmy1EXcYtmbyfIyKlYQ+zfSdfL+ dbbdjvhAXMcdtlvQLA+Ua0w55QxyIlJPbOGOCv/1RIioRwxhU17VzOGInkbQAhsbTUMZ qWcw== X-Gm-Message-State: AOAM530gOr1AKDxMjaFSy12G7amh7b3GM2PhdsspzizPGq7kcfaAzPLX 709+WhayjueObgZQtv0wu6VOx9Flm0lefmur9IEcLQ== X-Google-Smtp-Source: ABdhPJwWx0pWRaKUF5FLAIQlmovPequ/UY5DXY1fkchfSZo28OaM4qu+qsWs/Q/zgW2S6JuOC/wMiAfC1njT9riVmQ4= X-Received: by 2002:a05:6602:14c1:: with SMTP id b1mr104519iow.163.1597876326919; Wed, 19 Aug 2020 15:32:06 -0700 (PDT) MIME-Version: 1.0 References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 19 Aug 2020 15:31:24 -0700 Message-ID: To: John R Levine Cc: "Murray S. Kucherawy" , Dotzero , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dc8f8705ad4292ba" Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 22:32:09 -0000 --000000000000dc8f8705ad4292ba Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 12:11 PM John R Levine wrote: > > It is abundantly clear that Ericsson and AOL and Yahoo do not object to > their users sending mail through discussion lists. Ericsson doesn't want > their execs to be phished, AOLhoo doesn't want complaints "why am I > getting spam from people I know." In each case we know from experience > that their published p=reject doesn't describe their actual policy. > When domains have only three sizes of DMARC policy hammers, there aren't a lot of options to handle loose screws...though I still haven't heard any wormhole protocol suggestions which seem like viable mechanisms at scale or which would allow the organizations you cite to express the nuances of their presumptive "actual polic[ies]". --Kurt --000000000000dc8f8705ad4292ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 12:11 PM John R L= evine <johnl@taugh.com> wrote:=

It is abundantly clear that Ericsson and AOL and Yahoo do not object to their users sending mail through discussion lists.=C2=A0 Ericsson doesn'= ;t want
their execs to be phished, AOLhoo doesn't want complaints "why am = I
getting spam from people I know."=C2=A0 In each case we know from expe= rience
that their published p=3Dreject doesn't describe their actual policy.

When domains=C2=A0have only three sizes = of DMARC policy hammers, there aren't a lot of options to handle loose = screws...though I still haven't heard any wormhole protocol suggestions= which seem like viable mechanisms at scale or which would allow the=C2=A0o= rganizations you cite to express the=C2=A0nuances of their presumptive &quo= t;actual polic[ies]".

--Kurt=C2=A0
--000000000000dc8f8705ad4292ba-- From nobody Wed Aug 19 17:07:04 2020 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 811A23A0FAC for ; Wed, 19 Aug 2020 17:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 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_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.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 YcUP8ZMjhdG6 for ; Wed, 19 Aug 2020 17:07:02 -0700 (PDT) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 3E51C3A0FA5 for ; Wed, 19 Aug 2020 17:07:02 -0700 (PDT) Received: from pps.filterd (m0167073.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07K071Gc021978 for ; Wed, 19 Aug 2020 20:07:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : content-type; s=pps01; bh=vUxJLpt3cA7TBrNZLv2g+YlpwDHsKtgPlvn1cLbWKzc=; b=c/+5l/j6IbZLTF/E/1fUXTI6kNaHFB1rwQGmnZCpLGgrzwsMqb81L4rR2TRUxJz2l3SU x5NcGVIoYwiAhPf08r0qxw7JYXIstK6QG99Ud2BjMjKHSDiMeu7NmO3ywRG/DI+Nq8jM wsPTSKlH2IiuX806R+MWONVaHhIY/2qFn/nBTPsVp+dhsOEb3ZOydV1wJm3cvXrTpJZ1 eVsZTmkWvF3gPYPVRbaCE3dHEvUkPtc6+YqPhHst16gL6bQQw6Z8XeEzcSOcWIMrLYD9 oNsfqNeg1epWcxBYEkvKGOCRYRplzPjekt+e0OWx3TTr7MZ6lhqcc4KQWOJNJAfpQl7r TQ== Received: from sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0b-00364e01.pphosted.com with ESMTP id 3304nv4uyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Aug 2020 20:07:01 -0400 Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 07K070uB048773 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 19 Aug 2020 20:07:00 -0400 Received: by mail-io1-f69.google.com with SMTP id z25so124302ioh.21 for ; Wed, 19 Aug 2020 17:07:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vUxJLpt3cA7TBrNZLv2g+YlpwDHsKtgPlvn1cLbWKzc=; b=hStbKK2C/iwXKVpc0u3SiNg2QGXVZi1/dAkB+vEZbfbi7lWKwRLFFpur7BCCmRifGG tlCNVlOksm2p1xIR26dk9guT+xYN6+g0bHzBmkHmRnTuRD6HZN3YZtiqUd1aVignTI6a gAGa3y9Y9KDigJx4qnr7PGir6lc5Vux5WXVakUx1nZ8/uKGU9gj0k18fiyXIVQcFChFh MbmmHLB5IeYZQRmQWxyoso5kc7scNS0hDilSnZQtuln+7RCt0/8sTSWAgk/Z+I0r/58l XGCZa03Mw/u5wSGWts4DEu0MlwjZirNSKT0PvMGxKX8rI26DBwCifsoZd9u/EHw5bA+d 0c0Q== X-Gm-Message-State: AOAM530LLXd+yKuuL6S2n2QX7ISGODyVKyD0dEqQgkYp1pCUuO2d15P4 R1UZDhSosbTi7BrPEHyt8uHiMJJ+oaR6wd7z7J3N27OzZOJ2llWMeNG8RUKadTXsNSMyv+D8f0y kFH9mluritahXWodiunIz9yjdxlsocw== X-Received: by 2002:a05:6638:22d0:: with SMTP id j16mr811726jat.97.1597882019606; Wed, 19 Aug 2020 17:06:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKbeGm8Nss0G21DHgg/wTv1Omp42T8M0hlhKroKHUoPrz+N38tHt2hlMHX//uAxsUlzKunw+EUW8Uq+u2MKjI= X-Received: by 2002:a05:6638:22d0:: with SMTP id j16mr811700jat.97.1597882019217; Wed, 19 Aug 2020 17:06:59 -0700 (PDT) MIME-Version: 1.0 References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> In-Reply-To: From: Joseph Brennan Date: Wed, 19 Aug 2020 20:06:48 -0400 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000026298b05ad43e6d7" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-19_13:2020-08-19, 2020-08-19 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 00:07:04 -0000 --00000000000026298b05ad43e6d7 Content-Type: text/plain; charset="UTF-8" I've been running email servers for 25 years. My number 1 priority is that legitimate mail gets through. Stopping the bad stuff is very important but not number 1. Does DMARC causes legitimate mail to fail? Yes, so to me it's a fail. I can understand the transactional mail case, as I stated in previous messages. The burden is on the businesses implementing DMARC protection to inform customers to give their real end-point email addresses and not any vanity forwarding services. Any two sides can agree between them on some optional additional security measure. It's a good thing. For general end-user mail? It's a bad thing. It will cause email to fail, and it will cause people not drinking the DMARC kool-aid to implement crazy non-standard things with From headers to make email work the way it should work without crazy workarounds. I see no reason that the DMARC standard should not spell out explicitly the use case that it is intended to meet, and recommend against using it for other use cases. I realize that this was said ten years ago (or whatever it was) when yahoo/aol began abusing DMARC. But see how that went. The problem was not really DMARC at all, it was abuse of DMARC. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --00000000000026298b05ad43e6d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I've been running email serv= ers for 25 years. My number=C2=A01 priority is that legitimate mail gets th= rough. Stopping the bad stuff is very important but not number=C2=A01. Does= DMARC causes legitimate mail to fail? Yes, so to me it's a fail.
=

I can understand the transactional mail case, as I stat= ed in previous=C2=A0messages. The burden is on the=C2=A0businesses implemen= ting=C2=A0DMARC protection to inform customers to give their real end-point= email addresses and not any vanity forwarding=C2=A0services. Any two sides= can agree between them on some optional additional security measure. It= 9;s a good thing.

For general end-user mail? It= 9;s a bad thing. It will cause email to fail, and it will cause people not = drinking the DMARC kool-aid to implement=C2=A0crazy non-standard things wit= h From headers to make email work the way it should=C2=A0work without crazy= workarounds. I see no reason that the DMARC standard should not spell out = explicitly the use case that it is intended to meet, and recommend against= =C2=A0using it for other use cases.

I realize that= this was said ten years ago (or whatever it was) when yahoo/aol began abus= ing DMARC. But see how that went. The problem was not really DMARC at all, = it was abuse of DMARC.


--=C2=A0
=
Joseph = Brennan
Lead, Email and Systems Applications
Columbia Universi= ty Information Technology

<= br>
--00000000000026298b05ad43e6d7-- From nobody Wed Aug 19 19:34:53 2020 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 61BA93A106E for ; Wed, 19 Aug 2020 19:34:52 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyVX8VaaFq28 for ; Wed, 19 Aug 2020 19:34:50 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA473A1068 for ; Wed, 19 Aug 2020 19:34:50 -0700 (PDT) X-ASG-Debug-ID: 1597890888-11fa31095e46fc0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Wyguv3acPLHWFY2d (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 19 Aug 2020 22:34:48 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=cwJ3ctjTK431W24fePntANWAV857La3ySZzawZKXumg=; b=UZxLEttb0zfZ4nf0Z36TBTt9gKrIDk84FqiQ8omEEExwFhBOwz5W6uxaTdyf54J9g cr9WdfPtwygv/TTfZaeKLmDU1lPGmIY8njGLSxNbecpzAE93LS/oQieL2qI+acJYT WRn4t4V/f4HX140SvXCeuUo9rSmIWW44cGDGXjltc= From: "Douglas E. Foster" To: "Joseph Brennan" , "dmarc@ietf.org" Date: Thu, 20 Aug 2020 02:34:42 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 Reply-To: fosterd@bayviewphysicians.com Message-ID: <46c4c4429427470e9c5a7f66683292fa@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ef6eb4aa41e34e1986762e10639bdb0a In-Reply-To: References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> X-Exim-Id: 46c4c4429427470e9c5a7f66683292fa X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1597890888 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 8569 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84022 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 02:34:52 -0000 This is a multipart message in MIME format. --ef6eb4aa41e34e1986762e10639bdb0a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For incoming mail, you determine what constitutes legitimate mail. You c= hoose whether to enforce DMARC generally. If you enforce DMARC at all, you= also choose what exceptions to apply. But outgoing mail is different. The sender has no guarantee of delivery. = The sender has to convince the recipient that the message is legitimate a= nd desirable. (Plenty of advertising messages are sent legitimately, but s= till get blocked by my spam filters.) For mailing list mail, there are two messages. The first one goes from yo= ur user to the mailing list. The mailing list has various rules about whet= her the message is acceptable or not. For openers, the sender must be a r= egistered subscriber to the list. Additionally, there may be limits on at= tachments or limits on swear words. The subscriber knows these rules, or= learns them quickly, and complies. The second message is from the mailing list to the subscribers. As with e= very other message, the mailing list sender needs to determine host to sati= sfy the requirements of the recipient system. Maybe the recipient system = has a longer list of swear words. Or maybe the recipient system enforces = DMARC. Whatever the rule, the burden is on the sending mailing list to ge= t the message delivered by satisfying the screening criteria of the recipie= nt systems. One important way to demonstrate legitimacy is to provide a verifiable iden= tity. Verified identity allows a reputation to be assigned, which then det= ermines which content filtering rules will (or will not) be applied. If a= mailing list knows that the recipient requires a verified identity, but fa= ils to provide a verifiable identity, whose fault is it when the message do= es not get delivered? The working assumptions are that a mailing list must alter the received con= tent, the mailing list must not reformat the From address, and nonetheless = the recipient system must assume, without supporting evidence, that the mes= sage is legitimate. Assuming that mailing lists deserve a privileged role, we still need a way = to demonstrate that any specific message deserves that role because it is f= rom a trusted mailing list and not from an attacker. Doug Foster ---------------------------------------- From: Joseph Brennan Sent: 8/19/20 8:07 PM To: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dm= arc-sender-01 I've been running email servers for 25 years. My number 1 priority is that = legitimate mail gets through. Stopping the bad stuff is very important but = not number 1. Does DMARC causes legitimate mail to fail? Yes, so to me it's= a fail. I can understand the transactional mail case, as I stated in previous messa= ges. The burden is on the businesses implementing DMARC protection to infor= m customers to give their real end-point email addresses and not any vanity= forwarding services. Any two sides can agree between them on some optional= additional security measure. It's a good thing. For general end-user mail? It's a bad thing. It will cause email to fail, a= nd it will cause people not drinking the DMARC kool-aid to implement crazy = non-standard things with From headers to make email work the way it should = work without crazy workarounds. I see no reason that the DMARC standard sho= uld not spell out explicitly the use case that it is intended to meet, and = recommend against using it for other use cases. I realize that this was said ten years ago (or whatever it was) when yahoo/= aol began abusing DMARC. But see how that went. The problem was not really = DMARC at all, it was abuse of DMARC. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --ef6eb4aa41e34e1986762e10639bdb0a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
For incoming mail,= you determine what constitutes legitimate mail.    You choose wh= ether to enforce DMARC generally.  If you enforce DMARC at all, you al= so choose what exceptions to apply.

But outgoing m= ail is different.   The sender has no guarantee of delivery.   Th= e sender has to convince the recipient that the message is legitimate and d= esirable.  (Plenty of advertising messages are sent legitimately, but = still get blocked by my spam filters.)

For mailing= list mail, there are two messages.   The first one goes from your use= r to the mailing list.  The mailing list has various rules about wheth= er the message is acceptable or not.   For openers, the sender must be= a registered subscriber to the list.   Additionally, there may be lim= its on attachments or limits on swear words.    The subscriber kn= ows these rules, or learns them quickly, and complies.

=
The second message is from the mailing list to the subscribers.  = As with every other message, the mailing list sender needs to determine ho= st to satisfy the requirements of the recipient system.   Maybe the re= cipient system has a longer list of swear words.   Or maybe the recipi= ent system enforces DMARC.   Whatever the rule, the burden is on the s= ending mailing list to get the message delivered by satisfying the screenin= g criteria of the recipient systems.

One important= way to demonstrate legitimacy is to provide a verifiable identity.  V= erified identity allows a reputation to be assigned, which then determines = which content filtering rules will (or will not) be applied.   If a ma= iling list knows that the recipient requires a verified identity, but fails= to provide a verifiable identity, whose fault is it when the message does = not get delivered?

The working assumptions are tha= t a mailing list must alter the received content, the mailing list must not= reformat the From address, and nonetheless the recipient system must assum= e, without supporting evidence, that the message is legitimate.   = ;

Assuming that mailing lists deserve a privileged= role, we still need a way to demonstrate that any specific message deserve= s that role because it is from a trusted mailing list and not from an attac= ker.

Doug Foster


From: Joseph Brennan <brennan@columbia.edu>
<= strong>Sent: 8/19/20 8:07 PM
To: "dmarc@ietf.o= rg" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Re= visiting the Race Condition in draft-crocker-dmarc-sender-01

I've been running email servers fo= r 25 years. My number 1 priority is that legitimate mail gets through.= Stopping the bad stuff is very important but not number 1. Does DMARC= causes legitimate mail to fail? Yes, so to me it's a fail.

<= /div>
I can understand the transactional mail case, as I stated in prev= ious messages. The burden is on the businesses implementing = DMARC protection to inform customers to give their real end-point email add= resses and not any vanity forwarding services. Any two sides can agree= between them on some optional additional security measure. It's a good thi= ng.

For general end-user mail? It's a bad thing. I= t will cause email to fail, and it will cause people not drinking the DMARC= kool-aid to implement crazy non-standard things with From headers to = make email work the way it should work without crazy workarounds. I se= e no reason that the DMARC standard should not spell out explicitly the use= case that it is intended to meet, and recommend against using it for = other use cases.

I realize that this was said ten = years ago (or whatever it was) when yahoo/aol began abusing DMARC. But see = how that went. The problem was not really DMARC at all, it was abuse of DMA= RC.


-- 
Joseph Brennan
Lead, Email= and Systems Applications
Columbia University Information Technol= ogy


--ef6eb4aa41e34e1986762e10639bdb0a-- From nobody Thu Aug 20 01:58:50 2020 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 E6AAC3A0A3A for ; Thu, 20 Aug 2020 01:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 zUFbZJQaJw2E for ; Thu, 20 Aug 2020 01:58:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 CC9C43A0A41 for ; Thu, 20 Aug 2020 01:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597913922; bh=GBCWSmWeHBg1vTa2qlwgSNSLmy/bPOnn1VwYAhTgzLU=; l=8184; h=To:References:From:Date:In-Reply-To; b=BkvGhcbJiPuQOvJlOqDUUNHhwz2e+VVQ8mUXqWrpqZPYhrGZSQgKrtsz6aaN6itcR F2H7mwBCgkqQui/LjsNvjrndiTEbdefV8oOVKEgYvCXBLjWKyK1z7laOiBIfKHnpFp X3Y9Qugx+MK+LMJ+diPhwBezLU5i/AwbeUtTCNXTmU4qdpLK1d8JBIGziXILt Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.180]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F3E3B41.00002B8F; Thu, 20 Aug 2020 10:58:41 +0200 To: dmarc@ietf.org, Tim Draegen References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> From: Alessandro Vesely Message-ID: <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> Date: Thu, 20 Aug 2020 10:58:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 08:58:49 -0000 Hi Tim and all, I am wondering whether companies like Dmarcian could implement third-pary whitelisting. As they receive and analyze DMARC aggregate reports on behalf of many mail sites, they probably are able to distinguish various level of authentication failures, from mailing lists to misaligned ESPs, to actual abusers. In that case, they could maintain a whitelist tailored for any given client. The client would set, say: _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:client-id@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]" A receiver seeing a failed From: user@client.domain.example, but an authenticated Sender: whatever@example.com could check authorization by querying the following record: example.com.client-id.rhswl.dmarcian.com IN A 127.0.0.2 If the record exists, the sender is authorized. That way, a Dmarcian client can run for some time with p=none. Meanwhile Dmarcian fills the client's whitelist based on misaligned authentications and the client's desiderata. When the list is complete and receivers upgraded, the client can switch to p=reject or whatever they like. Delivery would still lag in case, say, users subscribe to mailing lists not yet whitelisted, unless we make provisions for whitelisting requests to be submitted at subscription time. For domain names longer than 200 octects (punycode), a whitelist may replace the domain name with a hash, á la ATPS. The above setting overcomes the diagnosed non-trivial upkeep which prevented the diffusion of previous schemes. Best Ale -------- Original Message -------- Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Date: Wed, 19 Aug 2020 21:18:29 GMT From: Douglas E. Foster Reply-To: fosterd@bayviewphysicians.com To: dmarc@ietf.org My two cents. 1) What has changed since 2012 is DMARC, including the ability through DMARC to obtain feedback. "New ATPS" would have to be implemented as a DMARC option, not a new thing. 2) A lot of organizations seem to be stick at p=none. Maybe that means they want it that way. Maybe it means that they are being courteous to mailing lists. But maybe it means something about DMARC is too hard. I am assuming that all of the problems with DMARC are related to third-party authorization, and something needs to be done to make it easier. 3) Delegation with an ATPS-type email entry seems functionally equivalent to DKIM scope delegation, with several benefits: Easier and cheaper for the third-party to implement. The third-party only needs to apply its own domain's signature. Simpler means quicker implementation. Private keys are never exchanged. Third-party is only responsible for its own key. A big organization like Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM keys, and that becomes an attractive target for attackers. If a delegated DKIM key store is stolen from a third party, the attacker knows every domain that has been compromised. If an ATPS-delegated third party has a corporate DKIM key stolen, the attacker knows that he has struck pay-dirt, but he does not have an immediate enumeration of compromised organizations.. That enumeration will require an additional data collection process, which might buy time for the affected organizations to take evasive measures. An ATPS-type scope delegation could be designated for a specific user, which I assume will represents an application. ("SMTP address must be applicationname@vendordomain"). This information is something that the receiving system can enforce and report. It is a weak enforcement tool, but limiting scope of delegation seems likely to satisfy some of the auditor concerns associated with any third-party delegation. This is also a new ideas relative to the original ATPS. Of course, a domain level delegation should also be an option for situations that the authorizing domain deems appropriate. ("SMTP address must be *@vendordomain") ATPS-type delegations could be given a pre-defined expire date (if specified with that feature). This would be particularly appropriate where a third-party authorization is linked to a time-limited contract. When the contract lapses, the authorization lapses, unless both the contract and the DNS entry are renewed. This limits risk associated with the possibility of delegated-but-forgotten authorizations. DKIM delegations are always good-til-cancelled (by removing the DNS public key). Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS propagation. DKIM delegation becomes impossible if the third-party is not cooperative. ATPS-type delegation can be done unilaterally by the owning domain. I am thinking of Proofpoint in particular. They violate my DMARC policy when my users, who are non-clients, respond to a secure message from one of their clients. Author self-copies arrive at my gateway looking like spoof, but I can fix this with local policy. When my user uses reply-all to a message with many recipients, those other domains will see my p=reject, which may mean that messages are not delivered and my user does not know that it happened. Maybe all those other domains will have a Proofpoint exception as well, impossible to say. Maybe Proofpoint will begin header munging, but they have not done so yet. So the big benefit for DKIM is the i= clause, but I think the sender-limiting potential with ATPS is superior to the impersonation-limiting capability of DKIM. Besides, it seems generally agreed that i= has very limited use. On all other risk-management concerns, an ATPS -type signature seems preferable. Implementation obstacles and notes: When a domain implements an ATPS signature, it must set the corresponding DMARC policy to p=none. Otherwise, sites that are DMARC-aware but ATPS-blind will block ATPS-authoized transactions. Consequently, this option will only interest organizations that are currently at p=none or that have no DMARC policy. If a new feature such as ATPS is implemented, senders have a problem knowing whether their recipients understand it or not. This dilemma would be helped if recipients published a DNS token to indicate that they understand the new feature. Some will consider this inappropriate information disclosure, although I am currently having a hard time seeing the risk in the release of that information. By and large, senders will want confidence that the new feature is widely deployed before they will begin depending on it for outbound delivery. In the absence of recipient reporting, change may never happen. Doug Foster ---------------------------------------- From: "Murray S. Kucherawy" Sent: 8/19/20 2:38 PM To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b) wrote: On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely wrote: On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > The industry in general, and the IETF in particular, have chosen not > to pursue widespread use of any kind of standards-based third party > domain signature policy or reputation system. . . > Both ATPS (individual submission, experimental, February 2012) and the > REPUTE series of documents (working group, standards track, late 2013) > saw nearly zero adoption after publication even when free reference > implementations were provided. They differ from basic DKIM in that > they require non-trivial upkeep, and that appears to be a step > function inhibiting adoption among operators. We can still try again. In particular, the non-trivial upkeep seems to be a valid diagnosis. Is there anything which has materially changed between 2012-13 and 2020 which would indicate that the anticipated results for such effort would be any different? +1. If anyone has some kind of creativity in this space that they've been hiding, now's the time. -MSK From nobody Thu Aug 20 02:46:36 2020 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 0D40D3A03F4 for ; Thu, 20 Aug 2020 02:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 q28mUeeUmNeb for ; Thu, 20 Aug 2020 02:46:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 48A3D3A02BD for ; Thu, 20 Aug 2020 02:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1597916787; bh=ugP5EZsNwVcsE3iFRr3eYUWQiepSSl91C+KX02kV7kc=; l=310; h=To:References:From:Date:In-Reply-To; b=DLtAhO8C+/dMh/wuu6TD1VZ6FvV2RfgZ/J/ewwxLdx9zVTnGgaBdsSFwxrAOQy1L1 C21VEYTLKs/IlWK8pa56R+MHSE5uAwMVPDrrObWja7ipkK9LNzdRV1vGKbKpgP2XmV 47VNxIeFBIocZX8FHNKueuV8anLUj1YIaVlPHD8nOxrzfxVzRyn77278en672 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.69.180]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F3E4672.0000315C; Thu, 20 Aug 2020 11:46:26 +0200 To: dmarc@ietf.org References: <20200819004724.16EE11EED520@ary.local> <8e939d83-3cc8-3989-4e48-7e79e7e86973@taugh.com> <73cb2f8c-5f9-8fa2-6b13-3ec9318f2c5@taugh.com> From: Alessandro Vesely Message-ID: Date: Thu, 20 Aug 2020 11:46:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Revisiting the Race Condition in draft-crocker-dmarc-sender-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 09:46:35 -0000 On Thu 20/Aug/2020 02:06:48 +0200 Joseph Brennan wrote: > The problem was not really DMARC at all, it was abuse of DMARC. Again, in that case we should devise a new protocol which /potentially/ allows all email domains to be protected. And I'd still call such new protocol DMARC... Best Ale -- From nobody Thu Aug 20 09:45:37 2020 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 CFB913A0975; Thu, 20 Aug 2020 09:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyFLqgpOJZ03; Thu, 20 Aug 2020 09:45:33 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110115.outbound.protection.outlook.com [40.107.11.115]) (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 753BA3A0969; Thu, 20 Aug 2020 09:45:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MtjeUq0Ez9LYfwbpqd9rB/Kdl+2m5k/ZoVyrc1SB9r2YtSSCIuqiLgyLYLdGjSenljrZvJRsmdWkGlsty/pu54Mt+R9OZpQAIF2/3gwN7+Qz2tELOJVtlUGhB0jTJ4lTFv7s6fwAb0aecg+T4gjDWNsF87aPkI4oSVIzGSFFvxbde1Scpek55Ouy9LpPNFpqhtg4fQnTbKFw/LWwqEaTgGsiqfqWDFi94Nn27ImwBSLy7uakj0TtlCg4Qley2hj9/RFE6semdaGn6x7YxmjJX4vWiafWSvLnRO7X8F7FqNQyfRuzYg3FUwgTNluPmZP1BqnvY6Srdf6vfQV6mn9LQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XC4Vnyw0wUtu5J+7Gev7ukk2Chg8/G90ERr4RHEpEvc=; b=kfgIokn7ELu3ueXyyHulyFuzS/68QE+lsxlvn2Dxd7WFmJO67D+IVVg85bjB6hgbmuILG3300KlX/HHISQHqH0ameSBD6fJoQ2CtmRmnpAKL6f2h+C6y1wonWIq/xperTh6am7n5/tzIMaWSXbtg4FH90mLDLrBOX70gF/THG81sxS1Y8ajVD8yXoEOecyPCDH7Qua04RFLvi9UomigijO/SD3cFQFB56Rsb6iFJpUR7OJt32Kgn6OYR1yMLUFcOvEAerQJA/sVbueuzvGD6Y5ZD6YlRdY9XSEs6xb3MCnCuUrP+a5FbnBDU2+oBADEEEPs2xeXbYxy/CRoDENK6hQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XC4Vnyw0wUtu5J+7Gev7ukk2Chg8/G90ERr4RHEpEvc=; b=smci+9KQYIOdMDwIQdQmqNB0zct7aPB8u0FuYS+Os6qeT1IJJHN98Fb5L9Cjhf956t/xe8YvDw5oQWcEzAcHUO203eKMihneYzm4O8TtsfKLaM6s21IN/a7jlhq1yvxBeYuWTezTjEDbSvH0xR5Jfipr9sMUzB6h3YdX5yegyXD6+RGDghmVRQPRBJmjN7IiH2UmU7BMk0NoKm8DrtX15I5ZLS3FcE1FwsE0doPHtrrVNa8OHSDRTP69xeKm28CtVmFWhgNOpQ/ONQSBO3NNEcr9SqaIpQul7/c2kY8ugG+um2DDQyPPGtzA27TZ/o7oE8jYocm44ru1k3DvUmNVVg== Received: from LO3P123MB3244.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:fc::16) by LO2P123MB3823.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:129::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 20 Aug 2020 16:45:30 +0000 Received: from LO3P123MB3244.GBRP123.PROD.OUTLOOK.COM ([fe80::61bf:80ca:2aa:8769]) by LO3P123MB3244.GBRP123.PROD.OUTLOOK.COM ([fe80::61bf:80ca:2aa:8769%8]) with mapi id 15.20.3305.024; Thu, 20 Aug 2020 16:45:30 +0000 From: David I To: Tim Wicinski , IETF DMARC WG CC: "dmarc-chairs@ietf.org" Thread-Topic: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field Thread-Index: AQHWb0kvAfXW9rCfQUm/Y0kSmNhkE6lBQapg Date: Thu, 20 Aug 2020 16:45:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 489513c5-4de0-46a8-befc-08d84528735e x-ms-traffictypediagnostic: LO2P123MB3823: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GGtCisll7L1bBiYWqCFWflYiEE271cDvXjyhzkj0Sw35JF/WipVKcrLcsliVovzX88L/TOvD2BxlbGRDZ+d2q+tiASBL2A4gR2x0rYi+ZBZ9a6BQOX0jUST7LqmEwEHhl0AU6o384t3W/x+qchWZYYClP4e3K4rn25tMWPvmKg4kfhnGhVT+o1nlRtPQFhs5VV8VLNxPbiP3wUArcvI94eEIouwUpCj4fcaO8bUdrYpUwWYbl3c97GnODPbkX+Rq/HwmQQpSuTJamw+3JnyEZi4/CE5h0N8WlxSYxiRGOj22z1/6ZCjpdMg5MYgO3d2MEUtSgXKYXWx93VOqruU9UrZcqYvyquXGjkhjjnoqup+ZUx6eSCHpLJKzo62GsTkTP56BaSuhIb+rWWXiIzadCQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO3P123MB3244.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(366004)(396003)(136003)(376002)(346002)(8936002)(9686003)(55016002)(966005)(2906002)(110136005)(186003)(7696005)(6506007)(4326008)(33656002)(86362001)(26005)(166002)(8676002)(5660300002)(66946007)(66556008)(64756008)(76116006)(66476007)(66446008)(478600001)(71200400001)(316002)(83380400001)(55236004)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ra0RvLN8iAbEpGQY7lCeEqucPDtNH2Yv43ZrlV/a9m1kV4gGW/91HSlufSnwcooURbawOWA4bmFH02lGaSiAI9/Z/nypkh7az5bx7olRkPHuM8cZBK68kvZThg53wryN63pLNVVHC6v8HZpuew+liOprOvSmSJ5ljm6TEI6JcqhhBxJWjF2QfQpWEif4ISlGQEARcaVVadN4CUsw32n2RQ5v2vfSGp/hCbYIbPuzv6xe0KeHNFK2JxQKMRyE8bTAoqbtZCFt+fwu6Dka7B5DffJ5eHYORs1FI8gvGqqVERccEySwvNnqLF55f24pCbGj3peou5nvYhrhwa/PM6qCHLaJKjcR3cq/I5S66X35Kbd+Ehw6cfCnVRohiXiD6AVTHB2i/VpbD72riBuNI1lRLXUXjmqsq9wXe3XnRUWyA74dKlZimtUxXxyD/Dj30WekiGD4OdfcCHhM1ZvtAT27qbup9viELhdNXlSUZDA0sFM3kK+5NKIwx6OPAy2Sotnj/aNLJWLKFkdKkG6juLzXfd2m8itlYNl4LS3c3DKCfp687+jBIQo4wX1J8vjVmeFDUemOi4RFzojykMHKENvKATsoicv5mawMEq6gE8N93YxlsvxAVf/fchbs+H5tinNwAu+eGTfzYGnO+mScfaSipg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO3P123MB32440698FD99F58AD45D6A55BE5A0LO3P123MB3244GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO3P123MB3244.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 489513c5-4de0-46a8-befc-08d84528735e X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 16:45:30.9064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GknrHHXE+k4WlSVZkapenpXlVVXzOc6+86ppKDYl6TlIZ2tVgDeRItjCsVfritvgqVsxd+A4Gc+mzOAOEh55gw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB3823 Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 16:45:36 -0000 --_000_LO3P123MB32440698FD99F58AD45D6A55BE5A0LO3P123MB3244GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHVyaW5nIElFVEYgMTA4LCB0aGUgY2hhaXJzIHJlYWxpemVkIHRoYXQgdGhlcmUgd2FzIGludGVy ZXN0IGluIERhdmUncw0KUkZDNTMyMi5TZW5kZXIgZHJhZnQuDQoNClRoaXMgc3RhcnRzIGEgQ2Fs bCBmb3IgQWRvcHRpb24gZm9yIGRyYWZ0LWNyb2NrZXItZG1hcmMtc2VuZGVyDQoNClRoZSBkcmFm dCBpcyBhdmFpbGFibGUgaGVyZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtY3JvY2tlci1kbWFyYy1zZW5kZXIvPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJG ZG9jJTJGZHJhZnQtY3JvY2tlci1kbWFyYy1zZW5kZXIlMkYmZGF0YT0wMiU3QzAxJTdDZGF2aWQu aSU0MG5jc2MuZ292LnVrJTdDOGI2ZjY5YmQ3OWEwNDU2YjA4M2EwOGQ4M2Q2MDUxNjIlN0MxNGFh NTc0NGVjZTE0NzRlYTJkNzM0ZjQ2ZGRhNjRhMSU3QzAlN0MwJTdDNjM3MzI2ODMxMTc5OTMwMzAw JnNkYXRhPWVzc293OW8xbm1xQVJOWENyJTJCVUZrQmhVd29teUJxMEUwZHB4enpLN3E5RSUzRCZy ZXNlcnZlZD0wPg0KDQpDdXJyZW50bHksIHRoZSBkcmFmdCBpcyBtYXJrZWQgYXMgIlN0YW5kYXJk cyBUcmFjayIuICBUaGUgY2hhaXJzIGZlZWwgaWYgdGhlDQp3b3JraW5nIGdyb3VwIGRvZXMgYWRv cHQgdGhpcywgaXQgc2hvdWxkIGJlZ2luIGFzICJFeHBlcmltZW50YWwiLiAgSWYgd2Ugc3RhcnQN CnRvIHNlZSBhZG9wdGlvbiBvZiB0aGlzIHdvcmssIHRoaXMgY2FuIGJlIGNoYW5nZWQgYmFjayB0 byAiU3RhbmRhcmRzIFRyYWNrIiBiZWZvcmUNCldvcmtpbmcgR3JvdXAgTGFzdCBDYWxsLiAgT2Yg Y291cnNlLCB3ZSB3ZWxjb21lIGlucHV0IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgb24gdGhpcy4N Cg0KUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgc3Vp dGFibGUgZm9yIGFkb3B0aW9uLCBhbmQNCnNlbmQgYW55IGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBj bGVhcmx5IHN0YXRpbmcgeW91ciB2aWV3Lg0KDQpUaGVyZSdzIHNvbWUgZ29vZCB0aGlua2luZyBp biB0aGUgZG9jdW1lbnQsIHRoYXQgaG93ZXZlciBsZWFkcyBtZSB0byBhIGRpZmZlcmVudCBzb2x1 dGlvbiBzcGFjZS4gVGhlcmUgYXJlIGFsc28gc29tZSBiaXRzIHdoaWNoIGFyZW4ndCBjbGVhciBl bm91Z2ggZm9yIG1lIHRvIGZ1bGx5IGFuYWx5c2UgdGhlIHNlY3VyaXR5IGltcGFjdCwgYW5kIHNv bWUgcGxhY2VzIHdoZXJlIEkgdGhpbmsgaXQncyBsYWNraW5nLg0KDQpJbiBhIGxpdHRsZSBtb3Jl IGRldGFpbDoNCi0gVGhlIHJlZmxlY3Rpb24gdGhhdCBtZWRpYXRvcnMgYXJlIGdvaW5nIHRvIGhh dmUgdG8gaW1wbGVtZW50IGFwcHJvYWNoZXMgbGlrZSBGcm9tLXJld3JpdGluZyBmb3IgYXQgbGVh c3QgYSB3aGlsZSBsZWFkcyBtZSB0byB0aGluayB0aGF0IHN0YW5kYXJkaXNpbmcgRnJvbSByZXdy aXRpbmcgaXMgYSBiZXR0ZXIgd2F5IHRvIGdvLiBTdGFuZGFyZGlzaW5nIHdvdWxkIGFsbG93IHJl Y2lwaWVudCBzeXN0ZW1zIHRvIHVuZG8gdGhlIEZyb20tcmV3cml0aW5nIGlmIHRoZXkgdHJ1c3Qg dGhlIGludGVybWVkaWFyeSBhbmQgdGhlIGVtYWlsIGlzIGF1dGhlbnRpY2F0ZWQgKHBlcmhhcHMg c2ltcGxlIERLSU0sIHBlcmhhcHMgc29tZXRoaW5nIEFSQy1yZWxhdGVkKS4gVGhpcyBoYXMgdGhl IGJlbmVmaXQgdGhhdCB0aGUgaW50ZXJtZWRpYXJ5IGRvZXNuJ3QgbmVlZCB0byB3b3JyeSBhYm91 dCB3aGV0aGVyIGl0J3MgdHJ1c3RlZCBieSB0aGUgcmVjaXBpZW50LCBvciB3aGV0aGVyIHRoZSBy ZWNpcGllbnQgaGFzIGltcGxlbWVudGVkIDxpbnNlcnQgbmV3IHN5c3RlbSBoZXJlPi4gSSBhZ3Jl ZSB3aXRoIGV2ZXJ5b25lIHdobyB0aGlua3MgaXQncyBzb21ld2hhdCBkaXN0YXN0ZWZ1bCwgYnV0 IHNlZW1zIGxlYXN0LXdvcnNlIHRvIG1lIGdpdmVuIHRvZGF5J3MgZW1haWwgZW52aXJvbm1lbnQu DQotIEl0J3Mgbm90IGNsZWFyIHRvIG1lIGluIHRoZSBkb2Mgd2hpY2ggZG9tYWluIGlzIGJlaW5n IHJlZmVycmVkIHRvIGluIHZhcmlvdXMgcGxhY2VzLiBlZyBhc3N1bWluZyBGcm9tOiB0ZXN0QGZy b20uZXhhbXBsZTxtYWlsdG86dGVzdEBmcm9tLmV4YW1wbGU+LCBTZW5kZXI6IHRlc3RAc2VuZGVy LmV4YW1wbGU8bWFpbHRvOnRlc3RAc2VuZGVyLmV4YW1wbGU+LCB3aGljaCBkb21haW4ncyBETUFS QyBwb2xpY3kgc2hvdWxkIGhhdmUgdGhlIHNuZCB0YWc/IElmIEkgbmV2ZXIgYWRkIHRoZSBzbmQg dGFnIHRvIF9kbWFyYy5mcm9tLmV4YW1wbGUsIGRvIEkgZ2V0IHRvIGtlZXAgdG9kYXkncyBiZWhh dmlvdXI/DQotIEl0IHR1cm5zIGEgZmFjdCBiYXNlZCBjaGVjayAnZGlkIHRoZSBETUFSQyBjaGVj a3MgcGFzcyBmb3IgdGhlIEZyb20gZG9tYWluJyB0byBhIGZ1enppZXIgcmVwdXRhdGlvbiBiYXNl ZCBvbmUuIFRoaXMgKm1heSogYmUgc2ltaWxhcmx5IGVmZmVjdGl2ZSBhdCBzY2FsZSBhZ2FpbnN0 IHZvbHVtZSBzcGFtLCB0aG91Z2ggSSdtIHNjZXB0aWNhbC4gSSBkb24ndCBiZWxpZXZlIGl0J3Mg dHJ1ZSBmb3IgbG93LXZvbHVtZSBzcGVhci1waGlzaGluZyB3aGVyZSAnYSBmZXcgZ2V0dGluZyB0 aHJvdWdoIHdoaWxlIHRoZSByZXB1dGF0aW9uIHN5c3RlbSB0cmFpbnMgaXRzZWxmJyBpc24ndCBn b29kIGVub3VnaC4NCi0gQ29tcGFyaW5nIHRoaXMgdG8gQVJDLCB0aGVyZSdzIG5vIHBhc3Npbmcg b2YgaW5mb3JtYXRpb24gYWJvdXQgd2hhdCBhdXRoZW50aWNhdGlvbiBjaGVja3MgYW4gaW50ZXJt ZWRpYXJ5IGRpZCwgbm9yIGEgc3RhdGVtZW50IHRoYXQgYW4gaW50ZXJtZWRpYXJ5IHNob3VsZCBi ZSBkb2luZyBzdHJpY3QgRE1BUkMgYXV0aGVudGljYXRpb24gYW5kIG5vdCBwYXNzaW5nIG9uIHRo aW5ncyB3aGljaCBmYWlsLiBUaGF0IG1ha2VzIHRoZSAndHJ1c3QnIGRlY2lzaW9uIGF0IGEgcmVj ZWl2ZXIgbXVjaCBoYXJkZXIgYXMgeW91IGRvbid0IGtub3cgaWYgYW55IGF1dGhlbnRpY2F0aW9u IGhhcyB0YWtlbiBwbGFjZS4NCi0gQXMgYSByZXB1dGF0aW9uL3RydXN0IGJhc2VkIG1lY2hhbmlz bSwgaXQgc2hhcmVzIHdlYWtuZXNzZXMgd2l0aCBBUkMgLSBkaWZmaWN1bHR5IG9mIGJvb3RzdHJh cHBpbmcsIGFuZCBmYXZvdXJpbmcgbGFyZ2UgYW5kIGV4aXN0aW5nIHBsYXllcnMuIFNvIEkgZG9u J3QgdGhpbmsgaXQncyBleHBhbmRpbmcgdGhlIHNvbHV0aW9uIHNwYWNlIG11Y2gsIGFuZCByaXNr cyBkaXN0cmFjdGluZyBmcm9tIEFSQyBhbmQgdGhlbiBydW5uaW5nIGludG8gc2ltaWxhciBpc3N1 ZXMuDQotIFRoZSBhYnNlbmNlIG9mIGEgbWVjaGFuaXNtIHRvIGdldCBhd2F5IGZyb20gRnJvbS1y ZXdyaXRpbmcgb3Igc2ltaWxhciAoZXZlbiBpbiB0aGUgbG9uZyB0ZXJtKSwgbWVhbnMgdGhpcyB3 b3VsZCBiZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgd2l0aCBsaXR0bGUsIGlmIGFueSBwcmFjdGlj YWwgdXBzaWRlLg0KDQpHaXZlbiB0aGUgYWJvdmUsIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGZy dWl0ZnVsIHBhdGgsIHNvIEkgZG9uJ3Qgc3VwcG9ydCBhZG9wdGlvbiBhdCB0aGlzIHRpbWUuDQoN ClJlZ2FyZHMsDQpEYXZpZA0KDQpUaGlzIGluZm9ybWF0aW9uIGlzIGV4ZW1wdCB1bmRlciB0aGUg RnJlZWRvbSBvZiBJbmZvcm1hdGlvbiBBY3QgMjAwMCAoRk9JQSkgYW5kIG1heSBiZSBleGVtcHQg dW5kZXIgb3RoZXIgVUsgaW5mb3JtYXRpb24gbGVnaXNsYXRpb24uIFJlZmVyIGFueSBGT0lBIHF1 ZXJpZXMgdG8gbmNzY2luZm9sZWdAbmNzYy5nb3YudWsuIEFsbCBtYXRlcmlhbCBpcyBVSyBDcm93 biBDb3B5cmlnaHQgwqkNCg== --_000_LO3P123MB32440698FD99F58AD45D6A55BE5A0LO3P123MB3244GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkR1cmluZyBJRVRGIDEwOCwgdGhlIGNoYWlycyByZWFsaXplZCB0aGF0IHRoZXJlIHdhcyBp bnRlcmVzdCBpbiBEYXZlJ3MNCjxicj4NClJGQzUzMjIuU2VuZGVyIGRyYWZ0LiAmbmJzcDs8YnI+ DQo8YnI+DQpUaGlzIHN0YXJ0cyBhIENhbGwgZm9yIEFkb3B0aW9uIGZvciBkcmFmdC1jcm9ja2Vy LWRtYXJjLXNlbmRlcjxicj4NCjxicj4NClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZTogPC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQt Y3JvY2tlci1kbWFyYy1zZW5kZXIlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q2RhdmlkLmklNDBuY3Nj Lmdvdi51ayU3QzhiNmY2OWJkNzlhMDQ1NmIwODNhMDhkODNkNjA1MTYyJTdDMTRhYTU3NDRlY2Ux NDc0ZWEyZDczNGY0NmRkYTY0YTElN0MwJTdDMCU3QzYzNzMyNjgzMTE3OTkzMDMwMCZhbXA7c2Rh dGE9ZXNzb3c5bzFubXFBUk5YQ3IlMkJVRmtCaFV3b215QnEwRTBkcHh6eks3cTlFJTNEJmFtcDty ZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNyb2NrZXItZG1hcmMt c2VuZGVyLzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQpDdXJyZW50bHksIHRoZSBkcmFmdCBpcyBtYXJrZWQgYXMg JnF1b3Q7U3RhbmRhcmRzIFRyYWNrJnF1b3Q7LiZuYnNwOyBUaGUgY2hhaXJzIGZlZWwgaWYgdGhl PGJyPg0Kd29ya2luZyBncm91cCBkb2VzIGFkb3B0IHRoaXMsIGl0IHNob3VsZCBiZWdpbiBhcyAm cXVvdDtFeHBlcmltZW50YWwmcXVvdDsuJm5ic3A7IElmIHdlIHN0YXJ0IDxicj4NCnRvIHNlZSBh ZG9wdGlvbiBvZiB0aGlzIHdvcmssIHRoaXMgY2FuIGJlIGNoYW5nZWQgYmFjayB0byAmcXVvdDtT dGFuZGFyZHMgVHJhY2smcXVvdDsgYmVmb3JlPGJyPg0KV29ya2luZyBHcm91cCBMYXN0IENhbGwu Jm5ic3A7IE9mIGNvdXJzZSwgd2Ugd2VsY29tZSBpbnB1dCBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw IG9uIHRoaXMuPGJyPg0KPGJyPg0KUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5 b3UgdGhpbmsgaXQgaXMgc3VpdGFibGUgZm9yIGFkb3B0aW9uLCBhbmQgPGJyPg0Kc2VuZCBhbnkg Y29tbWVudHMgdG8gdGhlIGxpc3QsIGNsZWFybHkgc3RhdGluZyB5b3VyIHZpZXcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJlJ3Mgc29tZSBnb29kIHRoaW5raW5nIGluIHRoZSBk b2N1bWVudCwgdGhhdCBob3dldmVyIGxlYWRzIG1lIHRvIGEgZGlmZmVyZW50IHNvbHV0aW9uIHNw YWNlLiBUaGVyZSBhcmUgYWxzbyBzb21lIGJpdHMgd2hpY2ggYXJlbid0IGNsZWFyIGVub3VnaCBm b3IgbWUgdG8gZnVsbHkgYW5hbHlzZSB0aGUgc2VjdXJpdHkgaW1wYWN0LCBhbmQNCiBzb21lIHBs YWNlcyB3aGVyZSBJIHRoaW5rIGl0J3MgbGFja2luZy4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIGEgbGl0dGxlIG1vcmUg ZGV0YWlsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBUaGUgcmVmbGVjdGlvbiB0aGF0 IG1lZGlhdG9ycyBhcmUgZ29pbmcgdG8gaGF2ZSB0byBpbXBsZW1lbnQgYXBwcm9hY2hlcyBsaWtl IEZyb20tcmV3cml0aW5nIGZvciBhdCBsZWFzdCBhIHdoaWxlIGxlYWRzIG1lIHRvIHRoaW5rIHRo YXQgc3RhbmRhcmRpc2luZyBGcm9tIHJld3JpdGluZyBpcyBhIGJldHRlciB3YXkgdG8gZ28uIFN0 YW5kYXJkaXNpbmcNCiB3b3VsZCBhbGxvdyByZWNpcGllbnQgc3lzdGVtcyB0byB1bmRvIHRoZSBG cm9tLXJld3JpdGluZyBpZiB0aGV5IHRydXN0IHRoZSBpbnRlcm1lZGlhcnkgYW5kIHRoZSBlbWFp bCBpcyBhdXRoZW50aWNhdGVkIChwZXJoYXBzIHNpbXBsZSBES0lNLCBwZXJoYXBzIHNvbWV0aGlu ZyBBUkMtcmVsYXRlZCkuIFRoaXMgaGFzIHRoZSBiZW5lZml0IHRoYXQgdGhlIGludGVybWVkaWFy eSBkb2Vzbid0IG5lZWQgdG8gd29ycnkgYWJvdXQgd2hldGhlciBpdCdzDQogdHJ1c3RlZCBieSB0 aGUgcmVjaXBpZW50LCBvciB3aGV0aGVyIHRoZSByZWNpcGllbnQgaGFzIGltcGxlbWVudGVkICZs dDtpbnNlcnQgbmV3IHN5c3RlbSBoZXJlJmd0Oy4gSSBhZ3JlZSB3aXRoIGV2ZXJ5b25lIHdobyB0 aGlua3MgaXQncyBzb21ld2hhdCBkaXN0YXN0ZWZ1bCwgYnV0IHNlZW1zIGxlYXN0LXdvcnNlIHRv IG1lIGdpdmVuIHRvZGF5J3MgZW1haWwgZW52aXJvbm1lbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4tIEl0J3Mgbm90IGNsZWFyIHRvIG1lIGluIHRoZSBkb2Mgd2hpY2ggZG9tYWluIGlz IGJlaW5nIHJlZmVycmVkIHRvIGluIHZhcmlvdXMgcGxhY2VzLiBlZyBhc3N1bWluZyBGcm9tOg0K PGEgaHJlZj0ibWFpbHRvOnRlc3RAZnJvbS5leGFtcGxlIj50ZXN0QGZyb20uZXhhbXBsZTwvYT4s IFNlbmRlcjogPGEgaHJlZj0ibWFpbHRvOnRlc3RAc2VuZGVyLmV4YW1wbGUiPg0KdGVzdEBzZW5k ZXIuZXhhbXBsZTwvYT4sIHdoaWNoIGRvbWFpbidzIERNQVJDIHBvbGljeSBzaG91bGQgaGF2ZSB0 aGUgc25kIHRhZz8gSWYgSSBuZXZlciBhZGQgdGhlIHNuZCB0YWcgdG8gX2RtYXJjLmZyb20uZXhh bXBsZSwgZG8gSSBnZXQgdG8ga2VlcCB0b2RheSdzIGJlaGF2aW91cj88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPi0gSXQgdHVybnMgYSBmYWN0IGJhc2VkIGNoZWNrICdkaWQgdGhlIERNQVJD IGNoZWNrcyBwYXNzIGZvciB0aGUgRnJvbSBkb21haW4nIHRvIGEgZnV6emllciByZXB1dGF0aW9u IGJhc2VkIG9uZS4gVGhpcyAqbWF5KiBiZSBzaW1pbGFybHkgZWZmZWN0aXZlIGF0IHNjYWxlIGFn YWluc3Qgdm9sdW1lIHNwYW0sIHRob3VnaCBJJ20gc2NlcHRpY2FsLg0KIEkgZG9uJ3QgYmVsaWV2 ZSBpdCdzIHRydWUgZm9yIGxvdy12b2x1bWUgc3BlYXItcGhpc2hpbmcgd2hlcmUgJ2EgZmV3IGdl dHRpbmcgdGhyb3VnaCB3aGlsZSB0aGUgcmVwdXRhdGlvbiBzeXN0ZW0gdHJhaW5zIGl0c2VsZicg aXNuJ3QgZ29vZCBlbm91Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tIENvbXBhcmlu ZyB0aGlzIHRvIEFSQywgdGhlcmUncyBubyBwYXNzaW5nIG9mIGluZm9ybWF0aW9uIGFib3V0IHdo YXQgYXV0aGVudGljYXRpb24gY2hlY2tzIGFuIGludGVybWVkaWFyeSBkaWQsIG5vciBhIHN0YXRl bWVudCB0aGF0IGFuIGludGVybWVkaWFyeSBzaG91bGQgYmUgZG9pbmcgc3RyaWN0IERNQVJDIGF1 dGhlbnRpY2F0aW9uIGFuZA0KIG5vdCBwYXNzaW5nIG9uIHRoaW5ncyB3aGljaCBmYWlsLiBUaGF0 IG1ha2VzIHRoZSAndHJ1c3QnIGRlY2lzaW9uIGF0IGEgcmVjZWl2ZXIgbXVjaCBoYXJkZXIgYXMg eW91IGRvbid0IGtub3cgaWYgYW55IGF1dGhlbnRpY2F0aW9uIGhhcyB0YWtlbiBwbGFjZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0gQXMgYSByZXB1dGF0aW9uL3RydXN0IGJhc2VkIG1l Y2hhbmlzbSwgaXQgc2hhcmVzIHdlYWtuZXNzZXMgd2l0aCBBUkMgLSBkaWZmaWN1bHR5IG9mIGJv b3RzdHJhcHBpbmcsIGFuZCBmYXZvdXJpbmcgbGFyZ2UgYW5kIGV4aXN0aW5nIHBsYXllcnMuIFNv IEkgZG9uJ3QgdGhpbmsgaXQncyBleHBhbmRpbmcgdGhlIHNvbHV0aW9uIHNwYWNlDQogbXVjaCwg YW5kIHJpc2tzIGRpc3RyYWN0aW5nIGZyb20gQVJDIGFuZCB0aGVuIHJ1bm5pbmcgaW50byBzaW1p bGFyIGlzc3Vlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0gVGhlIGFic2VuY2Ugb2Yg YSBtZWNoYW5pc20gdG8gZ2V0IGF3YXkgZnJvbSBGcm9tLXJld3JpdGluZyBvciBzaW1pbGFyIChl dmVuIGluIHRoZSBsb25nIHRlcm0pLCBtZWFucyB0aGlzIHdvdWxkIGJlIGFkZGl0aW9uYWwgY29t cGxleGl0eSB3aXRoIGxpdHRsZSwgaWYgYW55IHByYWN0aWNhbCB1cHNpZGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkdpdmVu IHRoZSBhYm92ZSwgSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZnJ1aXRmdWwgcGF0aCwgc28gSSBk b24ndCBzdXBwb3J0IGFkb3B0aW9uIGF0IHRoaXMgdGltZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NClRoaXMgaW5mb3JtYXRpb24gaXMgZXhlbXB0IHVuZGVyIHRoZSBGcmVl ZG9tIG9mIEluZm9ybWF0aW9uIEFjdCAyMDAwIChGT0lBKSBhbmQgbWF5IGJlIGV4ZW1wdCB1bmRl ciBvdGhlciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgYW55IEZPSUEgcXVlcmll cyB0byBuY3NjaW5mb2xlZ0BuY3NjLmdvdi51ay4gQWxsIG1hdGVyaWFsIGlzIFVLIENyb3duIENv cHlyaWdodCDCqQ0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_LO3P123MB32440698FD99F58AD45D6A55BE5A0LO3P123MB3244GBRP_-- From nobody Thu Aug 20 11:17:12 2020 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 F0BEE3A1180 for ; Thu, 20 Aug 2020 11:17:10 -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, 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 K7G68cDJcky4 for ; Thu, 20 Aug 2020 11:17:08 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 3F72F3A117D for ; Thu, 20 Aug 2020 11:17:08 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id y17so853511uaq.6 for ; Thu, 20 Aug 2020 11:17:08 -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=udgZaB2gcQl/soxkMVghWQ+p1FDGnE+fhhFyZJN/DLg=; b=slS3w7ioEvbl4cHphHO10s0VWjacAwPp49QKmTN0W5F/L73gkjpfmoWjOGX/k1y3a/ 9xekwO4Pov6IGfMPJSuYQrW+4Z6VKTOyaQLPDbsa9wzAY8UxIeYKtwrig1oAdtqlAYzW 7oHNZdWrST+Kh8KSe83fKhUQtncppZg50fD7BvyN7/EbNDnXF8SpVaRbSHXOIp5FL/kl iKjQEMhOM/gW6AICrLAF+oFye6F27OHdo5/ypfuJz5X4+S0iiNhDrxEJ3MFL8pfPJZc4 9JgcsT3GQMArdpJNapaT8g4KckNtXdDX4/5PGjnLXWUPmh81MvCm21n7wQRw93MfWKpk pcGg== 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=udgZaB2gcQl/soxkMVghWQ+p1FDGnE+fhhFyZJN/DLg=; b=K6XEBUb3RvuN4P9CYPJyiViDYXOjev1sD73M0PDnAr6zGFd2e2FOd+CWjerjaUvDAq n463pTdv18WJnBxdgXppl+B86yGIKiv5cjSshbcEDFD0Dapc1L6kBJO+AxGx1qXMIW0g 9JaRm3wyqG7YPrvPSiIQSaBGdJqjBB2hWuXXcG4y0xwZfxx4rTBr3N3Sbs6JeaW2FNss s/Utev8DO0tIX79USSCTJT7gXUjbMlGcoK9nZX1zG0E2iMGhC+0zqWH3WHFaVWJzeDFL eQN0FNbt+oFyoXLd0WVa0YqlxiIMj0Krf46M3nhb2r1itjpccKJ7km+0IR+8DO5O6n3E IZJg== X-Gm-Message-State: AOAM5307cvbN21ioMb/QQHg4G0xRG2XFuxTndqS/ApC3ZiLhgkvG3wvx uBcZYLf/y6vCd3/YAcR4fwOqy7CEA3N4sbp3TvQ= X-Google-Smtp-Source: ABdhPJyU69a+jMMxyhLz0Sea0wNcMN16cd32mUsThkVvuexiyQGHZUi6xRHwBk0cElEbv4pvFARX3zEHuIpW1+ipANA= X-Received: by 2002:a9f:26a5:: with SMTP id 34mr2807812uay.67.1597947427037; Thu, 20 Aug 2020 11:17:07 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> In-Reply-To: <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> From: "Murray S. Kucherawy" Date: Thu, 20 Aug 2020 11:16:55 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG , Tim Draegen Content-Type: multipart/alternative; boundary="000000000000c22af605ad532035" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 18:17:11 -0000 --000000000000c22af605ad532035 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely wrote: > I am wondering whether companies like Dmarcian could implement third-pary > whitelisting. As they receive and analyze DMARC aggregate reports on > behalf of many mail sites, they probably are able to distinguish various > level of authentication failures, from mailing lists to misaligned ESPs, to > actual abusers. In that case, they could maintain a whitelist tailored for > any given client. The client would set, say: > > _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto: > client-id@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]" > [...] > Having spent a lot of time and energy building a DKIM-based reputation system that (IMHO) showed promise, I made it available for people to try for free. There was no uptake, even after presenting its promising results in places like M3AAWG. Times may have changed, but in retrospect I think there are too many "what-ifs" for add-ons of this nature to be seen as feasible. The issues seem to be: - it has no hope of being universally accurate; participants have to accept that false positives and false negatives will happen - if it's perceived as effective, demand for this will skyrocket; the host needs to be resilient to this - participants have to trust the company providing the service to do so reliably and honestly (e.g., no paying to be listed or get a reputation boost) - depending on failure modes, the host could become a DoS target; they need to be resilient to this - the "lag" to which you refer might be unacceptable in some situations; participants need to be willing to tolerate this - there will be demands for accuracy and timely responses; interfering with someone's mail flow for whatever reason can draw unwanted legal attention (e.g., MAPS) I imagine large operators already have enough information to know where the lists are, so for them this might be moot. It's smaller operators without the infrastructure to make such determinations in real time that need to collaborate on something like this. -MSK --000000000000c22af605ad532035 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 20, 2020 at 1:59 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
I am wondering whether companies like Dmarcian could implement= third-pary whitelisting.=C2=A0 As they receive and analyze DMARC aggregate= reports on behalf of many mail sites, they probably are able to distinguis= h various level of authentication failures, from mailing lists to misaligne= d ESPs, to actual abusers.=C2=A0 In that case, they could maintain a whitel= ist tailored for any given client.=C2=A0 The client would set, say:

_dmarc.client.domain.example IN TXT "v=3DDMARC1; rua=3Dmailto:client-id@ag.dmarci= an.com; snd=3Dclient-id.rhswl.dmarcian.com; [...]" [...]

Having spent a lot of time and en= ergy building a DKIM-based reputation system that (IMHO) showed promise, I = made it available for people to try for free.=C2=A0 There was no uptake, ev= en after presenting its promising results in places like M3AAWG.=C2=A0 Time= s may have changed, but in retrospect I think there are too many "what= -ifs" for add-ons of this nature to be seen as feasible.=C2=A0 The iss= ues seem to be:

- it has no hope of being universally accurate; partici= pants have to accept that false positives and false negatives will happen

- i= f it's perceived as effective, demand for this will skyrocket; the host= needs to be resilient to this

- participants have to trust the company provi= ding the service to do so reliably and honestly (e.g., no paying to be list= ed or get a reputation boost)

- depending on failure modes, the host could be= come a DoS target; they need to be resilient to this

- the "lag" to= which you refer might be unacceptable in some situations; participants nee= d to be willing to tolerate this

- there will be demands for accuracy and tim= ely responses; interfering with someone's mail flow for whatever reason= can draw unwanted legal attention (e.g., MAPS)

I imagine large operators already= have enough information to know where the lists are, so for them this migh= t be moot.=C2=A0 It's smaller operators without the infrastructure to m= ake such determinations in real time that need to collaborate on something = like this.

-MSK

--000000000000c22af605ad532035-- From nobody Thu Aug 20 13:36:14 2020 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 4C2253A13FD for ; Thu, 20 Aug 2020 13:36:13 -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=eudaemon.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 l_4-RNPWctsE for ; Thu, 20 Aug 2020 13:36:11 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 3A5733A13FB for ; Thu, 20 Aug 2020 13:36:11 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id j187so2708369qke.11 for ; Thu, 20 Aug 2020 13:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WUVKSEJHO/8/HbgUsXK5rJD6toqV0/p1F48nWcVC7yc=; b=C2Lv8hkRlTVkPOOAjr5eBURBocKSQmJtA3X2CugVmccBBoGpFZ7T3WoN39nmxUSms2 e2aemFHOF0kdYpnOHTFGQrxvGj+YsTpJacD/jAj6itT23nAQjA7/BuKj5wkQmfn5lvLt KcZtUgUg0pOIitAV8Mdtqo22jBpUd9+B9gkUE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WUVKSEJHO/8/HbgUsXK5rJD6toqV0/p1F48nWcVC7yc=; b=U9+l0AsqYETTSp2h/VuofKdSU1dmAvxEdTW2ILB70cwByBE4zyOoiCaQDfJKpzOwMv KdUHa3joW9X7i5qbWzi/TdkTKWrWCykcJ9PtDme3PpPGjUuHkIl2xgC3mLsjCg6nqTT5 KAONMWm3Vo/8+aamMlwg0GZR3Whe4lIV3G3+a34d7UpK2RGZ6vOfTpKYMSgf0nbcRHlP ViXjisTmT4rgV8MC7/mBhMaIH8c6wMVFP35BprQ6MX/8SNNTKsPfpeihuVZRvvH9Mpf1 cyj/8Yk2Ej2L6gULC4P6zIL+AWg+qVscmU2f/vbblPsKm20iRPVFBAiCTjs7FQPp7o8y ymHw== X-Gm-Message-State: AOAM532lzmoLKWpdtxRcDSAj35VBtflxU73G1uSorwUHY7h7IYH10Zdu skWgUTwDK/JDB3dghfrEL8t4Ow== X-Google-Smtp-Source: ABdhPJwHyy4nC45pc4QhHiyra1AElVnF6PufoE18xqy87nUN9kLTyrE9jGKfvp3cRrSE8/gURhhkVw== X-Received: by 2002:ae9:dc45:: with SMTP id q66mr216999qkf.55.1597955769972; Thu, 20 Aug 2020 13:36:09 -0700 (PDT) Received: from [192.168.203.118] ([68.235.231.125]) by smtp.gmail.com with ESMTPSA id b37sm4249203qtk.85.2020.08.20.13.36.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2020 13:36:09 -0700 (PDT) From: Tim Draegen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2E869DF7-60FD-4596-B2DF-F0F5608B6215" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 20 Aug 2020 16:36:08 -0400 In-Reply-To: Cc: Alessandro Vesely , IETF DMARC WG To: "Murray S. Kucherawy" References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 20:36:13 -0000 --Apple-Mail=_2E869DF7-60FD-4596-B2DF-F0F5608B6215 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy = wrote: >=20 > On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely > wrote: > I am wondering whether companies like Dmarcian could implement = third-pary whitelisting. As they receive and analyze DMARC aggregate = reports on behalf of many mail sites, they probably are able to = distinguish various level of authentication failures, from mailing lists = to misaligned ESPs, to actual abusers. In that case, they could = maintain a whitelist tailored for any given client. The client would = set, say: >=20 > _dmarc.client.domain.example IN TXT "v=3DDMARC1; = rua=3Dmailto:client-id@ag.dmarcian.com = ; snd=3Dclient-id.rhswl.dmarcian.com = ; [...]" > [...] >=20 > Having spent a lot of time and energy building a DKIM-based reputation = system that (IMHO) showed promise, I made it available for people to try = for free. There was no uptake, even after presenting its promising = results in places like M3AAWG. Times may have changed, but in = retrospect I think there are too many "what-ifs" for add-ons of this = nature to be seen as feasible. The issues seem to be: Hi MSK, hi Ale, I can second that MSK's DKIM-based reputation system is amazing. =46rom = where I sit, it's like a flying saucer that humans just haven't figured = out how to fuel quite yet. I believe that fuel comes from widespread = adoption of domain-based email authentication aka DMARC. The challenge = of getting the email universe to embrace something like DMARC feels at = times impossible, but the fact is it just takes a lot of coordination, = dedication, and consistent levels of exercise to stay sane. That said, Ale, I like the idea of a Domain Owner being able to share = some sort of exception list for email flows that are recognized by the = Domain Owner, but are still (for various reasons) beyond the ability of = the Domain Owner to address. Something like, "I've got a vendor that = will never send DMARC-compliant email on my behalf". It appeals to my = fondness to be able to Just Fix Things without having to bother anyone. = I don't think it would work, though, because it relies on email = receivers having to widely implement new stuff, and it relies on Domain = Owners accurately maintaining another thing. It's easier and more = effective to get the vendor to do the right thing. Oh, on 2nd read (I've been consumed with the non-IETF world for a few = months and only took this up because Ale emailed me at work).. I think = keying off of "Sender:" is a really bad idea. Multiple policy keys into = a single piece of email has never made sense. Third party authorization makes sense to me in theory as a tool for a = very specific problem. In practice, people and organizations struggle to = get first party authorization into place. Once they start to tackle = their own first party authorization, the need for third party = authorization tends to evaporate. What's left over? People that want to = put together a list of authorized third parties but aren't quite ready = to do their own first party auth? =46rom a receiver's perspective, it then looks like the first party has = no idea what it is doing (which is the default anti-spam stance for all = Internet mail), so then the receiver is now looking at a bunch of = factors unrelated to first-party auth.. including any third party = authorization. EG, the receiver notes that the email is authorized by a = third-party - a newsletter company. "First party" authorization is NOT = established, so the receiver has to process the email based on the = strength of the newsletter company's reputation (among other things). So = then why bother at all with the construct of "third party = authorization"? So I guess put me in the camp of not seeing utility in third party = authorizations. Better to make the work that needs to be done as clear = and as simple as possible. =3D- Tim --Apple-Mail=_2E869DF7-60FD-4596-B2DF-F0F5608B6215 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Thu, Aug 20, 2020 = at 1:59 AM Alessandro Vesely <vesely@tana.it> wrote:
I am wondering whether companies like = Dmarcian could implement third-pary whitelisting.  As they receive = and analyze DMARC aggregate reports on behalf of many mail sites, they = probably are able to distinguish various level of authentication = failures, from mailing lists to misaligned ESPs, to actual = abusers.  In that case, they could maintain a whitelist tailored = for any given client.  The client would set, say:

_dmarc.client.domain.example IN TXT "v=3DDMARC1; rua=3Dmailto:client-id@ag.dmarcian.com; snd=3Dclient-id.rhswl.dmarcian.com; [...]"
[...]

Having spent a lot of time and energy building a DKIM-based = reputation system that (IMHO) showed promise, I made it available for = people to try for free.  There was no uptake, even after presenting = its promising results in places like M3AAWG.  Times may have = changed, but in retrospect I think there are too many "what-ifs" for = add-ons of this nature to be seen as feasible.  The issues seem to = be:

Hi MSK, hi Ale,

I can = second that MSK's DKIM-based reputation system is amazing. From where I sit, it's like a flying saucer that humans just haven't figured out how to fuel quite yet. I believe that fuel comes from widespread = adoption of domain-based email=20 authentication aka DMARC. The challenge of getting the email universe to embrace something like DMARC feels at times impossible, but the fact is it just takes a lot of coordination, dedication, and consistent levels=20= of exercise to stay sane.

That said, Ale, I like the = idea of a Domain Owner being able to share some sort of exception list = for email flows that are recognized by the Domain Owner, but are still = (for various reasons) beyond the ability of the Domain Owner to address. = Something like, "I've got a vendor that will never send DMARC-compliant = email on my behalf". It appeals to my fondness to be able to Just Fix = Things without having to bother anyone. I don't think it would work, = though, because it relies on email receivers having to widely implement = new stuff, and it relies on Domain Owners accurately maintaining another = thing. It's easier and more effective to get the vendor to do the right = thing.

Oh, on 2nd read (I've been consumed with the non-IETF = world for a few months and only took this up because Ale emailed me at = work).. I think keying off of "Sender:" is a really bad idea. Multiple = policy keys into a single piece of email has never made sense.

Third party authorization makes sense to me in theory as a = tool for a very specific problem. In practice, people and organizations = struggle to get first party authorization into place. Once they start to = tackle their own first party authorization, the need for third party = authorization tends to evaporate. What's left over? People that want to = put together a list of authorized third parties but aren't quite ready = to do their own first party auth?

=46rom a receiver's perspective, it = then looks like the first party has no idea what it is doing (which is = the default anti-spam stance for all Internet mail), so then the = receiver is now looking at a bunch of factors unrelated to first-party = auth.. including any third party authorization. EG, the receiver notes = that the email is authorized by a third-party - a newsletter company. = "First party" authorization is NOT established, so the receiver has to = process the email based on the strength of the newsletter company's = reputation (among other things). So then why bother at all with the = construct of "third party authorization"?

So I guess put me in the camp of not = seeing utility in third party authorizations. Better to make the work = that needs to be done as clear and as simple as possible.

=3D- Tim

= --Apple-Mail=_2E869DF7-60FD-4596-B2DF-F0F5608B6215-- From nobody Thu Aug 20 14:01:11 2020 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 51CFC3A1415 for ; Thu, 20 Aug 2020 14:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 cYNwikWnkX5Q for ; Thu, 20 Aug 2020 14:01:08 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 58E793A1414 for ; Thu, 20 Aug 2020 14:01:08 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id u126so3611388iod.12 for ; Thu, 20 Aug 2020 14:01:08 -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=sP6A1R9UdhHc5mlM6ulRXdXDWogVmVKTfhBTT/Tuqrg=; b=ppcVn/EuLFzLy4uMIaRkDWwA4FnOIXMqf8OURREf2YGzcXWWdj25TcwTbl5N1b73iL kAQftJlCv9Ph/KwwSfNSY96JTj1j/mG8e+B+hQZKdxbvARa61rFyAk5/1b4g+ZCIsEG7 itExMj9AmoSC7HQULsvhs9kpydGcFWHVbYkW0Oz8A1dZ96ph+R9+5DRciRdnw7i+De0O 66EQuFs7Zs8RIJE+2SYQP7u1NRD64NBFnmW6QAuyr/8+irfrbtaSfYSznOFVkZsuTJ3n Fbu+CO58b/FX0wBVi1B6jkQNtv74OmlfZnC8TOouW+Zc2kCBVDprqERBcnJY6ud3l0fL NsMA== 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=sP6A1R9UdhHc5mlM6ulRXdXDWogVmVKTfhBTT/Tuqrg=; b=EUkQ+eOxfWGHRmd1i2H+aflzsDGmOkuh7JnF7gs/PQ+zn74YQC1SbVRW1IiFtHn6tk 9BcIAmyNhhIrrdsEk8DEnJ4bBt5Xc+GfKYKwbt4H5j8hjxlxFOgvlUV4wQixKwQvktIK WKh4GUMlzK291JeQiJBDHZLa97YByZzlg76yMHWG3neDTPOZ4yPf+7IvBvc1/wT5rsqC 1iBj0rUL4SglF+fCBCnabD7kRPFvUk/Ed55j8tcTO9M+hBzDO6nxyJTEl7x9fmg9Zj87 19lQtk0VH8+EaQw/N4+RlAhecpObWFpiDO3BBeesT2ZzICfWF6ZfsHHJ6koFJcdDE0jr 7gvw== X-Gm-Message-State: AOAM532tbZvUjHA3MGfCsjnsbz8h+cGoFz7pR51MqVywJvGe/31ZkYJ8 AgdPfebRZZPmm8TdjcYe1u2bQ6cvoWP57HS4MTBHLnCReA== X-Google-Smtp-Source: ABdhPJzs51580srElMzHn+sAKpflU/qx5x/rYdFs0z9nSJym26m8VAfH3soBEe4tqcePQBXvX0oK0wBFMr2IDcf5h90= X-Received: by 2002:a5e:9601:: with SMTP id a1mr56198ioq.179.1597957266956; Thu, 20 Aug 2020 14:01:06 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> In-Reply-To: From: Brandon Long Date: Thu, 20 Aug 2020 14:00:53 -0700 Message-ID: To: Tim Draegen Cc: "Murray S. Kucherawy" , IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="00000000000044432605ad556beb" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 21:01:10 -0000 --00000000000044432605ad556beb Content-Type: text/plain; charset="UTF-8" On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen wrote: > On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy > wrote: > > On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely wrote: > >> I am wondering whether companies like Dmarcian could implement third-pary >> whitelisting. As they receive and analyze DMARC aggregate reports on >> behalf of many mail sites, they probably are able to distinguish various >> level of authentication failures, from mailing lists to misaligned ESPs, to >> actual abusers. In that case, they could maintain a whitelist tailored for >> any given client. The client would set, say: >> >> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto: >> client-id@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]" >> [...] >> > > Having spent a lot of time and energy building a DKIM-based reputation > system that (IMHO) showed promise, I made it available for people to try > for free. There was no uptake, even after presenting its promising results > in places like M3AAWG. Times may have changed, but in retrospect I think > there are too many "what-ifs" for add-ons of this nature to be seen as > feasible. The issues seem to be: > > > Hi MSK, hi Ale, > > I can second that MSK's DKIM-based reputation system is amazing. From > where I sit, it's like a flying saucer that humans just haven't figured out > how to fuel quite yet. I believe that fuel comes from widespread adoption > of domain-based email authentication aka DMARC. The challenge of getting > the email universe to embrace something like DMARC feels at times > impossible, but the fact is it just takes a lot of coordination, > dedication, and consistent levels of exercise to stay sane. > > That said, Ale, I like the idea of a Domain Owner being able to share some > sort of exception list for email flows that are recognized by the Domain > Owner, but are still (for various reasons) beyond the ability of the Domain > Owner to address. Something like, "I've got a vendor that will never send > DMARC-compliant email on my behalf". It appeals to my fondness to be able > to Just Fix Things without having to bother anyone. I don't think it would > work, though, because it relies on email receivers having to widely > implement new stuff, and it relies on Domain Owners accurately maintaining > another thing. It's easier and more effective to get the vendor to do the > right thing. > > Oh, on 2nd read (I've been consumed with the non-IETF world for a few > months and only took this up because Ale emailed me at work).. I think > keying off of "Sender:" is a really bad idea. Multiple policy keys into a > single piece of email has never made sense. > Third party authorization makes sense to me in theory as a tool for a very > specific problem. In practice, people and organizations struggle to get > first party authorization into place. Once they start to tackle their own > first party authorization, the need for third party authorization tends to > evaporate. What's left over? People that want to put together a list of > authorized third parties but aren't quite ready to do their own first party > auth? > > From a receiver's perspective, it then looks like the first party has no > idea what it is doing (which is the default anti-spam stance for all > Internet mail), so then the receiver is now looking at a bunch of factors > unrelated to first-party auth.. including any third party authorization. > EG, the receiver notes that the email is authorized by a third-party - a > newsletter company. "First party" authorization is NOT established, so the > receiver has to process the email based on the strength of the newsletter > company's reputation (among other things). So then why bother at all with > the construct of "third party authorization"? > > So I guess put me in the camp of not seeing utility in third party > authorizations. Better to make the work that needs to be done as clear and > as simple as possible. > I tend to agree with the negative stance on third party auth, but SPF obviously has the include: statement which is third party auth at the most basic level... atps[1] is the obvious equivalent for DKIM. I don't know if atps failed because it wasn't all that useful, or if it was tied in folks minds to adps, or the failure of the follow-on reputation system stuff.. Neither atps or spf include are really designed for large scale usage across thousands of "relays" etc, and I don't think they should be used for that, but for a bunch of small to medium entities, it could be the thing that makes higher p= possible. Brandon [1] I just looked atps again, but I might have missed something that makes it less useful --00000000000044432605ad556beb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 20, 2020 at 1:36 PM Tim D= raegen <tim@eudaemon.net> wro= te:
On Aug = 20, 2020, at 2:16 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Thu, Aug 20, 2020 at 1:59 AM Alessan= dro Vesely <vesely@t= ana.it> wrote:
I am wondering whether companies like Dmar= cian could implement third-pary whitelisting.=C2=A0 As they receive and ana= lyze DMARC aggregate reports on behalf of many mail sites, they probably ar= e able to distinguish various level of authentication failures, from mailin= g lists to misaligned ESPs, to actual abusers.=C2=A0 In that case, they cou= ld maintain a whitelist tailored for any given client.=C2=A0 The client wou= ld set, say:

_dmarc.client.domain.example IN TXT "v=3DDMARC1; rua=3Dmailto:client-id@ag.dmarci= an.com; snd=3Dclient-id.rhswl.dmarcian.com; [...]"<= br> [...]

Having spent a lot of time and en= ergy building a DKIM-based reputation system that (IMHO) showed promise, I = made it available for people to try for free.=C2=A0 There was no uptake, ev= en after presenting its promising results in places like M3AAWG.=C2=A0 Time= s may have changed, but in retrospect I think there are too many "what= -ifs" for add-ons of this nature to be seen as feasible.=C2=A0 The iss= ues seem to be:

Hi M= SK, hi Ale,

I can second that MSK's DKIM-based reputation system = is amazing. From where I sit, it's like a flying saucer that humans just haven't fi= gured out how to fuel quite yet. I believe that fuel comes from widespread adopt= ion of domain-based email=20 authentication aka DMARC. The challenge of getting the email universe to embrace something like DMARC feels at times impossible, but the fact is it just takes a lot of coordination, dedication, and consistent levels=20 of exercise to stay sane.

That said, Ale, I like the idea of a Domain= Owner being able to share some sort of exception list for email flows that= are recognized by the Domain Owner, but are still (for various reasons) be= yond the ability of the Domain Owner to address. Something like, "I= 9;ve got a vendor that will never send DMARC-compliant email on my behalf&q= uot;. It appeals to my fondness to be able to Just Fix Things without havin= g to bother anyone. I don't think it would work, though, because it rel= ies on email receivers having to widely implement new stuff, and it relies = on Domain Owners accurately maintaining another thing. It's easier and = more effective to get the vendor to do the right thing.

Oh, on 2nd read (I've been consumed with the non-IETF world for = a few months and only took this up because Ale emailed me at work).. I thin= k keying off of "Sender:" is a really bad idea. Multiple policy k= eys into a single piece of email has never made sense.

Third party = authorization makes sense to me in theory as a tool for a very specific pro= blem. In practice, people and organizations struggle to get first party aut= horization into place. Once they start to tackle their own first party auth= orization, the need for third party authorization tends to evaporate. What&= #39;s left over? People that want to put together a list of authorized thir= d parties but aren't quite ready to do their own first party auth?

From a receiver's perspective, it then looks like = the first party has no idea what it is doing (which is the default anti-spa= m stance for all Internet mail), so then the receiver is now looking at a b= unch of factors unrelated to first-party auth.. including any third party a= uthorization. EG, the receiver notes that the email is authorized by a thir= d-party - a newsletter company. "First party" authorization is NO= T established, so the receiver has to process the email based on the streng= th of the newsletter company's reputation (among other things). So then= why bother at all with the construct of "third party authorization&qu= ot;?

So I guess put me in the camp of not seeing u= tility in third party authorizations. Better to make the work that needs to= be done as clear and as simple as possible.
=

I tend to agree with the negative stance on third party= auth, but SPF obviously has the include: statement which is third party au= th at the most basic level...
atps[1] is the obvious equivalent f= or DKIM.=C2=A0 I don't know if atps failed because it wasn't all th= at useful, or if it was tied in folks minds to adps, or the failure of the = follow-on reputation system stuff..

Neither atps o= r spf include are really designed for large scale usage across thousands of= "relays" etc, and I don't think they should be used for that= , but for a bunch of small to medium entities, it could be the thing that m= akes higher p=3D possible.

Brandon

<= /div>
[1] I just looked atps again, but I might have missed something t= hat makes it less useful
--00000000000044432605ad556beb-- From nobody Thu Aug 20 16:26:28 2020 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 169153A1482 for ; Thu, 20 Aug 2020 16:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 U1AxhukrpVIK for ; Thu, 20 Aug 2020 16:26:25 -0700 (PDT) Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 713AD3A0EC9 for ; Thu, 20 Aug 2020 16:26:24 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2055.outbound.protection.outlook.com [104.47.46.55]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QFD008SSYFZ74A0@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 20 Aug 2020 18:26:23 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.20.232118, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.8.18.5750001, SenderIP=[104.47.46.55] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofsvHz0ulHfStITfkibsKUsznK+Tlo3lA66XA2/apmc060D2k6L+V61BHcHxt8/rjLh1Ta7Rhjba8W+yefhFlIdU49rerAbIbn5jv8HnhSGlr0TusUK70UAxIiK4seKhW3Y/tGKTTCCmrDHM0sFnY/+LQ2cfI2toXKffroMXjq1x32AQogqzNo9tKj3OaD6xK7MYppTZxXP7t4tfLVD7vsifQso66tyTTUl0FN1rQfR+fYegK+uaMnQCaXTgAi9djCw5VnSg7FI88DwI0o2oF/kkkpDIvPUUpK297OfZQwy4FFMtRKX0JJXVWoscBEsAlswyOPgIriJvEgIW0Km8kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MsGbvTi6YpxddeHEzrqvOiv97LUwJ8uwmYWrBUNxliw=; b=hrE4YXPWjHeO9Ri1vfYfV7laCGasg0NqcirbkZ09PuH4X+l26S9kp8uIUqdo36X0l41R30Z5xgeTIq8bL7dZzetcaIdyMw4B8roWt/CGZDn+aN9sBUDI+FZW3Oz/kT7E8Y4cSqqkf99Opz/G3yhURXqOyLz+7NVpZKJX9H8NYER5LiVojE9bwikipSIu0w2E6EuW5KoVNNJ4NmuEq/yUHmQb3vCe24L8Fe0obZU5oXczjSGV8C5d+ucfgAFSRRkjAYR2ThCtoEnjkOOee+hmc1N/QGHJu3ptxrUiwurAjzrhpXj8kSMaew+2omzeeVd8gnrh4qhGBSTIihnTY6OScw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MsGbvTi6YpxddeHEzrqvOiv97LUwJ8uwmYWrBUNxliw=; b=u9yz2329u5cVCHpapx/WpyZEuJuF/B0xdRXm+4bsCoPMa0K10DKWVwR/rE+8+IptstUWDvaE/tpaWMPl5ORNnKU0v/Mfd+nMJLSy5IaxpNjddJIaChTEDN+AeCta865Wc1lpRhBbbYIcqOfMc0jDYmdAVi5DYIh0wMwhAsPb3+0= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM6PR06MB3914.namprd06.prod.outlook.com (2603:10b6:5:8b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Thu, 20 Aug 2020 23:26:21 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50%6]) with mapi id 15.20.3283.027; Thu, 20 Aug 2020 23:26:21 +0000 To: dmarc@ietf.org References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> From: Jesse Thompson Message-id: <1988db12-7a72-6176-01aa-45848ad5683c@wisc.edu> Date: Thu, 20 Aug 2020 18:26:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.1.1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-ClientProxiedBy: CH2PR08CA0014.namprd08.prod.outlook.com (2603:10b6:610:5a::24) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR08CA0014.namprd08.prod.outlook.com (2603:10b6:610:5a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Thu, 20 Aug 2020 23:26:20 +0000 X-Originating-IP: [146.151.213.183] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b05584b0-6ed9-4493-b1ad-08d84560725f X-MS-TrafficTypeDiagnostic: DM6PR06MB3914: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CLMZseHMH5mWOZRNUGhrscXhaw0849lNeWw4Yxs1JoFbtsAFbtrSFbV3sIqB3v4VYO36KJBFfEVJXOdXk2JO28VKjon/b8p/+Cvjdi+PO0AlZxDsJfS1jrN3ot85oYcgSZrg3BKJP6P7YlWs19KSf03bsXjwNPertaKKwtFKKDvvmHONHpUDpggcQOScxpoTPK1LQOc1wmP0JBc8bMsLspMBzM+cNX5qpgfC6SPh9K8Z8qkCxeijHxLABX+iUj9gJYgd7qIdCHkypEulEt8rZQT1c+Bg9hwZan7hoPfEiujvljReTIELTBSx520x2VSI9pBBNG5D1qis/OiS0PS78StdYS/484QCveoyuc06O+tII8bVFkbMA+pnKvHsjYvtSDTli4+GAHtzjgGYRUHNbfavk3J/x3+aCfRueK07Vh4p9QnyoOEV3Ft+j4bT9EsGgoq3/+wNuzv83dlyJpkJMgWgLWQqudRXZKMWIWI1NV8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(396003)(346002)(376002)(2906002)(478600001)(316002)(31686004)(5660300002)(786003)(16576012)(4744005)(8936002)(6486002)(53546011)(31696002)(6706004)(8676002)(6916009)(26005)(66556008)(66476007)(66946007)(16526019)(44832011)(36756003)(2616005)(956004)(86362001)(75432002)(186003)(3940600001)(43740500002)(130980200001)(223123001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: eiXi8qBRbuX/RBJFpPRf9cPN1DDHMsngswr42mGfh+5KqByG2BgxPwoom50s841ygd4/F4wye7qgtXXjUfzFmDgcHnqC2kf/zVaxhLNE2DfebTHqhCapsrN1xkMd12xke2cty32EGCoQ10zL1+T1y8ZawOwIJntySmloCfOrh8p7PIIPAFqVSGzkSQ6PHHXlTub439/qlghcpv+zs4hTdRrU4uwotUOmh2og97tokliZiH+A+OF6AM6rAiW39Dmqj0ZegMKFFTOUdb+8CqgFcInH7+7uX0ODvVwl3tPUpBB7rw/phmUFNjSyn2rGHiZ2X05eFj5jNfOLxx+RUN1i6UQKVYYN3n9M1/6SIwwVbPJV/RDL8GDcv2dVHU2sgTGFunMsZVwGxqefraXnXhJnU8WdLh1WuWzu3HF/qei7ICyUibfjH63/eRGuF0XxvymjfCSOA623X1X+2JScwxM0PrQKVKkQHEkXlkUZF749av7O/SjfQbVmXiz8IXSdNjZaO0Ykrzn1SEVM+d+tmtuz0P8voVY9CeyePspqUHpXgu3tYEbnL/mKSZQy8bVBHu+aXnnKClo28leE4BzcgWqEqDt956uH6rX9tr+y62rUZXGNaW8rM/mnb5wtXSxg7LDOXTeaM1O1v7O5GWG1NrsNzA== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: b05584b0-6ed9-4493-b1ad-08d84560725f X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2020 23:26:21.2315 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: spLiz3JCx+nKyr3fldZ1sV5zcdzOQfkrXkJFvORDLi1y5WkRNXf06UlTfe0lxSCzKx5oRGSHpq3Npdh5yHMuiw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB3914 Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 23:26:27 -0000 On 8/20/20 4:00 PM, blong=40google.com@dmarc.ietf.org wrote: > Neither atps or spf include are really designed for large scale usage That's my conclusion, as well. I don't want to authorize every potential MLM to use all addresses in all of our domains cart blanch, even if I would otherwise trust them (e.g. their purported ARC results). I *do* want to authorize our *own* MLM(s) to use our own domains for *internal* use... so I thought for a minute... maybe ATSP has merit for small scale usage, as an alternative to SPF include? But no, I don't know if any MLM has a way to check to see if they are authorized via any mechanism, so they will continue to munge the From header for our DMARC-enabled domains anyway. So, for this *internal* use case, maybe I'll just check the ARC result from the trusted MLM and replace the From header with the value of Reply-to/X-Original-From, and call it a day. Jesse From nobody Thu Aug 20 16:55:58 2020 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 3FE153A14A9 for ; Thu, 20 Aug 2020 16:55:56 -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, 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 URrUNHnUsLIl for ; Thu, 20 Aug 2020 16:55:54 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 A9AB53A1458 for ; Thu, 20 Aug 2020 16:55:54 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id x12so146952qtp.1 for ; Thu, 20 Aug 2020 16:55:54 -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=j1VIhBc6loT+mSwyxbx5VEPdkYKbG4DbqclS2Ri71AE=; b=D3zuGF8wMImG7OGEQmHlmIZ+oVPjO9I5+WY5tJ0v2pXwfAU3qyNET+5E/RqH80LP4W Wy4P9tu27oJbxKJ2Z/mAcwjh2tOO2uy16P7WqnWt6WZKI3xTEvWycEXFIWc9QMYQe6H+ WJpDrQuiupldXQUUv0shqnrshY169qnDebxONMD2iBfl+zm7/jXqN7QeyawuaZW9xGAo C9aPG8X/Qe23Y+/pYrOxCi5qBaeVhY6wVNXmiZhnrhEDbVQRb5FC6pGrAIlvDPfzO0RZ 1W+JL2Lg5Em617/ZW++ZQdtAn41oql6nfBTHG9gVNHR2BXLKhRwkwGnqPWDlJTJ3M3Oe mXRA== 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=j1VIhBc6loT+mSwyxbx5VEPdkYKbG4DbqclS2Ri71AE=; b=dGOhS0oJ3BTorZRNp9spAPvN9aDBfKFKnaUqugzxRuyNSsInjQT9UT2rLHrA2cyrdA v/u5T7eMeytOE9BZrs8YeLSe1Y+tDSsjSvbpJEDulGJqAqWXfWdtefyufPZtmXAMJpQU jIv08D0Mn/C9+4P6/HhNCu8qsnEan8ERVUgTeeAUP71E5LUlxkR2FquzhDaHtqO16QA2 2ZnCR1SKhtOxgJ8rv9PT6eTNDCGEfy5n8+zQD3kXBYkkrIdqN3VSjC0XJWQ1BQ7AIvik q2q1skx3xKCxPuA5wPuKUnPa2RQTNa5svkebVCjf7DsjgAtim03/CXi9A320gWJWTVDu TP8w== X-Gm-Message-State: AOAM530jMkv9ARw95brafY+NonyonvX1zOa9uKJRYKjfi8fCg6q2ITnf UZ9KjobUDMlzozcRvQ1QlHfn/G56y2sLhjn0IO3JzZ6A320= X-Google-Smtp-Source: ABdhPJySsi6QX8Kxd85jYtgUsvtF/BE3j4bbK9qnGGPxPEjSA6f4Oi9uv9ej80+uKw7oRRU3MznYAFFqrNcfDu1u67k= X-Received: by 2002:ac8:660f:: with SMTP id c15mr355855qtp.34.1597967753597; Thu, 20 Aug 2020 16:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:fcd0:0:0:0:0:0 with HTTP; Thu, 20 Aug 2020 16:55:52 -0700 (PDT) In-Reply-To: <1988db12-7a72-6176-01aa-45848ad5683c@wisc.edu> References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <1988db12-7a72-6176-01aa-45848ad5683c@wisc.edu> From: Dotzero Date: Thu, 20 Aug 2020 19:55:52 -0400 Message-ID: To: Jesse Thompson Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050d7d705ad57dcaa" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 23:55:56 -0000 --00000000000050d7d705ad57dcaa Content-Type: text/plain; charset="UTF-8" On Thursday, August 20, 2020, Jesse Thompson wrote: > On 8/20/20 4:00 PM, blong=40google.com@dmarc.ietf.org wrote: > > Neither atps or spf include are really designed for large scale usage > > That's my conclusion, as well. I don't want to authorize every potential > MLM to use all addresses in all of our domains cart blanch, even if I would > otherwise trust them (e.g. their purported ARC results). > > I *do* want to authorize our *own* MLM(s) to use our own domains for > *internal* use... so I thought for a minute... maybe ATSP has merit for > small scale usage, as an alternative to SPF include? But no, I don't know > if any MLM has a way to check to see if they are authorized via any > mechanism, so they will continue to munge the From header for our > DMARC-enabled domains anyway. So, for this *internal* use case, maybe I'll > just check the ARC result from the trusted MLM and replace the From header > with the value of Reply-to/X-Original-From, and call it a day. > > Jesse > This is why I proposed a tag that would have a value consisting of the authorized intermediary domain. It would only be valid for that message. Because the tag is signed separately from the rest of the message, it should survive even if the intermediary modifies other parts of the message. If the intermediary DKIM signs the modified message with their own signature, that provides some assurance to the receiver. I haven't seen enough favorable response to justify working on a detailed submission to the group. I'm not an IETF standards wonk. Michael Hammer --00000000000050d7d705ad57dcaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thursday, August 20, 2020, Jesse Thompson <jesse.thompson=3D<= a href=3D"mailto:40wisc.edu@dmarc.ietf.org">40wisc.edu@dmarc.ietf.org&g= t; wrote:
On 8/20/20 4:00 PM, blong=3D40google.com@dmarc.ietf.or= g wrote:
> Neither atps or spf include are really designed for large scale usage<= br>
That's my conclusion, as well.=C2=A0 I don't want to authorize ever= y potential MLM to use all addresses in all of our domains cart blanch, eve= n if I would otherwise trust them (e.g. their purported ARC results).

I *do* want to authorize our *own* MLM(s) to use our own domains for *inter= nal* use... so I thought for a minute... maybe ATSP has merit for small sca= le usage, as an alternative to SPF include?=C2=A0 But no, I don't know = if any MLM has a way to check to see if they are authorized via any mechani= sm, so they will continue to munge the From header for our DMARC-enabled do= mains anyway.=C2=A0 So, for this *internal* use case, maybe I'll just c= heck the ARC result from the trusted MLM and replace the From header with t= he value of Reply-to/X-Original-From, and call it a day.

Jesse

This is why I proposed a tag that would ha= ve a value consisting of the authorized intermediary domain. It would only = be valid for that message. Because the tag is signed separately from the re= st of the message, it should survive even if the intermediary modifies othe= r parts of the message. If the intermediary DKIM signs the modified message= with their own signature, that provides some assurance to the receiver.

I haven't seen enough favorable response to just= ify working on a detailed submission to the group. I'm not an IETF stan= dards wonk.

Michael Hammer=C2=A0
--00000000000050d7d705ad57dcaa-- From nobody Fri Aug 21 01:57:57 2020 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 68BA13A08C1 for ; Fri, 21 Aug 2020 01:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 b1PfmpTZ6EFJ for ; Fri, 21 Aug 2020 01:57:53 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 892203A08C6 for ; Fri, 21 Aug 2020 01:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598000267; bh=uBSFpPhzG3UZpQAqeUP8E+mvGR8id+qc9q28cFCDPns=; l=3155; h=To:References:From:Date:In-Reply-To; b=DW3YZ19SsG01aYxmbyFV5XAJXQvM20wfzMeFUYRnS6MYgXJODdYbeO0NkQsRcuYJ1 sPi2or7n0kbuPrtR08InvgVnEL0FozzwrN0UWP4vm1qM3F1+g1HjNewXTQFvWNKxj5 OLNLXE0Ade3kKEYverV0O8/PoFdiJbQUCg/gtHieE/KEdDD0gq7j57c4M8wkw Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.103] ([5.170.68.179]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F3F8C8A.00000B09; Fri, 21 Aug 2020 10:57:46 +0200 To: dmarc@ietf.org References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <1988db12-7a72-6176-01aa-45848ad5683c@wisc.edu> From: Alessandro Vesely Message-ID: Date: Fri, 21 Aug 2020 10:57:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 08:57:55 -0000 On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote: > On Thursday, August 20, 2020, Jesse Thompson wrote: >> On 8/20/20 4:00 PM, blong@google.com wrote: >>> Neither atps or spf include are really designed for large scale usage >> >> That's my conclusion, as well. I don't want to authorize every potential >> MLM to use all addresses in all of our domains cart blanch, even if I would >> otherwise trust them (e.g. their purported ARC results). >> >> I *do* want to authorize our *own* MLM(s) to use our own domains for >> *internal* use... so I thought for a minute... maybe ATSP has merit for >> small scale usage, as an alternative to SPF include? Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a rhswl zone which can be outsourced. >> But no, I don't know if any MLM has a way to check to see if they >> are authorized via any mechanism, so they will continue to munge >> the From header for our DMARC-enabled domains anyway. That is going to be true for /any/ method we devise now. From: rewriting is not going to stop on the next day. We must tune aggregate reports so that MLMs can tell if it's still necessary. It may take decades... still better than ∞. >> So, for this *internal* use case, maybe I'll just check the ARC >> result from the trusted MLM and replace the From header with the >> value of Reply-to/X-Original-From, and call it a day. Restoring From: at the MDA is certainly a good idea. However, the need to whitelist each MLM is not much viable for a number of operators. And, in case, I'd adopt John's broad brush: If I went so far as to whitelist the MLM, why should I take the burden to scrutinize the way it applied policies? It seems more sound to allow my recipients to see the same messages as every other subscriber. > This is why I proposed a tag that would have a value consisting of the > authorized intermediary domain. It would only be valid for that message. > Because the tag is signed separately from the rest of the message, it > should survive even if the intermediary modifies other parts of the > message. If the intermediary DKIM signs the modified message with their own > signature, that provides some assurance to the receiver. That was described on June 26, here: https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/ It requires modifying signer behavior. AIUI, the sender recognizes that one of the recipients is an allowed mailing list, and adds that tag to that copy of the message. It looks less outsourceable than an external whitelist. Let me call weak signature this concept. As it is very similar to dkim-conditional, either one or the other should be adopted. By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as weak signatures can all be adopted concurrently. > I haven't seen enough favorable response to justify working on a detailed > submission to the group. I'm not an IETF standards wonk. I'd support weak signatures, in either embodiment. I don't think it needs to be linked to the Sender: field. Best Ale -- From nobody Fri Aug 21 04:04:35 2020 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 307CD3A0807 for ; Fri, 21 Aug 2020 04:04:33 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbqhGkyuUzRn for ; Fri, 21 Aug 2020 04:04:31 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119A23A07F6 for ; Fri, 21 Aug 2020 04:04:30 -0700 (PDT) X-ASG-Debug-ID: 1598007867-11fa31095e69520001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id vrKe1x1Dix2AMuae (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 21 Aug 2020 07:04:27 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=PX3oP/UUGRLPLy8KuwGQrj2sIyMwBhqmu3GAu/F8mHk=; b=bSdVklJg1seuqtEO5ynbi1aeUClugNv6JdH4VCvQxhyWPh1VObZmmayNhtQgI9s2E W5CIY3WFnmkopUsQOmoP6qcUw365jMFLCISy241Wql9ij3ZoVBCSniXl2ktGqh7jk dzYwGrAhNd6O8JKNxJpagAlOioKOfwKwlfxcf/v+U= From: "Douglas E. Foster" To: Date: Fri, 21 Aug 2020 11:04:20 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Reply-To: fosterd@bayviewphysicians.com Message-ID: <3332208e1040436798ee5ef0729275e3@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=4d24e574419e4d138463e45147b1d752 In-Reply-To: References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <1988db12-7a72-6176-01aa-45848ad5683c@wisc.edu> X-Exim-Id: 3332208e1040436798ee5ef0729275e3 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1598007867 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 11738 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84055 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 11:04:33 -0000 This is a multipart message in MIME format. --4d24e574419e4d138463e45147b1d752 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Instead of immediately deciding which ideas can and cannot work, I suggest = that we create an extension mechanism for DMARC and then let the market dec= ide. Perhaps someone will find traction for an idea that is useful to a su= bset of users even if it is not useful for every sender-receiver pair. The extension mechanism could be as simple as an "add-ons=3DY" clause in th= e DMARC record. If a receiver has implemented ANY add-on method, this flag tells him to che= ck all of the options that he supports. Most likely this will require one= or more additional DNS lookups to determine which add-on technique is supp= orted by the sender. The result of those lookups will determine if the s= ender and the receiver support any of the same techniques. When there is = a match on supported techniques, the logic for that technique is invoked. = But when the flag is absent, no resources are wasted on checking add-on m= ethods that can only apply to a subset of all messages. This approach separates the DMARC spec, which focuses on two specific authe= ntication strategies, from add-on methods that invoke alternate authenticat= ion strategies, so that the DMARC specification can move forward. It leaves room for all of the ideas mentioned so far, and for those that ha= ve not yet been suggested. It also leaves room for a good-but-neglected i= dea to gain traction based on future events. The details of those other implementations can be determined by private agr= eement or by RFC. DF ---------------------------------------- From: Alessandro Vesely Sent: 8/21/20 4:58 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing l= ist On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote: > On Thursday, August 20, 2020, Jesse Thompson wr= ote: >> On 8/20/20 4:00 PM, blong@google.com wrote: >>> Neither atps or spf include are really designed for large scale usage >> >> That's my conclusion, as well. I don't want to authorize every potential >> MLM to use all addresses in all of our domains cart blanch, even if I wo= uld >> otherwise trust them (e.g. their purported ARC results). >> >> I *do* want to authorize our *own* MLM(s) to use our own domains for >> *internal* use... so I thought for a minute... maybe ATSP has merit for >> small scale usage, as an alternative to SPF include? Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides fo= r a rhswl zone which can be outsourced. >> But no, I don't know if any MLM has a way to check to see if they >> are authorized via any mechanism, so they will continue to munge >> the From header for our DMARC-enabled domains anyway. That is going to be true for /any/ method we devise now. From: rewriting is= not going to stop on the next day. We must tune aggregate reports so that = MLMs can tell if it's still necessary. It may take decades... still better = than =E2=88=9E. >> So, for this *internal* use case, maybe I'll just check the ARC >> result from the trusted MLM and replace the From header with the >> value of Reply-to/X-Original-From, and call it a day. Restoring From: at the MDA is certainly a good idea. However, the need to whitelist each MLM is not much viable for a number of = operators. And, in case, I'd adopt John's broad brush: If I went so far as = to whitelist the MLM, why should I take the burden to scrutinize the way it= applied policies? It seems more sound to allow my recipients to see the sa= me messages as every other subscriber. > This is why I proposed a tag that would have a value consisting of the > authorized intermediary domain. It would only be valid for that message. > Because the tag is signed separately from the rest of the message, it > should survive even if the intermediary modifies other parts of the > message. If the intermediary DKIM signs the modified message with their o= wn > signature, that provides some assurance to the receiver. That was described on June 26, here: https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/ It requires modifying signer behavior. AIUI, the sender recognizes that one= of the recipients is an allowed mailing list, and adds that tag to that co= py of the message. It looks less outsourceable than an external whitelist. Let me call weak signature this concept. As it is very similar to dkim-cond= itional, either one or the other should be adopted. By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as= weak signatures can all be adopted concurrently. > I haven't seen enough favorable response to justify working on a detailed > submission to the group. I'm not an IETF standards wonk. I'd support weak signatures, in either embodiment. I don't think it needs t= o be linked to the Sender: field. Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --4d24e574419e4d138463e45147b1d752 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Instead of immedia= tely deciding which ideas can and cannot work, I suggest that we create an = extension mechanism for DMARC and then let the market decide.  Perhaps= someone will find traction for an idea that is useful to a subset of users= even if it is not useful for every sender-receiver pair.

The extension mechanism could be as simple as an "add-ons=3DY" clau= se in the DMARC record.

If a receiver has implemen= ted ANY add-on method, this flag tells him to check all of the options that= he supports.   Most likely this will require one or more additional D= NS lookups to determine which add-on technique is supported by the sender. =    The result of those lookups will determine if the sender and t= he receiver support any of the same techniques.   When there is a matc= h on supported techniques, the logic for that technique is invoked.   =  But when the flag is absent, no resources are wasted on checking add-= on methods that can only apply to a subset of all messages.

<= /div>
This approach separates the DMARC spec, which focuses on two spec= ific authentication strategies, from add-on methods that invoke alternate a= uthentication strategies, so that the DMARC specification can move forward.=

It leaves room for all of the ideas mentioned so = far, and for those that have not yet been suggested.   It also leaves = room for a good-but-neglected idea to gain traction based on future events.=

The details of those other implementations can be= determined by private agreement or by RFC.

DF


From: Alessandro Vesely <vesely@tana.it>
Sen= t: 8/21/20 4:58 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] third party authorization, not, was n= on-mailing list
On Fri 21/Aug/2020 01:55:52 +0200 Dotzero = wrote:
> On Thursday, August 20, 2020, Jesse Thompson <jess= e.thompson@wisc.edu> wrote:
>> On 8/20/20 4:00 PM, blong= @google.com wrote:
>>> Neither atps or spf include are r= eally designed for large scale usage
>>
>> = That's my conclusion, as well. I don't want to authorize every potential
>> MLM to use all addresses in all of our domains cart blanch= , even if I would
>> otherwise trust them (e.g. their purpo= rted ARC results).
>>
>> I *do* want to aut= horize our *own* MLM(s) to use our own domains for
>> *inte= rnal* use... so I thought for a minute... maybe ATSP has merit for
>> small scale usage, as an alternative to SPF include?
<= br>

Besides limiting the recourse to hashes, w.r.t= ATPS my proposal provides for a rhswl zone which can be outsourced.
<= div>

>> But no, I don't know if any MLM = has a way to check to see if they
>> are authorized via any= mechanism, so they will continue to munge
>> the From head= er for our DMARC-enabled domains anyway.

That is g= oing to be true for /any/ method we devise now. From: rewriting is not goin= g to stop on the next day. We must tune aggregate reports so that MLMs can = tell if it's still necessary. It may take decades... still better than = =E2=88=9E.


>> So, for this *i= nternal* use case, maybe I'll just check the ARC
>> result = from the trusted MLM and replace the From header with the
>>= ; value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a n= umber of operators. And, in case, I'd adopt John's broad brush: If I went s= o far as to whitelist the MLM, why should I take the burden to scrutinize t= he way it applied policies? It seems more sound to allow my recipients to s= ee the same messages as every other subscriber.

> This is why I proposed a tag that would have a value cons= isting of the
> authorized intermediary domain. It would only = be valid for that message.
> Because the tag is signed separat= ely from the rest of the message, it
> should survive even if = the intermediary modifies other parts of the
> message. If the= intermediary DKIM signs the modified message with their own
>= signature, that provides some assurance to the receiver.


That was described on June 26, here:

It requires modifying sign= er behavior. AIUI, the sender recognizes that one of the recipients is an a= llowed mailing list, and adds that tag to that copy of the message. It look= s less outsourceable than an external whitelist.

L= et me call weak signature this concept. As it is very similar to dkim-condi= tional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well a= s weak signatures can all be adopted concurrently.


> I haven't seen enough favorable response to justify wo= rking on a detailed
> submission to the group. I'm not an IETF= standards wonk.


I'd support weak s= ignatures, in either embodiment. I don't think it needs to be linked to the= Sender: field.


Best
Ale<= /div>
--


























_____________________________________= __________
dmarc mailing list
dmarc@ietf.org
--4d24e574419e4d138463e45147b1d752-- From nobody Fri Aug 21 12:09:54 2020 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 98DA23A106C for ; Fri, 21 Aug 2020 12:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 Dl6pftXLwwMX for ; Fri, 21 Aug 2020 12:09:50 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 9AE323A1068 for ; Fri, 21 Aug 2020 12:09:50 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:21b0:5472:b576:2ac8]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07LJ9mCj027634 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 21 Aug 2020 12:09:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1598036989; bh=HdTQ4K5QD9d3PpcgD0BHQaIS1U8gcl8o0PMhDvSNJTI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=IBCMVDykEOGVqgi0pp624eZGFI4NHXtm7Qa9tojT/IaVJMf+ZMIUp+VAJeO1OwEDB V8v3P+wpPpB5mpf+3wLDKBPmqKlnPhA0QnW1X8VLJeHb6wzaSi+53rp5RYnPdfPGhW /tlr7pFnsJGVmsER3jgfIvgh11Sm4sH6p4Y8OF8A= To: dmarc@ietf.org References: <20200815225306.967CC1E9E41D@ary.local> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Fri, 21 Aug 2020 12:09:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200815225306.967CC1E9E41D@ary.local> Content-Type: multipart/alternative; boundary="------------19D9FF6A2564DE1EF50145A3" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 19:09:53 -0000 This is a multi-part message in MIME format. --------------19D9FF6A2564DE1EF50145A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/15/20 3:53 PM, John Levine wrote: > Not really. DKIM was deliberately designed not to be tied to any > visible part of the message. ADSP was a poorly designed hack that was > never implemented other than small experiments, and that I don't think > many people understood. I got a lot of grief for making the most > strict policy "discardable" even though that's obviously what it was. > And even with the kinder-and-gentler term "discardable" for its most harsh policy option, ADSP was moved from Standards Track to Historic. From https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ = : > There is, however, evidence of harm caused by incorrect configuration a= nd by > inappropriate use. There have, for example, been real cases where a hi= gh-value > domain published an ADSP record of "discardable", but allowed users on = their > domain to subscribe to mailing lists. When posts from those users were= sent to > other domains that checked ADSP, those subscriber domains rejected the > messages, resulting in forced unsubscribes from mailman (due to bounces= ) for > the unsuspecting subscribers. > > Assurances that are provided by ADSP are generally obtained out of band= in the > real Internet, and not through ADSP. Current deployment of ADSP is not= > recommended. Is that not exactly the same situation with DMARC, except that the policy in question now is "reject" rather than "discardable"? Yes, it's just a keyword, but it reflects the semantics of the expected action as well. -Jim --------------19D9FF6A2564DE1EF50145A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/15/20 3:53 PM, John Levine wrote:
Not really. DKIM was deliberately designed not to be tied to any
visible part of the message. ADSP was a poorly designed hack that was
never implemented other than small experiments, and that I don't think
many people understood. I got a lot of grief for making the most
strict policy "discardable" even though that's obviously what it was.

And even with the kinder-and-gentler term "discardable" for its most harsh policy option, ADSP was moved from Standards Track to Historic. From https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :

There is, however, evidence of harm caused by incorrect configuration and by
inappropriate use.  There have, for example, been real cases where a high-value
domain published an ADSP record of "discardable", but allowed users on their
domain to subscribe to mailing lists.  When posts from those users were sent to
other domains that checked ADSP, those subscriber domains rejected the
messages, resulting in forced unsubscribes from mailman (due to bounces) for
the unsuspecting subscribers.

Assurances that are provided by ADSP are generally obtained out of band in the
real Internet, and not through ADSP.  Current deployment of ADSP is not
recommended.
Is that not exactly the same situation with DMARC, except that the policy in question now is "reject" rather than "discardable"? Yes, it's just a keyword, but it reflects the semantics of the expected action as well.

-Jim

--------------19D9FF6A2564DE1EF50145A3-- From nobody Fri Aug 21 12:24:05 2020 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 BCA5C3A101D for ; Fri, 21 Aug 2020 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=bluepopcorn.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 0PcKgOiRDnZc for ; Fri, 21 Aug 2020 12:24:03 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 93F1F3A1014 for ; Fri, 21 Aug 2020 12:24:03 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:21b0:5472:b576:2ac8]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07LJO2Du027758 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 21 Aug 2020 12:24:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1598037843; bh=elqO/foxpqdkVI6+ij3U+t5hzaeH3F4XXrmzkLx75vo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=hIKE4STdr1MB+BuGNFecshag2zXspS/U0xbiAl6vDKovibFk6JhNPgGTmZEd6N2/E TcLtDYVHdUt5fGqjKkO9O55bMOGWhqB1CN3pb48zsBNCZgBUa/vB386SEK4qwirZfC HqqTwvan7KhCu7bQG6ljQjKzM1Y5SqIYPIqa2204= To: dmarc@ietf.org References: <20200807191216.43E971E4014E@ary.qy> <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> <7ce20245-5942-14f3-3220-1faaa2c8ccbb@wisc.edu> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <4d13611d-e6e7-a6f8-d48a-2a11a74f5d51@bluepopcorn.net> Date: Fri, 21 Aug 2020 12:23:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <7ce20245-5942-14f3-3220-1faaa2c8ccbb@wisc.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 19:24:05 -0000 On 8/17/20 3:52 PM, Jesse Thompson wrote: > With a complex organization the only way to get people to change is to publish a restrictive DMARC policy and then see who comes out of the woodwork sheepishly admitting that they've been ignoring us for years. > > Normal people sending email (especially those who are working with an ESP, most of which happily send email without any DMARC alignment) do not comprehend the notion that they should be using a subdomain for their transactional messages; even when we directly communicate this fact to them repeatedly. They just don't understand the nuances of email. > I thought the DMARC reporting mechanism was there to allow such organizations to detect those behaviors and get them corrected without actually causing the damage of a restrictive policy. -Jim From nobody Fri Aug 21 12:26:06 2020 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 808AA3A1072 for ; Fri, 21 Aug 2020 12:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=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=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTXaQ7oOWyEU for ; Fri, 21 Aug 2020 12:26:02 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 A7DC23A1065 for ; Fri, 21 Aug 2020 12:26:02 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id 2so2343839qkf.10 for ; Fri, 21 Aug 2020 12:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=2MY2oMZGHG5HLmnCNG0kWGuJ8i7ZPBlZ3N6IVP5kI6E=; b=V7iu0RqddR4IPedDXW4H3EcYiJQmlYrkfXiVAFTE47CBWGl1MIT/fNPkG3R7+VhUaS mLtkJRmDSDPIdezslTrCZlbN3oPPCygvJqcTGV6OZW//GUURkfGV0B5FIrOmiq2Jqwix EEs1OJjH6Ol7TU+unAW3M1j1KYeCyKhEQyuJ//9so8RR7qVlMRuK/vagiAfhYqF8V+TG Je/ZXEnB6XlOqMsWyt9rnK0Girlf5lx6er2gwJsq7KWdivQMSR3nDINYyaViSzO3W5v7 GIKPo8bogCbimW6CaFR0cy31pwgS0Ig67cGBXHbgf4n/4phedYoM0OgL57Qy4RvqAGWh 2R5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2MY2oMZGHG5HLmnCNG0kWGuJ8i7ZPBlZ3N6IVP5kI6E=; b=A3XOTwTROgGZqk1DXr06mLi3vUF3Lk2MA4OU/h9ITKlFRYHZv5lXeCJMckodT0MZla eaxIbw4FqpXvqZnV3Ld+gYli2aduD2hGie35wDGTe7rVtEEYr6eE0PswNv49b02/po1X 2Ch1zwkSgDwTpLLN9uLGBzS3NVFCeWdWAPZcWFam4BuAPcGS/uAmk7hLaBtO+sdvEMco PZmv86/t1YLpY1HgdVG4WA38yyOucE+Q3UJVxlSa8SGV+VBOzf4oy4ndg9Vdw4tsYvqb WfuR8QySyedteXTcJEmRoA1A3aTeZvbrCQq+/HVDIRRwU5oQ2DaICqrN81Q2xNIZIv03 YD8g== X-Gm-Message-State: AOAM530nQX+O3VQQ8xmAsHDASvF0YU3AtpdtfaH2rQBuFxCgTPzX5u18 JXCZ4ixF2IJhDoeWGA2seSzXPMm271BUxn4vguxBvxKfJW6bJQ== X-Google-Smtp-Source: ABdhPJxh8ZhliAJXIb++FBd2GTymFsJBl1alh3ca1rxJHYJdni9DqdHHGId2EeoPmQqyILAbUbgfMV/BFih5Hnpxroc= X-Received: by 2002:a37:a758:: with SMTP id q85mr4106908qke.325.1598037961315; Fri, 21 Aug 2020 12:26:01 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 21 Aug 2020 15:25:50 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000005af7e05ad6835b8" Archived-At: Subject: [dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 19:26:05 -0000 --00000000000005af7e05ad6835b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://trac.ietf.org/trac/dmarc/ticket/66 When this issue was first raised on the list back in June, it seemed that consensus might've landed on the idea that this should be written up in a separate BCP, rather than be part of the DMARC bis effort itself. I'm concerned, however, that there might not be enough there there to warrant a separate BCP, and to that end I've taken a stab at modifying the base DMARC document, specifically Section 8, Implementation, as follows: ---------------------------------------------------------------------------= ---------------------------------------------- 8 . Implementations The characteristics of a DMARC implementation will vary for the different roles in the messaging infrastructure. 8.1 Domain Owner Implementations Section 6.5 describes many of the provisions for implementing the DMARC mechanism as a Domain Owner. This section will clarify those needed for minimal and full implementations. 8.1.1 Minimal Domain Owner Implementation The only action required for minimal implementation of the DMARC mechanism by a Domain Owner is the creation of the DMARC policy record in DNS. 8.1.2 Full Domain Owner Implementation Full implementation of the DMARC mechanism by a Domain Owner requires all of the following characteristics: - Creation of the DMARC policy record in DNS which meets these criteria: - The policy record MUST express a Requested Mail Receiver policy of =E2=80=9Cquarantine=E2=80=9D or =E2=80=9Creject=E2=80=9D for the Orga= nizational Domain and all sub-domains - The Requested Mail Receiver policy MUST apply to a percentage of mail not less than 100 - Establishment of an address to receive aggregate reports at least daily; other than in exceptional circumstances such as resource exhaustion, the address must support receiving reports up to at least ten megabytes in s= ize. - Deployment of authentication technologies to ensure Identifier Alignment 8.2 Mail Receiver Implementations This section will describe minimal and full implementations of the DMARC mechanism for Mail Receivers. 8.2.1 Minimal Mail Receiver Implementation Minimal implementation of the DMARC mechanism by a Mail Receiver means fully implementing the provisions of Section 6.6 8.2.2 Full Mail Receiver Implementation Full implementation of the DMARC mechanism by a Mail Receiver is defined by the following characteristics: - Fully implementing the provisions of Section 6.6 - Validation of any ARC header sets found in the message - Enforcement of discovered policies in a manner that is consistent with Section 6.7 - Send aggregate reports at least daily using =E2=80=9Cmailto=E2=80=9D URI= s; such aggregate reports MUST be no larger than ten megabytes in size. 8.3 Report Receiver Implementations The following implementations are defined for operators that receive reports about messages related to another operator. Implementations for Domain Owners that receive reports about their own messages are described in Section 8.1. 8.3.1 Full Report Receiver Implementation Full implementation of the DMARC mechanism by a Report Receiver means establishment of an address to receive aggregate reports at least daily; other than in exceptional circumstances such as resource exhaustion, the address must support receiving reports up to at least ten megabytes in size= . 8.4 Intermediary Implementations The term =E2=80=9CIntermediary=E2=80=9D is meant to encompass Mediators, Re= lays, and Gateways as defined in [EMAIL-ARCH ]. This section will describe minimal and full implementations for Intermediaries. 8.4.1 Minimal Intermediary Implementation Minimal implementation of the DMARC mechanism by an Intermediary means fully implementing the provisions of Section 6.6 8.4.2 Full Intermediary Implementation Full implementation of the DMARC mechanism by an Intermediary is defined by the following characteristics: - Fully implementing the provisions of Section 6.6 - Attaching a complete and valid ARC Set of headers to the message - Enforcement of discovered policies in a manner that is consistent with Section 6.7 - Send aggregate reports at least daily using =E2=80=9Cmailto=E2=80=9D URI= s; such aggregate reports MUST be no larger than ten megabytes in size ---------------------------------------------------------------------------= ---------------------------------------------- Thank you for reading, and I look forward to any and all comments and discussion. --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 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. --00000000000005af7e05ad6835b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Wh= en this issue was first raised on the list back in June, it seemed that con= sensus might've landed on the idea that this should be written up in a = separate BCP, rather than be part of the DMARC bis effort itself. I'm c= oncerned, however, that there might not be enough there there to warrant a = separate BCP, and to that end I've taken a stab at modifying the base D= MARC document, specifically Section 8, Implementation, as follows:

-= ---------------------------------------------------------------------------= ---------------------------------------------

8.= =C2=A0 Implementations

The characteristics of a = DMARC implementation will vary for the different roles in the messaging inf= rastructure.

8.1 Domain Owne= r Implementations

Section 6.5 describes many of the provision= s for implementing the DMARC mechanism as a Domain Owner. This section will= clarify those needed for minimal and full implementations.

8.1.1 Minimal Domain Owner Implementatio= n

The only action required for minimal implement= ation of the DMARC mechanism by a Domain Owner is the creation of the DMARC= policy record in DNS.

8.= 1.2 Full Domain Owner Implementation

Full implem= entation of the DMARC mechanism by a Domain Owner requires all of the follo= wing characteristics:

  • Creation of the DMARC policy r= ecord in DNS which meets these criteria:

    • The = policy record MUST express a Requested Mail Receiver policy of =E2=80=9Cqua= rantine=E2=80=9D or =E2=80=9Creject=E2=80=9D for the Organizational Domain = and all sub-domains

    • The Requested Mail Receiver policy MUST apply to a percentage of mail no= t less than 100

  • Deployment of authe= ntication technologies to ensure Identifier Alignment

<= h3 dir=3D"ltr" style=3D"line-height:1.38;margin-top:16pt;margin-bottom:4pt"= >8.2 Mail Receiver Implementations

This section will describe minimal and full implement= ations of the DMARC mechanism for Mail Receivers.

8.2.1 Minimal Mail Receiver Implementation

Minimal implementation of the DMARC mechanism by a Ma= il Receiver means fully implementing the provisions of Section 6.6

8.2.2 Full Mail Receiver Implementation=

Full implementation of the DMARC mechanism by a Mail R= eceiver is defined by the following characteristics:

  • Fully implementing the provisions of Section 6.6

  • Validation of any ARC header sets found in the message<= /span>

  • Enforcement of disc= overed policies in a manner that is consistent with Section 6.7

  • Send aggregate reports at least daily usi= ng =E2=80=9Cmailto=E2=80=9D URIs; such aggregate reports MUST be no larger = than ten megabytes in size.


8.3 Report Receiver Implementations

The following implementations are defined for operators that receive r= eports about messages related to another operator. Implementations for Doma= in Owners that receive reports about their own messages are described in Se= ction 8.1.

8.3.1 Full Rep= ort Receiver Implementation

Full implementation = of the DMARC mechanism by a Report Receiver means establishment of an addre= ss to receive aggregate reports at least daily; other than in exceptional c= ircumstances such as resource exhaustion, the address must support receivin= g reports up to at least ten megabytes in size.

8.4 Intermediary Implementations

The term =E2=80=9CIntermediary=E2=80=9D is meant to encompass Mediator= s, Relays, and Gateways as defined in [EMAIL-ARCH]. This secti= on will describe minimal and full implementations for Intermediaries.

8.4.1 Minimal Intermediary Imp= lementation

Minimal implementation of the DMARC = mechanism by an Intermediary means fully implementing the provisions of Section 6.6

8.4.2 Full Intermediary Imple= mentation

Full implementation of the DMARC mecha= nism by an Intermediary is defined by the following characteristics:=

  • Fully implementing the provisions of Section 6.6

  • Attaching a complete and valid ARC Set of= headers to the message

  • Enforcement of discovered policies in a manner that is consistent with= Section 6.7

  • Send aggregate re= ports at least daily using =E2=80=9Cmailto=E2=80=9D URIs; such aggregate re= ports MUST be no larger than ten megabytes in size

------------------------------------------------------------= -------------------------------------------------------------

Thank you for read= ing, and I look forward to any and all comments and discussion.
<= br>
--

Todd Herr | Sr. Technical Progra= m Manager
p: 703.220.4153


This email and all data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--00000000000005af7e05ad6835b8-- From nobody Fri Aug 21 14:05:21 2020 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 2FD593A1278 for ; Fri, 21 Aug 2020 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 U5dsIFuD2vPF for ; Fri, 21 Aug 2020 14:05:17 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 9E5263A1269 for ; Fri, 21 Aug 2020 14:05:17 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id h4so3076689ioe.5 for ; Fri, 21 Aug 2020 14:05:17 -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=MxHvCvCVKlUm8F1SxiXHETwFh3MyxkJTk33nuGTDQ0o=; b=TWlM4Yyyv2X2Vr13zEzFEcFXjEir5L9j4UFIQ5xnlophjZ0uOMNAZn7d85feY5D03r l6el1mvrNhf8petP5LOIEFVX6Ng/w5eHzVAwKt1uOYELxQYQ1t+W4TObhKXeteAPTkRF 69Tpbl39rpbb0WphIsVSOy2gDWky4WRoypzrs50ACDKWD/eAIz9uhXwWdNo+SxSPnTkW Ty2PdbUH7xSb8yID1QpH3TLFKABLYo0uNfihilWUVvYny2vQFqnzYUjPS9V3sZrQFTpi RCu+KTPGoiGXYZGGtbVOXaARG1v1ZkXhBOuwSAyApc/7OW4VZl4c8kSTKL+VtCk0Bu72 VU0A== 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=MxHvCvCVKlUm8F1SxiXHETwFh3MyxkJTk33nuGTDQ0o=; b=j2z1+en3iwlvsBP/Gt9Nr3J0li9pU6/FgRhgJySBQF15lvCzPH3gB2O0jIML750zqA x1eGR7Fl8lPdS5XtjuwMxdY02gOxNVcoLTv4OBUjIx90PqzWXPjzHpl7pLTItpp+xtHe OjCZmAL34OdT7Iqrzg6RjXDbiL2ny4PLH3rPKPi0rkYDqWJaLyrKOAxtg46fk5STljMT Gs2ANbarUZWKbU+sudBd9RG9JEk5owxxTHKz1DmGrAkyC1PwFkAz2Lve/Aa/OqW8qn5F vYpVoYAPRmrn84sdKs42Ath9qui9WSCgi7vEdj4usDngmVVED6E08qgFAoqWFWXBd030 vxIQ== X-Gm-Message-State: AOAM5313Ccr0+EHdEYfQ/0AFLYFIhMj5RB7szeVS7F8d2ScXh2pAWuU6 O/nprjx6lV/YdFtd+dB1qC263Ez9T14u4iEJyrGX+xM+Gg== X-Google-Smtp-Source: ABdhPJz3lmQM9Hw7fCgTqoz9s0SNsvCOPgPOjtgaRzvIpq42rsss1FZ/9o+8NECZ1RysOfNTJUbCpOXHY4SFG+a4oRg= X-Received: by 2002:a6b:b74b:: with SMTP id h72mr3795478iof.52.1598043916411; Fri, 21 Aug 2020 14:05:16 -0700 (PDT) MIME-Version: 1.0 References: <20200807191216.43E971E4014E@ary.qy> <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> <7ce20245-5942-14f3-3220-1faaa2c8ccbb@wisc.edu> <4d13611d-e6e7-a6f8-d48a-2a11a74f5d51@bluepopcorn.net> In-Reply-To: <4d13611d-e6e7-a6f8-d48a-2a11a74f5d51@bluepopcorn.net> From: Brandon Long Date: Fri, 21 Aug 2020 14:05:03 -0700 Message-ID: To: Jim Fenton Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f9b9c705ad6997db" Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 21:05:19 -0000 --000000000000f9b9c705ad6997db Content-Type: text/plain; charset="UTF-8" On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton wrote: > On 8/17/20 3:52 PM, Jesse Thompson wrote: > > With a complex organization the only way to get people to change is to > publish a restrictive DMARC policy and then see who comes out of the > woodwork sheepishly admitting that they've been ignoring us for years. > > > > Normal people sending email (especially those who are working with an > ESP, most of which happily send email without any DMARC alignment) do not > comprehend the notion that they should be using a subdomain for their > transactional messages; even when we directly communicate this fact to them > repeatedly. They just don't understand the nuances of email. > > > I thought the DMARC reporting mechanism was there to allow such > organizations to detect those behaviors and get them corrected without > actually causing the damage of a restrictive policy. > One thing we've found useful in this case is controlling the organization from spamming. Which is to say that the org has a policy on approvals and what is allowed to be sent marketing wise, in some parts of the world to comply with laws on such topics, or to be sure the entire org follows the principles and someone new doesn't just poison the pool for everyone else. There are always people who route around restrictions or sometimes don't even bother to look for anything, they'll just hire a third party ESP and spam away. DMARC helps in this case to reduce the success of that and force them back to internal compliance, which relieves the legal burden as well as the negative impacts on delivery and public perception. For folks who just register a new domain name and spam anyways... yeah, well, there are other consequences down the line and other anti-phishing restrictions that kick in at least on our inbound systems.. Brandon --000000000000f9b9c705ad6997db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 21, 2020 at 12:24 PM Jim = Fenton <fenton@bluepopcorn.net= > wrote:
= On 8/17/20 3:52 PM, Jesse Thompson wrote:
> With a complex organization the only way to get people to change is to= publish a restrictive DMARC policy and then see who comes out of the woodw= ork sheepishly admitting that they've been ignoring us for years.=C2=A0=
>
> Normal people sending email (especially those who are working with an = ESP, most of which happily send email without any DMARC alignment) do not c= omprehend the notion that they should be using a subdomain for their transa= ctional messages; even when we directly communicate this fact to them repea= tedly.=C2=A0 They just don't understand the nuances of email.
>
I thought the DMARC reporting mechanism was there to allow such
organizations to detect those behaviors and get them corrected without
actually causing the damage of a restrictive policy.
<= br>One thing we've found useful in this case is controlling the organiz= ation from spamming.

Which is to say that the org = has a policy on approvals and what is allowed to be sent marketing wise, in= some parts of the world to comply with laws on such topics,
or t= o be sure the entire org follows the principles and someone new doesn't= just poison the pool for everyone else.

There are= always people who route around restrictions or sometimes don't even bo= ther to look for anything, they'll just hire a third party ESP and spam= away.

DMARC helps in this case to reduce the succ= ess of that and force them back to internal compliance, which relieves the = legal burden as well as the negative impacts
on delivery and publ= ic perception.

For folks who just register a new d= omain name and spam anyways... yeah, well, there are other consequences dow= n the line and other anti-phishing restrictions that
kick in at l= east on our inbound systems..

Brandon=C2=A0
<= /div>
--000000000000f9b9c705ad6997db-- From nobody Fri Aug 21 14:18:33 2020 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 C962E3A1297 for ; Fri, 21 Aug 2020 14:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 v-YZ_QHDJ0df for ; Fri, 21 Aug 2020 14:18:26 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 A33523A1294 for ; Fri, 21 Aug 2020 14:18:26 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id j9so2551647ilc.11 for ; Fri, 21 Aug 2020 14:18:26 -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=40cTUI5qy/btFmoDTwoY3bH8fyFTJs+WGE3sUVMAgdM=; b=u9T3uCkdLdoaLFZRw1m2UrBgyXfSA3hGOI6VXMqdjuwXQ1H/rciio7eZQ+z3dHPpy6 EOqYe8WffDwamP9Ef+e8TOe7zWM73CwcbBKwhES2HqCdrbZStBNekO51dGh3X+tqxUaJ 1zC3zRBvks6QY/d68rJ4NXfjvg5YqoFDKLVpar0cN28PGoorGiLoecY8z1ubN4+DFgus B1Y94JXt+LybRHbrOHBjgppb/endJmNfAvSj3QcPbi0wfkiJyViYKazu3P7m/L7SYL6v Jor5thtrIhwgddvUPv0LTf7lOZ6OZTfxrMw0w9JDUkPKwPrugjwpFYLdBC5QVZS5iiX1 2Zig== 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=40cTUI5qy/btFmoDTwoY3bH8fyFTJs+WGE3sUVMAgdM=; b=lCjxk8RL8K3CqE6Yx6XkcjX/HlTpRpOozURxs2oJ3cNh8Sn+nkrlENcHi5y4xPMJ82 RgqVv2ocZO0C9uietAnbPKejfKlN1yVIC5LoN5DY1/51edHJ6LKpDAl3UT802zrF6kpN Ua9VdESFY4I4FSnCRoom1LgqNcE9pk5n2eawVW/tHAMozU3gKX1K39nBjyP42AMcTb21 hyzXMdboVWeGI+S5/xQYxA7H7KkaWSDlAnruiuxfFfJBQwf687g7f7oA3UW+J5XS/ks2 Em4eB36yWnxDn3m/pInKoikmtok4CBE4CKwNbiQDJrsShgHZAKLAom5o4VAqLyIycETq swXw== X-Gm-Message-State: AOAM531Wq7v5e950qFQmT0zxNeEpGzCwcPQI8LBiRBo2XliLwa4gelFB fdSoaT4x0QUhIDorg2OF2faVAlM+/D0PuTJzzE6FKtkEV/3O X-Google-Smtp-Source: ABdhPJyEFE1VI+6XlTA3tGlTR+q28FlMOlOPBaaXiCWTnRVVDHPPqtNm9ygXDsYrUX/KVDRojHmMpoZ3pOvVQvwfvQ4= X-Received: by 2002:a92:1fd9:: with SMTP id f86mr4100673ilf.250.1598044705574; Fri, 21 Aug 2020 14:18:25 -0700 (PDT) MIME-Version: 1.0 References: <20200815225306.967CC1E9E41D@ary.local> In-Reply-To: From: Brandon Long Date: Fri, 21 Aug 2020 14:18:09 -0700 Message-ID: To: Jim Fenton Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000038e5205ad69c7f0" Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 21:18:29 -0000 --000000000000038e5205ad69c7f0 Content-Type: text/plain; charset="UTF-8" I think the DMARC RFC does a good job explaining why DMARC is better than ADSP, even if the same mailing list issue is still there: https://tools.ietf.org/html/rfc7489#appendix-A.5 And if you read the archives on the move to historic for adsp, there were others then who objected to the reason put in the historic move as likely as affecting the replacement . Given the success of the replacement, it stands to reason that the reasoning given in the move to historic was not the full reason for the failure... and perhaps lends credence to the thought that certain folks are more concerned about the effects on mailing lists than the ecosystem as a whole is. Brandon On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton wrote: > On 8/15/20 3:53 PM, John Levine wrote: > > Not really. DKIM was deliberately designed not to be tied to any > visible part of the message. ADSP was a poorly designed hack that was > never implemented other than small experiments, and that I don't think > many people understood. I got a lot of grief for making the most > strict policy "discardable" even though that's obviously what it was. > > > And even with the kinder-and-gentler term "discardable" for its most harsh > policy option, ADSP was moved from Standards Track to Historic. From > https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ : > > There is, however, evidence of harm caused by incorrect configuration and by > inappropriate use. There have, for example, been real cases where a high-value > domain published an ADSP record of "discardable", but allowed users on their > domain to subscribe to mailing lists. When posts from those users were sent to > other domains that checked ADSP, those subscriber domains rejected the > messages, resulting in forced unsubscribes from mailman (due to bounces) for > the unsuspecting subscribers. > > Assurances that are provided by ADSP are generally obtained out of band in the > real Internet, and not through ADSP. Current deployment of ADSP is not > recommended. > > Is that not exactly the same situation with DMARC, except that the policy > in question now is "reject" rather than "discardable"? Yes, it's just a > keyword, but it reflects the semantics of the expected action as well. > > -Jim > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000038e5205ad69c7f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the DMARC RFC does a good job explaining why DMARC= is better than ADSP, even if the same mailing list issue is still there:https://too= ls.ietf.org/html/rfc7489#appendix-A.5

And = if you read the archives on the move to historic for adsp, there were other= s then who objected to the reason put in the historic move as
lik= ely as affecting=C2=A0the replacement .=C2=A0 Given the success of the repl= acement, it stands to reason that the reasoning given in the move
to historic was not the full reason for the failure... and perhaps lends c= redence to the thought that certain folks are more concerned about the
effects on mailing lists than the ecosystem as a whole is.
=
Brandon

On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton <fenton@bluepopcorn.net> wrote:
=20 =20 =20
On 8/15/20 3:53 PM, John Levine wrote:
Not really. DKIM was deliberately designed not to be tied to any
visible part of the message. ADSP was a poorly designed hack that was
never implemented other than small experiments, and that I don't think
many people understood. I got a lot of grief for making the most
strict policy "discardable" even though that's obviously what=
 it was.

And even with the kinder-and-gentler term "discardable" fo= r its most harsh policy option, ADSP was moved from Standards Track to Historic. From https://datatracker.ietf.org/doc/status-c= hange-adsp-rfc5617-to-historic/ :

There is, however, evidence of harm caused by incorrect config=
uration and by
inappropriate use.  There have, for example, been real cases where a high-v=
alue
domain published an ADSP record of "discardable", but allowed use=
rs on their
domain to subscribe to mailing lists.  When posts from those users were sen=
t to
other domains that checked ADSP, those subscriber domains rejected the
messages, resulting in forced unsubscribes from mailman (due to bounces) fo=
r
the unsuspecting subscribers.

Assurances that are provided by ADSP are generally obtained out of band in =
the
real Internet, and not through ADSP.  Current deployment of ADSP is not
recommended.
Is that not exactly the same situation with DMARC, except that the policy in question now is "reject" rather than "discar= dable"? Yes, it's just a keyword, but it reflects the semantics of the expecte= d action as well.

-Jim

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000038e5205ad69c7f0-- From nobody Fri Aug 21 15:07:16 2020 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 DC4013A12DB for ; Fri, 21 Aug 2020 15:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, 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=wisc.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 vFg70BadmGyY for ; Fri, 21 Aug 2020 15:07:13 -0700 (PDT) Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 E83293A12D9 for ; Fri, 21 Aug 2020 15:07:12 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QFF006K0PFYKR30@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 21 Aug 2020 17:07:11 -0500 (CDT) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.8.21.220017, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.8.18.5750001, SenderIP=[104.47.59.176] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HR4W7uEREtFdMI6snWkBD2DtMZ5FLR1z9T5duwU4RASifvzrAkmeHPZ0+tebM6Th5uCGED3FsljMZmj2DIQOO13hBHcvRWOwfO+73tCt4atMrEECDEgwcIBLYNFE0Hg+YnoqTFwM6RY3GPo+lK6oO41nrlrKLTZYWr/q3pL4kcRBqkefM7G1TDwyk20MHYH9qONYXUsCpXCogiGgrBWi0adazRjUpfzqxxoLx9Bnm2/3YfkzAQ/Vj54+ukaeS0qZYAMREJIWiTA1oClsvj47sOALQNrnAdPT2H425hN6aNKrwkWR+elTfPQLas4lMUE5qkS7z2zEEo+qGmIZUtVjBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3mriE5J57LAS7nKljS+slWTh9bnnqyi/9ty2eMMrMz0=; b=YssoBxZHFZ6eQvmnDFuqfzp5d81dAJi4UP7idRFymZ/46QMrnyJkqkHW1z+b/Q6FIttGo0jlapUm6LX+14NLh5BcBRxwSVAOAPRuH/ur/j6CsIRgZi84n9rlDVRjlSPuFZXX0GRHp3DynQVb5mH5OJqE7cTb1/yc3jXHPVt7vv5mx6hZkX3ySBTCxjncZGSup64HeA3RGpLYGudPsSdXNKPILCT+Nb0lGf3uFuDeRdXywboDBQfRNb5XBk5MciCZ63kqXfpsnsbsdx39fex96/39HHSCX0FQIYTGEbl1QnIcKTBlTXn1099AM9znMgFe2zv2m2Ae6Fw0c30dqrg77g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3mriE5J57LAS7nKljS+slWTh9bnnqyi/9ty2eMMrMz0=; b=CJoAjgshFWVreQ8s2wDlCC0Qb9eJN2g5cjfGbNxOCsn0NCEudEAwGRdLancd9hIyoHM882BN98uC1cF7+lDUyul2yPC6lI1ateuH6um3p5IcviTYhOyGZCsVXffHL0PVFjS9wU8M3oUD8sUvGrIA05glbZ1oa1Mr81V5dh1CnyY= Received: from DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) by DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Fri, 21 Aug 2020 22:07:09 +0000 Received: from DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50]) by DM5PR0601MB3671.namprd06.prod.outlook.com ([fe80::8def:be24:c82c:8d50%6]) with mapi id 15.20.3283.027; Fri, 21 Aug 2020 22:07:09 +0000 To: dmarc@ietf.org References: <20200807191216.43E971E4014E@ary.qy> <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> <7ce20245-5942-14f3-3220-1faaa2c8ccbb@wisc.edu> <4d13611d-e6e7-a6f8-d48a-2a11a74f5d51@bluepopcorn.net> From: Jesse Thompson Message-id: Date: Fri, 21 Aug 2020 17:07:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.1.1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-ClientProxiedBy: CH2PR16CA0001.namprd16.prod.outlook.com (2603:10b6:610:50::11) To DM5PR0601MB3671.namprd06.prod.outlook.com (2603:10b6:4:7b::16) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR16CA0001.namprd16.prod.outlook.com (2603:10b6:610:50::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24 via Frontend Transport; Fri, 21 Aug 2020 22:07:08 +0000 X-Originating-IP: [47.12.96.133] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d758a85c-2466-4586-184a-08d8461e8c29 X-MS-TrafficTypeDiagnostic: DM5PR0601MB3671: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PoICKH/RPPCEyO7/lzSkFskIwpJxYKGzxr2smNQWysPM936toUk8//jm/0tYhTNfcpA7Hxfn0LNuh3s873zME2cCeifvAl96rtEdqSVBX97ueh0m0hl0LLwB14kgiDiklVpmf8WzcyY00AVgcUSOYSP5wSWUxElPcdQRS3pdJX6gXHbP2T/B0+/LPHhAo4qUsnr39fSLCD/MqVBE0MPKMefIkOfRDCbX+2hbcUbw9aLXdLDSFdQ1rvKfQrJPRSrP4yYBi+L8uXpRXIeX+ZUfYDcyyV1KHkOY+jmhnXiJzs0I1efGVOGFKffVWfe84tZiKAFPHakg01EAeAfWXkfsdCSGhK//rVDinGM7xjem8lORIw77J7bpXfhzYIeWJdL+bQu0KGs8mpt8Z7VDbxZA1rfaXFqF3PxsofERS1sWSIA53Wh6QYIX2LFq1LUkkFeO X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0601MB3671.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(346002)(396003)(376002)(39860400002)(2906002)(36756003)(44832011)(6486002)(8936002)(66476007)(31696002)(66556008)(75432002)(26005)(66946007)(2616005)(53546011)(956004)(478600001)(83380400001)(16576012)(16526019)(31686004)(186003)(6916009)(86362001)(8676002)(5660300002)(316002)(786003)(223123001)(43740500002)(130980200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Ijky3m/UD9s2W58/ERfFL7NCyrCshtQ/O4HtR6V1urNlULDGTkjKtGLh4yvWiLP0hrOZkei/aMDUfLl3c757vM1fq8vTb82wvtP3nQxnaUY+HlB6oOX0G5GVylASBy95Fs5/hv84mh4bwjUbZaLq9QkbFr5lUxHuaKizLF0XxNyeVGoXiv+eWC+IuW03C/yROJL0G0ChM7V0MqAwV/I/+BL91Wy7lJqNV2fEoO7KhpuZR9xIKr0OuJiLLh0bls2q+JC/XQLY7rLrQlE1VYTszb9YySIzwn4OHKTiWrjuFgMYdcHN0bQ8GaWyJZEUgU4wnBeG/1aaqoIBFKJasmO9iDnVwrjpecwWTbjdQvs/TSx+MH6j7+qtC/YPhUI9nVCtlMZ/JQ5t3ru6b62c1DH17hUsmiKHw9RmQ3avglT2748pLpeRhERkGp45VpfikTVtq2kYL68z1Sg730e93BNnxghBOv6kCeAQ1P/8xlwOnN+t2tKG316cQjaTOnoA1cR0Hmr2G0tAqB3XKxKh4qy+HbegYDHF1BBUDf4xt9bGFatYwJBVJpZXrXiKuLYSxm+9VsJl8u+ix8BGj+9nV18Mfq4Ya5QwxetTf9L01RI4Dtsqy44NhPfL9/LEO8Q1LyrRm/uPvjPXGp/6X8OeqTINww== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: d758a85c-2466-4586-184a-08d8461e8c29 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0601MB3671.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2020 22:07:08.9220 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: X+0GO0u6etnqsE9N7lCqT3kqp37ztP1bedoTiUOMmqg+iFXI7ZTA2K9Mwg6DW3NFNBgInMUHHZozvssC1CZzig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0601MB3671 Archived-At: Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 22:07:15 -0000 On 8/21/20 4:05 PM, Brandon Long wrote: > > > On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton > wrote: > > On 8/17/20 3:52 PM, Jesse Thompson wrote: > > With a complex organization the only way to get people to change is to publish a restrictive DMARC policy and then see who comes out of the woodwork sheepishly admitting that they've been ignoring us for years.  > > > > Normal people sending email (especially those who are working with an ESP, most of which happily send email without any DMARC alignment) do not comprehend the notion that they should be using a subdomain for their transactional messages; even when we directly communicate this fact to them repeatedly.  They just don't understand the nuances of email. > > > I thought the DMARC reporting mechanism was there to allow such > organizations to detect those behaviors and get them corrected without > actually causing the damage of a restrictive policy. > > > One thing we've found useful in this case is controlling the organization from spamming. > > Which is to say that the org has a policy on approvals and what is allowed to be sent marketing wise, in some parts of the world to comply with laws on such topics, > or to be sure the entire org follows the principles and someone new doesn't just poison the pool for everyone else. > > There are always people who route around restrictions or sometimes don't even bother to look for anything, they'll just hire a third party ESP and spam away. > > DMARC helps in this case to reduce the success of that and force them back to internal compliance, which relieves the legal burden as well as the negative impacts > on delivery and public perception. > > For folks who just register a new domain name and spam anyways... yeah, well, there are other consequences down the line and other anti-phishing restrictions that > kick in at least on our inbound systems.. Right. Moving past p=none puts somewhat of a backstop on the internal compliance problem, which would otherwise continue indefinitely. I've put them into a state where they have to get a subdomain and learn about DMARC. DMARC [aggregate] reports don't tell us *who* in our organization is perpetuating the problem, especially if their volume is low or not visible to the few DMARC reporters. At some point you need to acknowledge that you will never have complete visibility. Jesse From nobody Sat Aug 22 02:06:47 2020 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 0608E3A1095 for ; Sat, 22 Aug 2020 02:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.953 X-Spam-Level: * X-Spam-Status: No, score=1.953 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, GB_SUMOF=5, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 UcOqdDKo4lFF for ; Sat, 22 Aug 2020 02:06:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 EE8D03A1093 for ; Sat, 22 Aug 2020 02:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598087200; bh=i0QWAJgX+KVcoh8Ad4WUvddJkbE3xIUgW9IGZedlHMc=; l=5838; h=To:References:From:Date:In-Reply-To; b=CU19rxNqthfsz5rKqW82srPv95PZx3dcTuMHVGx43Ny7dA9BhSjgsQShni8o4TxyH qgqjR7X2OrzfH8332b0Fx7tATDjI/3zUIk1acm4pcddlySfTjb4RIixiGy1DW2iaHP s5B+PzkehhX7JuWDLjhtEbxNOH9Wa3udHpymXo25UL3ERuMoxeeI880+fkixE Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.103] ([5.171.36.128]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005F40E020.0000737D; Sat, 22 Aug 2020 11:06:40 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sat, 22 Aug 2020 11:06:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 09:06:46 -0000 On Fri 21/Aug/2020 21:25:50 +0200 Todd Herr wrote: > https://trac.ietf.org/trac/dmarc/ticket/66 It seems to me it is a bit too early to consider this issue. > When this issue was first raised on the list back in June, it seemed that > consensus might've landed on the idea that this should be written up in a > separate BCP, rather than be part of the DMARC bis effort itself. I'm > concerned, however, that there might not be enough there there to warrant a > separate BCP, and to that end I've taken a stab at modifying the base DMARC > document, specifically Section 8, Implementation, as follows: I'm not yet clear about how many documents will the WG end up with. > ------------------------------------------------------------------------------------------------------------------------- > 8 Implementations > > The characteristics of a DMARC implementation will vary for the different > roles in the messaging infrastructure. > 8.1 Domain Owner Implementations > > Section 6.5 describes > many of the provisions for implementing the DMARC mechanism as a Domain > Owner. This section will clarify those needed for minimal and full > implementations. I'd start by introducing the distinction between domain owner and mail receiver. A statement should then say what is the combined minimal/ full implementation. > 8.1.1 Minimal Domain Owner Implementation > > The only action required for minimal implementation of the DMARC mechanism > by a Domain Owner is the creation of the DMARC policy record in DNS. Ok. > 8.1.2 Full Domain Owner Implementation > > Full implementation of the DMARC mechanism by a Domain Owner requires all > of the following characteristics: > > - > > Creation of the DMARC policy record in DNS which meets these criteria: > - > > The policy record MUST express a Requested Mail Receiver policy of > “quarantine” or “reject” for the Organizational Domain and all sub-domains > - > > The Requested Mail Receiver policy MUST apply to a percentage of mail > not less than 100 > - Nope. A domain can say it has a *strict policy* when the above criteria are met. Standing the principle that domains which host human users mailboxes must not publish a strict policy, mandating that these domains don't fully implement DMARC makes little sense. Note that I'm opposed to said principle, which is a limitation of DMARC. However, the limitation is there and we must first remove it. Afterwards, perhaps, we can mandate strict policies. > Establishment of an address to receive aggregate reports at least daily; > other than in exceptional circumstances such as resource exhaustion, the > address must support receiving reports up to at least ten megabytes in size. > - > > Deployment of authentication technologies to ensure Identifier Alignment Isn't it clearer to say "both SPF and DKIM"? > 8.2 Mail Receiver Implementations > > This section will describe minimal and full implementations of the DMARC > mechanism for Mail Receivers. > 8.2.1 Minimal Mail Receiver Implementation > > Minimal implementation of the DMARC mechanism by a Mail Receiver means > fully implementing the provisions of Section 6.6 > Maybe a minimal implementation could skip storing the results of DMARC processing. > 8.2.2 Full Mail Receiver Implementation > > Full implementation of the DMARC mechanism by a Mail Receiver is defined by > the following characteristics: > > - > > Fully implementing the provisions of Section 6.6 > Ok. > - > > Validation of any ARC header sets found in the message Nope. DMARC has nothing to do with ARC. > - > > Enforcement of discovered policies in a manner that is consistent > with Section > 6.7 Hm... that adds nothing to the requirements. Section 6.7 allows receivers to do what they see fit. > - > > Send aggregate reports at least daily using “mailto” URIs; such > aggregate reports MUST be no larger than ten megabytes in size. I'd just mandate reporting. Size is a different issue. Limiting the size makes more sense for each mailto: address, as it should reflect message size limits that the corresponding MTA enforces. See also ticket #53. Some domains react to the size limit by sending multiple records for the same period. The sum of sizes exceeds the size of a single report, given the way compression works. Report size is obviously inversely proportional to frequency. How about requiring the ability to send reports hourly for full implementations and at least daily for medium ones? > 8.3 Report Receiver Implementations > > The following implementations are defined for operators that receive > reports about messages related to another operator. Implementations for > Domain Owners that receive reports about their own messages are described > in Section 8.1. > 8.3.1 Full Report Receiver Implementation > > Full implementation of the DMARC mechanism by a Report Receiver means > establishment of an address to receive aggregate reports at least daily; > other than in exceptional circumstances such as resource exhaustion, the > address must support receiving reports up to at least ten megabytes in size.. Ok. > 8.4 Intermediary Implementations > I don't comment on this section, as we haven't established much about intermediaries, yet. Unless some intermediator-specific behavior is going to be defined, an intermediary implementation should be just the same as any other one. BTW, I'm not receiving reports from ietf.org. Best Ale -- From nobody Sun Aug 23 03:00:10 2020 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 4E3DF3A0841 for ; Sun, 23 Aug 2020 03:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=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 sdgxgRyzSgBf for ; Sun, 23 Aug 2020 03:00:06 -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 712F63A083F for ; Sun, 23 Aug 2020 03:00:06 -0700 (PDT) Received: (qmail 73442 invoked by uid 100); 23 Aug 2020 10:00:05 -0000 Date: 23 Aug 2020 09:59:41 -0000 Message-ID: <20200823095941.73427.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 23 06:00:04 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 10:00:09 -0000 17 | 180845 | Dotzero 16 | 101029 | Alessandro Vesely 10 | 54554 | John R Levine 10 | 52421 | Dave Crocker 7 | 82320 | Murray S. Kucherawy 7 | 79120 | Jesse Thompson 6 | 91131 | Douglas E. Foster 5 | 117191 | Laura Atkins 4 | 46484 | Brandon Long 2 | 54558 | Todd Herr 2 | 20610 | Joseph Brennan 2 | 17940 | Jim Fenton 2 | 13790 | Kurt Andersen (b) 1 | 23327 | David I 1 | 20782 | Autumn Tyr-Salvia 1 | 14664 | Tim Draegen 1 | 11242 | Seth Blank 1 | 11208 | Neil Anuskiewicz 1 | 9584 | Tim Wicinski 1 | 8861 | Rolf E. Sonneveld 1 | 8031 | Hector Santos 1 | 7438 | Dave Crocker 1 | 5911 | Dave Crocker 1 | 5889 | Luis E. Muñoz From nobody Sun Aug 23 23:00:27 2020 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 112F23A0A4F for ; Sun, 23 Aug 2020 23:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, 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=isdg.net header.b=ETFH3c2P; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=tjsKhCi8 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 er2LEal_wHGb for ; Sun, 23 Aug 2020 23:00:23 -0700 (PDT) Received: from mail.winserver.com (winserver.com [76.245.57.69]) (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 C2AEB3A0442 for ; Sun, 23 Aug 2020 23:00:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=681; t=1598248813; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=bLlpDDRVq17baI3DuQggThoGIzE=; b=ETFH3c2PV3H9t4eSgopNLM4dm3WlUcO4Ga4ebRdfEgzhwCwfXaHF4M9DYsgv6j kYMuCsYjjuDUrftonnHtC4LOCoBSl9wV6XznKCU/TYYL1cyNHgidMPAQCggKWxs0 4mPJvl+KNW6YZKtaZBqxsTp7YJdAVWgEOAqlpL+Wp18hU= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 24 Aug 2020 02:00:13 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 278938071.5.3892; Mon, 24 Aug 2020 02:00:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=681; t=1598248656; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3+4Coch pwQkDt9nKj34gRkvfwGvwLSFL707VG9lMX0k=; b=tjsKhCi87pyjygj5A1xGh2e Nw7dDTNSsLp3qulQ18W6AJl66Aw4ZzQavECleBbeZuNt4UT/F9ke91cVlfXWsNeZ 4COI5ByQUV2CVT5+yosquCTIGEJEjtHipfqqUNjCc0r2p9NFBFOLmMFAC8fAxK9U nSjn3GyE7Pc9u3K8ShVc= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Mon, 24 Aug 2020 01:57:36 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 145895187.4.212; Mon, 24 Aug 2020 01:57:35 -0400 Message-ID: <5F43576A.4050905@isdg.net> Date: Mon, 24 Aug 2020 02:00:10 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20200815225306.967CC1E9E41D@ary.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 06:00:26 -0000 On 8/21/2020 3:09 PM, Jim Fenton wrote: > On 8/15/20 3:53 PM, John Levine wrote: >> Assurances that are provided by ADSP are generally obtained out of band in the >> real Internet, and not through ADSP. Current deployment of ADSP is not >> recommended. > Is that not exactly the same situation with DMARC, except that the > policy in question now is "reject" rather than "discardable"? Yes, > it's just a keyword, but it reflects the semantics of the expected > action as well. > > -Jim No one was expected to follow a reject, so it was said, until it did happen. SPF pushed -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Mon Aug 24 08:13:35 2020 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 074033A0F13 for ; Mon, 24 Aug 2020 08:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 NMhxi8k8wEKO for ; Mon, 24 Aug 2020 08:13:32 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 AE2073A0F07 for ; Mon, 24 Aug 2020 08:13:32 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id z12so2709097uam.12 for ; Mon, 24 Aug 2020 08:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ojv85Uwdb2qnkT2aRyEhAnJU5vuXnOWEk9pEqWiYt0=; b=lBfJE1HWvIkgaaTdmtQ7b6sCT3KDQtxaFJ1EJnzCwKzP7UaTR6spX0gY7ySd9wCG8u 4biQme4YSE8ONx3M/LhI7g936Zc/GiJiPfz3qUVUP92mB5MgwCv5Re0pqRyqkitLxARy ZOPnaEBEevxsDvmKixCd42titDZH1yUm79wqOTeEUX7b2lZNWia/Y3ES3qjOV3q8HK1U SasLqDxgVa3vEce+21GsuA4yft80oJRfdGQG8hxPKNgsU3nGzUZUy/KEu6BL+uzu8agw JMEIOcRXOeUlf08XGKWY47OgjDbDDYjiK4VigCKiZllvuA1NDfsRXKyNLwPVCFzoO0jH r9Cw== 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=3ojv85Uwdb2qnkT2aRyEhAnJU5vuXnOWEk9pEqWiYt0=; b=acLtNlV/AA/+lZozn4dKwp9ELi7mOV5RmxWcD6nnmP/0pXYoq0oV8NScIf2o8dA1uG 7Lnz5LD7nAZzADFxxHlBnQkwEw0zgNmYt51bH/Uk/mW3GpDmHKAetHqn1TgCyI9/+pGE TPmZmdNyzF5ML485erIhRC+JDoJpj+7XjiTUWLSYHBM0WLybFAQaAGVgmiefb/XuqWU/ GTWrF+lq9J3WK1SOTkDMxIQzkDjFGXwlr1yClok27oR1i+fzjQGz8z8wlage6rQO9cGM 3L+nCG5lcHbw1hviIBsv72rKec0LVMP+nwSSfctKzTcyK2rYR6Sj7Eba4Xcnc02NLhZz WJPw== X-Gm-Message-State: AOAM532ZphIhfN+hxFzKfqcZBPmMHsis50rhsOS3nUI9VROYQQTWx2PZ 8GMX3cYZlydabvcKLssIMFPnUL6OhiQhBvxQxis= X-Google-Smtp-Source: ABdhPJzdSHWJWn8WKVJ2GzYcnEVB/wHwyscNx8MRu6TVkqMHq0Th+K2GtoGeJSsV2Roy1qKvpaLrEwFpUBXvzislGbM= X-Received: by 2002:a9f:26a5:: with SMTP id 34mr2924123uay.67.1598282011582; Mon, 24 Aug 2020 08:13:31 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <1988db12-7a72-6176-01aa-45848ad5683c@wisc.edu> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 24 Aug 2020 08:13:20 -0700 Message-ID: To: Dotzero Cc: Jesse Thompson , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008d29c805ada1075b" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 15:13:34 -0000 --0000000000008d29c805ada1075b Content-Type: text/plain; charset="UTF-8" On Thu, Aug 20, 2020 at 4:56 PM Dotzero wrote: > This is why I proposed a tag that would have a value consisting of the > authorized intermediary domain. It would only be valid for that message. > Because the tag is signed separately from the rest of the message, it > should survive even if the intermediary modifies other parts of the > message. If the intermediary DKIM signs the modified message with their own > signature, that provides some assurance to the receiver. You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00? I'm pretty sure that got implemented too, but I can't recall now if it ever shipped. -MSK --0000000000008d29c805ada1075b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 20, 2020 at 4:56 PM Dotzero &= lt;dotzero@gmail.com> wrote:
This is why I proposed a tag that would have a value consisting = of the authorized intermediary domain. It would only be valid for that mess= age. Because the tag is signed separately from the rest of the message, it = should survive even if the intermediary modifies other parts of the message= . If the intermediary DKIM signs the modified message with their own signat= ure, that provides some assurance to the receiver.

I'm pretty sure that got implemented too, = but I can't recall now if it ever shipped.

-MSK

--0000000000008d29c805ada1075b-- From nobody Mon Aug 24 08:20:55 2020 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 A206B3A0F0F for ; Mon, 24 Aug 2020 08:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, 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 1HdDTSozdx5J for ; Mon, 24 Aug 2020 08:20:52 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 347A43A0F2C for ; Mon, 24 Aug 2020 08:20:51 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id j188so4641984vsd.2 for ; Mon, 24 Aug 2020 08:20:51 -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=ig1l8GJjJ8NRx+IpfvzuOYa64joPGq56z3ebCLYcf/A=; b=IIMiyejUFrex7rkgFls48Rv5cFLBOIrFrZa7THrJnMohZbnT5pkEYL9Fic035hB25z /cS24WWqYQn5t16j1sT/Q29dwxZ+9OWca/5gIesLdJqBEWwOkSeTceDn2PVe+B6wNZNM VUhk9QIEnwN0kMhlA7djCNvQ50nR/ZCnwl6Fa8MzeK5Q4S4p/ZWBWLia8ogsx+hDAoBv 8YQGfHoPrQKFdBMdVN4fi/gCpsL8uHzKbdcXHuMB64iBoMT1/w7EyB1fm+kAQozW0N6y wVlwLgGE8l+REYQWDowCByS6Lzo/i7gRJi/M4/XROWm7yt80CVU2eev9AD2rg9nw/EHS JY8Q== 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=ig1l8GJjJ8NRx+IpfvzuOYa64joPGq56z3ebCLYcf/A=; b=mK+9HS0GQFAWlyeFhJBLi3sJ92YBQomGkLQ2wvMcAGYj+X5sjuM6D9PfmEO6aheD11 zfm6xa7NBKlO9ER/P0jtqCCHrYbCs6fbVbtjHj7JF/C1+ZOUlsRO+h40jz65RTY9kvmu c649s5ApbKVmJa3vI6EnT5Y5DTmdfE6xJb6AR2HxVTC969eQwyv81++YIoxOjl/0HefV w82Ld1pjQ4CjKL3hx5O7joFpbiZ/wCt9NTybh1AwvDj/dzaUdPQ55PGI8ZLJ3N+WL+On 16sN1XzhJjoFntCY5lwKqGZ8JpqERaKQ+fq5chRKYjFGSBeY+kZ28BdYWW99y+jGkUZF 2dGA== X-Gm-Message-State: AOAM532AH1tUDloKHWm3F4I934qshcAHIMt2kJkZYY/ykXnBdhaY9KaF dvIqxIttlqj1FnOs3vXqU85ODbNrlMRy+3l2tFc= X-Google-Smtp-Source: ABdhPJz3fCZv6tE2M0fwVon4qqrwJZKKQHqzCudjqzf7mYKPiF63ITRA0EgYSmZbn59ZlXgXgubZdTE9bLFuCGcHnAY= X-Received: by 2002:a05:6102:1c9:: with SMTP id s9mr2660631vsq.13.1598282450046; Mon, 24 Aug 2020 08:20:50 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 24 Aug 2020 08:20:39 -0700 Message-ID: To: Brandon Long Cc: Tim Draegen , IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="000000000000af94d205ada12181" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 15:20:54 -0000 --000000000000af94d205ada12181 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 20, 2020 at 2:01 PM Brandon Long wrote: > I tend to agree with the negative stance on third party auth, but SPF > obviously has the include: statement which is third party auth at the most > basic level... > atps[1] is the obvious equivalent for DKIM. I don't know if atps failed > because it wasn't all that useful, or if it was tied in folks minds to > adps, or the failure of the follow-on reputation system stuff.. > > Neither atps or spf include are really designed for large scale usage > across thousands of "relays" etc, and I don't think they should be used for > that, but for a bunch of small to medium entities, it could be the thing > that makes higher p= possible. > ATPS was designed as a proof of concept to see if third party policy was conceptually useful at all. Scale could come later if the initial experiment had a positive result. The industry, however, apparently didn't even have appetite to try, so we may never know. -MSK --000000000000af94d205ada12181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 20, 2020 at 2:01 PM Brandon L= ong <blong@google.com> wrote:=
I tend to agree with the negative stance on th= ird party auth, but SPF obviously has the include: statement which is third= party auth at the most basic level...
atps[= 1] is the obvious equivalent for DKIM.=C2=A0 I don't know if atps faile= d because it wasn't all that useful, or if it was tied in folks minds t= o adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large s= cale usage across thousands of "relays" etc, and I don't thin= k they should be used for that, but for a bunch of small to medium entities= , it could be the thing that makes higher p=3D possible.
<= /blockquote>

ATPS was designed as a proof of concept to see if third party policy= was conceptually useful at all.=C2=A0 Scale could come later if the initia= l experiment had a positive result.=C2=A0 The industry, however, apparently= didn't even have appetite to try, so we may never know.

-MSK
--000000000000af94d205ada12181-- From nobody Mon Aug 24 10:24:08 2020 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 E6CD63A0B69 for ; Mon, 24 Aug 2020 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=OV2pIQAt; dkim=pass (2048-bit key) header.d=taugh.com header.b=qO1QE6hW 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 9GzW_qnD2ZcH for ; Mon, 24 Aug 2020 10:24:05 -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 5EB793A0B66 for ; Mon, 24 Aug 2020 10:24:05 -0700 (PDT) Received: (qmail 7784 invoked from network); 24 Aug 2020 17:24:04 -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=1e66.5f43f7b4.k2008; bh=DPyEOGss5RO9GjQIRoJZMmjz20uuFPYSRWdP5OkKlRI=; b=OV2pIQAtDgt2/XW0gREs7FdOjaRt028S12ONbIdp/dWvQMkMoH2bhf1xlDu6vFHl1BJCZ4PWYtACtXptF3SFVlcKfjZgW0D3zI+xQFltCQN1yXpG3c+R8/h2ITwxe2F0TpGe3s0CSvjB232O4TLGIs84nVuh8vkdQ3GMctBmAxjAaBhrMVamOPgkIWb+K9tclH/uhh+EGa2qN9GdMPp80q9MT65V5WLSZVmSBUgbYqviNqMjVuSMSTwo+AvIb1UelN4FV2knuxO6xHBfZzv706EarfklJZK9Zp0YBpY7EvZZRvvdQFaRXhckgjbPZL/zNUD4mCWanEB62mkJWT+/aw== 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=1e66.5f43f7b4.k2008; bh=DPyEOGss5RO9GjQIRoJZMmjz20uuFPYSRWdP5OkKlRI=; b=qO1QE6hWdHfWuTT3GzrXXp5PcTFMmeL30H3wgNw8TJFh5OPNCWahTxtc6DgCN4j7ousl7cyHsx4qVggTizpjnSaMNECAniosjai0X7IUh1yYjPcTR0G59bjgB11uCUlT2u4z9notmwGB04oX7y0zqyHFbu6ORd0LX4KZCRbfE2pZedcVxX12pc+zP2WKHFSSkUCf6C/VMh754BuaqhQqaAASltMxFF2vqu+ujoLxkjsYc1SwPRV1oqlEXYNW21DgQBLa/GHV48I9zfBLZNhMCyTLxrw9QtpyeW22kLhNpwuWy55VopxiIg648BMuuGtK/DUUPcamrpJsWgVPIQWVdg== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Aug 2020 17:24:04 -0000 Received: by ary.qy (Postfix, from userid 501) id A927C1F14BF5; Mon, 24 Aug 2020 13:24:03 -0400 (EDT) Date: 24 Aug 2020 13:24:03 -0400 Message-Id: <20200824172403.A927C1F14BF5@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 17:24:07 -0000 In article you write: >> message. If the intermediary DKIM signs the modified message with their own >> signature, that provides some assurance to the receiver. > >You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > >I'm pretty sure that got implemented too, but I can't recall now if it ever shipped. I don't think it ever did. It has the scaling problem of every system that sends to mailing lists having to decide what mail it's willing to have re-signed and what domain the second signature will use. Usually it's the domain name of the list except when it's not. R's, John From nobody Mon Aug 24 11:20:26 2020 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 8494B3A0998 for ; Mon, 24 Aug 2020 11:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.802 X-Spam-Level: **** X-Spam-Status: No, score=4.802 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npe7vNgd7z1I for ; Mon, 24 Aug 2020 11:20:22 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 70CC93A09A0 for ; Mon, 24 Aug 2020 11:20:22 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id i20so8348236qkk.8 for ; Mon, 24 Aug 2020 11:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=khgpNTgWXzk3W1QCfMuSRCfzB18DzwBdfnK6bcKjcs4=; b=d/93m9+GJ3Km2/KGeRdajGMQd5F+DCoaUn/ydLjTAjRJ7AYbgRL+wb12bKeklKv4Zi F16eS4CpvSJZhzd/+OnIIpPpP+mZjXPQI7BjpiyEQqgfIkf5zxGDLcCc08hhblHYiCk6 tjZ3dF11QySwtNLNnGWMip7IhWW8+UC5p0Y3wB3gEMXwZrjPaKI0iLKw/me62jrrDRY2 60MAq63d4qPu82b7JTjnYPn/RV2KV3TIzUgq9JGJr9n/H33r4Q5SSFTNFrbPwEqeLoHx z9kZzbHZKFYHKJPc+v+ncLmKahUajpceZiF5ywoIuRD5m20HoeGESdoiQbsTHcpHs0Mh sozw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=khgpNTgWXzk3W1QCfMuSRCfzB18DzwBdfnK6bcKjcs4=; b=r4ykekYtQLtjjSJsHYWl4nDKhNo+Q/3udOSJYouQ/1K/bKEsquyT0SbyeAoO1ij4vn kHCZJ9R+s2FFZ9rIJCtd/o7yIMKaQODx7oNzA//uWe4lULfuvu691WQgy4hVRHgNOZ7p 66gRJADTDaXkv8JKphnTfqRnc18tgIBoOXXuj7cfHCAc8f5kBZs13LDd7co90N+Zt8Ll LFlFJPAR2leb8bSFz6+xgQWCgTnW0H7pzi/g+xsp3aBHkQzXoYmiF/EzFNz/Kr2YQ8G+ Gyf/TlbEeqkr7+BEaePDknXr6A+7rfr5O4RKosHoosrVtHy27+LdXeFs8wQdFuCAV8ZV 7RXw== X-Gm-Message-State: AOAM533D0lvSGN3tzk6v4mc9oBkZU14O1MCD9cDMlrikKG6lHjviNnFU dpwx7tuSQ3QCPWGLXUj0f28LhUafj8n4vQbKYmK+8bLTIH4tWg== X-Google-Smtp-Source: ABdhPJxa0ADSWUV1kqiHEb54R86/1EXLoNJlUf4Z1mg7hBqZTSS1BhiAtOSnmdmtYF+GKLqKNDOteyxYNGl0K6fLktg= X-Received: by 2002:a05:620a:25b:: with SMTP id q27mr5702593qkn.208.1598293217283; Mon, 24 Aug 2020 11:20:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Mon, 24 Aug 2020 14:20:06 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000076a37c05ada3a3b9" Archived-At: Subject: Re: [dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 18:20:25 -0000 --00000000000076a37c05ada3a3b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the feedback, Ale; comments inline. On Sat, Aug 22, 2020 at 5:06 AM Alessandro Vesely wrote: > On Fri 21/Aug/2020 21:25:50 +0200 Todd Herr wrote: > [snip] > > > > -------------------------------------------------------------------------= ------------------------------------------------ > > 8 Implementations > > > > The characteristics of a DMARC implementation will vary for the differe= nt > > roles in the messaging infrastructure. > > 8.1 Domain Owner Implementations > > > > Section 6.5 describes > > many of the provisions for implementing the DMARC mechanism as a Domain > > Owner. This section will clarify those needed for minimal and full > > implementations. > > > I'd start by introducing the distinction between domain owner and mail > receiver. > > The distinctions already exist in RFC 7489, the original DMARC spec: https://tools.ietf.org/html/rfc7489#section-3 > A statement should then say what is the combined minimal/ full > implementation. > > > > 8.1.2 Full Domain Owner Implementation > > > > Full implementation of the DMARC mechanism by a Domain Owner requires a= ll > > of the following characteristics: > > > > - > > > > Creation of the DMARC policy record in DNS which meets these > criteria: > > - > > > > The policy record MUST express a Requested Mail Receiver policy = of > > =E2=80=9Cquarantine=E2=80=9D or =E2=80=9Creject=E2=80=9D for the= Organizational Domain and all > sub-domains > > - > > > > The Requested Mail Receiver policy MUST apply to a percentage of > mail > > not less than 100 > > - > > > Nope. A domain can say it has a *strict policy* when the above criteria > are met. Standing the principle that domains which host human users > mailboxes must not publish a strict policy, mandating that these domains > don't fully implement DMARC makes little sense. > > Note that I'm opposed to said principle, which is a limitation of DMARC. > However, the limitation is there and we must first remove it. Afterwards= , > perhaps, we can mandate strict policies. > > I'm not clear on what you mean by "strict policy"; it's not a term I used here. Also worth noting is that I'm not trying to mandate anything, only attempting to define two levels of implementation for each role - minimal and full. > > > Establishment of an address to receive aggregate reports at least > daily; > > other than in exceptional circumstances such as resource exhaustion= , > the > > address must support receiving reports up to at least ten megabytes > in size. > > - > > > > Deployment of authentication technologies to ensure Identifier > Alignment > > > Isn't it clearer to say "both SPF and DKIM"? > > Perhaps, but I took pains here to re-use the same verbiage that's in section 6.5 of RFC 7489: https://tools.ietf.org/html/rfc7489#section-6.5 > > > 8.2 Mail Receiver Implementations > > > > This section will describe minimal and full implementations of the DMAR= C > > mechanism for Mail Receivers. > > > > 8.2.1 Minimal Mail Receiver Implementation > > > > Minimal implementation of the DMARC mechanism by a Mail Receiver means > > fully implementing the provisions of Section 6.6 > > > > > Maybe a minimal implementation could skip storing the results of DMARC > processing. > > Perhaps, but again I was re-using text from the original RFC - https://tools.ietf.org/html/rfc7489#section-8 > > - > > > > Validation of any ARC header sets found in the message > > > Nope. DMARC has nothing to do with ARC. > > Your statement is true, but I would submit that ARC has everything to do with DMARC (and SPF, and DKIM) and attempting to mitigate the failures in authentication that can be caused by mail transiting intermediaries. > > > - > > > > Enforcement of discovered policies in a manner that is consistent > > with Section > > 6.7 > > > Hm... that adds nothing to the requirements. Section 6.7 allows > receivers to do what they see fit. > > Again, I'm not proposing to mandate any behavior here, only to define different levels of implementation; further, I don't sense much in the way of consensus from the group on trying to mandate behavior. > > > - > > > > Send aggregate reports at least daily using =E2=80=9Cmailto=E2=80= =9D URIs; such > > aggregate reports MUST be no larger than ten megabytes in size. > > > I'd just mandate reporting. Size is a different issue. > > The ten megabytes limit is original text from section 8 - https://tools.ietf.org/html/rfc7489#section-8 - It seems antiquated to use such a small size today, but I was trying not to stray too far afield of the original text. Limiting the size makes more sense for each mailto: address, as it should > reflect message size limits that the corresponding MTA enforces. See als= o > ticket #53. > > Some domains react to the size limit by sending multiple records for the > same period. The sum of sizes exceeds the size of a single report, given > the way compression works. > > Report size is obviously inversely proportional to frequency. How about > requiring the ability to send reports hourly for full implementations and > at least daily for medium ones? > > Once every 24 hours was in the original text; I wasn't present at the creation of the original RFC, but it seems to be a cadence that most reporters use. --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 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. --00000000000076a37c05ada3a3b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the feedback, Ale; comments inline.

On Sat, Aug 22, 2020 at 5:06 AM Alessandr= o Vesely <vesely@tan= a.it> wrote:
On Fri 21/Aug/2020 21:25:50 +0200 Todd Her= r wrote:
[snip]

> ----------------------------------------------------------------------= ---------------------------------------------------
> 8 Implementations
>
> The characteristics of a DMARC implementation will vary for the differ= ent
> roles in the messaging infrastructure.
> 8.1 Domain Owner Implementations
>
> Section 6.5 <https://tools.ietf.org/html/rfc7= 489#section-6.5> describes
> many of the provisions for implementing the DMARC mechanism as a Domai= n
> Owner. This section will clarify those needed for minimal and full
> implementations.


I'd start by introducing the distinction between domain owner and mail = receiver.


The distinctions already exist in RFC = 7489, the original DMARC spec:

=C2=A0
A statement should then say what is the combined minimal/ full implementati= on.


> 8.1.2 Full Domain Owner Implementation
>
> Full implementation of the DMARC mechanism by a Domain Owner requires = all
> of the following characteristics:
>
>=C2=A0 =C2=A0 =C2=A0-
>
>=C2=A0 =C2=A0 =C2=A0Creation of the DMARC policy record in DNS which me= ets these criteria:
>=C2=A0 =C2=A0 =C2=A0-
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The policy record MUST express a Requested = Mail Receiver policy of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Cquarantine=E2=80=9D or =E2=80=9Cre= ject=E2=80=9D for the Organizational Domain and all sub-domains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 -
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Requested Mail Receiver policy MUST app= ly to a percentage of mail
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 not less than 100
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 -


Nope.=C2=A0 A domain can say it has a *strict policy* when the above criter= ia are met.=C2=A0 Standing the principle that domains which host human user= s mailboxes must not publish a strict policy, mandating that these domains = don't fully implement DMARC makes little sense.

Note that I'm opposed to said principle, which is a limitation of DMARC= .=C2=A0 However, the limitation is there and we must first remove it.=C2=A0= Afterwards, perhaps, we can mandate strict policies.


I'm not clear on what you mean by = "strict policy"; it's not a term I used here.=C2=A0

Also worth noting is that I'm not trying to mandate any= thing, only attempting to define two levels of implementation for each role= - minimal and full.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0Establishment of an address to receive aggregate re= ports at least daily;
>=C2=A0 =C2=A0 =C2=A0other than in exceptional circumstances such as res= ource exhaustion, the
>=C2=A0 =C2=A0 =C2=A0address must support receiving reports up to at lea= st ten megabytes in size.
>=C2=A0 =C2=A0 =C2=A0-
>
>=C2=A0 =C2=A0 =C2=A0Deployment of authentication technologies to ensure= Identifier Alignment


Isn't it clearer to say "both SPF and DKIM"?


Perhaps, but I took pains here to re-u= se=C2=A0the same verbiage that's in section 6.5 of RFC 7489:
=
=C2=A0

> 8.2 Mail Receiver Implementations
>
> This section will describe minimal and full implementations of the DMA= RC
> mechanism for Mail Receivers.


> 8.2.1 Minimal Mail Receiver Implementation
>
> Minimal implementation of the DMARC mechanism by a Mail Receiver means=
> fully implementing the provisions of Section 6.6
> <https://tools.ietf.org/html/rfc7489#section-= 6.6>


Maybe a minimal implementation could skip storing the results of DMARC proc= essing.


Perhaps, but again I was re-using text= from the original RFC -=C2=A0https://tools.ietf.org/html/rfc7489#section-8
= =C2=A0
>=C2=A0 =C2=A0 =C2=A0-
>
>=C2=A0 =C2=A0 =C2=A0Validation of any ARC header sets found in the mess= age


Nope.=C2=A0 DMARC has nothing to do with ARC.


Your statement is true, but I would su= bmit that ARC has everything to do with DMARC (and SPF, and DKIM) and attem= pting to mitigate the failures in authentication that can be caused by mail= transiting intermediaries.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0-
>
>=C2=A0 =C2=A0 =C2=A0Enforcement of discovered policies in a manner that= is consistent
> with Section
>=C2=A0 =C2=A0 =C2=A06.7 <https://tools.ietf.or= g/html/rfc7489#section-6.7>


Hm...=C2=A0 that adds nothing to the requirements.=C2=A0 Section 6.7 allows= receivers to do what they see fit.


Again, I'm not proposing to mandat= e any behavior here, only to define different levels of implementation; fur= ther, I don't sense much in the way of consensus from the group on tryi= ng to mandate behavior.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0-
>
>=C2=A0 =C2=A0 =C2=A0Send aggregate reports at least daily using =E2=80= =9Cmailto=E2=80=9D URIs; such
>=C2=A0 =C2=A0 =C2=A0aggregate reports MUST be no larger than ten megaby= tes in size.


I'd just mandate reporting.=C2=A0 Size is a different issue.


The ten megabytes limit is original te= xt from section 8 -=C2=A0=C2=A0https://tools.ietf.org/html/rfc7489#section-8=C2=A0-=C2= =A0 It seems antiquated to use such a small size today, but I was trying no= t to stray too far afield of the original text.

Limiting the size makes more sense for each mailto: address, as it should r= eflect message size limits that the corresponding MTA enforces.=C2=A0 See a= lso ticket #53.

Some domains react to the size limit by sending multiple records for the sa= me period.=C2=A0 The sum of sizes exceeds the size of a single report, give= n the way compression works.

Report size is obviously inversely proportional to frequency.=C2=A0 How abo= ut requiring the ability to send reports hourly for full implementations an= d at least daily for medium ones?


Once every 24 hours was in the origina= l text; I wasn't present at the creation of the original RFC, but it se= ems to be a cadence that most reporters use.

-- <= br>

Todd Herr | Sr. Technical Progra= m Manager
p: 703.220.4153


This email and all data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--00000000000076a37c05ada3a3b9-- From nobody Mon Aug 24 15:34:43 2020 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 2BEFB3A0E22 for ; Mon, 24 Aug 2020 15:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW7oKcb0EWXI for ; Mon, 24 Aug 2020 15:34:39 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF59E3A0E30 for ; Mon, 24 Aug 2020 15:34:39 -0700 (PDT) X-ASG-Debug-ID: 1598308477-11fa31095ea4b00001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id L7NHO9gnn0YVri7s (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 24 Aug 2020 18:34:38 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=aucNvN25dqYTYsmH6BnGO2WVjaPCHCDDwL89HQqiFsM=; b=Fzgb3DRNlNnCCcBsOEmW+NA9vDSVJ3ja/EJWUONweAvC9SyrM8RY+6Wmk6k2pVUlH TPa7x14HuImvP2h5NsLMd9V9+L5ThmE/dNxeLWyWmqbokjqoggf+3GGfrfcKlT+lH v+JDLgS7l8Wy7WBsYGDur6lT9o0Gf/3b/vCacAlBs= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Mon, 24 Aug 2020 22:34:31 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Reply-To: fosterd@bayviewphysicians.com Message-ID: <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=853c4097e2ab49d7a908b8af9b8142c8 In-Reply-To: References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> X-Exim-Id: 5e1469f9af1347569cac199ea9318d54 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1598308478 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4286 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84138 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 22:34:41 -0000 This is a multipart message in MIME format. --853c4097e2ab49d7a908b8af9b8142c8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Something seems inconsistent: - The people who have implemented DMARC do not see any significant problems= , and as a result they are not interested in a third-party authorization sc= heme. - Yet adoption is very slow, especially for anything other than p=3Dnone Are we to assume that mailing list compatibility explains the slow adoption= ? If not, what other obstacles do we need to be considering? DF ---------------------------------------- From: "Murray S. Kucherawy" Sent: 8/24/20 11:21 AM To: Brandon Long Cc: IETF DMARC WG , Tim Draegen , Alessan= dro Vesely Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing l= ist On Thu, Aug 20, 2020 at 2:01 PM Brandon Long wrote: I tend to agree with the negative stance on third party auth, but SPF obvio= usly has the include: statement which is third party auth at the most basic= level...atps[1] is the obvious equivalent for DKIM. I don't know if atps = failed because it wasn't all that useful, or if it was tied in folks minds = to adps, or the failure of the follow-on reputation system stuff.. Neither atps or spf include are really designed for large scale usage acros= s thousands of "relays" etc, and I don't think they should be used for that= , but for a bunch of small to medium entities, it could be the thing that m= akes higher p=3D possible. ATPS was designed as a proof of concept to see if third party policy was co= nceptually useful at all. Scale could come later if the initial experiment= had a positive result. The industry, however, apparently didn't even have= appetite to try, so we may never know. -MSK --853c4097e2ab49d7a908b8af9b8142c8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Something seems in= consistent:

- The people who have implemented DMAR= C do not see any significant problems, and as a result they are not interes= ted in a third-party authorization scheme.

- Yet a= doption is very slow, especially for anything other than p=3Dnone

Are we to assume that mailing list compatibility explains t= he slow adoption?   If not, what other obstacles do we need to be cons= idering?

DF

From: "Murray S. Kucherawy" <supe= ruser@gmail.com>
Sent: 8/24/20 11:21 AM
T= o: Brandon Long <blong@google.com>
Cc: I= ETF DMARC WG <dmarc@ietf.org>, Tim Draegen <tim@eudaemon.net>, = Alessandro Vesely <vesely@tana.it>
Subject: Re: [= dmarc-ietf] third party authorization, not, was non-mailing list
On Thu, Aug 20, 2020 at 2:01 PM Brandon= Long <blong@googl= e.com> wrote:
I tend to agree with the nega= tive stance on third party auth, but SPF obviously has the include: stateme= nt which is third party auth at the most basic level...
atps[1] is the obvious equivalent for DKIM.  I don't know = if atps failed because it wasn't all that useful, or if it was tied in folk= s minds to adps, or the failure of the follow-on reputation system stuff..<= /div>

Neither atps or spf include are really designed fo= r large scale usage across thousands of "relays" etc, and I don't think the= y should be used for that, but for a bunch of small to medium entities, it = could be the thing that makes higher p=3D possible.

ATPS was designed as a proof of concept to see if third party policy was = conceptually useful at all.  Scale could come later if the initial exp= eriment had a positive result.  The industry, however, apparently didn= 't even have appetite to try, so we may never know.

-MSK
--853c4097e2ab49d7a908b8af9b8142c8-- From nobody Mon Aug 24 21:20:12 2020 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 DA7C93A097F for ; Mon, 24 Aug 2020 21:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 xCTLJV-T-gqj for ; Mon, 24 Aug 2020 21:20:11 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 E39633A0965 for ; Mon, 24 Aug 2020 21:20:10 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id x2so2512512vkd.8 for ; Mon, 24 Aug 2020 21:20:10 -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=Z9N8YcMi49udOpw0GBn++P85BmZgg+om657Z7AR28gg=; b=HoPD8lguD5PQAYYxgf1TMvBY5seLTjU7lzJF35ArVYh3Jzs5tNBcgcZzviNynfkBkd 3StvQ9slxd/AzPEZe3SEXZ7kzo47aACO2Xd8Uj0KVs9rtfJV1UnKqA0gfVza9FZd9+IV 3KmjYPNtTdJFelUVgSqQcp+sqcYaB+H1ziGY+jEQKhJs+C8GUnA1dDPvBQdLmpM6VrQ0 372TPCY9qhWn739cfF6NRnUS23Cqdf15v3TKO3PdxSGaiUPeoyCMzAJgSdb531Rx6awl 69ivyjx99fy+ATIBBaKr+2T1Qg0kO1dfEpKsjh5BEeAiqceNdE1FPMOyLTEiYMACbf34 sd3A== 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=Z9N8YcMi49udOpw0GBn++P85BmZgg+om657Z7AR28gg=; b=De6Z/Fyjzi61Wl6BjUrOf0mk6wknJM+pBkCgaddynOsFfYeJxJBi5isNiaBB44fxS5 /DRY1qvTgMwKkRuMKM9J2XPssGNUzaAIPWKEjdoiBR0GrgVngBJhasS85ME810Cwh2eE aW9eZTIwyqqt6Ly8gchOF1eQfpyXte6713kiUd1zMFG9lG0TIrqcGIt7h7fi4dCutwb7 Iqgbvw2viIlEerNMhyFcpKbbWe38BQQKiNaWrOtg8Ax3BH9gQqt4osmJmgTZ8XyxSbYN A+IgStJ91ev/phm05kFDeoJg+zs0IGlFxf1ZvLY8Bi3hshwJPcPWFehKrBJsV+Z/0MKJ aeZQ== X-Gm-Message-State: AOAM530zmlxyoTfjGk/wbGONl0+r83Q8luB8gDT5k02XuulwCgxwQWMp jbFglCGcXVKIm6qBFORvHZAaHvkALAUeT1S95a3MbrqQ X-Google-Smtp-Source: ABdhPJxtozK1canCbgkXNJ948dfHLv9Reo04aOz8yWEVNQKtIdJfnLiDIw2tF31jXPEs1nZr45qyVDmTRVio/FYKMO0= X-Received: by 2002:a1f:f402:: with SMTP id s2mr4611829vkh.95.1598329209727; Mon, 24 Aug 2020 21:20:09 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> In-Reply-To: <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Mon, 24 Aug 2020 21:19:57 -0700 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c7ace705adac0467" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 04:20:12 -0000 --000000000000c7ace705adac0467 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 24, 2020 at 3:34 PM Douglas E. Foster wrote: > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result they are not interested in a third-party > authorization scheme. > I suspect you are conflating disinterest with being unconvinced that it is workable, at least in any of the forms in which it's been presented. I implemented DMARC and, unless you've been missing my commentary, I am far from "do not see any significant problems". -MSK --000000000000c7ace705adac0467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 24, 2020 at 3:34 PM Douglas E= . Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
Something seems inconsiste= nt:

- The people who have implemented DMARC do not= see any significant problems, and as a result they are not interested in a= third-party authorization scheme.

<= div>I suspect you are conflating disinterest with being unconvinced that it= is workable, at least in any of the forms in which it's been presented= .

I implemented DMARC and, unless you've been = missing my commentary, I am far from "do not see any significant probl= ems".

-MSK

--000000000000c7ace705adac0467-- From nobody Tue Aug 25 01:44:08 2020 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 1B9563A0BA1 for ; Tue, 25 Aug 2020 01:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.854 X-Spam-Level: *** X-Spam-Status: No, score=3.854 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 PiBhvyPlvE3G for ; Tue, 25 Aug 2020 01:44:05 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 352BA3A0775 for ; Tue, 25 Aug 2020 01:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598345042; bh=v+d0FpenH2XHz69Bnzom4CZbDKY9gv+FgBYTBaCtTPI=; l=4951; h=To:References:From:Date:In-Reply-To; b=CYShQFMcPSeRMJSeLBAuUqd9PrQePgvoZQwmnQC9ZC4RZVm/oyA7LffajHrx0sQ8j cUeRfNyjw+BES7Zcu8yQAwlg/UH/BvARu2CdrWziS8L1SP6ZPQTnokhJ3GmAZfNJmm hUUoP+i7U/8X52CTKWVsgnhzMUv5KWclm1sW/EjWvaCR79jl4LJSdSBCi2aE/ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.103] ([5.170.68.61]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F44CF51.000038D9; Tue, 25 Aug 2020 10:44:01 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <16de4b1f-299a-91e3-3f6a-0ff33c691fe1@tana.it> Date: Tue, 25 Aug 2020 10:43:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 08:44:07 -0000 Just a couple of notes, inline: On Mon 24/Aug/2020 20:20:06 +0200 Todd Herr wrote: > On Sat, Aug 22, 2020 at 5:06 AM Alessandro Vesely wrote: >> On Fri 21/Aug/2020 21:25:50 +0200 Todd Herr wrote: >> [snip] >> >>> 8.1.2 Full Domain Owner Implementation >>> >>> Full implementation of the DMARC mechanism by a Domain Owner requires all >>> of the following characteristics: >>> >>> - >>> >>> Creation of the DMARC policy record in DNS which meets these >> criteria: >>> - >>> >>> The policy record MUST express a Requested Mail Receiver policy of >>> “quarantine” or “reject” for the Organizational Domain and all >> sub-domains >>> - >>> >>> The Requested Mail Receiver policy MUST apply to a percentage of >> mail >>> not less than 100 >>> - >> >> >> Nope. A domain can say it has a *strict policy* when the above criteria >> are met. Standing the principle that domains which host human users >> mailboxes must not publish a strict policy, mandating that these domains >> don't fully implement DMARC makes little sense. >> >> Note that I'm opposed to said principle, which is a limitation of DMARC. >> However, the limitation is there and we must first remove it. Afterwards, >> perhaps, we can mandate strict policies. >> >> > I'm not clear on what you mean by "strict policy"; it's not a term I used > here. I was proposing that term, as an alternative to "domain X fully implements DMARC" —which can hardly be a synonym of "domain X deploys a strict DMARC policy". > Also worth noting is that I'm not trying to mandate anything, only > attempting to define two levels of implementation for each role - minimal > and full. Got it. Still, to require a strict policy in order to enable a mail site to boast full DMARC compliance makes little sense nowadays, especially since we deprecate Yahoo, AOL, et al. for having done so... >>> - >>> >>> Validation of any ARC header sets found in the message >> >> >> Nope. DMARC has nothing to do with ARC. >> >> > Your statement is true, but I would submit that ARC has everything to do > with DMARC (and SPF, and DKIM) and attempting to mitigate the failures in > authentication that can be caused by mail transiting intermediaries. The difference is DMARC is deterministic, in the sense that a receiver can mechanically operate according to the spec. ARC, reputation sites, and other external sources of information are very useful but have "batteries not included". >>> - >>> >>> Send aggregate reports at least daily using “mailto” URIs; such >>> aggregate reports MUST be no larger than ten megabytes in size. >> >> >> I'd just mandate reporting. Size is a different issue. >> >> > The ten megabytes limit is original text from section 8 - > https://tools.ietf.org/html/rfc7489#section-8 - It seems antiquated to use > such a small size today, but I was trying not to stray too far afield of > the original text. Uh, I hadn't noticed it. SMTP mandates a minimum of 64K only. In Italy, we have a legal minimum of 30Mb[*], Gmail can receive up to 50Mb[†], while others still suggest a limit of 10Mb[‡]. Looking around, I see values ranging from 150Mb to 40Mb: 250-DM3NAM06FT012.mail.protection.outlook.com Hello [5.170.68.61] 250-SIZE 157286400 250-mx.google.com at your service, [5.170.68.61] 250-SIZE 157286400 250-BN8NAM12FT041.mail.protection.outlook.com Hello [5.170.68.61] 250-SIZE 157286400 250-ietfa.amsl.com 250-PIPELINING 250-SIZE 67108864 250-BN8NAM11FT050.mail.protection.outlook.com Hello [5.170.68.61] 250-SIZE 49283072 250-mtaproxy523.free.mail.gq1.yahoo.com 250-PIPELINING 250-SIZE 41943040 250-us-app.us.dmarcian.com 250-PIPELINING 250-SIZE 40960000 [*] https://tools.ietf.org/html/rfc6109#section-3.1.1 [†] https://support.google.com/a/answer/1366776?hl=en [‡] https://support.microsoft.com/en-us/office/send-large-files-with-outlook-8c698842-b462-4a4c-8d53-5c5dd04f77ef >> Limiting the size makes more sense for each mailto: address, as it should >> reflect message size limits that the corresponding MTA enforces. See also >> ticket #53. >> >> Some domains react to the size limit by sending multiple records for the >> same period. The sum of sizes exceeds the size of a single report, given >> the way compression works. >> >> Report size is obviously inversely proportional to frequency. How about >> requiring the ability to send reports hourly for full implementations and >> at least daily for medium ones? >> >> > Once every 24 hours was in the original text; I wasn't present at the > creation of the original RFC, but it seems to be a cadence that most > reporters use. This topic deserves more discussion. The spec doesn't help much for developing a way to negotiate values of ri= between the consumer and the producer of aggregate reports. Best Ale -- From nobody Tue Aug 25 01:58:39 2020 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 B260C3A0BB0 for ; Tue, 25 Aug 2020 01:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 9UnHXHCv-wc7 for ; Tue, 25 Aug 2020 01:58:37 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 6165F3A0BAE for ; Tue, 25 Aug 2020 01:58:37 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id u3so10242960qkd.9 for ; Tue, 25 Aug 2020 01:58:37 -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=FizAt48lIUgU/4v5QHWO5oQ/wlWXRbi38l887KQnt7c=; b=AQr8fHtUebq0AqZrsj6r1DiN8kcYZl4QS7/lp0fK4C4VdYub7150fetqGTT0cbz/jc t5nWjIScvzztJx4qRUuhzI79+kbqA04nVcRfpXTLVdimgh60aVdpqDfQY/31D31TcVzY guRHbm3F3XMSHrPemxxwOQOYMsh/ETT2V5jY1vjXcOioQRkhLjyGi9/NSnQp7Q13fzJi I9ZvfEzVXA2ZhqfCUJ2x0MYaKeQpof7xqTg7d08tY2LuCkvEqawJdKlAGxykMCVL9nfJ Ehi3p5ZXT6Ea0ldRJkmRs1xkmI7sl8zcZcPR8eAh+MQ8IOZgwGLlfAfh/1WhFv+7IdZY l5jw== 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=FizAt48lIUgU/4v5QHWO5oQ/wlWXRbi38l887KQnt7c=; b=ATvwzmOOPoMcRYGMDzTjsSCaI5hQqci7EOS/EEvd9Hu14QAz6h8Ul2k4slqGPTxEKk gLjAvnAmpKq36k7UFouRJcR7S+XgwB4NQN8rcdi+WXNiUym8+4LQxM61eH0QYdWRku97 5zF/3DSPPzM46dzqtZ/YeikgkMaJdbD5/XG/umC2b+ijGQtal+6XMw+YntSWk63tLl+W s0vJgVjJ59E53368epOJDsI2oPBNFXf0QGy85J9Km02ynww/9ITDjpTi10wtmm3Qhp78 5uVIxQv8JpVqZAqTdDmRLbwCRA6ZYysFQi1/klXDtTQR3smSCFIEn8gIgdw2RGQK7tPT PblA== X-Gm-Message-State: AOAM531cIJpkaGLR4oRTYHQEeTHEC2BQvddPL1tQOIfyOtPNi0DZKkrA j3+TGxe6utUUA5cz3BeBgkLu3Ko1Zj6uwOkyI7GPeiT2md0= X-Google-Smtp-Source: ABdhPJxNuNcIccj9Gxpjt4y97ws4tbkCa9jQLhG4u55oQHy5CUYrZOc51XP0fBr1s6VRpSx+WrDdxSQ28XAl8+L0W6o= X-Received: by 2002:a37:498e:: with SMTP id w136mr7877232qka.187.1598345916464; Tue, 25 Aug 2020 01:58:36 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> In-Reply-To: <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> From: Dotzero Date: Tue, 25 Aug 2020 04:58:25 -0400 Message-ID: To: "Douglas E. Foster" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009443bf05adafe8ba" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 08:58:39 -0000 --0000000000009443bf05adafe8ba Content-Type: text/plain; charset="UTF-8" On Mon, Aug 24, 2020 at 6:34 PM Douglas E. Foster wrote: > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result they are not interested in a third-party > authorization scheme. > > - Yet adoption is very slow, especially for anything other than p=none > > Are we to assume that mailing list compatibility explains the slow > adoption? If not, what other obstacles do we need to be considering? > > DF > DMARC itself is easy to implement. It's getting control of your mail flows that is the difficult part for most organizations interested in implementing. I think the real issue for "slow adoption" is lack of perceived need, until you believe your domain is being abused. What is the uptake for DNSSEC? For most IETF standards other than very core ones, the long tail is indeed very long. My gut tells me, based on being in this space a long time, that the overwhelming majority of people aren't thinking about DMARC, let alone the "mailing list problem"/ Michael Hammer --0000000000009443bf05adafe8ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 24, 2020 at 6:34 PM Dougl= as E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
Something seems inconsistent:

- The people who have implemented DMARC do not see any significant pr= oblems, and as a result they are not interested in a third-party authorizat= ion scheme.

- Yet adoption is very slow, especiall= y for anything other than p=3Dnone

Are we to assum= e that mailing list compatibility explains the slow adoption? =C2=A0 If not= , what other obstacles do we need to be considering?

DF

DMARC itself is easy to i= mplement. It's getting control of your mail flows that is the difficult= part for most organizations interested in implementing. I think the real i= ssue for "slow adoption" is lack of perceived need, until you bel= ieve your domain is being abused.=C2=A0 What is the uptake for DNSSEC? For = most IETF standards other than very core ones, the long tail is indeed very= long. My gut tells me, based on being in this space a long time, that the = overwhelming majority of people aren't thinking about DMARC, let alone = the "mailing list problem"/

Michael Hamm= er
--0000000000009443bf05adafe8ba-- From nobody Tue Aug 25 02:03:49 2020 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 B4E7D3A0BAA for ; Tue, 25 Aug 2020 02:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 w_Uobl75kHOk for ; Tue, 25 Aug 2020 02:03:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 254BA3A0B87 for ; Tue, 25 Aug 2020 02:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598346222; bh=aPoFLsCH4HJzwQF/hYVjzXhfwzhtEQpCTlQYzTtvoM0=; l=1434; h=To:Cc:References:From:Date:In-Reply-To; b=AYlavvnjN/1qnZeNpMGarKxBDmhlnnerJH0inztLVcOx+fFwTSgW/1BDF1Up37jYs DWl/pOgEZwHeISn9mJ01HGLKSSarRXxsJZvijaaFYIyAH+Wz6lWtGJPbj0bxKoHDNu KXkBBFNDD1ZlmtcNFutsM1LZa6maSKARA2bWtY664hYeCvBsyfkXfvsZQtCMw Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.103] ([5.170.68.61]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005F44D3EE.00003B23; Tue, 25 Aug 2020 11:03:42 +0200 To: John Levine , dmarc@ietf.org Cc: superuser@gmail.com References: <20200824172403.A927C1F14BF5@ary.qy> From: Alessandro Vesely Message-ID: <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> Date: Tue, 25 Aug 2020 11:03:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200824172403.A927C1F14BF5@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 09:03:48 -0000 On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote: > In article you write: >>> If the intermediary DKIM signs the modified message with their own >>> signature, that provides some assurance to the receiver. >> >> You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00? >> >> I'm pretty sure that got implemented too, but I can't recall now if it ever shipped. > > I don't think it ever did. It has the scaling problem of every system that sends to mailing lists > having to decide what mail it's willing to have re-signed and what domain the second signature > will use. Usually it's the domain name of the list except when it's not. Right. The only practical implementation I see is that the sender has a list of recipient addresses that require weak signatures. When it is about to send a message destined to a listed address, it can fork the message so that the weakly signed copy is sent to the (trusted) list address only. Any direct copy is signed in full. To configure that, a postmaster would need an application by the list. Something saying "your users A, B, and C are subscribed to list X, please sign weakly". The postmaster would then verify if A, B, and C are trusted users and if they confirm to be subscribed to X. In that case, the address of X gets enlisted. Would that scale? Best Ale -- From nobody Tue Aug 25 02:14:43 2020 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 6C8D13A090C for ; Tue, 25 Aug 2020 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 9J2RsWjiuFG5 for ; Tue, 25 Aug 2020 02:14:39 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 B0D0D3A08E5 for ; Tue, 25 Aug 2020 02:14:39 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id 144so10275453qkl.5 for ; Tue, 25 Aug 2020 02:14:39 -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=jMf967JyC1sHeIPQNDzr0alAVx1Xg++8rmQShugdidk=; b=AmoMB+YT41+It/baNT4d/7Z4S64gDeelyw0UGSLjQhfpL2qANcvcQkU5Xe2Pj7Ew1/ aLovWVlaC7yh7xz3fFV/kAOSVftp7gDrlDWZQpkLab6skrpNbd+u8iD8gI3S18jxOFOo tYAJv4z82EjAwT6/bzIjwcsExmiOCNp6kG7zBbZ/wCpV76HYHMVI4t4MR7G9y2MYa0rU d0fL6C9jHOjsvlrcfiGUnVwUsZ6m088wJ0GGf9YtexVm8RUa+uxE+HJoTdPWN038/2BM olpigbsbA9UBAO/Ev+NfPK7/H0fa0jtO1WqXzMEa3yKeHYBg8SPhE1uHKx/+1C34cJBY Sn/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=jMf967JyC1sHeIPQNDzr0alAVx1Xg++8rmQShugdidk=; b=o9zV8yeiIpx/EXZYhVIZF9H9C+nhPLhW3TkZ6W09WoGwvsQ0UVVvEADc7IGy50FKe6 qkceLNee06xHC23GEGyWj+53kufo6/FJf4h1SUemJcmvswdjN6k3tMfu1HDa32uDBRhr I72XN/pPgOBprMQNxDXn9ekGDt17ue+rPNowQLZSDA3Qcx/FLEN3D/DMj6B8W6Na0Ds4 Rs33lSHl0SBb/TqWFwOkbkssdWBelrq9G757nBO9K0W7VUrFPr0VqXVl2/rvHEvTQAeH 6DNro9VIwWkE8G3T8RfongRPSlBppFH6U1VNn84+GEDT5ZI1FYPaotbVlWCfcNjS11E4 QrbA== X-Gm-Message-State: AOAM530Rm0z/9WxTM9yzbfpPt/6WUDNcvdI3m61ZF09Fw/blQ8kiFpk+ MHq0/kfOH87fDyWYlpEkEi9Fi3C95oWN0FT2mMtLribiaHk= X-Google-Smtp-Source: ABdhPJzI8ZoUheXSMVT+H88HhScMEQY7RhITkN39jXPEGZu6UJ68BL+OyQopeeLWCIsWoXMOnPblcL7sko8YpHdtJ7E= X-Received: by 2002:a37:a9cb:: with SMTP id s194mr8489162qke.64.1598346878811; Tue, 25 Aug 2020 02:14:38 -0700 (PDT) MIME-Version: 1.0 References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> In-Reply-To: <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> From: Dotzero Date: Tue, 25 Aug 2020 05:14:27 -0400 Message-ID: To: Alessandro Vesely Cc: John Levine , IETF DMARC WG , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="000000000000f081ca05adb0214f" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 09:14:41 -0000 --000000000000f081ca05adb0214f Content-Type: text/plain; charset="UTF-8" On Tue, Aug 25, 2020 at 5:03 AM Alessandro Vesely wrote: > On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote: > > In article 8qgy3wkYfXw@mail.gmail.com> you write: > >>> If the intermediary DKIM signs the modified message with their own > >>> signature, that provides some assurance to the receiver. > >> > >> You mean like > https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > >> > >> I'm pretty sure that got implemented too, but I can't recall now if it > ever shipped. > > > > I don't think it ever did. It has the scaling problem of every system > that sends to mailing lists > > having to decide what mail it's willing to have re-signed and what > domain the second signature > > will use. Usually it's the domain name of the list except when it's not. > > > Right. The only practical implementation I see is that the sender has > a list of recipient addresses that require weak signatures. When it > is about to send a message destined to a listed address, it can fork > the message so that the weakly signed copy is sent to the (trusted) > list address only. Any direct copy is signed in full. > > To configure that, a postmaster would need an application by the list. > Something saying "your users A, B, and C are subscribed to list X, > please sign weakly". The postmaster would then verify if A, B, and C > are trusted users and if they confirm to be subscribed to X. In that > case, the address of X gets enlisted. Would that scale? > > > Best > Ale > -- > Under my concept, all mail would still be signed in full. The weak signature would be in addition to the full signature and the intermediary would be expected to sign in full as well. If the original full signature is broken you are left with the original "weak signature" which authorizes the intermediary and the full signature of the intermediary. I would expect there to be multiple potential approaches to identifying acceptable intermediaries. One might be user self enrollment. For larger organizations it might be intermediary application/approval. A 3rd approach might be a trusted 3rd party providing lists of known intermediaries. This would be separate from the core signing RFC, whether it is part of DMARC or a separate document. Michael Hammer. --000000000000f081ca05adb0214f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0

On Tue, Aug 25, 2020 at 5:03 AM= Alessandro Vesely <vesely@tana.it= > wrote:
On M= on 24/Aug/2020 19:24:03 +0200 John Levine wrote:
> In article <CAL0qLwaip0fzXpqnK=3DXTcEELZRat_gnjuEGZYj=3D8qgy3wkYfXw@mail.gmail= .com> you write:
>>> If the intermediary DKIM signs the modified message with their= own
>>> signature, that provides some assurance to the receiver.
>>
>> You mean like https://tools.iet= f.org/html/draft-levine-dkim-conditional-00?
>>
>> I'm pretty sure that got implemented too, but I can't reca= ll now if it ever shipped.
>
> I don't think it ever did.=C2=A0 It has the scaling problem of eve= ry system that sends to mailing lists
> having to decide what mail it's willing to have re-signed and what= domain the second signature
> will use.=C2=A0 Usually it's the domain name of the list except wh= en it's not.


Right.=C2=A0 The only practical implementation I see is that the sender has=
a list of recipient addresses that require weak signatures.=C2=A0 When it <= br> is about to send a message destined to a listed address, it can fork
the message so that the weakly signed copy is sent to the (trusted)
list address only.=C2=A0 Any direct copy is signed in full.

To configure that, a postmaster would need an application by the list.
=C2=A0 Something saying "your users A, B, and C are subscribed to list= X,
please sign weakly".=C2=A0 The postmaster would then verify if A, B, a= nd C
are trusted users and if they confirm to be subscribed to X.=C2=A0 In that =
case, the address of X gets enlisted.=C2=A0 Would that scale?


Best
Ale
--

Under my concept, all mail would st= ill be signed in full. The weak signature would be in addition to the full = signature and the intermediary would be expected to sign in full as well. I= f the original full signature is broken you are left with the original &quo= t;weak signature" which authorizes the intermediary and the full signa= ture of the intermediary.

I would expect ther= e to be multiple potential approaches to identifying acceptable intermediar= ies. One might be user self enrollment. For larger organizations it might b= e intermediary application/approval. A 3rd approach might be a trusted 3rd = party providing lists of known intermediaries. This would be separate from = the core signing RFC, whether it is part of DMARC or a separate document.

Michael Hammer.
--000000000000f081ca05adb0214f-- From nobody Tue Aug 25 02:47:45 2020 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 CF4513A0BE6 for ; Tue, 25 Aug 2020 02:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=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 T0iAeEfm6BiK for ; Tue, 25 Aug 2020 02:47:42 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id F12973A0BF4 for ; Tue, 25 Aug 2020 02:47:41 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id BE0BA9F1F7 for ; Tue, 25 Aug 2020 02:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1598348861; bh=udunT6kJkdSLjnjPLZDl6ZjlMLGS9OqMlDBcs2ZejJ0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=GApbsyZ1/q9pJzH2xrabnKBpEEDOS5wc5JVQEoRf0FWqmTzunjh+w8eCq9/yrMJYx /ZhYbw06N2TfQBDsBqpIkcIchgk5/ePZRmMjorRDWJW5KHwGgPwxx4SCISJfPeLqA4 FRWRN8hzYcL2+8jHkKYjF+sbVpJaET0BJVmphZxY= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_BA8B773A-2237-4346-AC9C-A5B133320AE2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 25 Aug 2020 10:47:38 +0100 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> To: "dmarc@ietf.org" In-Reply-To: <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> Message-Id: <58F823DC-05C6-4036-BE4B-70BACB9ED0A4@wordtothewise.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 09:47:44 -0000 --Apple-Mail=_BA8B773A-2237-4346-AC9C-A5B133320AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Aug 2020, at 23:34, Douglas E. Foster = wrote: >=20 > Something seems inconsistent: >=20 > - The people who have implemented DMARC do not see any significant = problems, and as a result they are not interested in a third-party = authorization scheme. >=20 > - Yet adoption is very slow, especially for anything other than p=3Dnone= >=20 > Are we to assume that mailing list compatibility explains the slow = adoption? If not, what other obstacles do we need to be considering? I don=E2=80=99t believe mailing list compatibility is a primary reason = for slow adoption, although I do think it=E2=80=99s a contributing = factor. To my mind the biggest obstacle to adoption of restrictive = policies is the expense of implementation and the lack of return for = that investment.=20 Implementing DMARC, particularly for larger companies who want to do it = correctly, is expensive and resource intensive. It is a multi-month = process to identify all the legitimate sources of mail, create alignment = or move vendors and set up the correct reporting mechanism. You can, and = I do recommend, outsource this to one of the vendors who does this well. = Not every company outsources or has the resources to do this correctly = internally. A client from last year was told they had less than a week = to go from no DMARC to p=3Dreject. Unfortunately, the IT directive came = with nothing more than a =E2=80=9Cpublish v=3DDMARC1; p=3Dreject in your = DNS.=E2=80=9D Client lost days worth of mail due to a lack of direct = alignment even though they were using their own domains in SPF and DKIM. = Checking now, client still isn=E2=80=99t collecting reports, but has = backed down to p=3Dquarantine.=20 A restrictive DMARC record requires a large, up-front commitment of = resources. It also requires ongoing resources for monitoring and = understanding the reports and the ability to be able to address any = problems that show up in the reports.=20 For a lot of companies, the benefit to publishing restrictive DMARC = policy is minor. It stops bad guys from directly forging their domain, = but doesn=E2=80=99t stop your brand being phished or your executives = from being spear phished using cousin domains or taking advantage of the = 5322.from comment. It also disrupts normal business processes as we=E2=80=99= ve been discussing on the list here. To borrow an example from John = Levine, a restrictive DMARC policy is preventing employees at a large = company from participating in industry specific mailing lists; = participation which is part of their actual job.=20 I believe a lot of the very slow adoption is folks inside companies = looking at the cost of implementing restrictive DMARC records and the = benefits to implementing restrictive DMARC records and deciding there = just isn=E2=80=99t enough benefit to justify the expense. BIMI is an = attempt to bring more benefit to the table, but I=E2=80=99m not sure = even that is enough to justify the overall expense to a lot of = corporations.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_BA8B773A-2237-4346-AC9C-A5B133320AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24 Aug 2020, at 23:34, Douglas E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> = wrote:

Something seems inconsistent:

- The people who have implemented DMARC = do not see any significant problems, and as a result they are not = interested in a third-party authorization scheme.
- Yet adoption is very slow, = especially for anything other than p=3Dnone

Are we to assume that mailing list = compatibility explains the slow adoption?   If not, what other = obstacles do we need to be = considering?

I = don=E2=80=99t believe mailing list compatibility is a primary reason for = slow adoption, although I do think it=E2=80=99s a contributing factor. = To my mind the biggest obstacle to adoption of restrictive policies is = the expense of implementation and the lack of return for that = investment. 

Implementing = DMARC, particularly for larger companies who want to do it correctly, is = expensive and resource intensive. It is a multi-month process to = identify all the legitimate sources of mail, create alignment or move = vendors and set up the correct reporting mechanism. You can, and I do = recommend, outsource this to one of the vendors who does this well. Not = every company outsources or has the resources to do this correctly = internally. A client from last year was told they had less than a week = to go from no DMARC to p=3Dreject. Unfortunately, the IT directive came = with nothing more than a =E2=80=9Cpublish v=3DDMARC1; p=3Dreject in = your DNS.=E2=80=9D Client lost days worth of mail due to a lack of = direct alignment even though they were using their own domains in SPF = and DKIM. Checking now, client still isn=E2=80=99t collecting reports, = but has backed down to p=3Dquarantine. 

A restrictive DMARC record requires a large, = up-front commitment of resources. It also requires ongoing resources for = monitoring and understanding the reports and the ability to be able to = address any problems that show up in the reports. 

For a lot of companies, the benefit to publishing = restrictive DMARC policy is minor. It stops bad guys from directly = forging their domain, but doesn=E2=80=99t stop your brand being phished = or your executives from being spear phished using cousin domains or = taking advantage of the 5322.from comment. It also disrupts normal = business processes as we=E2=80=99ve been discussing on the list here. To = borrow an example from John Levine, a restrictive DMARC policy is = preventing employees at a large company from participating in industry = specific mailing lists; participation which is part of their actual = job. 

I believe a lot of the = very slow adoption is folks inside companies looking at the cost of = implementing restrictive DMARC records and the benefits to implementing = restrictive DMARC records and deciding there just isn=E2=80=99t enough = benefit to justify the expense. BIMI is an attempt to bring more benefit = to the table, but I=E2=80=99m not sure even that is enough to justify = the overall expense to a lot of corporations. 

laura 

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_BA8B773A-2237-4346-AC9C-A5B133320AE2-- From nobody Tue Aug 25 06:08:10 2020 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 EAAA83A0CD3 for ; Tue, 25 Aug 2020 06:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 EDaD0O1vDXH7 for ; Tue, 25 Aug 2020 06:08:07 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 2AADE3A0B25 for ; Tue, 25 Aug 2020 06:08:07 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id i20so10802327qkk.8 for ; Tue, 25 Aug 2020 06:08:07 -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=QECH5pANeEodoWhWMiuhG7QdsH8pxrvlJlXqNq7lnQM=; b=tFHu3YsCVCChOxmbP+k3/rQcDWoFOUTf8XtJXC68OY0iaLpNyl/Vy/GK/kRIrD4yO0 v10GeaIVDAxQraeIsn8wYtclR4gMeUEzGIj4DTRwjeO5IT7cY388YzDoqukJrCYid4dk 6+9+W9f3smRxTz3lRhywCZUXhK23XwZ5caWvfIMrFQpSk/kMJU4o4oCsI1Ek4xL1HDDL 00q1Ka5bxto23qHCibcN7x2tJADl67whOrpnqcxk7w4rGZPzhAv7/GApZec4lfdEnD7g PH3supSWCfGh2mlP8DpNc8F92uQnmAb+sVplzEbsaM+KwyoJP8rzag8S28BFcGWfZARX UPSw== 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=QECH5pANeEodoWhWMiuhG7QdsH8pxrvlJlXqNq7lnQM=; b=f6bJcorw/maaT8MMXeJvjt4pg3/4iM2xvzlj1c06UIE334bedG8RvQAudCv7S8pPOF aO/GWgl8CNeozmxU2W49y+5La38snOTdSpUdks3546PKnqJKmBBviISN4dWFP5xYuUKk AQYpMf+5r+/1KUZVsRIiMSBIVhuaYCKIb7BTzo9ScTdnKdX0eZ1f2/YaGUHWexaC7BuU xEbfD65cIFNaH8Y2Flex+LNvVUcYWVLrgDed25Y59Hi2xE6lXvs1e4uoR2quioUoSC4k WlGed3cVGlqaYYWI4FW6iJuyNOtG/HeljfmUCiZEWTIGGMIQVQ8YGKxqd89z3OeNV8hg 88cQ== X-Gm-Message-State: AOAM5329o5A0Ls/x+gKyZ/m6aVvd8mZdgJru9DxXbLr2Mpge+9qoQhr4 hiKW2NVJVaCjnXKeGWUhO8DGnaDeWHswXQDbv0ohNaz7gn6mtw== X-Google-Smtp-Source: ABdhPJz+g56y7mZVLA1Yvk9QBFBqy9Z+EbfDE6naTZnSvCkIuTJHBP1FgKqAZrvdquu/41C+lrU56m3R1uaSUvVbSTc= X-Received: by 2002:a37:5cc1:: with SMTP id q184mr2796018qkb.66.1598360885201; Tue, 25 Aug 2020 06:08:05 -0700 (PDT) MIME-Version: 1.0 References: <20200810172411.A13681E7CD8B@ary.local> <7e9326fc-ae27-d4bd-9f2b-9896da8320f1@dcrocker.net> <5F396A77.3000109@isdg.net> <21110e7f-ea60-66d6-c2fb-65b716a049a9@tana.it> <5d4e48f86ca7479ab4889ddff57a2870@bayviewphysicians.com> <6c7c2ad9-8a7e-e44c-6b2f-559129f70a9d@tana.it> <5e1469f9af1347569cac199ea9318d54@bayviewphysicians.com> <58F823DC-05C6-4036-BE4B-70BACB9ED0A4@wordtothewise.com> In-Reply-To: <58F823DC-05C6-4036-BE4B-70BACB9ED0A4@wordtothewise.com> From: Dotzero Date: Tue, 25 Aug 2020 09:07:53 -0400 Message-ID: To: Laura Atkins Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9106905adb36476" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 13:08:09 -0000 --000000000000c9106905adb36476 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 25, 2020 at 5:48 AM Laura Atkins wrote: > > > On 24 Aug 2020, at 23:34, Douglas E. Foster < > fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote: > > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result they are not interested in a third-party > authorization scheme. > > - Yet adoption is very slow, especially for anything other than p=3Dnone > > Are we to assume that mailing list compatibility explains the slow > adoption? If not, what other obstacles do we need to be considering? > > > I don=E2=80=99t believe mailing list compatibility is a primary reason fo= r slow > adoption, although I do think it=E2=80=99s a contributing factor. To my m= ind the > biggest obstacle to adoption of restrictive policies is the expense of > implementation and the lack of return for that investment. > > Implementing DMARC, particularly for larger companies who want to do it > correctly, is expensive and resource intensive. It is a multi-month proce= ss > to identify all the legitimate sources of mail, create alignment or move > vendors and set up the correct reporting mechanism. You can, and I do > recommend, outsource this to one of the vendors who does this well. Not > every company outsources or has the resources to do this correctly > internally. A client from last year was told they had less than a week to > go from no DMARC to p=3Dreject. Unfortunately, the IT directive came with > nothing more than a =E2=80=9Cpublish v=3DDMARC1; p=3Dreject in your DNS.= =E2=80=9D Client lost > days worth of mail due to a lack of direct alignment even though they wer= e > using their own domains in SPF and DKIM. Checking now, client still isn= =E2=80=99t > collecting reports, but has backed down to p=3Dquarantine. > > A restrictive DMARC record requires a large, up-front commitment of > resources. It also requires ongoing resources for monitoring and > understanding the reports and the ability to be able to address any > problems that show up in the reports. > > For a lot of companies, the benefit to publishing restrictive DMARC polic= y > is minor. It stops bad guys from directly forging their domain, but doesn= =E2=80=99t > stop your brand being phished or your executives from being spear phished > using cousin domains or taking advantage of the 5322.from comment. It als= o > disrupts normal business processes as we=E2=80=99ve been discussing on th= e list > here. To borrow an example from John Levine, a restrictive DMARC policy i= s > preventing employees at a large company from participating in industry > specific mailing lists; participation which is part of their actual job. > > I believe a lot of the very slow adoption is folks inside companies > looking at the cost of implementing restrictive DMARC records and the > benefits to implementing restrictive DMARC records and deciding there jus= t > isn=E2=80=99t enough benefit to justify the expense. BIMI is an attempt t= o bring > more benefit to the table, but I=E2=80=99m not sure even that is enough t= o justify > the overall expense to a lot of corporations. > > laura > I agree with many of Laura's observations. One other issue is that DMARC adoption is typically advocated by security and/or IT. When put against competing demands for resources and potential projects in an organization, it often gets moved down the priority list... until the organization is being abused in a way that they feel DMARC might help mitigate. Then there is a rush to implement, often with painful outcomes. Michael Hammer --000000000000c9106905adb36476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Aug 25, 2020 at 5:48 AM Laura Atk= ins <laura@wordtothewise.com<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">


Something seems inconsist= ent:

- The people who have implemented DMARC do no= t see any significant problems, and as a result they are not interested in = a third-party authorization scheme.

- Yet adoption= is very slow, especially for anything other than p=3Dnone

Are we to assume that mailing list compatibility explains the slow= adoption? =C2=A0 If not, what other obstacles do we need to be considering= ?

I don=E2=80=99t believe mail= ing list compatibility is a primary reason for slow adoption, although I do= think it=E2=80=99s a contributing factor. To my mind the biggest obstacle = to adoption of restrictive policies is the expense of implementation and th= e lack of return for that investment.=C2=A0

Implem= enting DMARC, particularly for larger companies who want to do it correctly= , is expensive and resource intensive. It is a multi-month process to ident= ify all the legitimate sources of mail, create alignment or move vendors an= d set up the correct reporting mechanism. You can, and I do recommend, outs= ource this to one of the vendors who does this well. Not every company outs= ources or has the resources to do this correctly internally. A client from = last year was told they had less than a week to go from no DMARC to p=3Drej= ect. Unfortunately, the IT directive came with nothing more than a =E2=80= =9Cpublish=C2=A0v=3DDMARC1; p=3Dreject in your DNS.=E2=80=9D Client lost da= ys worth of mail due to a lack of direct alignment even though they were us= ing their own domains in SPF and DKIM. Checking now, client still isn=E2=80= =99t collecting reports, but has backed down to p=3Dquarantine.=C2=A0
=

A restrictive DMARC record requires a large, up-front c= ommitment of resources. It also requires ongoing resources for monitoring a= nd understanding the reports and the ability to be able to address any prob= lems that show up in the reports.=C2=A0

For a lot = of companies, the benefit to publishing restrictive DMARC policy is minor. = It stops bad guys from directly forging their domain, but doesn=E2=80=99t s= top your brand being phished or your executives from being spear phished us= ing cousin domains or taking advantage of the 5322.from comment. It also di= srupts normal business processes as we=E2=80=99ve been discussing on the li= st here. To borrow an example from John Levine, a restrictive DMARC policy = is preventing employees at a large company from participating in industry s= pecific mailing lists; participation which is part of their actual job.=C2= =A0

I believe a lot of the very slow adoption is f= olks inside companies looking at the cost of implementing restrictive DMARC= records and the benefits to implementing restrictive DMARC records and dec= iding there just isn=E2=80=99t enough benefit to justify the expense. BIMI = is an attempt to bring more benefit to the table, but I=E2=80=99m not sure = even that is enough to justify the overall expense to a lot of corporations= .=C2=A0

laura
I agree with many of Laura's observations. One other issue is that DMAR= C adoption is typically advocated by security and/or IT.=C2=A0 When put aga= inst competing demands for resources and potential projects in an organizat= ion, it often gets moved down the priority list... until the organization i= s being abused in a way that they feel DMARC might help mitigate. Then ther= e is a rush to implement, often with painful outcomes.

=
Michael Hammer
--000000000000c9106905adb36476-- From nobody Tue Aug 25 09:22:24 2020 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 476FF3A104A for ; Tue, 25 Aug 2020 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Khc1SuEc; dkim=pass (2048-bit key) header.d=taugh.com header.b=r8dSNmWy 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 8admwgOs7Z3V for ; Tue, 25 Aug 2020 09:22:21 -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 858B73A10EC for ; Tue, 25 Aug 2020 09:22:21 -0700 (PDT) Received: (qmail 27262 invoked from network); 25 Aug 2020 16:22:19 -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; s=6a7c.5f453abb.k2008; i=johnl-iecc.com@submit.iecc.com; bh=YVip5WC2QkRraufMC4CqX0mWw1BbBNTtmmqCWI9UW0k=; b=Khc1SuEcccJKdaW9EvbIW0drdFVPkVzBBM+l5eciNb5wvLHJnOI5hZEc/xO8vib/rKqQp7jr4OFOlXyGp87js21yfpFVc1IW1rWZBn19B85YHc69zjRIe1sLAsaV6UWnaGhY7m155tWTXVOa9Qibv7ug287tXAaQEB0iYKFWyYzh4jSN0DcFkdSvaiKIoBXfQj0lGcCcm7Oa5bU8w6vX0NZt3gKpYNJzTtFkia0vDO5b3eefCRnqv/3szlXdkpTqJC2ARXLHC68NSn8OZ3d82Mjm5eZ+Z3jKzBvz5UwGiEsKWrz4zf5VcAd/Qctis9mkx2zzwhncOQOqndrXB+vW2w== 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; s=6a7c.5f453abb.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=YVip5WC2QkRraufMC4CqX0mWw1BbBNTtmmqCWI9UW0k=; b=r8dSNmWy9ZVc3QphWVpuWPtNcvn/yv3zUhU39Te9zOx852JMdjr5apIbdvzMT+3IlOtK9nhZQEeEZguLgbiu6dDu7x+J4c2mxTb3+GaIGfpwomNM2IfVR6wnYYBbcW4x0zLCauVrYWIJbMZfKRkxRUskjaz8p7S+s3Euyr1gcnEykQsjt+OELQ/+tluejmkeJEMlnUfKcJIPgu0Qh/iD6LY9AiwYMyF6ZD1r2sxb8WUNfOWC7prm6L+sL8XBHqv+WnmZXvWpfJFuPDMg9C5mO3LHotMQ4HfF7OMWsmvyHr+peesZEP2DSFNo2feb1SsAyAHEd7hyRC4iuaU0sz+aHQ== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 25 Aug 2020 16:22:19 -0000 Date: 25 Aug 2020 12:22:19 -0400 Message-ID: <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> From: "John R Levine" To: "Dotzero" Cc: "IETF DMARC WG" In-Reply-To: References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 16:22:23 -0000 On Tue, 25 Aug 2020, Dotzero wrote: >> https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > Under my concept, all mail would still be signed in full. The weak > signature would be in addition to the full signature and the intermediary > would be expected to sign in full as well. If the original full signature > is broken you are left with the original "weak signature" which authorizes > the intermediary and the full signature of the intermediary. Take another look at my old draft. Sounds like exactly the same plan. > I would expect there to be multiple potential approaches to identifying > acceptable intermediaries. The harder part is to decide which intermediary gets to re-sign which message at the time you apply the weak signature. 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 Aug 25 10:51:32 2020 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 275F73A0B35 for ; Tue, 25 Aug 2020 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 N_hwxzx8qy3L for ; Tue, 25 Aug 2020 10:51:29 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 4AA8B3A0B33 for ; Tue, 25 Aug 2020 10:51:28 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id o12so7142339qki.13 for ; Tue, 25 Aug 2020 10:51:28 -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=ZDvxNflxzPhWAmcfPAHjXoClTuJO0C7uE1VdGcKOZ38=; b=JugHOrQK/9S39lbweica9KyAeZ6ARZjid6Q5U8nkohUfm1HTYf885QOVdVF5b22hOs 98aGeNNSOGiV1TmyzbhiJb3M8UFnvHpTkvNiT809iduc5QWyWNIG7ilxzmDZ2erHxdxr zMgLBf75ChBUGaY76gK6ZGywlBBxn79h1vFQJkSCmd46y1T90MTvca1jMr5nQ6iUAUHj i3UuruqaQmsZXMqKCr2a/5IdXeMvEotxMGqmFRNJjhUmqHwC7C5si/w9NGu/Ss2f400F 8LnXYA4YCbHu8tjN7RFOAI/YIJ3aowHacJ6pEaIjm9C0JPMxkIi55rTOwPiMGRnIqfhF /txw== 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=ZDvxNflxzPhWAmcfPAHjXoClTuJO0C7uE1VdGcKOZ38=; b=ckKMvWEtdtnb0n/a3KofwVs6J+syjxYGH8uFKuPb8P34Dz5klsdRiV6tjCPvKrgAKj 8kOT5B7+9OsxOSlkfi6FCgIgf9gtfSjSCdORiXhd98gxG6Bml/LDsd7auqrYibWJHp5J xQJdydDBPrdoH7eM6gxar4baJj6G8NT3u+/laEqUTj4M+QLMcOYUycrTqLOumSgq007g QdwdQIyu2H9q67+TyXS83APgRn2J0NgRJmwtoCKl3lvTD4eFWlUML5MgUCHWVKck9ZWh n+D/mZeEqGSgEU2F7FPsN8Z+98l6VCPmyMoQR4KerX85RPu/urEEW1D9B27osZrAKnFL p6Ig== X-Gm-Message-State: AOAM530/4r26zDFAhk0D8dvAaKzW6OvguIi69D3rWejIj4q0aKT+80MY OTMohKqs8b+6qg9wGRUvkzwNvEYqDYlPp8oTouXaO5r75b8= X-Google-Smtp-Source: ABdhPJyt7NIU+/TfZn2biMVRiwpeOCOG8iFTRSg/JdiJXn6VdrfilaoyqzygY26JOX3F+UUcAmFxw78qf5u000s5h9U= X-Received: by 2002:a37:5cc1:: with SMTP id q184mr4068805qkb.66.1598377887315; Tue, 25 Aug 2020 10:51:27 -0700 (PDT) MIME-Version: 1.0 References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> In-Reply-To: <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> From: Dotzero Date: Tue, 25 Aug 2020 13:51:11 -0400 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000030be4c05adb75aa0" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 17:51:31 -0000 --00000000000030be4c05adb75aa0 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 25, 2020 at 12:22 PM John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: > >> https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > > > Under my concept, all mail would still be signed in full. The weak > > signature would be in addition to the full signature and the intermediary > > would be expected to sign in full as well. If the original full signature > > is broken you are left with the original "weak signature" which > authorizes > > the intermediary and the full signature of the intermediary. > > Take another look at my old draft. Sounds like exactly the same plan. > I will. > > > I would expect there to be multiple potential approaches to identifying > > acceptable intermediaries. > > The harder part is to decide which intermediary gets to re-sign which > message at the time you apply the weak signature. > It would have be the domain in the "To" field. It wouldn't work with random unknown intermediaries. It would address the MLM issue as long as the MLM domain is the same as the "To" domain when the message was originally sent. It could also presumably work for vanity domains if they DKIM sign. It wouldn't work for forwards on the receiver side that the sender is unaware of. Michael Hammer --00000000000030be4c05adb75aa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 25, 2020 at 12:22 PM John= R Levine <johnl@ta= ugh.com> wrote:
On Tue, 25 Aug 2020, Dotzero wrote:
>> https://tools.ietf.org/html/dra= ft-levine-dkim-conditional-00?

> Under my concept, all mail would still be signed in full. The weak
> signature would be in addition to the full signature and the intermedi= ary
> would be expected to sign in full as well. If the original full signat= ure
> is broken you are left with the original "weak signature" wh= ich authorizes
> the intermediary and the full signature of the intermediary.

Take another look at my old draft.=C2=A0 Sounds like exactly the same plan.=

I will.

> I would expect there to be multiple potential approaches to identifyin= g
> acceptable intermediaries.

The harder part is to decide which intermediary gets to re-sign which
message at the time you apply the weak signature.
=C2= =A0
It would have be the domain in the "To" field.=C2=A0 It = wouldn't work with random unknown intermediaries. It would address the = MLM issue as long as the MLM domain is the same as the "To" domai= n when the message was originally sent. It could also presumably work for v= anity domains if they DKIM sign. It wouldn't work for forwards on the r= eceiver side that the sender is unaware of.

Michael Hammer

--00000000000030be4c05adb75aa0-- From nobody Tue Aug 25 11:13:54 2020 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 DBA463A0BDD for ; Tue, 25 Aug 2020 11:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Q7KN6lCe; dkim=pass (2048-bit key) header.d=taugh.com header.b=oeDrvbyi 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 8rE44bGrB4R6 for ; Tue, 25 Aug 2020 11:13:50 -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 AD1743A0BE3 for ; Tue, 25 Aug 2020 11:13:49 -0700 (PDT) Received: (qmail 59993 invoked from network); 25 Aug 2020 18:13:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=ea55.5f4554da.k2008; i=johnl-iecc.com@submit.iecc.com; bh=CGMHqONQ7PnRlZ6ub5DWG8Bc266aL5vVxI6LVEMtCrM=; b=Q7KN6lCeoJaSTy1qHyyi2kqhFfEyu7YhGLzrJUJPYbJCFoCafF0I/jBAYdqqMsLP3WGXqL8IchEkXwB9ZE2jRLn5gD/FCTyRHbFu587d3oFZRwt2Ne4DxjHDkSx24SgyAbgnyby0xOidY+dewinG7pOb2rfPG8QtL8gMYCfQM6ExEe05Tqr79W1MkiRZO9HZPTXUvi7jvF48YgfVnHaGp/UURCTZ1s5/lNhmtSeMCGAlhiLuD9mG+QWXkphwFj97+919Nn/6FL1HBQtVGbwtT/QiV0h4/mfcjmcbAST5wYoQNYgA8WMUi7Il/x+XVwHs6lCQPEE6bAnUj0lHM2j8dg== 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; s=ea55.5f4554da.k2008; olt=johnl-iecc.com@submit.iecc.com; bh=CGMHqONQ7PnRlZ6ub5DWG8Bc266aL5vVxI6LVEMtCrM=; b=oeDrvbyittp4Oa9mFK7O9n95YTmBTT0ZnxcnYSGg6pqt+cd4QAFsrn/V/t3uxyHWtVoDPfMnx/QI1KByS2kQnwNgtM22jF8VDYQsKm5L/gj4cwxP2TXQYs71CnmIWTurl0NzsCLVmfJ8wFkZi9KvUx8GhSeScM8Ff2pyY45OGsnyL/K2QOL2jiSYdPpNu+0dhyRtCmAR+1qY/EKGXwd9lg051D7Vap9Yoo3dKGWUjHaUWeSBuJw8zmtm5oVGUzcTzuJqCqMleJDlVMoisRMlV+bmVowGgcRfO+rlBjggOKEEqnztv4XHL1he1Kwo7TdR12RI8bi5qUGXyM9SI6XqvA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 25 Aug 2020 18:13:46 -0000 Date: 25 Aug 2020 14:13:46 -0400 Message-ID: <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> From: "John R Levine" To: "Dotzero" Cc: "IETF DMARC WG" In-Reply-To: References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 18:13:52 -0000 On Tue, 25 Aug 2020, Dotzero wrote: >>> I would expect there to be multiple potential approaches to identifying >>> acceptable intermediaries. >> >> The harder part is to decide which intermediary gets to re-sign which >> message at the time you apply the weak signature. > > It would have be the domain in the "To" field. It wouldn't work with > random unknown intermediaries. It would address the MLM issue as long as > the MLM domain is the same as the "To" domain when the message was > originally sent. It could also presumably work for vanity domains if they > DKIM sign. It wouldn't work for forwards on the receiver side that the > sender is unaware of. If the list is somelist@lists.foo.org, does the signature have to be d=lists.foo.org? How about d=foo.org? On the flip side, do you put a weak signature on all of your outgoing mail, which seems like a bad idea, or just mail that you expect to go through list modification? In the latter case, how do you tell? These are the scaling problems that I fear make this unworkable. 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 Aug 25 13:30:07 2020 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 B37243A0B93 for ; Tue, 25 Aug 2020 13:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 X5wx6s2WCyPm for ; Tue, 25 Aug 2020 13:30:04 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 1A8023A0B92 for ; Tue, 25 Aug 2020 13:30:04 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id p36so6697422qtd.12 for ; Tue, 25 Aug 2020 13:30:04 -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=OxUozbb4rtpRMVDEgxNSku3QbLeaotK6cdeaYuRB9hM=; b=SRJZqje2W6Uxt0NTdxEXw4XQmIj15rub0NH1s6fyNzfnFcL/7jlrZdSl32C4AVl9n+ 8O8QAHF1oFTyiVABbj2QAmiaKzjkREWgqiv6tYWgPBoWTLjKmXtrli+WJcNVICEepGs1 asXaBNQKTbZR8gti/hseYF43QTN4Rjq+joK8mTNA0fQD4iU5QiGweH1nkgmk71ghdoay 8kJEqd2S1URv8zYuVU4vteO+GccpHcQtZiG0u6ycL74XuQsTJHJnSrTaQIvA+SG1PCd1 496ElishWxqTnff9jhbkQQzJp8l3TdexiwdtjW+O/NlfxtVzibuyHx41zeg7jDqLvrSF VIPQ== 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=OxUozbb4rtpRMVDEgxNSku3QbLeaotK6cdeaYuRB9hM=; b=EsuIxsTmqK58wR31eLSZHqOq4RM0nsn0Emk5WCUiWcNiUFBwMNZt+UJC4Q4ujVy4ri MTYmhg0uuNAd7GrttGGiUvSdyty3ZjG6Be227k+tiJ1FLuJU+PM3JV2VqQFnLD08qtwN 5YTxfaDxCu/Lfl7GP5vL8QabY18r1cLHBTeCARya9iHTrgBkCDnCKO2FtawdU23yQ+lb gA7yrN5YB0lfH/aeXnhw4XyRRT9IO17n7Ib2n7qIkMnxFtinUn6jq/FpOl7SwWGv37la Zm3c03mi3MwWsgCm67jT0rH285C9HZ1AwLOHXupaWa+YfXNkrBBDLIo6/u2Rs4Q/h7qy JPng== X-Gm-Message-State: AOAM530SoVa4eWj8y66Vv6Y+CMHqjOhUnngzIe5XD1WMEQQ/rOr2lwnF sgEybbdGFbC54rXgU/wQQMjwAG2sDerzsq0LYnEdKXRDa+Q= X-Google-Smtp-Source: ABdhPJySv9vpejwBfAXD5ZZNZgtcj55OsdOIjXlPgPMCvGGNNd3pJgIobfzxGIkt3gXhY9h1YQOw95JsDidxWqqKjkQ= X-Received: by 2002:ac8:660f:: with SMTP id c15mr11297165qtp.34.1598387402985; Tue, 25 Aug 2020 13:30:02 -0700 (PDT) MIME-Version: 1.0 References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> In-Reply-To: <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> From: Dotzero Date: Tue, 25 Aug 2020 16:29:51 -0400 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005e57b605adb99134" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 20:30:06 -0000 --0000000000005e57b605adb99134 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 25, 2020 at 2:13 PM John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: > >>> I would expect there to be multiple potential approaches to identifying > >>> acceptable intermediaries. > >> > >> The harder part is to decide which intermediary gets to re-sign which > >> message at the time you apply the weak signature. > > > > It would have be the domain in the "To" field. It wouldn't work with > > random unknown intermediaries. It would address the MLM issue as long as > > the MLM domain is the same as the "To" domain when the message was > > originally sent. It could also presumably work for vanity domains if they > > DKIM sign. It wouldn't work for forwards on the receiver side that the > > sender is unaware of. > > If the list is somelist@lists.foo.org, does the signature have to be > d=lists.foo.org? How about d=foo.org? > This is something that would have to be thought through and discussed. I want to lean towards exact match but I could be convinced that the base organization signature would be acceptable as a starting point. I would recommend anyone coding this for signing to use a flag to easily switch between the two. I'd recommend that any intermediary doing signing consider using the CNAME approach so that all their lists can easily be signed with an exact match signature. This is one of the areas where implementation and operational considerations may differ from standards considerations. > > On the flip side, do you put a weak signature on all of your outgoing > mail, which seems like a bad idea, or just mail that you expect to go > through list modification? In the latter case, how do you tell? These > are the scaling problems that I fear make this unworkable. > I think only putting the weak signature on mail you expect to be modified would be the way to go. As I indicated in my previous post, there are multiple ways to address identifying which mail is likely to go through an intermediary. Large mail providers/data gatherers probably already have an awareness in this space. Others could probably create lists which could be checked realtime or updated/downloaded once or twice a day. Organizations could also enable self registration of intermediary use by their users. It might also be a combination of these approaches. I don't see this as an issue that makes scaling unworkable. There are plenty of folks checking for blocklists, how does this differ significantly either operationally or in scale? Michael Hammer --0000000000005e57b605adb99134 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 25, 2020 at 2:13 PM John = R Levine <johnl@taugh.com> wro= te:
On Tue, 25 A= ug 2020, Dotzero wrote:
>>> I would expect there to be multiple potential approaches to id= entifying
>>> acceptable intermediaries.
>>
>> The harder part is to decide which intermediary gets to re-sign wh= ich
>> message at the time you apply the weak signature.
>
> It would have be the domain in the "To" field.=C2=A0 It woul= dn't work with
> random unknown intermediaries. It would address the MLM issue as long = as
> the MLM domain is the same as the "To" domain when the messa= ge was
> originally sent. It could also presumably work for vanity domains if t= hey
> DKIM sign. It wouldn't work for forwards on the receiver side that= the
> sender is unaware of.

If the list is = somelist@lists.foo.org, does the signature have to be
d=3Dl= ists.foo.org?=C2=A0 How about d=3Dfoo.org?

This is something that would have to be thought through and discussed. I w= ant to lean towards exact match but I could be convinced that the base orga= nization signature would be acceptable as a starting point. I would recomme= nd anyone coding this for signing to use a flag to easily switch between th= e two. I'd recommend that any intermediary doing signing consider using= the CNAME approach so that all their lists can easily be signed with an ex= act match signature. This is one of the areas where implementation and oper= ational considerations may differ from standards considerations.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On the flip side, do you put a weak signature on all of your outgoing
mail, which seems like a bad idea, or just mail that you expect to go
through list modification?=C2=A0 In the latter case, how do you tell?=C2=A0= These
are the scaling problems that I fear make this unworkable.
=

I think only putting the weak signature on mail you exp= ect to be modified would be the way to go. As I indicated in my previous po= st, there are multiple ways to address identifying which mail is likely to = go through an intermediary.=C2=A0 Large mail providers/data gatherers proba= bly already have an awareness in this space. Others could probably create l= ists which could be checked realtime or updated/downloaded once or twice a = day. Organizations could also enable self registration of intermediary use = by their users. It might also be a combination of these approaches. I don&#= 39;t see this as an issue that makes scaling unworkable. There are plenty o= f folks checking for blocklists, how does this differ significantly either = operationally or in scale?

Michael Hammer
--0000000000005e57b605adb99134-- From nobody Tue Aug 25 15:09:58 2020 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 D3AF33A005E for ; Tue, 25 Aug 2020 15:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, 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=bluepopcorn.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 UZhjLAjx2CRz for ; Tue, 25 Aug 2020 15:09:55 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 14EEE3A0037 for ; Tue, 25 Aug 2020 15:09:55 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:65f9:e264:a836:6546]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07PM9roh025080 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 25 Aug 2020 15:09:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1598393394; bh=vdvgww9oj+/e36FNq/3hSzqXOIxirCyIjql1Vo0cPR0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GslVVRqZh+jX/zHirAH1/nBSaI/kF+0lngvDwf2jJiu9pt/85DRfc2oTZaZHR9IU2 ye6jx66Jv3TNI+yD4jcH6vHOv9vNegBt7loqTOa+FnJqOXNCu8GJCacbkTFeJSGeSz j8mofKwU87pvGcOtAnH+EyRXnQ3qYIOK9MGTwg+c= To: dmarc@ietf.org References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Tue, 25 Aug 2020 15:09:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 22:09:57 -0000 On 8/25/20 11:13 AM, John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: >>>> I would expect there to be multiple potential approaches to >>>> identifying >>>> acceptable intermediaries. >>> >>> The harder part is to decide which intermediary gets to re-sign which >>> message at the time you apply the weak signature. >> >> It would have be the domain in the "To" field.  It wouldn't work with >> random unknown intermediaries. It would address the MLM issue as long as >> the MLM domain is the same as the "To" domain when the message was >> originally sent. It could also presumably work for vanity domains if >> they >> DKIM sign. It wouldn't work for forwards on the receiver side that the >> sender is unaware of. > > If the list is somelist@lists.foo.org, does the signature have to be > d=lists.foo.org?  How about d=foo.org? > > This seems like an analogous situation to the DKIM i= flag, where the domain MUST be the same as, or a subdomain of, the value of the d= flag. So I'd recommend allowing d=foo.org. -Jim From nobody Tue Aug 25 19:39:53 2020 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 C86A53A0BC1 for ; Tue, 25 Aug 2020 19:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=UE+PYclp; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZHVmuOCk 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 kZ8DEPaxh6y7 for ; Tue, 25 Aug 2020 19:39:50 -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 4A3FC3A0BC2 for ; Tue, 25 Aug 2020 19:39:49 -0700 (PDT) Received: (qmail 64462 invoked from network); 26 Aug 2020 02:39:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fbcc.5f45cb74.k2008; bh=9wuKhYLFFgK714/Wx76MPSPPuXxcOmHFiQZcuSZGZr0=; b=UE+PYclpYLQMiPwE8kLTmbpMn072W+GUHgDsz6J8+yAY4xQ+t9RzsqemhSOYh2eM0igIfG6pgXBa/2ysng7YbMclpbXgHsQSSuaBSnrvVMcXDbFm+IHx7dpfOm9gMjEfAa+QDm4pZv9CLlCbxwu5YI7uNSVi1Hc6YiI3RjIM2xjfTmUhcqVDgXRg3AIhJiBenFKrsIUzqR5sGF0cQxfqggHtyGZeoXyieJS4rDkS4k1hlyor12wqZa/89/Zww0rsyNxvgmDbLyVe+Hsudl8VY2+5ui8xYw89FP8e1UpVhSGyTQyKj8H32P1dP7Z06XHCAvTzkDX74SNJFwWoNO8Xiw== 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=fbcc.5f45cb74.k2008; bh=9wuKhYLFFgK714/Wx76MPSPPuXxcOmHFiQZcuSZGZr0=; b=ZHVmuOCk/H2W6r0AGRjMR+yT9ELLVe/ymEfpqMzxdJR1UY7h613Owbmh9Au4E89yll5iVQQ604QK2yAdUJ4MKAgjn5uZpkYy+C0Mi5SDs29pIvPO+SgQ/KZdFYzT6nWQFvTe6Bdjf0hHRjNtDQJnqrNRru3kf9Ov/ljHYmQ/Unhe6nSJvhOKtEkwrLjRsym5Rj+55nbm5jKEP3Wxi+ueUHV/DVIsyHRx0xHDdnN4zNPx8nbX3X8pXE9LIv3hIb6zngBF4vA/Yro9ln2RRRWLBJvwrFEBmPCwiLJlsCYHZGRDNaRJJEsR4kAMGxbTVy+yZl/gcWrZp1ti7SS11tg2Yw== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 26 Aug 2020 02:39:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 4215E1F294FC; Tue, 25 Aug 2020 22:39:48 -0400 (EDT) Date: 25 Aug 2020 22:39:48 -0400 Message-Id: <20200826023948.4215E1F294FC@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: fenton@bluepopcorn.net 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] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 02:39:52 -0000 In article you write: >> If the list is somelist@lists.foo.org, does the signature have to be >> d=lists.foo.org?  How about d=foo.org? >> >This seems like an analogous situation to the DKIM i= flag, where the >domain MUST be the same as, or a subdomain of, the value of the d= flag. >So I'd recommend allowing d=foo.org. Well, OK, how about d=org? This is the opposite of i=, superdomains rather than subdomains. R's, John PS: I realize .org isn't likely to be signing anything, there are 25 TLDs with top level MX or A records that plausibly could. From nobody Wed Aug 26 09:36:33 2020 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 23E2D3A16C7 for ; Wed, 26 Aug 2020 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.948, 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=bluepopcorn.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 yX8ucQx3pd03 for ; Wed, 26 Aug 2020 09:36:31 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 18D783A16C6 for ; Wed, 26 Aug 2020 09:36:31 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:4400:9fb0:cd15:4338:ab5f:9981]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07QGaT4g011162 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 26 Aug 2020 09:36:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1598459790; bh=23g7iSmfxTxOZ1mmUuDBWMGDOnBO+hf6Z4s8/TB2KSo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dJpI62ftM1rryNhJoDP/cBQRVooq1+QO8OWLTfPnTrgQlecW3bh4aNRaqSA1Au9hG 9F46ERkuM7CxfG8dTzApP6U5FFJlSamXWDLR4meNCgjJ9T9JmoXJo9tOv/WBPPoiaP jFyGJEwQS4Y0oNv4DhuLf8O/g6fxuywcg0ShLSGs= To: dmarc@ietf.org References: <20200826023948.4215E1F294FC@ary.qy> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: Date: Wed, 26 Aug 2020 09:36:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200826023948.4215E1F294FC@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 16:36:32 -0000 On 8/25/20 7:39 PM, John Levine wrote: > In article you w= rite: >>> If the list is somelist@lists.foo.org, does the signature have to be >>> d=3Dlists.foo.org?=C2=A0 How about d=3Dfoo.org? >>> >> This seems like an analogous situation to the DKIM i=3D flag, where th= e >> domain MUST be the same as, or a subdomain of, the value of the d=3D f= lag. >> So I'd recommend allowing d=3Dfoo.org. > Well, OK, how about d=3Dorg? This is the opposite of i=3D, superdomain= s rather than subdomains. I see it as being in the same direction as i=3D, because we're talking about being able to sign with a superdomain of [whatever identifier] in both cases. But it doesn't really matter. In principle, d=3Dorg would work too. The identified domain (list domain,= i=3D, whatever) always has to trust all higher level domains: because the= y delegate the DNS to the lower level, they could in principle add their own selector records if they wanted to spoof the subdomain. But I haven't ever heard of that being a problem. -Jim From nobody Wed Aug 26 09:58:33 2020 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 7CB813A1720 for ; Wed, 26 Aug 2020 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Ug7UK1hV27-8 for ; Wed, 26 Aug 2020 09:58:28 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 23C683A1727 for ; Wed, 26 Aug 2020 09:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598461102; bh=DQOnyrKc43LdjOhGIboTN+kDnPuJYb8bcnbb+HfQyVg=; l=3806; h=To:Cc:References:From:Date:In-Reply-To; b=Bc0TdIfqQ1EDQIedPg2o9kbWPTCxgocayScDWQ5nGUyQ1IeGzz8M8uGUUFHVkg9ez 2ScdN8ZJyCHwEy+iQQ3/4wYYw4HjG3e7DJqA9DZ2l7JNgfu83LetZT4cP7hyIYbQUh nyPMFGwccoDT/9KtAXf6mH71vUgCiS210BANiP2HcQ23RqM6IarOviltUGRIy 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, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F4694AE.00006FA9; Wed, 26 Aug 2020 18:58:22 +0200 To: John R Levine , Dotzero Cc: IETF DMARC WG References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> From: Alessandro Vesely Message-ID: Date: Wed, 26 Aug 2020 18:58:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <13aa3f6f-df8-4ea-c075-9a1e885b28da@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 16:58:31 -0000 On Tue 25/Aug/2020 20:13:46 +0200 John R Levine wrote: > On Tue, 25 Aug 2020, Dotzero wrote: >>>> I would expect there to be multiple potential approaches to identifying >>>> acceptable intermediaries. >>> >>> The harder part is to decide which intermediary gets to re-sign which >>> message at the time you apply the weak signature. >> >> It would have be the domain in the "To" field.  It wouldn't work with >> random unknown intermediaries. It would address the MLM issue as long as >> the MLM domain is the same as the "To" domain when the message was >> originally sent. It could also presumably work for vanity domains if they >> DKIM sign. It wouldn't work for forwards on the receiver side that the >> sender is unaware of. > > If the list is somelist@lists.foo.org, does the signature have to be > d=lists.foo.org?  How about d=foo.org? > > On the flip side, do you put a weak signature on all of your outgoing mail, > which seems like a bad idea, or just mail that you expect to go through list > modification?  In the latter case, how do you tell?  These are the scaling > problems that I fear make this unworkable. https://tools.ietf.org/html/draft-levine-dkim-conditional-03#section-4.1 looks quizzical. It says: A small sender that doesn't know which of its mail recipients are likely to be forwarders might put a weak signature on all outgoing mail, in the expectation that few of its users correspondents are likely to be malicious. If a sender has no idea, what domain would it put in fs=, the recipient's domain? That entails that a signing filter acts in an advanced SMTP step, where the connection to the MX is established and the receiving domain known. Also, in the previous paragraph: A sender that expects a message to be forwarded might put both a conventional DKIM signature and a signature with a !fs tag that refers to the domain name of the expected forwarder. That signature would typically be a "weak" signature that covers the From, To, Date, and Message-ID headers but does not cover the Subject header or the message body, so that it would remain valid even if a forwarder made changes typical of forwarders such as mailing lists. I understand that nobody can prevent a sender to put a conventional DKIM signature, even if it expects the message to be forwarded. However, if the scenario gets upgraded so as to consider that the sender /knows/ that the message is going to be forwarded, then the conventional signature is pretty useless, as forwarding will break it. How about this: A sender that expects a message to be forwarded might well skip putting a conventional DKIM signature and put just a signature with a !fs tag that refers to the domain name of the expected forwarder. That signature would typically be a "weak" signature that covers the From, Date, and Message-ID headers but does not cover the Subject, To, or Cc header fields, nor the message body. (To: and Cc: are often reordered, which breaks signatures.) Finally, IMHO the Security Consideration section should compare using !fs= versus plain weak signatures. In particular, consider senders who carefully avoid to send out weak signatures except for trusted (forwarding) recipients. Would it be advisable to put both a plain weak signature and a signature with !fs=? Plain weak signatures might be discarded by recipients with local policies about l=, while v=man signatures might be discarded by unupgraded verifiers. Putting two signatures together is rather common in the presence of new features, e.g. those who use elliptic keys do so. What is the difference between the risks brought on by each kind of weak signature? Answering such question justifies the version change. Best Ale -- From nobody Wed Aug 26 10:31:54 2020 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 357103A18F7 for ; Wed, 26 Aug 2020 10:31:52 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7iPwExYCPbc for ; Wed, 26 Aug 2020 10:31:47 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFB43A18E4 for ; Wed, 26 Aug 2020 10:31:43 -0700 (PDT) X-ASG-Debug-ID: 1598463101-11fa31095ed63a0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 4CEQ5ajY3CEdPNu7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 26 Aug 2020 13:31:41 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=3IdO+dfYAyAOXrfJP9MtDw8Bcbu2RvUNTs1vRm9BZxg=; b=AMuce1H0TsFyNEeP3vbS+iRM3yM3ZZ+hXoY4PzifFTkWuWAe418EdLFZ0kuKcu51s /yozKBS2fJRTLAoJJfLZNMrSPq/m3aWkaS1PDIxy40dPZZlw1bMoHTIucrFT63++G gH9cEfcxX75LRoDOUp26yCkbb3LHgF4HaYxmxgPN8= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 26 Aug 2020 13:31:32 -0400 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF DMARC WG'" References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> In-Reply-To: Date: Wed, 26 Aug 2020 13:31:33 -0400 X-ASG-Orig-Subj: RE: [dmarc-ietf] third party authorization, not, was non-mailing list Message-ID: <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D67BAD.36E89860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJgB1D2dINlKlh07HGwpTB1qO3hiQK/ySKcAn/sJpADPLdKZwI+DOKsp+G6xwA= Content-Language: en-us X-Exim-Id: 001801d67bce$bdf97510$39ec5f30$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1598463101 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 6840 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84181 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 17:31:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01D67BAD.36E89860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are the weak signatures vulnerable to a replay attack? I thought that = one of the reasons that DKIM signatures included the whole body was to = prevent the signature from being reused. =20 DF =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dotzero Sent: Tuesday, August 25, 2020 1:51 PM To: John R Levine Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] third party authorization, not, was = non-mailing list =20 =20 =20 On Tue, Aug 25, 2020 at 12:22 PM John R Levine wrote: On Tue, 25 Aug 2020, Dotzero wrote: >> https://tools.ietf.org/html/draft-levine-dkim-conditional-00? > Under my concept, all mail would still be signed in full. The weak > signature would be in addition to the full signature and the = intermediary > would be expected to sign in full as well. If the original full = signature > is broken you are left with the original "weak signature" which = authorizes > the intermediary and the full signature of the intermediary. Take another look at my old draft. Sounds like exactly the same plan. =20 I will.=20 > I would expect there to be multiple potential approaches to = identifying > acceptable intermediaries. The harder part is to decide which intermediary gets to re-sign which=20 message at the time you apply the weak signature. =20 It would have be the domain in the "To" field. It wouldn't work with = random unknown intermediaries. It would address the MLM issue as long as = the MLM domain is the same as the "To" domain when the message was = originally sent. It could also presumably work for vanity domains if = they DKIM sign. It wouldn't work for forwards on the receiver side that = the sender is unaware of. =20 Michael Hammer =20 ------=_NextPart_000_0019_01D67BAD.36E89860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Are the weak signatures vulnerable to a replay = attack?=C2=A0=C2=A0=C2=A0 I thought that one of the reasons that DKIM = signatures included the whole body was to prevent the signature from = being reused.

 

DF

 

From:= = dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of = Dotzero
Sent: Tuesday, August 25, 2020 1:51 = PM
To: John R Levine
Cc: IETF DMARC = WG
Subject: Re: [dmarc-ietf] third party authorization, not, = was non-mailing list

 

 

 

On = Tue, Aug 25, 2020 at 12:22 PM John R Levine <johnl@taugh.com> = wrote:

On Tue, = 25 Aug 2020, Dotzero wrote:
>> https://tools.ietf.org/html/draft-levine-dkim-condition= al-00?

> Under my concept, all mail would still be signed = in full. The weak
> signature would be in addition to the full = signature and the intermediary
> would be expected to sign in full = as well. If the original full signature
> is broken you are left = with the original "weak signature" which authorizes
> = the intermediary and the full signature of the intermediary.

Take = another look at my old draft.  Sounds like exactly the same = plan.

 

I = will.


> = I would expect there to be multiple potential approaches to = identifying
> acceptable intermediaries.

The harder part is = to decide which intermediary gets to re-sign which
message at the = time you apply the weak signature.

 

It = would have be the domain in the "To" field.  It wouldn't = work with random unknown intermediaries. It would address the MLM issue = as long as the MLM domain is the same as the "To" domain when = the message was originally sent. It could also presumably work for = vanity domains if they DKIM sign. It wouldn't work for forwards on the = receiver side that the sender is unaware of.

 

Michael Hammer

 

------=_NextPart_000_0019_01D67BAD.36E89860-- From nobody Wed Aug 26 10:54:23 2020 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 4E5143A194D for ; Wed, 26 Aug 2020 10:54:21 -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, 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 WOR-opmrTQ-P for ; Wed, 26 Aug 2020 10:54:20 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 290B83A1800 for ; Wed, 26 Aug 2020 10:54:20 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id x69so2838824qkb.1 for ; Wed, 26 Aug 2020 10:54:20 -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=B5VGHx2YteIDGNN5FbTec6OkFNMBrU2McDu2cezc4jI=; b=Qb7Xv7G5u6ySY7N8usMyms5SLuL0aR+IOit4HAnJRp2F9tuksCxkNTa2Xgx+puQQMP cGC+sM+BOMwZQdYIqJX83stkK7IzmFh7X6ZL1RoTlRrLvEQTg/a4adiy9pZ+bRq/4cnq /mOZIAXGCR9MmK6gRQWXOxUxdl4NSsOmdccrKdP6HzkgKTwXMvHrDtgCfVoLshj3wXew nrA4QTw9qO5vEsBNZo052Yj0BnvNRwDnAVEAsI3eJMIiZhd7ttK7evLeGX2xf7D2fKOX kNQ3f60IHsxHx9vfqFmBVMjmmsuPrxjV803DnmpCy80+Umb8osXoJzl+l3J03OKzjkLT 9WhQ== 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=B5VGHx2YteIDGNN5FbTec6OkFNMBrU2McDu2cezc4jI=; b=J9UrsbzKBUYqsqW5IKfWKFCJi9Wa02Z66WQAV7zaSPULSbkXGLygKE4t1hB+uwmDV5 efdiRhaz9JfUzqx3M/2SRubSHBItWe/yiDO6AsiSRWlfjSV51OenoI+bxDfIyJlX4eEU ZYk3VKQzJtVmIVVrmgKtaQsYUVRZZOwxtCGwg1IpDvniHkbkgoI6ce7RlTIT3kgjQjXR DiNOI7kXWY4tn4F822C+2WsU6NrWdaqqownf135fjv86rYCkMcvbgzmH5/GdZPtKkhwy C0WL/wJrYXaZ0mHxCK9VLWO5lilIil2QKCR7r+vEFaCT4GB+/gTmBTV9TU9ae+SOK9L3 pQZg== X-Gm-Message-State: AOAM532MgLFXRCsNfEIWDZqBTqOI7F2GAcQcxAjUdON2PeOWlv6FkFkB g6+k4wlkfi9ma6Vbbmwt7C9afCHMg2O5dHvmLR7+b9jw1H0= X-Google-Smtp-Source: ABdhPJzpUpdAPSnVVcnPbLw8/PaaZk5LMrjdCquxfnYpxPVEfEVJp495wMbPwzMfeypJdYfWDcAt07IU5d9Iy5QD7n4= X-Received: by 2002:a37:a9cb:: with SMTP id s194mr15257407qke.64.1598464459186; Wed, 26 Aug 2020 10:54:19 -0700 (PDT) MIME-Version: 1.0 References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> In-Reply-To: <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> From: Dotzero Date: Wed, 26 Aug 2020 13:54:08 -0400 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000046a88c05adcb82f7" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 17:54:21 -0000 --00000000000046a88c05adcb82f7 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 26, 2020 at 1:32 PM Doug Foster wrote: > Are the weak signatures vulnerable to a replay attack? I thought that > one of the reasons that DKIM signatures included the whole body was to > prevent the signature from being reused. > > > > DF > Not particularly vulnerable. The requirement is that you have the "weak signature" plus the intermediary full DKIM signature. This let's the validator/receiver know that the originating domain knew that the intermediary might break the originating domains DKIM signature but the validator/receiver would have the DKIM signature of the intermediary. The "weak signature" is only validated against that specific message and headers it signed and that specific intermediary. It's not a generic/general signature. Michael Hammer --00000000000046a88c05adcb82f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 26, 2020 at 1:32 PM Doug = Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:

Are the weak signatures vuln= erable to a replay attack?=C2=A0=C2=A0=C2=A0 I thought that one of the reas= ons that DKIM signatures included the whole body was to prevent the signatu= re from being reused.

=C2=A0

DF

=

Not particularly vulnerable. The requirement is that yo= u have the "weak signature" plus the intermediary full DKIM signa= ture. This let's the validator/receiver know that the originating domai= n knew that the intermediary might break the originating domains DKIM signa= ture but the validator/receiver would have the DKIM signature of the interm= ediary. The "weak signature" is only validated against that speci= fic message and headers it signed and that specific intermediary. It's = not a generic/general signature.

Michael Hamm= er

--00000000000046a88c05adcb82f7-- From nobody Wed Aug 26 14:00:39 2020 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 1D4A03A0138 for ; Wed, 26 Aug 2020 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 lYWDWzPK68xm for ; Wed, 26 Aug 2020 14:00:37 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 0F9C53A0121 for ; Wed, 26 Aug 2020 14:00:37 -0700 (PDT) Received: from steel.bluepopcorn.net ([IPv6:2601:647:4400:1261:8943:d470:4d35:1cd2]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07QL0Xeb015176 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 26 Aug 2020 14:00:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1598475635; bh=a6i96l/dYlY+yYk+GrI9NPzD8MK2ZkYd5OZLSgB99Fs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=IK0EjHxCr4kalc6s0XQOi9MFe6CeMQgsjdq1vYSawYrWzTK1ixsRaaRvDgrMuRZDy iN/ulAio5MAHUWJypUKKwAe8sPkiy1Fol+XYExBIfUwx/dbTpxFckbPyNa/i4HF1Wo YlwQcmUZcNDyVUKxgdw2J6TYBZze5N4ZCkuTKPgU= To: Dotzero , Doug Foster Cc: IETF DMARC WG References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> Date: Wed, 26 Aug 2020 14:00:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7603E66535EA77E05D339AF1" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 21:00:38 -0000 This is a multi-part message in MIME format. --------------7603E66535EA77E05D339AF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 8/26/20 10:54 AM, Dotzero wrote: > > > On Wed, Aug 26, 2020 at 1:32 PM Doug Foster > > wrote: > > Are the weak signatures vulnerable to a replay attack?    I > thought that one of the reasons that DKIM signatures included the > whole body was to prevent the signature from being reused. > >   > > DF > > > Not particularly vulnerable. The requirement is that you have the > "weak signature" plus the intermediary full DKIM signature. This let's > the validator/receiver know that the originating domain knew that the > intermediary might break the originating domains DKIM signature but > the validator/receiver would have the DKIM signature of the > intermediary. The "weak signature" is only validated against that > specific message and headers it signed and that specific intermediary. > It's not a generic/general signature. It sounds like the weak signature is just a regular DKIM signature plus the designation of the intermediary, and the "weak" part is that you don't check the body hash against the body. Have I got that right? -Jim --------------7603E66535EA77E05D339AF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/26/20 10:54 AM, Dotzero wrote:


On Wed, Aug 26, 2020 at 1:32 PM Doug Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org> wrote:

Are the weak signatures vulnerable to a replay attack?    I thought that one of the reasons that DKIM signatures included the whole body was to prevent the signature from being reused.

 

DF


Not particularly vulnerable. The requirement is that you have the "weak signature" plus the intermediary full DKIM signature. This let's the validator/receiver know that the originating domain knew that the intermediary might break the originating domains DKIM signature but the validator/receiver would have the DKIM signature of the intermediary. The "weak signature" is only validated against that specific message and headers it signed and that specific intermediary. It's not a generic/general signature.


It sounds like the weak signature is just a regular DKIM signature plus the designation of the intermediary, and the "weak" part is that you don't check the body hash against the body. Have I got that right?

-Jim


--------------7603E66535EA77E05D339AF1-- From nobody Wed Aug 26 14:32:23 2020 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 4E51E3A0839 for ; Wed, 26 Aug 2020 14:32:22 -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, 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 f2N5AyX-ZnNN for ; Wed, 26 Aug 2020 14:32:20 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 B2BF73A0836 for ; Wed, 26 Aug 2020 14:32:20 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id o2so1643906qvk.6 for ; Wed, 26 Aug 2020 14:32:20 -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=gcGzZ3I4HT1l78o3ehhK5QnB38EQbFdVyhjoQ99OhDc=; b=dJQenbpoW+q3vbw0MAxiehdfi6Q+TkPEQLbZMD3w27JW3m2ftKG5zVxUmjeskLSX+t mL4QErr5t3NgfAJ/bhCPis7t+gnWMcVNiRXjx/iLsgjJbhsGfB6LTMK0dbmPND7B3kAm kZbHAdKGK+Ize++fDeAkCebfCQtJFx5+o8eP+jcYl3WhRhuK0sI+7wLcgpeFZnDidQ3s 6dSSGSYp2+0fX70fw1/67GHyrhkmXptgMpmFY14BmelmH9Szkyb4gyERXTRuoaOPY0vf +PyJbagCXK+Zq77CBm1sWQiZ1G2prLfn+MXiZ3GzbtPBaGOf6wpGOLIcomWe15asCg/8 5SuQ== 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=gcGzZ3I4HT1l78o3ehhK5QnB38EQbFdVyhjoQ99OhDc=; b=RkkNTB2Zye3gzbSXdfcsENQ8Sj1Dm9LlaAnylXS7bS1DT+atcMkYP5IC2KhHi04VXk 0Kw08FHzPdxpklkkLMP3K7dhhvmwpcY4Hmc2fWD9/oCnmk2nhbc+MzfbqXo78giJ/ZJo raDSOXUrhUHuAZUxfqhgECyMhfwnS1L9zeYlfJ/Y6YVnDVWXNpWspvC3HMWkx91DpmZn Z+UDLkIH5CNLQGrlXtxJl3PYHyyeMB7Tm85Fd+cCHke0azYt9ECR0XPB1vz9EqVXnWM+ eJd5x89jJANGSF23cBG7Y3gzveLVR0EnkLIUIjalNYuFFOHgXuNTorSRalH2rfDzSXkz MpKQ== X-Gm-Message-State: AOAM530RlUjQi+jFmKuGRA/j5jGE3tMabNdcmlK/4bBRC9T5LrhXURmY HQR2EjM6hee6WGj1vOpV9kXbvMhy0h33jXJcLoW9vSJlcwk= X-Google-Smtp-Source: ABdhPJw2NUcfoiUvd3osHOXvYr0aAiCCF7GrJX8BFYanUzltbAiwVY62ChIUy8FcexzvqxxQW6DhxQgK/OpT74opv6k= X-Received: by 2002:a0c:8b5d:: with SMTP id d29mr15593001qvc.172.1598477539863; Wed, 26 Aug 2020 14:32:19 -0700 (PDT) MIME-Version: 1.0 References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> In-Reply-To: <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> From: Dotzero Date: Wed, 26 Aug 2020 17:32:10 -0400 Message-ID: To: Jim Fenton Cc: Doug Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f1eed905adce8d81" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 21:32:22 -0000 --000000000000f1eed905adce8d81 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 26, 2020 at 5:00 PM Jim Fenton wrote: > On 8/26/20 10:54 AM, Dotzero wrote: > > > > On Wed, Aug 26, 2020 at 1:32 PM Doug Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> Are the weak signatures vulnerable to a replay attack? I thought that >> one of the reasons that DKIM signatures included the whole body was to >> prevent the signature from being reused. >> >> >> >> DF >> > > Not particularly vulnerable. The requirement is that you have the "weak > signature" plus the intermediary full DKIM signature. This let's the > validator/receiver know that the originating domain knew that the > intermediary might break the originating domains DKIM signature but the > validator/receiver would have the DKIM signature of the intermediary. The > "weak signature" is only validated against that specific message and > headers it signed and that specific intermediary. It's not a > generic/general signature. > > > It sounds like the weak signature is just a regular DKIM signature plus > the designation of the intermediary, and the "weak" part is that you don't > check the body hash against the body. Have I got that right? > > -Jim > Not exactly. The intermediary can check the full DKIM signature. The ultimate validator/receiver can check the full DKIM signature of the intermediary plus the "small" signature (I'm not comfortable with the phrase "weak signature") of the originator. If the original DKIM signature gets broken by the known intermediary then you have a mechanism to identify that the originator recognized the intermediary. This is not my preferred approach but I'm trying to find something that works to accommodate the various needs/wants expressed on the list. In my perfect world the intermediary would change it's behavior but that isn't going to happen. This is more straight forward than many of the other suggestions I've seen. Hat tip to John for his original idea for this approach. I'd be interested in seeing if any of the larger players (receivers) would be willing to utilize this sort of approach. Also, if anyone (organization) would be willing to provide a list of known intermediaries on some basis (whether free or pay). If these two things are in place then it is certainly worth exploring this approach in more detail. Michael Hammer --000000000000f1eed905adce8d81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 26, 2020 at 5:00 PM Jim F= enton <fenton@bluepopcorn.net<= /a>> wrote:
=20 =20 =20
On 8/26/20 10:54 AM, Dotzero wrote:
=20


On Wed, Aug 26, 2020 at 1:3= 2 PM Doug Foster <fosterd=3D40bayviewphysicians.com@dmarc.iet= f.org> wrote:

Are the weak signatures vulnerable to a replay attack?=C2=A0=C2=A0=C2=A0 I thought that one of the rea= sons that DKIM signatures included the whole body was to prevent the signature from being reused.

=C2= =A0

DF


Not particularly vulnerable. The requirement is that you have the "weak signature" plus the intermediary full = DKIM signature. This let's the validator/receiver know that the originating domain knew that the intermediary might break the originating domains DKIM signature but the validator/receiver would have the DKIM signature of the intermediary. The "weak signature" is only validated = against that specific message and headers it signed and that specific intermediary. It's not a generic/general signature= .


It sounds like the weak signature is just a regular DKIM signature plus the designation of the intermediary, and the "wea= k" part is that you don't check the body hash against the body. Have I got that right?

-Jim

Not exactly. The intermediary can ch= eck the full DKIM signature. The ultimate validator/receiver can check the = full DKIM signature of the intermediary plus the "small" signatur= e (I'm not comfortable with the phrase "weak signature") of t= he originator. If the original DKIM signature gets broken by the known inte= rmediary then you have a mechanism to identify that the originator recogniz= ed the intermediary. This is not my preferred approach but I'm trying t= o find something that works to accommodate the various needs/wants expresse= d on the list. In my perfect world the intermediary would change it's b= ehavior but that isn't going to happen. This is more straight forward t= han many of the other suggestions I've seen. Hat tip to John for his or= iginal idea for this approach. I'd be interested in seeing if any of th= e larger players (receivers) would be willing to utilize this sort of appro= ach. Also, if anyone (organization) would be willing to provide a list of k= nown intermediaries on some basis (whether free or pay). If these two thing= s are in place then it is certainly worth exploring this approach in more d= etail.

Michael Hammer
--000000000000f1eed905adce8d81-- From nobody Sat Aug 29 12:42:52 2020 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 8564E3A0F99 for ; Sat, 29 Aug 2020 12:42:50 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il1GTBzzsRwI for ; Sat, 29 Aug 2020 12:42:48 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8863A0F93 for ; Sat, 29 Aug 2020 12:42:48 -0700 (PDT) X-ASG-Debug-ID: 1598730164-11fa31165b2ebf0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id hVrcyZx57sFdFZeZ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 29 Aug 2020 15:42:45 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=5g/KJSXBS2acSyN5K26iJnQXCJoLPMZl9NfUWLHQsuY=; b=CG573yWTG5zXNmvLBweMbcWPfE0BGUuSyqynQVfiov5CdchwpQMlO+GWH0FZmmnHi Ms9vMFKN4oiIpBZ04jnqSm+x3mgNTixQL8Z+orTNfxPeS5X2hRURV8xwG3E5kGj2H NzRoCVqRP5XbKJCTA98gVpyRrWMHgtTEjZqzfcUr0= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 29 Aug 2020 19:42:36 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Reply-To: fosterd@bayviewphysicians.com Message-ID: <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=e6762da219814772a2eba7f9c5535443 In-Reply-To: <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> X-Exim-Id: 613173c7fdfb4b40afdd80e2354f5042 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1598730165 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5950 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84255 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 19:42:51 -0000 This is a multipart message in MIME format. --e6762da219814772a2eba7f9c5535443 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To elaborate on my question and Michael Hammer's answer: To be unique, a signature needs a unique dataset from which the hash is com= puted. The weak signature will not be unique because it will be computed = on non-random content such as From, To, and Date. However, the signature can only be used by the designated domain. So the = worst possible "misuse" would be for the designated domain to use the signa= ture on other messages. This seems unlikely, and the worst-case use is no= different than what ATSP would authorize. But the weak signature has les= s information leakage, since nothing is published in DNS about the signatur= e technique. So I agree that the approach is a good one for those who wan= t to provide mailing-list authorization. The remaining challenge is to communicate between recipient domains and mai= ling lists so that the list knows whether the recipient will honor the weak= signature system. Doug Foster ---------------------------------------- From: Jim Fenton Sent: 8/26/20 5:01 PM To: Dotzero Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing l= ist On 8/26/20 10:54 AM, Dotzero wrote: On Wed, Aug 26, 2020 at 1:32 PM Doug Foster wrote: Are the weak signatures vulnerable to a replay attack? I thought that on= e of the reasons that DKIM signatures included the whole body was to preven= t the signature from being reused. DF Not particularly vulnerable. The requirement is that you have the "weak sig= nature" plus the intermediary full DKIM signature. This let's the validator= /receiver know that the originating domain knew that the intermediary might= break the originating domains DKIM signature but the validator/receiver wo= uld have the DKIM signature of the intermediary. The "weak signature" is on= ly validated against that specific message and headers it signed and that s= pecific intermediary. It's not a generic/general signature. It sounds like the weak signature is just a regular DKIM signature plus the= designation of the intermediary, and the "weak" part is that you don't che= ck the body hash against the body. Have I got that right? -Jim --e6762da219814772a2eba7f9c5535443 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
To elaborate on my= question and Michael Hammer's answer:

To be uniqu= e, a signature needs a unique dataset from which the hash is computed. &nbs= p; The weak signature will not be unique because it will be computed on non= -random content such as From, To, and Date.

Howeve= r, the signature can only be used by the designated domain.   So the w= orst possible "misuse" would be for the designated domain to use the signat= ure on other messages.   This seems unlikely, and the worst-case use i= s no different than what ATSP would authorize.   But the weak signatur= e has less information leakage, since nothing is published in DNS about the= signature technique.   So I agree that the approach is a good one for= those who want to provide mailing-list authorization.

=
The remaining challenge is to communicate between recipient domains an= d mailing lists so that the list knows whether the recipient will honor the= weak signature system.

Doug Foster

=



From:= Jim Fenton <fenton@bluepopcorn.net>
Sent: 8/26/2= 0 5:01 PM
To: Dotzero <dotzero@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing li= st
On 8/26/20 10:54 AM, Dotzero = wrote:


On Wed, Aug 26, 2020 at 1:32 PM Doug Foster <fosterd=3D40bayviewp= hysicians.com@dmarc.ietf.org> wrote:
Are the weak signatur= es vulnerable to a replay attack?    I thought that one of t= he reasons that DKIM signatures included the whole body was to prevent the = signature from being reused.

 

DF


=
Not particularly vulnerable. The requirement is that you have the "wea= k signature" plus the intermediary full DKIM signature. This let's the vali= dator/receiver know that the originating domain knew that the intermediary = might break the originating domains DKIM signature but the validator/receiv= er would have the DKIM signature of the intermediary. The "weak signature" = is only validated against that specific message and headers it signed and t= hat specific intermediary. It's not a generic/general signature.


It sounds like the weak signature is just= a regular DKIM signature plus the designation of the intermediary, and the= "weak" part is that you don't check the body hash against the body. Have I= got that right?

-Jim


--e6762da219814772a2eba7f9c5535443-- From nobody Sat Aug 29 13:12:22 2020 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 E48E13A0FBA for ; Sat, 29 Aug 2020 13:12:20 -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, 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 ew6ml2vEiCTI for ; Sat, 29 Aug 2020 13:12:19 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 083143A0FB8 for ; Sat, 29 Aug 2020 13:12:19 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id e7so2133379qtj.11 for ; Sat, 29 Aug 2020 13:12:18 -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=VVPjqxaCdu74xMLB5vFAnDogBUEPTI/5BE0nyJw/tlg=; b=rprlmrbsgOIr+pxaxdZkmjy+Q79rvrBPxrvop3FmX3HYc3tyL9+GcAKZn/may2LnJP a57RyEyXXfDvcCgW+DQ3aidSYAkBDzbqhnVRgoeklQGVaZFzS3qifqFC9XsYvI7/aBcI LyQNPqiXyjXjYdbAffjVoEla1O9BpQaQ+yzEtZaZUnxbMOdhO56nRuYN5JU1TSXee6vc 4aRWxXp8k4uDfysn3u1v8CxURjMSEggEHZlmZ6Mzwfiz7ktmEgCHO9Q3j/gSHBGZdp/T LHDgii7XZuyOkGzsVKiInWL40IhSbdsVNjVaGFGp7Wxl/mO5xnxs4JfBBNvJINUWlvQn +/vQ== 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=VVPjqxaCdu74xMLB5vFAnDogBUEPTI/5BE0nyJw/tlg=; b=r6KuEfN2Th9cyeVnvOTH+yO59eDdcAH98SrdhmFYeMqpTTR8qgXLk8ZYqMZLFhcUq8 ggx3ZF2EoXJmb66YpXb4eBTn+mSiHOE3MMfJJaNhvyYYS05mONsemiYGRtCn6dVBPHvS ExjfIV/ayVES4aHWyx407y7TZGDRjhFHSPtkBnPyzUz99JotzQrjfXK+A4P/8Reo5u+x DyuL//6e5K/Wl8M2uqBdcPUvyUcy1ToJIX+CUa/biD+DzSPlkw7pGAzCWSm4a0h8HPFH ajeHYA+6F73vEy0QmGgG8MWfdHJ3Fq17D9ZP/VUrWFNlGeO8Uy4H/vwUqGvC2V46AyOv EFBg== X-Gm-Message-State: AOAM531Y5M64U+ATIYsUxFukknNwsX/Z0KpcCeQt/IQ8Cnj/W8RT5AMT Z2kaNnwQTQxnTLl3PZDfrXfwNIfL2N8L/JbFrNQ= X-Google-Smtp-Source: ABdhPJwHu1UBwzNy1kT7oaXnTF8/TIngiwBWZBeyh5AFRevZoP/DVAsWPuY7Na2yCqOaB+7pwtGVbmPKLYtZOaTA/cI= X-Received: by 2002:ac8:6906:: with SMTP id e6mr6984813qtr.267.1598731938059; Sat, 29 Aug 2020 13:12:18 -0700 (PDT) MIME-Version: 1.0 References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com> In-Reply-To: <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com> From: Dotzero Date: Sat, 29 Aug 2020 16:12:11 -0400 Message-ID: To: "Douglas E. Foster" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000425b1705ae09c912" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 20:12:21 -0000 --000000000000425b1705ae09c912 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 29, 2020 at 3:43 PM Douglas E. Foster wrote: > To elaborate on my question and Michael Hammer's answer: > > To be unique, a signature needs a unique dataset from which the hash is > computed. The weak signature will not be unique because it will be > computed on non-random content such as From, To, and Date. > There are additional ways of introducing complexity and randomness. > > However, the signature can only be used by the designated domain. So the > worst possible "misuse" would be for the designated domain to use the > signature on other messages. This seems unlikely, and the worst-case use > is no different than what ATSP would authorize. But the weak signature > has less information leakage, since nothing is published in DNS about the > signature technique. So I agree that the approach is a good one for those > who want to provide mailing-list authorization. > > The remaining challenge is to communicate between recipient domains and > mailing lists so that the list knows whether the recipient will honor the > weak signature system. > > Doug Foster > > > > > ------------------------------ > *From*: Jim Fenton > *Sent*: 8/26/20 5:01 PM > *To*: Dotzero > *Cc*: IETF DMARC WG > *Subject*: Re: [dmarc-ietf] third party authorization, not, was > non-mailing list > On 8/26/20 10:54 AM, Dotzero wrote: > > > > On Wed, Aug 26, 2020 at 1:32 PM Doug Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> Are the weak signatures vulnerable to a replay attack? I thought that >> one of the reasons that DKIM signatures included the whole body was to >> prevent the signature from being reused. >> >> >> >> DF >> > > Not particularly vulnerable. The requirement is that you have the "weak > signature" plus the intermediary full DKIM signature. This let's the > validator/receiver know that the originating domain knew that the > intermediary might break the originating domains DKIM signature but the > validator/receiver would have the DKIM signature of the intermediary. The > "weak signature" is only validated against that specific message and > headers it signed and that specific intermediary. It's not a > generic/general signature. > > > It sounds like the weak signature is just a regular DKIM signature plus > the designation of the intermediary, and the "weak" part is that you don't > check the body hash against the body. Have I got that right? > > -Jim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000425b1705ae09c912 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Aug 29, 2020 at 3:43 PM Dougl= as E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
To elaborate on my question and Michael Hammer= 9;s answer:

To be unique, a signature needs a uniq= ue dataset from which the hash is computed. =C2=A0 The weak signature will = not be unique because it will be computed on non-random content such as Fro= m, To, and Date.

There are addi= tional ways of introducing complexity and randomness.

However, the signature can only be used by = the designated domain. =C2=A0 So the worst possible "misuse" woul= d be for the designated domain to use the signature on other messages. =C2= =A0 This seems unlikely, and the worst-case use is no different than what A= TSP would authorize. =C2=A0 But the weak signature has less information lea= kage, since nothing is published in DNS about the signature technique. =C2= =A0 So I agree that the approach is a good one for those who want to provid= e mailing-list authorization.

The remaining challe= nge is to communicate between recipient domains and mailing lists so that t= he list knows whether the recipient will honor the weak signature system.

Doug Foster




From: Jim Fenton <fenton@bluepopcorn.net>Sent: 8/26/20 5:01 PM
To: Dotzero <dotzero@gmail.com>
Cc= : IETF DMARC WG <dma= rc@ietf.org>
Subject: Re: [dmarc-ietf] third party authori= zation, not, was non-mailing list
On 8/26/20 10:54 AM, Dot= zero wrote:


On Wed, Aug 26, 2020 at 1:32 PM Doug Foster <fosterd=3D40bayviewp= hysicians.com@dmarc.ietf.org> wrote:

Are the weak signatures vulnerable to a replay attack?=C2=A0= =C2=A0=C2=A0 I thought that one of the reasons that DKIM signatures include= d the whole body was to prevent the signature from being reused.

=

=C2=A0

DF


Not particularly vulnerable. The require= ment is that you have the "weak signature" plus the intermediary = full DKIM signature. This let's the validator/receiver know that the or= iginating domain knew that the intermediary might break the originating dom= ains DKIM signature but the validator/receiver would have the DKIM signatur= e of the intermediary. The "weak signature" is only validated aga= inst that specific message and headers it signed and that specific intermed= iary. It's not a generic/general signature.


It sounds like the weak signature is just a regular DKIM s= ignature plus the designation of the intermediary, and the "weak"= part is that you don't check the body hash against the body. Have I go= t that right?

-Jim


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000425b1705ae09c912-- From nobody Sat Aug 29 16:11:16 2020 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 144763A1133 for ; Sat, 29 Aug 2020 16:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.948, 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=bluepopcorn.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 BNydkF-9uVZs for ; Sat, 29 Aug 2020 16:11:13 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 884A53A0D5E for ; Sat, 29 Aug 2020 16:11:13 -0700 (PDT) Received: from steel.bluepopcorn.net ([IPv6:2601:647:4400:1261:f584:135:c5dd:5610]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 07TNB9Fo025316 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 29 Aug 2020 16:11:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1598742671; bh=04EXWnfDOvOECvM+gHHxu5msNcEnMouzK/6N+JcBBHs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kk2zP751KbvSw/4cQiSysGeo4a4X5Mc1jucgQVrkB/gBl6MC/vRb9BfvJu7Hs2k4E n8NAvLn4V/4pTeCFzAKQjiDLrKfmHEUP6wmqMaBiVaIfDNt+tQiQgYeBTC3jZdw3Yg jYvimrbc5vBse6C6Rs04y+SAbWliIKUcNhoaAKTs= To: fosterd@bayviewphysicians.com, "dmarc@ietf.org" References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com> From: Jim Fenton Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE Message-ID: <46d35938-50ee-871d-d88b-e93c68555dff@bluepopcorn.net> Date: Sat, 29 Aug 2020 16:11:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com> Content-Type: multipart/alternative; boundary="------------7CEFC26465411F310B586602" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 23:11:15 -0000 This is a multi-part message in MIME format. --------------7CEFC26465411F310B586602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/29/20 12:42 PM, Douglas E. Foster wrote: > To elaborate on my question and Michael Hammer's answer: > > To be unique, a signature needs a unique dataset from which the hash > is computed. =C2=A0 The weak signature will not be unique because it wi= ll > be computed on non-random content such as From, To, and Date. Unique !=3D random. A time stamp (with enough precision) might be unique,= even though it is not random. For that matter, DKIM signatures don't include any random values either. But what I was getting at is that the "weak" signature might not have to be any different from any other DKIM signature (except possibly to specify the authorized mediator). It's just that a verifier might fully verify the mediator's signature, and verify the original signature but not check to see if the body hash matches. The one problem is that some mediators add things like [dmarc-ietf] to the subject line, and that's usually signed. -Jim --------------7CEFC26465411F310B586602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/29/20 12:42 PM, Douglas E. Foster wrote:
To elaborate on my question and Michael Hammer's answer:

To be unique, a signature needs a unique dataset from which the hash is computed.   The weak signature will not be unique because it will be computed on non-random content such as From, To, and Date.

Unique != random. A time stamp (with enough precision) might be unique, even though it is not random. For that matter, DKIM signatures don't include any random values either.

But what I was getting at is that the "weak" signature might not have to be any different from any other DKIM signature (except possibly to specify the authorized mediator). It's just that a verifier might fully verify the mediator's signature, and verify the original signature but not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to the subject line, and that's usually signed.

-Jim


--------------7CEFC26465411F310B586602-- From nobody Sat Aug 29 19:23:53 2020 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 7A4923A131F for ; Sat, 29 Aug 2020 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.948, 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=isdg.net header.b=PYU/l07S; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=X/OW5+kh 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 XX6DobtO3uVT for ; Sat, 29 Aug 2020 19:23:49 -0700 (PDT) Received: from mail.winserver.com (mail.winserver.com [76.245.57.69]) (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 21CF83A131C for ; Sat, 29 Aug 2020 19:23:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2230; t=1598754223; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=AR2eFhINdGJ4O4bnnaNu3hFHaWU=; b=PYU/l07S03s2AVG+z4t5jmsgsN9DNax/s8kVZxOzK8LbYPzbJhkYh5bjbq8E9z n8If0U8Cf2ipFg6UwumOByDubrxI2WWWz4y8IVd8R7jIgqWf6WkBkHXJoKqy66Tf Y+E+mItTSs1DBpcnre/0wefErb91lS3deuen+0IOlNjIM= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 29 Aug 2020 22:23:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 784341124.1.3308; Sat, 29 Aug 2020 22:23:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2230; t=1598754055; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=k1mNITX hSkprdaRUFzF9w9FdVnnK9bS8Yhyk1mO9CV8=; b=X/OW5+khBSchqaIuvZoTzIL Ww4qrk8U1FillmuINStbxTtUY2YWmZh8lwc0KhDGKGRMw8VWSi6u+pXlJU850d/4 7ofGeDuKy0UHyYDNH5cv9H0zczRWQ3NW0tlMtLq/vxAMM/ZMrZN/W+xmtUMWvKsu NyZf9jJw+ASW1gjGElPM= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Sat, 29 Aug 2020 22:20:55 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 651293703.1.4180; Sat, 29 Aug 2020 22:20:53 -0400 Message-ID: <5F4B0DAD.1050208@isdg.net> Date: Sat, 29 Aug 2020 22:23:41 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Jim Fenton , Dotzero , Doug Foster CC: IETF DMARC WG References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> In-Reply-To: <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 02:23:52 -0000 On 8/26/2020 5:00 PM, Jim Fenton wrote: > On 8/26/20 10:54 AM, Dotzero wrote: >> >> >> On Wed, Aug 26, 2020 at 1:32 PM Doug Foster >> > > wrote: >> >> Are the weak signatures vulnerable to a replay attack? I >> thought that one of the reasons that DKIM signatures included >> the whole body was to prevent the signature from being reused. >> >> DF >> >> >> Not particularly vulnerable. The requirement is that you have the >> "weak signature" plus the intermediary full DKIM signature. This >> let's the validator/receiver know that the originating domain knew >> that the intermediary might break the originating domains DKIM >> signature but the validator/receiver would have the DKIM signature >> of the intermediary. The "weak signature" is only validated against >> that specific message and headers it signed and that specific >> intermediary. It's not a generic/general signature. > > > It sounds like the weak signature is just a regular DKIM signature > plus the designation of the intermediary, and the "weak" part is that > you don't check the body hash against the body. Have I got that right? Yes. ATPS vs Conditional Signature The end goal is technically the same. Author Domain authorizing a 3rd party signer. The key difference is DNS. ATPS uses DNS to authorize the signer. Conditional signature has the extra tag to define an expected 3rd party signature by a 3rd party domain uplink. For the signing code, there is no change for ATPS. Conditional requires significant signer code change. For the verifying code, the DMARC verifier adds ATPS DNS lookup checks if 1st != 3rd party domains differ or it can also add conditional signatures checks. We should ALLOW both to be explored. For conditional, you don't need a DMARC tag extension. The existence of the extra tag triggers the logic. For ATPS RFC6541, it was designed to piggyback off ADSP. So ATPS will need to be updated to use DMARCbis. The Domain sets the atps=y extension tag to trigger the logic. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Aug 30 01:47:36 2020 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 556D93A134D for ; Sun, 30 Aug 2020 01:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 zWG7oIY8ljgL for ; Sun, 30 Aug 2020 01:47:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 1C5143A11DF for ; Sun, 30 Aug 2020 01:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598777250; bh=Sv4ppaOPuGHlNm/EPTqWa9G4KaN95tlotx6hHBj78z0=; l=288; h=To:References:From:Date:In-Reply-To; b=C10WS/wjSrrvZ98q0B6Iav1G2g4+c961xFi6T/hxLzcpypuSzd+VR+88EcbhXcBT3 FYAzuS0SBZPiTVcNA/JcWe//jOlbDuY2OJ7GoV6LFm5m3624MZ/1oaPn885xnmmntq 8J3rW1zIPQNTKH88rXnaiPzld8Uv0hKyAjeZHW0Q3mBJRdVvtYKu4J0wdzBC2 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, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F4B67A2.0000571B; Sun, 30 Aug 2020 10:47:30 +0200 To: dmarc@ietf.org References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net> <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com> <46d35938-50ee-871d-d88b-e93c68555dff@bluepopcorn.net> From: Alessandro Vesely Message-ID: <50af1fa5-d980-f867-aa5b-c12c1faccff2@tana.it> Date: Sun, 30 Aug 2020 10:47:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <46d35938-50ee-871d-d88b-e93c68555dff@bluepopcorn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 08:47:35 -0000 On Sun 30/Aug/2020 01:11:03 +0200 Jim Fenton wrote: > The one problem is that some mediators add things like [dmarc-ietf] to the > subject line, and that's usually signed. > Multi-mailbox To: and Cc: are also usually signed and possibly reordered by mediators. Best Ale -- From nobody Sun Aug 30 05:08:36 2020 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 7B8AC3A0121 for ; Sun, 30 Aug 2020 05:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 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, HTML_TAG_BALANCE_BODY=0.1, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HPQAQKe1H3Z for ; Sun, 30 Aug 2020 05:08:15 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06E63A0112 for ; Sun, 30 Aug 2020 05:07:59 -0700 (PDT) X-ASG-Debug-ID: 1598789262-11fa31165b35040001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id gx3b5s0KQEsL5Bvk (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 30 Aug 2020 08:07:42 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=iDQwHmbM0Mfmk6jUz8goQnbKHoq8sbgh29n7HmUZ1UQ=; b=cRZRJD5Fp34aMQ5ok+76DmyAJa9FIzABspIaEWZ1HT4xtso2hfU/qv7Z+QnZXsBpY OTAXFmIf8Ss6zRTZDJ/xmA92EnjGK6CxtvUQVGFWyLy7IXwVIhs16trip9oFKoSLo LU2yMV+83HVE0teyWJz4dvEVV1fsKnGEfeKYL0mO4= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 30 Aug 2020 08:07:35 -0400 To: "dmarc@ietf.org" Date: Sun, 30 Aug 2020 08:07:33 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Message-ID: <7e71edd41d84410380879149d0962096@com> MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=b7ef20b993504d778fb0e9ba1a292850 Importance: normal From: "Douglas E. Foster" X-Exim-Id: 7e71edd41d84410380879149d0962096 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1598789262 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5528 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84270 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 12:08:35 -0000 This is a multipart message in MIME format. --b7ef20b993504d778fb0e9ba1a292850 Content-Type: multipart/alternative; boundary=3bba02ea794340a5ba615e4222d982dd --3bba02ea794340a5ba615e4222d982dd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since we are designing a system that allows a mediator to alter Subject and= Body, it should be no surprise that the conditional signature has the pote= ntial for re-use.=A0 =A0A well behaved mediator must be assumed before any = such trust delegation is granted.I see no way to ensure that the conditiona= l signature is single-use. As long as all of the signature's hashed cntent = can be replicated onto another message, the signature can be reused.The mor= e important question is whether conditional signature could be subject to t= hird-party attacks.=A0 Does the limited and predictable content of a condit= ional signature intcrease the risk that a bad guy could use guess-and-test = to construct a valid=A0 signature block for someone else?=A0=A0DKIM uses th= e body content in two different hash calculations.=A0 This severely limits = the ability of an attacker to find and exploit a hash collision.=A0 =A0The = conditional=A0 signatures seem unlikely to have that strength.Sent from my = Verizon, Samsung Galaxy smartphone
-------- Original message --------
=
From: Jim Fenton
Date: 8/29/20 7:= 11 PM (GMT-05:00)
To: fosterd@bayviewphysicians.com, dmarc@ietf= .org
Subject: Re: [dmarc-ietf] third party authorization, not, w= as non-mailing list
On 8/29/20 12:42 PM, Douglas E. Foster wrote: > To elaborate on my question and Michael Hammer's answer: > > To be unique, a signature needs a unique dataset from which the hash > is computed. =A0 The weak signature will not be unique because it will > be computed on non-random content such as From, To, and Date. Unique !=3D random. A time stamp (with enough precision) might be unique, even though it is not random. For that matter, DKIM signatures don't include any random values either. But what I was getting at is that the "weak" signature might not have to be any different from any other DKIM signature (except possibly to specify the authorized mediator). It's just that a verifier might fully verify the mediator's signature, and verify the original signature but not check to see if the body hash matches. The one problem is that some mediators add things like [dmarc-ietf] to the subject line, and that's usually signed. -Jim --3bba02ea794340a5ba615e4222d982dd Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Since we are designing a system that allows a m= ediator to alter Subject and Body, it should be no surprise that the condit= ional signature has the potential for re-use.   A well behaved me= diator must be assumed before any such trust delegation is granted.

I see no way to ensure that the conditional signature is = single-use. As long as all of the signature's hashed cntent can be replicat= ed onto another message, the signature can be reused.

<= div>The more important question is whether conditional signature could be s= ubject to third-party attacks.  Does the limited and predictable conte= nt of a conditional signature intcrease the risk that a bad guy could use g= uess-and-test to construct a valid  signature block for someone else?&= nbsp; 

DKIM uses the body content in two diff= erent hash calculations.  This severely limits the ability of an attac= ker to find and exploit a hash collision.   The conditional = signatures seem unlikely to have that strength.

<= br>

Sent from my Verizon, Samsung Galaxy sm= artphone


<= div>-------- Original message --------
From: Jim Fenton <fento= n@bluepopcorn.net>
Date: 8/29/20 7:11 PM (GMT-05:00)
=
To: fosterd@bayviewphysicians.com, dmarc@ietf.org
Subject: = Re: [dmarc-ietf] third party authorization, not, was non-mailing list

On 8/29/20 12:42 PM, Douglas E. Foster wrote:
To elaborate on my question and Michael Hammer's answer:

To be unique, a signature needs a unique dataset from which the hash is computed. =A0 The weak signature will not be unique because it will be computed on non-random content such as From, To, and Date.

Unique !=3D random. A time stamp (with enough precision) might be unique, even though it is not random. For that matter, DKIM signatures don't include any random values either.

But what I was getting at is that the "weak" signature might not have to be any different from any other DKIM signature (except possibly to specify the authorized mediator). It's just that a verifier might fully verify the mediator's signature, and verify the original signature but not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to the subject line, and that's usually signed.

-Jim


--3bba02ea794340a5ba615e4222d982dd-- --b7ef20b993504d778fb0e9ba1a292850-- From nobody Sun Aug 30 09:11:10 2020 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 C3F7E3A0BA3 for ; Sun, 30 Aug 2020 09:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 chLW4bnRntyZ for ; Sun, 30 Aug 2020 09:11:05 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 D58033A0BA4 for ; Sun, 30 Aug 2020 09:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1598803860; bh=pvHIEnnd/WDveQHKTWpmbL9HnvcGxfaZ/hHm3cQhMXo=; l=1834; h=To:References:From:Date:In-Reply-To; b=AjpJwSliJAxoMOw9f9P1YLkb3BeukrtWlxg162x6CjcXkv+5pQuNZsSXMnk3hToeS ceDpRyDva7wpVo2DdI1FJsMFdMHO1hO39lzXiTk1DNMGFxzy6e8Mow6ynJNMNAGZvB XVIUhdpyTuA1nYSfiW3ZQi1i0K9vsTuSpYtWlW1eR3JyIG4FT9qZXiKq+qvYG 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, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005F4BCF94.00001212; Sun, 30 Aug 2020 18:11:00 +0200 To: dmarc@ietf.org References: <7e71edd41d84410380879149d0962096@com> From: Alessandro Vesely Message-ID: Date: Sun, 30 Aug 2020 18:11:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <7e71edd41d84410380879149d0962096@com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 16:11:08 -0000 On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote: > Since we are designing a system that allows a mediator to alter Subject and > Body, it should be no surprise that the conditional signature has the potential > for re-use.   A well behaved mediator must be assumed before any such trust > delegation is granted. > > I see no way to ensure that the conditional signature is single-use. As long as > all of the signature's hashed content can be replicated onto another message, > the signature can be reused. Yes. That's true for any DKIM signature, in particular if using l=, which allows to append varying content. > The more important question is whether conditional signature could be subject > to third-party attacks.  Does the limited and predictable content of a > conditional signature intcrease the risk that a bad guy could use > guess-and-test to construct a valid  signature block for someone else? If you have the signature, you presumably have the whole message. So there's no need to guess. It is enough to keep signed header fields, presumably From:, Message-Id: (which is random, btw), and Date:. All the rest can be changed at will. > DKIM uses the body content in two different hash calculations.  This severely > limits the ability of an attacker to find and exploit a hash collision.   The > conditional  signatures seem unlikely to have that strength. Even if the hash covers few data, finding a collision is not any easier. According to dkim-conditional, an attacker would need a private key of the domain pointed by !fs=. That limits exploits substantially. Using vanilla weak signatures (e.g. to be compatible with v=1 verifiers) allows replaying at recipient's discretion, a state of affairs loosely comparable to p=none. Best Ale -- From nobody Sun Aug 30 09:27:54 2020 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 EAA3B3A0BCD for ; Sun, 30 Aug 2020 09:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=hNJZz+au; dkim=pass (2048-bit key) header.d=taugh.com header.b=OR8IEyOW 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 l2FrqdP6alPh for ; Sun, 30 Aug 2020 09:27:51 -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 497A63A0BCC for ; Sun, 30 Aug 2020 09:27:50 -0700 (PDT) Received: (qmail 96246 invoked from network); 30 Aug 2020 16:27:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=177f1.5f4bd385.k2008; bh=L9HoT24Zzq9NAVN6KOEPP0wiuB3J60K9eRVqfNbYpmI=; b=hNJZz+auUEtPKVlI+efXnkHOowkgCWjgt6nFuAD9rUcfec13rjkGxsgGISCcvedT9lL/Jgr7RURzGN0eoy3hhjSOc7Zp+uipTwpmEkFAM3jCHV9cupxYhHVdw1VZJj7JeTkaGMlFiuwbM9SRwbLy6x8R5xC9S9CfzkX58d3JERE9iRbLM7vqBED4MdxzrdO/XMhYavEtdWVqMEA/B5oLq/8y0Gr2KfVM/lBVOfSt5XB6fOAUoxTbtoV8Pmg80mgIOk/KvruwWzPJvJB/DsaTJE4JyPiSrb+StYliGXy9HWC4lEuNq2M7Sfuu/T59QB1FiEN2DqZv/n+kTrjSVeZnxw== 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=177f1.5f4bd385.k2008; bh=L9HoT24Zzq9NAVN6KOEPP0wiuB3J60K9eRVqfNbYpmI=; b=OR8IEyOWUwpJGYqHXPAExn/jD+oPrxhXChzDcup4GVxDl+Ezn+YLgC+szb16YRZTz1+Hn1QIjdFV+jKtGz2b0jPHYGzLX9NVDMTFAA8UwH1WfiSXasgeeNE5eW5I1j68SkGx5K8KeYjPdMNi2B/9OOM9O0bAXWHPz6lJxzEoJySolqtt0a0eCPukw+N2FjtPI/CBgl28833xbg8jBlVFQDuOYNtyuV85gRv5mmerfydre3n6rSQsY/gyY7Nu91QPWbnrqMhdnx3u4azTYOo4Qv2OxgXzpnytVieksHzEZp4u27ul6cnPRClQTIthz+zVLhJwYaTferVaM4annB2rPA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 30 Aug 2020 16:27:49 -0000 Received: by ary.qy (Postfix, from userid 501) id C66D31F4A314; Sun, 30 Aug 2020 12:27:48 -0400 (EDT) Date: 30 Aug 2020 12:27:48 -0400 Message-Id: <20200830162748.C66D31F4A314@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: fenton@bluepopcorn.net In-Reply-To: <46d35938-50ee-871d-d88b-e93c68555dff@bluepopcorn.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 16:27:53 -0000 In article <46d35938-50ee-871d-d88b-e93c68555dff@bluepopcorn.net> you write: >But what I was getting at is that the "weak" signature might not have to >be any different from any other DKIM signature (except possibly to >specify the authorized mediator). It's just that a verifier might fully >verify the mediator's signature, and verify the original signature but >not check to see if the body hash matches. ... I just sent in a slightly refreshed version of my conditional signature draft which says exactly that. It's not very different from the orginal version I sent in over six years ago. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ R's, John From nobody Sun Aug 30 11:37:59 2020 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 336AA3A0D69 for ; Sun, 30 Aug 2020 11:37:58 -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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9ZbFIJ0_po2 for ; Sun, 30 Aug 2020 11:37:56 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6D73A0D68 for ; Sun, 30 Aug 2020 11:37:51 -0700 (PDT) X-ASG-Debug-ID: 1598812667-11fa31165b36ab0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id vfiAAMVkYV9G9ZPs (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 30 Aug 2020 14:37:48 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=UsWNDx9LQ4mQHClEdI4Luycl5Gt8pHE3tYo6GGbXPWA=; b=jZSo95UZlFeEVBOzXtm3ZTwR2kNM+hTY++8NpDi4sCQeeZWw/Aawb7xehm5lwiL+o z7pPf3LOOSSFUQ4PXm3aPNMKQBFXsEW36gFhU+9yrJ7g7h5vo8Wf8J9ZaXJZbB+s+ QBBLnxjXw2xqeTW/INnApC/JoTD4b/zoDML6Yl8WI= From: "Douglas E. Foster" To: Date: Sun, 30 Aug 2020 18:37:38 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party authorization, not, was non-mailing list Reply-To: fosterd@bayviewphysicians.com Message-ID: <7d667f487d46434f972cc396f55af9d0@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=20322b4e32844774912f1b4bb1370c62 In-Reply-To: <20200830162748.C66D31F4A314@ary.qy> References: <20200830162748.C66D31F4A314@ary.qy> X-Exim-Id: 7d667f487d46434f972cc396f55af9d0 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1598812668 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5151 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84278 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 18:37:58 -0000 This is a multipart message in MIME format. --20322b4e32844774912f1b4bb1370c62 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This all looks workable to me, if it can gain support from senders, recipie= nts, and mailing lists. But as I have said before, the last part of the protocol needs to be a way = for the mediator to know that the recipient will accept the message. This= could be because: Recipient honors conditional signatures (or any other future third-party au= thorization system.)Recipient has whitelisted the mailing list, so DMARC wi= ll not be enforced against the list.Recipient does not enforce DMARC at all= . The first option is the most complicated, because it requires the list to c= hange behavior based on both sender and recipient configuration. The latt= er two only require knowledge of the recipient configuration, and could be = implemented today. But early in this discussion, John implied that recipi= ent-specific tailoring of the From address is outside the capabilities of m= odern mailing lists. To get IETF backing, the signalling between lists an= d recipients also needs to scale, which implies a high level of automation.= Is there any way to solve this part of the problem? DF ---------------------------------------- From: "John Levine" Sent: 8/30/20 12:28 PM To: dmarc@ietf.org Cc: fenton@bluepopcorn.net Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party= authorization, not, was non-mailing list In article <46d35938-50ee-871d-d88b-e93c68555dff@bluepopcorn.net> you write= : >But what I was getting at is that the "weak" signature might not have to >be any different from any other DKIM signature (except possibly to >specify the authorized mediator). It's just that a verifier might fully >verify the mediator's signature, and verify the original signature but >not check to see if the body hash matches. ... I just sent in a slightly refreshed version of my conditional signature dra= ft which says exactly that. It's not very different from the orginal version I sent in over six years a= go. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --20322b4e32844774912f1b4bb1370c62 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
This all looks wor= kable to me, if it can gain support from senders, recipients, and mailing l= ists.

But as I have said before, the last part of = the protocol needs to be a way for the mediator to know that the recipient = will accept the message.   This could be because:
  • Recipie= nt honors conditional signatures (or any other future third-party authoriza= tion system.)
  • Recipient has whitelisted the mailing list, so DMARC = will not be enforced against the list.
  • Recipient does not enforce D= MARC at all.
The first option is the most complicated, becaus= e it requires the list to change behavior based on both sender and recipien= t configuration.   The latter two only require knowledge of the recipi= ent configuration, and could be implemented today.   But early in this= discussion, John implied that recipient-specific tailoring of the From add= ress is outside the capabilities of modern mailing lists.   To get IET= F backing, the signalling between lists and recipients also needs to scale,= which implies a high level of automation. 

I= s there any way to solve this part of the problem?

DF

Fro= m: "John Levine" <johnl@taugh.com>
Sent:= 8/30/20 12:28 PM
To: dmarc@ietf.org
Cc: fenton@bluepopcorn.net
Subject: Re: [dmarc-ietf] = draft-levine-dkim-conditional-04, was third party authorization, not, was n= on-mailing list
In article <46d35938-50ee-871d-d88b-e93= c68555dff@bluepopcorn.net> you write:
>But what I was getti= ng at is that the "weak" signature might not have to
>be any d= ifferent from any other DKIM signature (except possibly to
>sp= ecify the authorized mediator). It's just that a verifier might fully
=
>verify the mediator's signature, and verify the original signature= but
>not check to see if the body hash matches. ...

I just sent in a slightly refreshed version of my condition= al signature draft
which says exactly that.

<= div>It's not very different from the orginal version I sent in over six yea= rs ago.


R's,
John

____________________________________= ___________
dmarc mailing list
dmarc@ietf.org
= https://www.ietf.org/mailman/listinfo/dmarc

--20322b4e32844774912f1b4bb1370c62-- From nobody Sun Aug 30 22:32:39 2020 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 EF7433A0EF1 for ; Sun, 30 Aug 2020 22:32:37 -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, 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 eQa4LzMOgfsM for ; Sun, 30 Aug 2020 22:32:36 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 75B953A0EF0 for ; Sun, 30 Aug 2020 22:32:36 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id v138so2587673vsv.7 for ; Sun, 30 Aug 2020 22:32:36 -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=2+CCKKDpA1mB3Gcs3/Czwl1e34Dw1ceM0WQpEe0R8+s=; b=qch8vE5tyTA4TU7wMHmDF8+KIIPnhBF7HV/GAj0xd0PDxkEjzvBpUIEJt6hHTdRa5C 4RdrTNHhuJSNPGPKA8IbU1HWrj2fL3gEWkcebwlQ/HGzhnZdipRHtaBgSzA30p/pfpEl MS4LqU5T1fn8Omzq2kYKIidzIMxLNH+xrAc4mwR5TIhl3bL2brpzMFZlC1Cib7gt4Wg9 Pvw5rqgH/UZKkcuwdxfhhmLuUsqHj9chugz4Zxk14jUEWYS2BxS5me2vDa42FWynNzCo w+am71nOP/sg8m42ekS73qnfhDZBq5uIgsIc+f6U98FJ0iORL7kLLn1xrUmChDEI6llG vYTQ== 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=2+CCKKDpA1mB3Gcs3/Czwl1e34Dw1ceM0WQpEe0R8+s=; b=QEpNQl+EdrQZ7/PkA3QTsR9FA35jIQx3b/7XCno1prvzNPRPnzalBiAbNWFL2Ui2kv M/BCwjRkkVjShw7HwEH813yp9H/ltkK2AWAaN2jBA8n35Ix9kgS6h32iIVbssNKuR9gL 3XsKcqmnckIrsFoedMrzG853FY7XxnbQ+kPHwciN7VZhnxcw0NY5v+LVOnYqBqLhRwmm kcgCrff5BuxU9qPHIuep9f8UADJuDKxx1drQZmp5midRHGcNo0hZW3wkFNbgbg62ljq3 jPOEus1qOilFwdMP0cWFxAND57BZMR81gp+jq8b0CRuZoyhiLJQaaD7kEyr5IWz8omr+ GtZw== X-Gm-Message-State: AOAM532lwwk628kn6shCTeZMo+l5vytdIhFrbIZmVRgvy7/EaabEYhtc M3IBHTa0ViCGF8z4rIRRucEe7oPADAQdiqXPis+AiMWIO+Q= X-Google-Smtp-Source: ABdhPJxZLA2g5Fx9eZgPcQQp2CHMBJuWGrV9orpeiUAJvVYhR989dOw58KpAnZjJBJQP8UPc2u5Zy/vbRgosrHGzpFs= X-Received: by 2002:a67:e1ce:: with SMTP id p14mr4632866vsl.24.1598851955240; Sun, 30 Aug 2020 22:32:35 -0700 (PDT) MIME-Version: 1.0 References: <20200830162748.C66D31F4A314@ary.qy> <7d667f487d46434f972cc396f55af9d0@bayviewphysicians.com> In-Reply-To: <7d667f487d46434f972cc396f55af9d0@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Sun, 30 Aug 2020 22:32:21 -0700 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d7343205ae25ba8d" Archived-At: Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-04, was third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 05:32:38 -0000 --000000000000d7343205ae25ba8d Content-Type: text/plain; charset="UTF-8" On Sun, Aug 30, 2020 at 11:38 AM Douglas E. Foster wrote: > This all looks workable to me, if it can gain support from senders, > recipients, and mailing lists. > > But as I have said before, the last part of the protocol needs to be a way > for the mediator to know that the recipient will accept the message. This > could be because: > > - Recipient honors conditional signatures (or any other future > third-party authorization system.) > - Recipient has whitelisted the mailing list, so DMARC will not be > enforced against the list. > - Recipient does not enforce DMARC at all. > > The first option is the most complicated, because it requires the list to > change behavior based on both sender and recipient configuration. The > latter two only require knowledge of the recipient configuration, and could > be implemented today. But early in this discussion, John implied that > recipient-specific tailoring of the From address is outside the > capabilities of modern mailing lists. To get IETF backing, the signalling > between lists and recipients also needs to scale, which implies a high > level of automation. > > Is there any way to solve this part of the problem? > I'm not clear on why you think the first option is the most complicated. I think it's the simplest, since the entire thing is implemented at the DKIM layer. DMARC and the MLM don't even know any of this is happening. I suspect the complicated part is the logic the author domain's signer needs to use when deciding whether to affix the weaker signature, because of the replay risk described in the draft. If you want to be pure about this, you need to know where all the lists are, which means either discovering them or having your users register them. At a large scale, those aren't pragmatic, so you might do something like affix the weaker signature only if the set of domains in the union of the To: and Cc: fields (or perhaps the envelope recipients) is small, and avail yourself of the semantics of the "x=" tag (also described in the draft). Interesting. Looking at my open source stuff, it seems I did a variant of the -03 draft, where the tag was "cd" (probably for "conditional domain"). I vaguely remember that discussion. Wouldn't be hard to change one or the other. -MSK --000000000000d7343205ae25ba8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2020 at 11:38 AM Douglas = E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
This all looks workable t= o me, if it can gain support from senders, recipients, and mailing lists.

But as I have said before, the last part of the pro= tocol needs to be a way for the mediator to know that the recipient will ac= cept the message. =C2=A0 This could be because:
  • Recipient hono= rs conditional signatures (or any other future third-party authorization sy= stem.)
  • Recipient has whitelisted the mailing list, so DMARC will no= t be enforced against the list.
  • Recipient does not enforce DMARC at= all.
The first option is the most complicated, because it re= quires the list to change behavior based on both sender and recipient confi= guration. =C2=A0 The latter two only require knowledge of the recipient con= figuration, and could be implemented today. =C2=A0 But early in this discus= sion, John implied that recipient-specific tailoring of the From address is= outside the capabilities of modern mailing lists. =C2=A0 To get IETF backi= ng, the signalling between lists and recipients also needs to scale, which = implies a high level of automation.=C2=A0

Is there= any way to solve this part of the problem?
I'm not clear on why you think the first option is the mos= t complicated.=C2=A0 I think it's the simplest, since the entire thing = is implemented at the DKIM layer.=C2=A0 DMARC and the MLM don't even kn= ow any of this is happening.

I suspect the complicated = part is the logic the author domain's signer needs to use when deciding= whether to affix the weaker signature, because of the replay risk describe= d in the draft.=C2=A0 If you want to be pure about this, you need to know w= here all the lists are, which means either discovering them or having your = users register them.=C2=A0 At a large scale, those aren't pragmatic, so= you might do something like affix the weaker signature only if the set of = domains in the union of the To: and Cc: fields (or perhaps the envelope rec= ipients) is small, and avail yourself of the semantics of the "x=3D&qu= ot; tag (also described in the draft).
=
Interesting.

Looking at my open source stuff= , it seems I did a variant of the -03 draft, where the tag was "cd&quo= t; (probably for "conditional domain").=C2=A0 I vaguely remember = that discussion.=C2=A0 Wouldn't be hard to change one or the other.
=

= -MSK


--000000000000d7343205ae25ba8d-- From nobody Sun Aug 30 22:54:20 2020 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 6100C3A0F20 for ; Sun, 30 Aug 2020 22:54:18 -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, 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 Vub9EA3iA2Tl for ; Sun, 30 Aug 2020 22:54:16 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 BC8B53A0F1F for ; Sun, 30 Aug 2020 22:54:16 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id q67so566285vsd.5 for ; Sun, 30 Aug 2020 22:54:16 -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=S5BKijYqEsUlnIrru6/iHWomYfSv+b4iVFsqUY8riwY=; b=lzwr4v/1bp3jFpDafm80q96QqFs871yni2Bayus+hL7cGdzRyK+OkLlcVWimT6napG ZKFYSWfiZ3Mx2heTRUPFIFdEpKbCgZGIu6uEReN0VJB8i9LbjQIQT/ORmaAYdrDpU8j2 0Bc21A0zYRAOe63Xa9pdK1HxKLIBIBMvzOe+qd4KIMAIhRbbUCP0D4xx1ofVHpVEF0qy ueuIyGPHEEo9/7RssIrzpwOuhJvxOQNZOVjccT83Qi5ERVBDkZo8Fi6Tt4A/DAt9EDYr n2PJvUYK/jzuOtwA/lq0YTYulzS/m6/6Qarv4GalSPBPByOBUnhDbihO3E3jdScdFZJU N+qQ== 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=S5BKijYqEsUlnIrru6/iHWomYfSv+b4iVFsqUY8riwY=; b=DiJeo9ew0xbeQjFtg13O7kkvW95r0xJ6UkvUdPK0bvP6ldPdHNiQodzr3tQBYVM3Xc VA/hLiM03LkbQZ3eI7yZO3h79jaKaT8gHDnqAhkjV1TFm3Ib8FtsbNgqf6dZlIpPgbee 4qU31Eqydh5lzMMYm5MlJqiPPKAD2FlTifzM9VLEqroUxZBvs4geYAj3Vwd12TzIdvj/ 7a5VOYHxIFmHk7IGOpzwa2cueS+WK0NGwbwXVToVi+iPrc21m1u0wynjZtwiRXoISiug 8UKccAhid2YCIk1TDHlQeDMJYK2DyLHsCzJSsDcB6+28Nvj64IwV/23nx1ha4v6dgbK8 JyFg== X-Gm-Message-State: AOAM532s1uxz71+VC97aM7oFAYsUBnRtYfQ7GPacSfPow9Ei7Sa2UJMa x47x7nZM3zBS0jLYu6G4UKH5bvZNiWoJI8WfWw6WVDdjXeYoTA== X-Google-Smtp-Source: ABdhPJyX/BobdqTRKXoeuyfUhUxgVQMcdD4sDPsngi2UgyxQ1UPIkCJxNFwgV0txqH1N15YE+1ZVUPmICeu5WX1AIq0= X-Received: by 2002:a67:e1ce:: with SMTP id p14mr12144vsl.24.1598853255605; Sun, 30 Aug 2020 22:54:15 -0700 (PDT) MIME-Version: 1.0 References: <7e71edd41d84410380879149d0962096@com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 30 Aug 2020 22:54:02 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005930f605ae260877" Archived-At: Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 05:54:18 -0000 --0000000000005930f605ae260877 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 30, 2020 at 9:11 AM Alessandro Vesely wrote: > On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote: > > Since we are designing a system that allows a mediator to alter Subject > and > > Body, it should be no surprise that the conditional signature has the > potential > > for re-use. A well behaved mediator must be assumed before any such > trust > > delegation is granted. > > > > I see no way to ensure that the conditional signature is single-use. As > long as > > all of the signature's hashed content can be replicated onto another > message, > > the signature can be reused. > > Yes. That's true for any DKIM signature, in particular if using l=, which > allows to append varying content. > Indeed, RFC 6376 discusses replay attacks in a number of places. It would be nice if we could reduce that, but I suggest that's not a roadblock to this working group's progress since it's an acknowledged property of DKIM already. > DKIM uses the body content in two different hash calculations. This > severely > > limits the ability of an attacker to find and exploit a hash collision. > The > > conditional signatures seem unlikely to have that strength. > > Even if the hash covers few data, finding a collision is not any easier. > > According to dkim-conditional, an attacker would need a private key of the > domain pointed by !fs=. That limits exploits substantially. Using > vanilla > weak signatures (e.g. to be compatible with v=1 verifiers) allows > replaying at > recipient's discretion, a state of affairs loosely comparable to p=none. > The draft suggests use of "x=" as a way to limit exposure. If you do that, then an attacker would need to be able to generate mail through your signer with an "!fs=" tag identifying a domain they control, and exploit the replay before the time in the "x=" tag arrives. Sure, it's time-limited, but it only takes seconds for such an attack to succeed, and automation of such an attack is easy. If you attach a "!fs=" for any old domain, then the exposure is wide; if you can somehow constrain the domains, the attack surface is considerably smaller. In either case, reputation of the target domain might help, assuming that's a service to which the author domain's signer has access. For the cases of employers that want their staff to participate in, say, IETF lists, they might be willing to institute a program of registering domains where lists exist, thus limiting the attack surface. So you register "ietf.org" with your IT department, and they start issuing weak signatures on mail going to that domain for six months. As the deadline approaches, people are warned to re-register, else the registration expires and the conditional signatures stop; destructive results resume. Fraudulent registrations can be traced back to who made them. But we still have the Yahoo/GMail sized use cases to consider. I still don't think any kind of registration system could be reasonably expected to scale. Auto-detection, maybe, but that's got to be prone to false negatives (and destructive results) while the data warm up about a new destination. -MSK --0000000000005930f605ae260877 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2020 at 9:11 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote:
> Since we are designing a system that allows a mediator to alter Subjec= t and
> Body, it should be no surprise that the conditional signature has the = potential
> for re-use.=C2=A0 =C2=A0A well behaved mediator must be assumed before= any such trust
> delegation is granted.
>
> I see no way to ensure that the conditional signature is single-use. A= s long as
> all of the signature's hashed content can be replicated onto anoth= er message,
> the signature can be reused.

Yes.=C2=A0 That's true for any DKIM signature, in particular if using l= =3D, which
allows to append varying content.

Indee= d, RFC 6376 discusses replay attacks in a number of places.=C2=A0 It would = be nice if we could reduce that, but I suggest that's not a roadblock t= o this working group's progress since it's an acknowledged property= of DKIM already.

> DKIM uses the body content in two different hash calculations.=C2=A0 T= his severely
> limits the ability of an attacker to find and exploit a hash collision= .=C2=A0 =C2=A0The
> conditional=C2=A0 signatures seem unlikely to have that strength.

Even if the hash covers few data, finding a collision is not any easier.
According to dkim-conditional, an attacker would need a private key of the =
domain pointed by !fs=3D.=C2=A0 That limits exploits substantially.=C2=A0 U= sing vanilla
weak signatures (e.g. to be compatible with v=3D1 verifiers) allows replayi= ng at
recipient's discretion, a state of affairs loosely comparable to p=3Dno= ne.

The draft suggests use of "x= =3D" as a way to limit exposure.=C2=A0 If you do that, then an attacke= r would need to be able to generate mail through your signer with an "= !fs=3D" tag identifying a domain they control, and exploit the replay = before the time in the "x=3D" tag arrives.=C2=A0 Sure,=20 it's time-limited, but it only takes seconds for such an attack to succ= eed, and automation of such an attack is easy.

If = you attach a "!fs=3D" for any old domain, then the exposure is wi= de; if you can somehow constrain the domains, the attack surface is conside= rably smaller.=C2=A0 In either case, reputation of the target domain might = help, assuming that's a service to which the author domain's signer= has access.

For the cases of employers that want = their staff to participate in, say, IETF lists, they might be willing to in= stitute a program of registering domains where lists exist, thus limiting t= he attack surface.=C2=A0 So you register "= ietf.org" with your IT department, and they start issuing weak sig= natures on mail going to that domain for six months.=C2=A0 As the deadline = approaches, people are warned to re-register, else the registration expires= and the conditional signatures stop; destructive results resume.=C2=A0 Fra= udulent registrations can be traced back to who made them.

But we still have the Yahoo/GMail sized use cases to consider.=C2= =A0 I still don't think any kind of registration system could be reason= ably expected to scale.=C2=A0 Auto-detection, maybe, but that's got to = be prone to false negatives (and destructive results) while the data warm u= p about a new destination.

-MSK
--0000000000005930f605ae260877-- From nobody Mon Aug 31 09:15:46 2020 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 3D8C43A1795 for ; Mon, 31 Aug 2020 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=TGXEBDAx; dkim=pass (2048-bit key) header.d=taugh.com header.b=i71jTYjk 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 EJ3BB2iZFV9B for ; Mon, 31 Aug 2020 09:15:42 -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 7CDB23A17A2 for ; Mon, 31 Aug 2020 09:15:42 -0700 (PDT) Received: (qmail 9144 invoked from network); 31 Aug 2020 16:15:40 -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=23b6.5f4d222c.k2008; bh=7NwdcojtncHliOT2FdciYJsUtR87hkSiKgg3wa+kXlM=; b=TGXEBDAx8pG9UPyUpdoXofTfFJIvPsbe0GhcLExtzB5KkufVu/+PJXLw2ycg3jSTmq0sX9hg1/Qc8XDJxN05RJGdp/gSgZ0ikLZKxfEBkFNGEH0LDLdOZ0KEvv90XU8QyUstg6KS3RNRzyin63zmDItME83wgT+kNjhxzlZNhDonLJIsGCWiyKJkI3jpyy35F/H7Zp5DUSkY7UEF9HaOcR64TYCrBsJG0iGR4FlodISO4aManTAt5ZL6Q2vva+mRWABYOc1yunVonIUcaeN1jdAl1k0/Ktc+H6gabD1kIE+mo76BpAbMEQTwJUCoBS1bb1cSyQAaElB3ngw3Qf6K8w== 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=23b6.5f4d222c.k2008; bh=7NwdcojtncHliOT2FdciYJsUtR87hkSiKgg3wa+kXlM=; b=i71jTYjkjcK5+JQbWumE11eJKHIhll58K7I6IXs62ITQAtfJy8tcV/XiCCIro/dIUYfeUfQNqS6B7g0bLMYVi2C5ivqX1/uClXJCwbol1fQPRPN05UzcT3SAZ3o7cGA49RFtDB1w0ppmKVsVY6QugeJycJZtK4CaxUFcjvee0FjDAyY3J/mD5uqQHlNHk50jB8gjiTb9Sd4enVAAKBIjiEUM2gj+DHYdAbNehEua9TmERv351pn597nnToI/SK0KJZiZI91W4Em09VKZe5z3BwPve+A7NS2js3WXHGuWi4hy7Lppj02KPQR0DaiBS8oAwdPw0oeudpc97Gbw03KDLw== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 31 Aug 2020 16:15:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 2C9F41F510E8; Mon, 31 Aug 2020 12:15:40 -0400 (EDT) Date: 31 Aug 2020 12:15:40 -0400 Message-Id: <20200831161540.2C9F41F510E8@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] my forward signer draft, third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 16:15:45 -0000 In article you write: >The draft suggests use of "x=" as a way to limit exposure. If you do that, >then an attacker would need to be able to generate mail through your signer >with an "!fs=" tag identifying a domain they control, and exploit the >replay before the time in the "x=" tag arrives. Sure, it's time-limited, >but it only takes seconds for such an attack to succeed, and automation of >such an attack is easy. The threats I had in mind were more like attacker finds an old message in an archive with a fs domain that's been abandoned and the attacker can reregister. An x= of a few days should prevent that while still letting normal list traffic work. As always, as I hope we all remember DMARC alignment doesn't mean not spam, and you still do all of the stuff you do to sort your mail. This scheme depends on the forwarders you authorize being well-behaved. That's why I am concerned that senders need to be selective about who they allow to forward. R's, John From nobody Mon Aug 31 14:49:10 2020 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 A49053A1984 for ; Mon, 31 Aug 2020 14:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 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, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=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 uE0l_EJTKm2T for ; Mon, 31 Aug 2020 14:49:06 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC423A1982 for ; Mon, 31 Aug 2020 14:49:06 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 4BgP3h0yP2z1tp50; Mon, 31 Aug 2020 23:49:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx20.mailtransaction.com 4BgP3h0yP2z1tp50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1598910544; bh=aaxqRO534+6LNLYDDiJg9DDakP0KKo7DTM6Nh/0WS9g=; h=Subject:To:From:Message-ID:Date:From; b=kVGbkZT8AOWkrD5cJzuztd4xYE251hOKFIDzQSBzy3CBgTOf8b6kPtH4vuVhHsHsI 2vYurp6jDuNd055WH9hgIfJrth+eV1HMkANifxgUn9bPgQGdtLn+v8ZlYR1pEmDcaG 2n0aEQalqeahsYDNHJTdPU4SjDlrEcVJN+TAgiSA= Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx24.mailtransaction.com (Postfix) with ESMTPS id 4BgP3g1s1zz1tp3b; Mon, 31 Aug 2020 23:49:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 05E0B4223A3; Mon, 31 Aug 2020 23:49:03 +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 sc_dwKvdwzMh; Mon, 31 Aug 2020 23:49:02 +0200 (CEST) Received: from [192.168.40.49] (cat.sonnection.nl [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id CA7074223A2; Mon, 31 Aug 2020 23:49:02 +0200 (CEST) To: John Levine , dmarc@ietf.org Cc: superuser@gmail.com References: <20200831161540.2C9F41F510E8@ary.qy> From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: Date: Mon, 31 Aug 2020 23:49:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200831161540.2C9F41F510E8@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] my forward signer draft, third party authorization, not, was non-mailing list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 21:49:09 -0000 On 31/08/2020 18:15, John Levine wrote: > In article you write: >> The draft suggests use of "x=" as a way to limit exposure. If you do that, >> then an attacker would need to be able to generate mail through your signer >> with an "!fs=" tag identifying a domain they control, and exploit the >> replay before the time in the "x=" tag arrives. Sure, it's time-limited, >> but it only takes seconds for such an attack to succeed, and automation of >> such an attack is easy. > The threats I had in mind were more like attacker finds an old message > in an archive with a fs domain that's been abandoned and the attacker > can reregister. An x= of a few days should prevent that while still > letting normal list traffic work. > > As always, as I hope we all remember DMARC alignment doesn't mean not spam, > and you still do all of the stuff you do to sort your mail. This scheme > depends on the forwarders you authorize being well-behaved. That's why I > am concerned that senders need to be selective about who they allow to > forward. Yep. I like the proposal, but for me the only question left is: (how) will this scale? I'm not (yet) convinced it will. /rolf