Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Jim Fenton]

On 2 Dec 2020, at 6:09, Dave Crocker wrote:


   *none*: The Domain Owner offers no expression of concern.

   *quarantine:* The Domain Owner considers such mail to be
   suspicious. It is possible the mail is valid, although the
   failure creates a significant concern.

   *reject: *The Domain Owner considers all such failures to be a
   clear indication that the use of the domain name is not 
valid. 

   See Section 10.3
    for some
   discussion of SMTP rejection methods and their implications.


The problem is that _quarantine_ and _reject_ are imperative verbs. The 
specification can use any definition, but if it uses imperative words, 
they are going to be taken as imperative.


Maybe _discardable_ should be used instead.

Why do I have a feeling of deja vu?

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Jim Fenton]

On 2 Dec 2020, at 1:47, Laura Atkins wrote:

p=quarantine is quite useful, particularly for those folks who are 
trying to get to a p=reject state.


In practice, senders who publish p=none don’t find all of the 
indirect mail flows as some mailing lists do nothing to transform the 
5322.from address for a p=none policy. Senders have found that when 
they switch from p=none to p=quarantine pct=0 they regularly find mail 
that was not failing for a p=none.


I’m really confused by this. It sounds like the 5322.from address 
rewriting is creating additional errors that didn’t exist beforehand, 
and that’s the opposite of the intended purpose. Isn’t the purpose 
of rewriting the 5322.from address to change the domain to that of the 
mediator, which should redirect reporting to the mediator rather than 
the original sender?


-Jim

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Jim Fenton]

On 1 Dec 2020, at 17:42, Steven M Jones wrote:


On 12/1/20 4:16 PM, Douglas Foster wrote:


I really hope no casual readers get the impression that DMARC bypasses 
spam filtering. DMARC evaluations are expected to be independent of 
spam evaluations. If there's any overlap here, perhaps it would be for 
DMARC (and/or underlying protocols) to provide reliable domain 
attribution to drive a local policy decision about filtering.


Agree about not bypassing spam filtering. But not about the 
“independent of spam evaluations” part. Spam filters are going to 
use any message characteristic that they find useful, including whether 
the message is signed, passes SPF, has an aligned From address, has a 
DMARC record of a certain type, etc. to make a decision. It’s what 
spam filters do, and we have no say about that.


-Jim

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

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

if you're trying to make a point about the bloat, you might actually get 
your facts straight. ARC adds an additional DKIM signature and a Seal. i 
have no idea what a X-Google-DKIM-Signature is and is not relevant.


Mike

On 12/2/20 6:55 PM, John R. Levine wrote:
PS: you're adding X-Google-DKIM-Signature which nobody knows what its 
utility is to your bloat total for dramatic effect.


Um, it was there when your message arrived here.  Complain to your 
mail provider.



On 12/2/20 6:33 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
But why bother?  The IANA header field registry currently has 419 
entries. Why is it a crisis if it increases to 422 rather than 420?


It does a lot more than that:


We've been through this all before and none of these are 
persuasive.  For

example:


3) It adds a lot more bloat to the headers


The message you just sent arrived with 4600 bytes of header (see 
below) and under 2K of text.  Copies that went through the dmarc 
mailing list probably had at least another 1K of header.


If header bloat were ever an issue, it hasn't been for decades.

R's,
John
 snip ---
Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com
X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 
tests=BAYES_00,DCC_REPUT_00_12,

DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE
autolearn=no autolearn_force=no version=3.4.4
Delivered-To: jo...@iecc.com
Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -
Delivered-To: virtual-taugh-jo...@taugh.com
Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -
Authentication-Results: iecc.com; spf=pass 
spf.mailfrom=m...@fresheez.com spf.helo=mail-pl1-x62a.google.com 
smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass 
header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 
header.a=rsa-sha256 header.b="vvoZ+Loe"

Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a])
  by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
  with ESMTPS via TCP6 (port 38853/25) id 665297367
  tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 
2020 23:30:06 -

Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5
    for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mtcc-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding:content-language;
    bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar
KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji
+Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3
l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S
VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS
 Y3Nw==
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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu
TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap
82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa
GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS
T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz
 2CWA==
X-Gm-Message-State: 
AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD

chdQCnyR1XB3fAEw5oIqGysS4Q==
X-Google-Smtp-Source: 
ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw==
X-Received: by 2002:a17:90a:c4f:: with SMTP id 
u15mr287214pje.177.1606951804840;

    Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Return-Path: 
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. 
[107.182.42.33])
    by smtp.gmail.com with ESMTPSA id 
x7sm158495pfn.85.2020.12.02.15.30.03

    (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
    Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Subject: Re: [dmarc-ietf] ARC questions
To: John R Levine , Brandon Long 
Cc: IETF DMARC WG 
References: <20201124020453.afdc027ce...@ary.qy>
 
 
 
 
 <1eed8278-4efa-4abc-15e0-2efcf014e...@mtcc.com>
 
 <446d491b-100a-9813-6463-2294f67bb...@mtcc.com>
 
 <4190de2d-9f17-06d5-6354-30c989eec...@mtcc.com>
 <17d886fd-49fd-28d8-f8e4-7caf2e859...@taugh.com>
 
 
From: Michael Thomas 
Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b1613...@mtcc.com>
Date: Wed, 2 Dec 2020 15:30:01 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.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

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

On 12/2/20 6:33 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
But why bother?  The IANA header field registry currently has 419 
entries. Why is it a crisis if it increases to 422 rather than 420?


It does a lot more than that:


We've been through this all before and none of these are persuasive.  For
example:

So you just dismissed every other thing i wrote as insignificant and 
picked off one that is just calling into question why this is worth it. 
Sorry you are not persuasive. And you most certainly have not answered 
the central question of what having the previous auth-res is useful for 
in practice to add all of this heavy and untested machinery.


Mike

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

Re: [dmarc-ietf] ARC questions

[John R Levine]

On Wed, 2 Dec 2020, Michael Thomas wrote:
But why bother?  The IANA header field registry currently has 419 entries. 
Why is it a crisis if it increases to 422 rather than 420?


It does a lot more than that:


We've been through this all before and none of these are persuasive.  For
example:


3) It adds a lot more bloat to the headers


The message you just sent arrived with 4600 bytes of header (see below) 
and under 2K of text.  Copies that went through the dmarc mailing list 
probably had at least another 1K of header.


If header bloat were ever an issue, it hasn't been for decades.

R's,
John
 snip ---
Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 required=4.4 tests=BAYES_00,DCC_REPUT_00_12,

DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE
autolearn=no autolearn_force=no version=3.4.4
Delivered-To: jo...@iecc.com
Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -
Delivered-To: virtual-taugh-jo...@taugh.com
Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -
Authentication-Results: iecc.com; spf=pass spf.mailfrom=m...@fresheez.com 
spf.helo=mail-pl1-x62a.google.com smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass 
header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256 
header.b="vvoZ+Loe"
Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a])
  by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
  with ESMTPS via TCP6 (port 38853/25) id 665297367
  tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 2020 23:30:06 
-
Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5
for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=mtcc-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-transfer-encoding:content-language;
bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar
 KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji
 +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3
 l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S
 VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS
 Y3Nw==
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=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu
 TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap
 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa
 GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS
 T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz
 2CWA==
X-Gm-Message-State: AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD
chdQCnyR1XB3fAEw5oIqGysS4Q==
X-Google-Smtp-Source: 
ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw==
X-Received: by 2002:a17:90a:c4f:: with SMTP id u15mr287214pje.177.1606951804840;
Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Return-Path: 
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33])
by smtp.gmail.com with ESMTPSA id x7sm158495pfn.85.2020.12.02.15.30.03
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Subject: Re: [dmarc-ietf] ARC questions
To: John R Levine , Brandon Long 
Cc: IETF DMARC WG 
References: <20201124020453.afdc027ce...@ary.qy>
 
 
 
 
 <1eed8278-4efa-4abc-15e0-2efcf014e...@mtcc.com>
 
 <446d491b-100a-9813-6463-2294f67bb...@mtcc.com>
 
 <4190de2d-9f17-06d5-6354-30c989eec...@mtcc.com>
 <17d886fd-49fd-28d8-f8e4-7caf2e859...@taugh.com>
 
 
From: Michael Thomas 
Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b1613...@mtcc.com>
Date: Wed, 2 Dec 2020 15:30:01 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.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___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Advancing ARC?

[Michael Thomas]

Was/is there a plan to advance ARC to standards track? I see in the rfc 
that there are some questions that assumedly need to be answered. I 
would hope that that list is not exhaustive and that other questions can 
be posed to determine whether to go forward.


As I've said in the other thread, it's been extremely hard to tease out 
what problem is actually being solved, and especially whether that 
problem is worth being solved in the first place. It seems to be that 
the Auth-Res from the intermediate mangler has some value, but I have 
been unsuccessful finding out why it is valuable.


That leads me to think two things are probably needed:

1) A problem statement/requirements which details why the mechanism is 
valuable and why it can't be done with existing technology


2) An informational report whether the experiment had value and 
especially hard numbers rather than anecdotes. As in why should I trust 
ARC to turn my policy to "reject" and not suffer consequences?


Mike

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John Levine]

In article  you write:
>On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
>> We can adapt the approach MTA-STS uses in RFC 8460.
>> 
>> If rua= has an https URI, the reporter uses HTTP POST to that URI with
>> the report as an uncompressed or gzipped XML file as the POST body.
>
>TL;DR: neutral
>
>Delivery via https, with possible retry queue, imposes an additional burden to 
>report producers.  Since there seem to be less producers than consumers, it 
>may 
>be fair to grant the choice of transport to the former.  That is, to make the 
>mailto scheme mandatory and https optional.
>
>Even if the the spec allows consumers to specify the transport they like 
>better, there will probably be producers which only honor one type.  So, 
>consumers may want to specify both schemes anyway.

That seems reasonable to make mailto: mandatory and https: optional if
you have an rua tag. I wouldn't expect reporters to provide queueing
if https fails, and mailto is certainly not going away. But if both
are available, http is a lot faster.

>A better means to control report size is to gauge the reporting interval.

When this came up before someone said that reports can be extremely
large, many megabytes.  An HTTP POST or PUT is a much better way to send that.

Here's another nit: POST doesn't pass the report's filename. There
should be a copy of the name in the header of the gzip data, but
semantically it would be better to do an https PUT to
/. That also has the advantage of being idempotent so
if it puts the same file twice the server can tell it's a duplicate.

R's,
John

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

Re: [dmarc-ietf] ARC questions

[John R Levine]

Which could trivially be added as an extension to DKIM and Auth-Res negating 
the need for the Seal altogether since DKIM can directly sign the old 
(renamed) auth-res. I can understand for an experiment not wanting to touch 
dkim or auth-res, but for something standards track less is more.


I still don't get it.  I suppose the ARC group could have done something 
to register extra tags for DKIM-Signature and A-R and tried to do 
something about the fact that if a message passes through the same network 
twice, the first A-R will be deleted, and try and find and turn off all of 
the places where mailing lists helpfully delete DKIM signatures that no 
longer are valid, and what they came up with wouldn't work a whole lot 
worse than ARC does.


But why bother?  The IANA header field registry currently has 419 entries. 
Why is it a crisis if it increases to 422 rather than 420?


Regards,
John Levine, jo...@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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Benny Lyne Amorsen]

Dotzero  writes:

> p= DID NOT mistakenly choose to use the language of receiver
> actions. p= represents the domain-owner request to the receiver as to
> the disposition of messages which fail to validate. Any reading of
> "concern" is supposition on the part of yourself or other self
> appointed interpreters of the mind of the domain-owner or
> administrator. [..] This is an interoperability standard, not a
> seance.

Am I particularly thin-skinned for considering this language
inflammatory?

The thing is, domain owners can request anything they want, but why
should anyone listen? Particularly if they are rude about it instead of
asking nicely.

When someone brings up a concern they have and explain why it is of
benefit to either the recipient or the community to take certain
actions, that will likely be heard. However, unexplained edicts are
unlikely to be taken very seriously.

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

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

On 12/2/20 12:35 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
different in that respect. In fact as far as I can tell they are 
identical modulo the i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level 
N tells you whether the ARC and DKIM signatures were good at level N-1.



That's why I said "modulo the i= difference"


Well, yeah.  That i= is why we have ARC seals rather than just using a 
DKIM signature.


Remember that ARC is only useful if the last system sending the 
message to you is reasonably trustworthy, not in the sense that it 
never sends spam, but in the sense that its ARC tells the truth about 
what it saw.  That's a low bar that any mailing list should be able to 
meet.


Which could trivially be added as an extension to DKIM and Auth-Res 
negating the need for the Seal altogether since DKIM can directly sign 
the old (renamed) auth-res. I can understand for an experiment not 
wanting to touch dkim or auth-res, but for something standards track 
less is more.


Mike

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

Re: [dmarc-ietf] ARC questions

[John R Levine]

On Wed, 2 Dec 2020, Michael Thomas wrote:
different in that respect. In fact as far as I can tell they are identical 
modulo the i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.



That's why I said "modulo the i= difference"


Well, yeah.  That i= is why we have ARC seals rather than just using a 
DKIM signature.


Remember that ARC is only useful if the last system sending the message to 
you is reasonably trustworthy, not in the sense that it never sends spam, 
but in the sense that its ARC tells the truth about what it saw.  That's 
a low bar that any mailing list should be able to meet.


Regards,
John Levine, jo...@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

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

On 12/2/20 12:31 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
Ignoring the existing usage of DKIM, DKIM+A-R would only work for a 
single hop, and lead to some complication compared to the other DKIM 
signatures already on the message.


Wait, what? a DKIM signatures survives until it encounters an 
intermediary that alters the message in a breaking manner. 
Arc-Signatures are no different in that respect. In fact as far as I 
can tell they are identical modulo the i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.




That's why I said "modulo the i= difference"

Mike

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

Re: [dmarc-ietf] ARC questions

[John R Levine]

On Wed, 2 Dec 2020, Michael Thomas wrote:
Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single 
hop, and lead to some complication compared to the other DKIM signatures 
already on the message.


Wait, what? a DKIM signatures survives until it encounters an intermediary 
that alters the message in a breaking manner. Arc-Signatures are no different 
in that respect. In fact as far as I can tell they are identical modulo the 
i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.


R's,
John

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

Re: [dmarc-ietf] Domains

[Murray S. Kucherawy]

On Tue, Dec 1, 2020 at 5:44 PM Joseph Brennan  wrote:

> I want to ask again why DMARC should consider any domain other than
> the one in the Header From. The purpose of DMARC should be stated
> right at the top of the proposed standard. It is intended to control
> use of a domain in the Header From. If the Header From has
> bla...@example.com, the DMARC record for _dmarc.example.com should
> apply.
>
> It does not make sense to me to say that if the Header From is
> u...@alpha.example.com, and there is no _dmarc.alpha.example.com
> record, then recipient systems should continue to look for
> _dmarc.example.com and apply the dmarc rule there. I know of no other
> standard that requires this type of relationship. This is something
> new. It will require administrators to continually check what their
> sub- and supra-domains are doing in order to escape interference by
> DMARC records they did not create. I think this is unreasonable. Only
> domains interested in applying DMARC should be involved with DMARC.
> Others should be able to do what they want. I know that otherwise will
> out rule out DMARC for the "columbia.edu" domain that I administer.
>

If DMARC is thus constrained and you have a "p=reject" on "columbia.edu"
only, then nothing stops me from generating unauthenticated email with a
>From field indicating "foobar.columbia.edu" for any subdomain "foobar",
whether or not it actually exists in the DNS.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

[Brotman, Alex]

Folks,

While this ticket/enhancement specifically mentions ARC, I could perhaps see 
the usefulness in other places.  It seems like it would be more beneficial to 
create a method by which other documents could provide XML- based "extensions" 
to the report.  This would allow mechanisms relying on DMARC to independently 
define their reporting schema to be included in DMARC aggregate reports.  
Alternately, we could focus specifically on ARC, and work to include that in 
the base XML.  This means that any later reporting requirements could again 
require changes to the core drafts.

If possible, we'd like to see if we can reach some consensus within a few weeks.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 12/1/20 6:21 PM, Brandon Long wrote:



On Tue, Dec 1, 2020 at 10:07 AM Michael Thomas > wrote:



On 11/30/20 8:56 PM, Brandon Long wrote:

Right, some of the other dkim-light or diff concepts we discussed
would be better than using l=

We again got hung up on the 100% solution, though... something
that handled subject-prefix and
footer in a transport agnostic way might have worked.  The fact
that DKIM isn't transport agnostic
is an achilles heel to even that, though, since we'd have to come
up with a new canonicalization
and get it to widespread adoption before the simple diff could
work.  Or require mailing lists to
be a lot more strict in how they do their email rewriting, but I
imagine that's harder work than
even ARC.


Frankly all it would take is a google or another large mail
provider to publicly state that unless a mailing list supports BCP
XYZ, your mail will be subject to very strict scrutiny and likely
not delivered to get the attention of mailing list providers. That
was my suggestion back in the day but it was scoffed at because
people could point to some edge case that generates .001% of list
traffic and thus invalidating the entire approach. The best is
definitely the enemy of the good here.

People really need to keep in mind that service provider email is
not the only game in town. That point keeps getting lost.

arguably we're all here because a large mail provider did make such a 
change (though to be fair, there were plenty of others who wanted to 
make that change).


While Google might be able to help move things along, there would need 
to be strong community support for that, no one wants to go this alone 
and look like the big bully.


I also think that you're overestimating what we could do. Ultimately, 
we serve our customers, and they want their legitimate email, even if 
it doesn't support BCP XYZ.




Well obviously the BCP would have to come first and there would have to 
be community buy-in to create such a BCP, but a Google participating in 
creating such a BCP ought pique the interests of people who make mailing 
list software who obviously have the biggest stake in this.


It occurs to me that it might not even be a BCP. Maybe mailing lists can 
just create a header with sed commands to undo its changes :)


Mike

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Murray S. Kucherawy]

On Wed, Dec 2, 2020 at 6:47 AM Dotzero  wrote:

> p= DID NOT mistakenly choose to use the language of receiver actions. p=
> represents the domain-owner request to the receiver as to the disposition
> of messages which fail to validate. Any reading of "concern" is supposition
> on the part of yourself or other self appointed interpreters of the mind of
> the domain-owner or administrator. The vocabulary is perfectly fine as it
> accurately describes the request being made. It makes no attempt to read
> the underlying reasoning behind the request because, surprisingly, there is
> likely to be a wide range of underlying reasoning behind why various
> domains publish the policies they publish. This is an interoperability
> standard, not a seance.
>

Not sure I agree.

I have long held a quiet dislike for "quarantine" because that has a
particular meaning to milter implementations.  Specifically, milter can
render one of several final results about a message, one of which is
actually called "quarantine".  It means "park this in the queue
indefinitely until a human decides what to do with it."  There's no
indication to the operator that such a job is waiting for review unless one
goes and looks for such things.  The upshot of this is that quarantining in
that environment can become a denial of service attack if I send you enough
messages that end up getting handled that way and your queue disk fills, or
the queue takes an inordinately long time to process because these have
piled up and need to be inspected.

Certainly not all implementers will trip on this (maybe none will) but it's
an argument to me in favor of picking a word or set of words that describe
what the domain owner thinks of the message, rather than what the domain
owner thinks you should do with it.

-MSK (hatless)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Domains and tree walk

[Todd Herr]

On Tue, Dec 1, 2020 at 9:50 PM John Levine  wrote:

>  In organizations that are not universities, the entity that
> is responsible for the registered domain generally sets policies for
> the whole organization, and a good deal of the DMARC design is there
> to let them figure out who is sending mail with their name on it from
> any of their subdomains and identify and adjust senders whose mail
> doesn't match the policy.
>
>
This is, I think, one of the most underappreciated features of DMARC. With
p=none, a proper rua= value, and enough time, one can collect all the
information needed to address any authentication shortcomings within a
designated portion of the DNS namespace before moving forward to p=reject,
assuming that that is one's goal with a DMARC implementation. Even for less
lofty goals such as ensuring that all mail is properly DKIM signed, or that
the SPF record properly enumerates all mail sources, I can't think of a
better tool than DMARC aggregate reports for ferreting out that third party
that the Marketing department hired to send mail on the company's behalf,
or locating that one mail stream emanating from the "server" sitting at the
side of Eddie the Engineer's desk.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Dotzero]

On Wed, Dec 2, 2020 at 9:29 AM Benny Lyne Amorsen 
wrote:

> Dave Crocker  writes:
>
> >  p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy
> >  records). Indicates the severity of concern the domain owner has, for
> >  mail using its domain but not passing DMARC validation. Policy
> >  applies to the domain queried and to subdomains, unless subdomain
> >  policy is explicitly described using the "sp" tag. This tag is
> >  mandatory for policy records only, but not for third-party reporting
> >  records (see Section 7.1). Possible values are as follows:
> >
> >  none: The Domain Owner offers no expression of concern.
> >
> >  quarantine: The Domain Owner considers such mail to be suspicious. It
> >  is possible the mail is valid, although the failure creates a
> >  significant concern.
> >
> >  reject: The Domain Owner considers all such failures to be a clear
> >  indication that the use of the domain name is not valid.  See Section
> >  10.3 for some discussion of SMTP rejection methods and their
> >  implications.
>
> Perhaps, in retrospect, the p= should have had something like the
> following values:
>
> none
> untrustworthy
> invalid
>
> p= mistakenly chose to use the language of receiver actions to describe
> what is actually domain-owner judgements. This is unfortunate, since it
> risks making the sender believe that it is possible to dictate receiver
> policy.
>
>
p= DID NOT mistakenly choose to use the language of receiver actions. p=
represents the domain-owner request to the receiver as to the disposition
of messages which fail to validate. Any reading of "concern" is supposition
on the part of yourself or other self appointed interpreters of the mind of
the domain-owner or administrator. The vocabulary is perfectly fine as it
accurately describes the request being made. It makes no attempt to read
the underlying reasoning behind the request because, surprisingly, there is
likely to be a wide range of underlying reasoning behind why various
domains publish the policies they publish. This is an interoperability
standard, not a seance.

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Dave Crocker]

On 12/2/2020 6:28 AM, Benny Lyne Amorsen wrote:

Perhaps, in retrospect, the p= should have had something like the
following values:

none
untrustworthy
invalid

p= mistakenly chose to use the language of receiver actions to describe
what is actually domain-owner judgements. This is unfortunate, since it
risks making the sender believe that it is possible to dictate receiver
policy.

Perhaps new names can be found, and the old ones kept as historical
aliases?


Yes!  I would deeply wish we could change the vocabulary to something 
like this.


However I'd expect too much persistence, due to operational history.  
Still, it would be really nice if the working group could convince 
itself to specify a better vocabulary.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Benny Lyne Amorsen]

Dave Crocker  writes:

>  p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy
>  records). Indicates the severity of concern the domain owner has, for
>  mail using its domain but not passing DMARC validation. Policy
>  applies to the domain queried and to subdomains, unless subdomain
>  policy is explicitly described using the "sp" tag. This tag is
>  mandatory for policy records only, but not for third-party reporting
>  records (see Section 7.1). Possible values are as follows:
>
>  none: The Domain Owner offers no expression of concern. 
>
>  quarantine: The Domain Owner considers such mail to be suspicious. It
>  is possible the mail is valid, although the failure creates a
>  significant concern.
>
>  reject: The Domain Owner considers all such failures to be a clear
>  indication that the use of the domain name is not valid.  See Section
>  10.3 for some discussion of SMTP rejection methods and their
>  implications.

Perhaps, in retrospect, the p= should have had something like the
following values:

none
untrustworthy
invalid

p= mistakenly chose to use the language of receiver actions to describe
what is actually domain-owner judgements. This is unfortunate, since it
risks making the sender believe that it is possible to dictate receiver
policy.

Perhaps new names can be found, and the old ones kept as historical
aliases?


/Benny


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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Dave Crocker]

On 12/2/2020 3:15 AM, Дилян Палаузов wrote:

On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote:
 My email archive indicates it hasn't gotten any discussion at all. 

This was discussed under the subject “Abolishing DMARC policy
quarantine” in June 2019.



I see that was quite a lengthy thread.  Thanks for the research. My 
assessment was based on looking for the cited ticket number.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Dave Crocker]

On 12/2/2020 1:55 AM, Steven M Jones wrote:


hen he commanded the tide to halt)" -- the latter phrasing is just 
/slightly/ too ponderous even for me... Does "requesting" really imply 
control over the outcome, rather than the expression of a desire?


My point is that I think the language MUST NOT be cast as saying 
anything about receiver behavior.  Rather, it must only talk about the 
domain owner's assessment of message validity, or the like.



I'd frankly recommend changing the labels for these expressions, but 
expect folk to argue that there is too much installed base and 
operational history.


Ah, now maybe we're getting somewhere. But if you toss that notion 
out, you have to follow up with an example or two. Which labels, and 
changing them in what way?


Well, I share that view of accompanying obligation... when I can.  I 
couldn't think of a reasonable 'hook' for the language, in the previous 
message.


But above, I see I wrote a perspective that might be useful: validity.

So, perhaps, something like:

   *p*: Domain Owner Assessment Policy (plain-text; REQUIRED for policy
   records). Indicates the severity of concern the domain owner has,
   for mail using its domain but not passing DMARC validation. Policy
   applies to the domain queried and to subdomains, unless subdomain
   policy is explicitly described using the "sp" tag. This tag is
   mandatory for policy records only, but not for third-party reporting
   records (see Section 7.1
   ). Possible values
   are as follows:

   *none*: The Domain Owner offers no expression of concern.

   *quarantine:* The Domain Owner considers such mail to be
   suspicious. It is possible the mail is valid, although the
   failure creates a significant concern.

   *reject: *The Domain Owner considers all such failures to be a
   clear indication that the use of the domain name is not valid. 
   See Section 10.3
    for some
   discussion of SMTP rejection methods and their implications.

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Dotzero]

You are absolutely correct. It also doesn't prevent direct domain abuse
when someone uses snail mail.

Michael Hammer

On Tue, Dec 1, 2020 at 10:09 PM Dave Crocker  wrote:

> On 12/1/2020 7:01 PM, Dotzero wrote:
> > DMARC does one thing and one thing only - It mitigates direct domain
> > abuse.
>
> It mitigates direct domain abuse in the rfc5322.From field.
>
> It doesn't mitigate domain abuse anywhere else.
>
> d/
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Дилян Палаузов]

Hello,

On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote:
> On 12/1/2020 3:17 PM, John R Levine wrote:
> > #39 proposes that we remove p=quarantine.  I propose we leave it
> > in, 
> > even if it
> > is not very useful, because trying to remove it would be too
> > confusing. 
> 
> process, I suggest this issue gets some meaningful discussion.  My
> email 
> archive indicates it hasn't gotten any discussion at all.

This was discussed under the subject “Abolishing DMARC policy
quarantine” in June 2019.  There was no consensus.  SMTP offers this
distinciton and this is mirrored in DMARC.  In particular, senders are
free to publish p=quarantine and receipients are free to interpret it
as p=reject.  Senders can publish p=reject and receivers are free to
interpret it as p=quarantine.

Moreover, some destination addresses do not have the concepts of a
quarantine.  E.g an address that accepts commands for mailing lists
managements.  Such addresses can either accept or reject the message -
there is no quarantine, so interpreting published p=quarantine as
p=reject is feasible.

Recalling the discussion from June 2019 I do not count on any different
consensus, if it the discussion happens here again now.

Greetings
  Дилян

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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:

On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely  wrote:

On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:

On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely  wrote:

On 25/11/2020 20:16, Michael Thomas wrote:

On 11/25/20 11:11 AM, Alessandro Vesely wrote:

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:

Without resorting to ARC, it is still possible to validate author
domain's signatures directly if the MLM just adds a subject tag
and a footer>

I agree that ARC isn't really needed to do this (trust the last hop
from the MLM and determine the original authenticity from the MLM's
perspective)

I didn't mean to trust the MLM.  I meant remove the subject tag and
the footer, then the original DKIM signature verifies.  See:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/


When I was at Cisco, with l= and some subject line heuristics I could get
probably like 90+% verification rate across the entire company, a company that
uses external mailing lists a lot. Definitely not 100% though.



DKIM itself is not 100%.  You always have lines beginning with "From " or
occasional autoconversions.

l= doesn't cover multipart/alternative nor Content-Transfer-Encoding:
base64. In addition, the DKIM spec discourages its usage and suggests
that "Assessors might wish to ignore signatures that use the tag.">>


Right, some of the other dkim-light or diff concepts we discussed would be
better than using l=

We again got hung up on the 100% solution, though... something that handled
subject-prefix and footer in a transport agnostic way might have worked.


I'm not clear about the meaning of "100%".  If an author domain puts no
DKIM signatures, there is no way to verify them.  Hence, some compliance of
the author domain has to be required.

The same holds for conditional signatures.

The same holds for MLM transformations.



Yes, by 100% I meant of messages that were already authenticated and 
therefore should continue to be authenticated through the relay.



That's ARC.  If a message lacks DKIM and was SPF-authenticated, there's no way 
it can continue to be authenticated through a relay.


OTOH, mailing lists and relays are two different beasts.  For one thing, it is 
very unusual for a mailing list to send to another mailing list.  Thus, we can 
safely specify a non-stackable authentication method.



Some of the conditional signatures of the "include a diff you can remove to 
validate the original" attempt seemed to fail on the theory that there were

too many things that couldn't be handled.  Ie, if your relay removes
attachments, including them back in a diff kind of breaks the whole point of
that... but how common is that (even less now with Yahoo Groups gone, but
possibly still some av/malware relays still do this).


Not to mention anonymous lists, which remove the OP identity completely.  They 
are DMARC-proof by themselves, with no additional twists.  My draft restricts 
footers to text/plain MIME type, to overcome the objection to l=.  Hence, if a 
list appends HTML parts (e.g. to use ), it doesn't qualify as DMARC-proof.



I think that one issue we've had is that DMARC is very mechanical and 
straight-forward, so anything that's fuzzy in response seems more

complicated.


It may seem fuzzy, but it's not.  The ietf list (i...@ietf.org), for example, 
adds no subject tag and no footer.  DKIM signatures should remain valid, then. 
 Yet, if posters sign Sender:, they fail.  I wouldn't call that fuzziness.  It 
is the very nature of the spec.  If you sign Received:, no relay can hold your 
signature over.



Best
Ale
--



















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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Alessandro Vesely]

On Wed 02/Dec/2020 00:20:12 +0100 Douglas Foster wrote:


2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC 5321 
Mail From is a different domain.
All this tells us is that the Mail From domain is a client on that system.  
  Being a client of a hosting service does not give the right to speak for the 
hosting service.



What if I wanted to collect bounces at a different domain?


OTOH, an MSA can relay using a different HELO (or even a different IP), 
according to the right (categorization) it wants to supply.



Best
Ale
--















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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Alessandro Vesely]

On Tue 01/Dec/2020 23:17:15 +0100 John R Levine wrote:
We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.


[...]

I think that for SPF, it should be considered a pass if either the MAIL FROM
or the HELO is aligned and results in a pass at the SPF level.


+1, especially for bounces.



If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.



If alignment is not known at step 4, both domain names (if different) must be 
passed to step 5.



Best
Ale
--



















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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Alessandro Vesely]

On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.


[...]

We can adapt the approach MTA-STS uses in RFC 8460.

If rua= has an https URI, the reporter uses HTTP POST to that URI with
the report as an uncompressed or gzipped XML file as the POST body.



TL;DR: neutral

Delivery via https, with possible retry queue, imposes an additional burden to 
report producers.  Since there seem to be less producers than consumers, it may 
be fair to grant the choice of transport to the former.  That is, to make the 
mailto scheme mandatory and https optional.


Even if the the spec allows consumers to specify the transport they like 
better, there will probably be producers which only honor one type.  So, 
consumers may want to specify both schemes anyway.


A better means to control report size is to gauge the reporting interval.

The addition of the new transport doesn't seem to simplify things.  I fail to 
see the advantage, but I can cope with it if it comes.




Best
Ale
--



















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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Laura Atkins]

> On 1 Dec 2020, at 23:17, John R Levine  wrote:
> 
> We would like to close this ticket by Dec 15, two weeks from now, so short
> trenchant comments are welcome.
> 
> #39 proposes that we remove p=quarantine.  I propose we leave it in, even if 
> it
> is not very useful, because trying to remove it would be too confusing.


p=quarantine is quite useful, particularly for those folks who are trying to 
get to a p=reject state. 

In practice, senders who publish p=none don’t find all of the indirect mail 
flows as some mailing lists do nothing to transform the 5322.from address for a 
p=none policy. Senders have found that when they switch from p=none to 
p=quarantine pct=0 they regularly find mail that was not failing for a p=none. 

p=quarantine should stay in, especially if the goal is to encourage senders to 
publish a p=reject. It’s a valuable step in the deployment process. 

laura 

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

Laura Atkins
Word to the Wise
la...@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