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

[Alessandro Vesely]

On Thu 10/Dec/2020 02:23:10 +0100 Michael Thomas wrote:

On 12/9/20 4:04 PM, Brandon Long wrote:


When you switch to p=quarantine pct=0, no one should apply quarantine (so 
it's equivalent to p=none), but Groups will start rewriting, thereby removing 
all of those failures from your reports.  Yes, you won't see those messages 
in the reports at all anymore because they are no longer using your domain.



There is a reporting feature of mlm-transform that might be worth considering 
apart from any indirect mailflow revival.  By adding an Original-From: header 
field —a copy of From: on the first relay— a domain owner can ask to receive 
aggregate reports even if From: was rewritten by a MLM.



Is that what's going on with some of the messages I see on this list? That 
seems pretty awful from a security standpoint. Basically you're engineering a 
lookalike From address attack. The one big disappointment from my standpoint is 
that MUA's don't seem to be using auth-res, etc, to do some basic annotation. 
At least Thunderbird.



You need to install DKIM Verifier[*].  It reads A-R and displays some results.


Best
Ale
--

[*] https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/




























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

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

[Michael Thomas]

On 12/9/20 4:04 PM, Brandon Long wrote:



When you switch to p=quarantine pct=0, no one should apply quarantine 
(so it's equivalent to p=none), but Groups will start rewriting, 
thereby removing all of those failures from your reports.  Yes, you 
won't see those messages in the reports at all anymore because they 
are no longer using your domain.


Is that what's going on with some of the messages I see on this list? 
That seems pretty awful from a security standpoint. Basically you're 
engineering a lookalike From address attack. The one big disappointment 
from my standpoint is that MUA's don't seem to be using auth-res, etc, 
to do some basic annotation. At least Thunderbird. And I don't recall 
gmail doing anything either.


Mike


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

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

[Jesse Thompson]

On 12/3/20 8:21 AM, Todd Herr wrote:
> On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins  > wrote:
> 
> 
> 
>> On 3 Dec 2020, at 06:03, Jim Fenton > > wrote:
>>
>> 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?
> 
> What I am trying to say is that as I understand it from the folks who 
> professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of 
> the deployment process. There are DMARC failures that go undetected in a 
> p=none situation but that is detected in a p=quarantine  pct=0 situation.  My 
> understanding was this was related to indirect flows through mailing lists 
> and how mailing lists are handling the header transformation but it’s 
> possible I got that piece incorrect. 
> 
> 
> Time was (and may still be) that there was a very specific type of mailing 
> list for which p=quarantine, pct=0 was required to get accurate DMARC 
> reporting, and that was for mail that transited Google groups. There've been 
> a couple of public discussions of the topic over on mailop, including a 
> thread from April 2018 with the subject of "DMARC p=quarantine pct=0". 

p=quarantine pct=0 is a very useful strategy

1) It allowed us to find the mailing lists that don't munge from the From 
header - which would subsequently be problematic once we moved to pct=100

2) It allowed us to segregate the user complaints.  With a large change 
initiative you need to reduce the number of uncontrolled variables at any one 
time.  If we went straight to pct=100 then there would be a mix of people 
complaining about from munging mixed in with complaints about delivery.  
Confusion would ensue and the entire premise of DMARC would have been called 
into question.  By using an incremental process it's easier to deflect people 
complaining about the Stage 1 problems after moving to Stage 2.

3) It allowed us to discover email receivers who ignore pct.  It was annoying, 
but also a convenient gift in disguise, since it allowed us to innocently blame 
the receiver when non-compliant senders objected to the necessary DMARC 
adaptations.

Jesse

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

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

[Hector Santos]

On 12/8/2020 6:24 AM, Дилян Палаузов wrote:> Hello,


I do no see the point of having all the discussions here, as nobody is
capable to read and understarstand all written emails in their whole
quantity.  I personally do not follow the discussions anymore, apart
from reading the subjects…



+1 Major Plus One. Its all deja vu.

Optional reading. I'll use this opportunity to express my key summary 
concerns as a long time DKIM and SPF implementation and commercial 
DKIM/SPF product vendor.


FWIW.

We have a Developer vs Administrative protocol design issue once 
again.  Too many philosophical "Administrative" subjective opinions 
trying to burn their idea into how IETF protocols is written and how 
implementations should behave operationally from an admin standpoint.


The DKIM POLICY model is a simple DNS lookup protocol, like SPF. It 
hasn't change since day one. DMARC is just the current rendition of 
the same thing since SSP - nearly 15 years - plus Reporting which was 
rejected for SSP and ADSP. Unlike SPF, what DKIM POLICY lacked 3rd 
party authorization protocol support.


But we had discussed the idea of using SPF softfails as a way to link 
together with a valid DKIM result. I recall Microsoft was exploring 
this methods as one the early explorers of ADSP. I liked the concept 
and explored it myself by looking at a possible "fuzzy" logic of the 
results, for example:


SPF PASS + DKIM PASS => Result PASS (confidence? 100%)
SPF SOFTWARE + DKIM PASS => Result PASS (confidence? 80%)
SPF NEUTRAL + DKIM PASS => Result PASS (confidence? 50%)
SPF FAIL + DKIM PASS => Result PASS (confidence? 0%, SPF fail preempts 
DKIM?)


But when it came to the new filtering protocols we were development, I 
was more interested in 100% or 0% deterministic protocol results. 
Anything in between is "fuzzy" and imo, can't make hard filtering 
unless we are now learning from the BIAS from Deep AI methods. For 
many, Pareto's 80% may be good enough for a filtering decision.


It is well established, DKIM POLICY works for 1st party signatures. We 
know this since day one.  The proof of concept was long set in stone 
and never to be killed.  We documented it in the early initial DKIM WG 
work productions - Thread Analysis and the Functional specification:


2006 RFC4686.txt  Analysis of Threats Motivating DKIM
2006 RFC5016.txt  Requirements for a DKIM Signing Practices Protocol

DKIM Policy is a powerful concept and in the words of one of the key 
cogs - "Its scary!"   Yes, for direct 1 to 1 private mail, you have a 
very powerful way to protect against domain spoofing in the same way 
SPF protects against unauthorized transports from unknown machines. 
SPF has its "in-direct" issue with routing of transports which I 
called a "Node Transition" point. DKIM was initially marketed as a 
solution to the node transition problem.


The stage was set. SSP with its 3rd party options, defined the ideas 
that a domain, like SPF, can describe which domain(s) can "notarize" 
the email.  But we did not have a way to define the authorized 3rd 
party domain.  The simple idea was to use tag= list, like a Access 
control list, for example


acl=ietf.org, gmail.com

which it reduced the need for another DNS lookup.  The acl= tag works 
for a small well organization network. But it does not scale.  ATPS 
was written to some some like of scalable using a zone record per 3rd 
party authorized domain. ATPS starts with a tag:


atps=1

and if enabled, receiver will check for the signer domain 
authorization ATPS record.   Does it work for all, no.  But it works 
for many and its been in production since 2012.


The DMARC or DKIM Policy protocol payoff does not come from positive 
passed results but rather with failed results because the protocol 
raises the bar by authorizing the receiver to reject or discard or 
quarantine a.k.a filter a message for the sake of the end-user.


Side note: There are four states for mail transport:

- Reject (SMTP does not accept it).
- Accept (user sees it in inbox, may be filtered with other things)
- Accept & Discard (lost to the user)
- Accept & quarantine (move to spam box, outside the main inbox stream)

The p= policy not only should keep quarantine, it should add p=discard

Unfortunately, a key moment came, in RFC5016, section 5. item 10, when 
the beginning of this long 14+ year "fight" with Mailing list 
administrators started, imo.  This was when all the heart aches became 
to occur, the major disagreements between Policy Advocates and Trust 
Advocates.


Read it carefully. Its about local policy (duh), but this last minute 
item provision altered the future of DKIM POLICY. Every since then, we 
had his long debate of DKIM-POLICY Model vs Mailing List Systems.  It 
basically lead to this protocol conclusion:


DKIM POLICY does not work for Mailing List unless the Mailing List 
Server vendors supports and honors the DKIM POLICY model - period. If 
it does not, it will have trouble integrating into a 

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

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

Hello,

I do no see the point of having all the discussions here, as nobody is
capable to read and understarstand all written emails in their whole
quantity.  I personally do not follow the discussions anymore, apart
from reading the subjects…

On Mon, 2020-12-07 at 17:55 -0800, Brandon Long wrote:
> 
> 
> On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy
>  wrote:
> > 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.
> > 
> 
> 
> Hmm, reading this thread, I think one missing feature in the dmarc
> spec is passing the expected disposition in the authres header, since
> presumably the evaluation is at smtp time, but the mailbox
> delivery itself would need to know it.  One could use the dmarc=
> names and look up the dmarc policy itself to also figure that out
> with some amount of work.

… and in July 2019 there was a discussion with the subject „Reporting
DMARC policy in A-R header fields“ on this mailing lists.    Below is
an off-list consensensus to put the applied policy in the A-R from that
thread, that was not sent eventually over the mailing list:

From: Scott Kitterman 
To: Дилян Палаузов 
Subject: Re: Reporting DMARC policy in A-R header fields
Date: Wed, 31 Jul 2019 10:49:32 +


I agree with your statement.  MTA does the percentage test and puts the
policy to be applied in A-R for the MDA to consume.

I'm working off my phone, so typing is slow.  I don't mind being more
verbose once I'm at my laptop, but it will have to wait.  Please let me
know if it's still uncertain.

Scott K

On July 31, 2019 10:35:15 AM UTC, "Дилян Палаузов"
 wrote:
>Hello Scott,
>
>you are too spare in your words.
>
>My understanding of the conversation so far is that only the MTA does
>the sampling for failed messages based on p= and
>pct= . The A-R header is supposed to carry information, whether the
>message validated or failed DMARC and for failed
>validation, what the MDA shall do with the message (basically
>quarantine or deliver).
>
>If you put the policy to be applied in the A-R, then it is not the
>policy from DNS, but rather the disposition to be
>applied.
>
>Regards
>  Дилян
>
>On Wed, 2019-07-31 at 10:28 +, Scott Kitterman wrote:
>> I suppose you could also add something like dmarc.pct=50 too, but I
>think that would add complexity to no benefit.  As long as you make
the
>sample decision once, it works out the same.  For the case where a
>message wasn't selected due to sampling then I'd put the policy to be
>applied in A-R so the MDA doesn't have to worry about the percentage.
>> 
>> Scott K
>> 
>> On July 31, 2019 5:56:26 AM UTC, "Дилян Палаузов"
> wrote:
>> > Hello Scott,
>> > 
>> > for p=quarantine; pct=50 if the MTA does the sampling and decides
>to
>> > quarantine, and forward the email to the MDA, how can the MDA know
>> > whether it shall quarantine the message or not?
>> > 
>> > Regards
>> >  Dilyan
>> > 
>> > On July 31, 2019 1:25:23 AM GMT+03:00, Scott Kitterman
>> >  wrote:
>> > > Since the status is per message, I think the MTA should do it
and
>> > other
>> > > than as perhaps a comment, it doesn't need to be in A-R.
>> > > 
>> > > Scott K
>> > > 
>> 

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

[John Levine]

In article  
you write:
>Anyways, +1 to keeping p=quarantine as a concept, but willing to go along
>with the consensus on naming.

I'm modestly in favor of keeping p=quarantine as a feature but utterly opposed
to changing the keywords such as "p=quarantine" in the DMARC record.

It's fine to improve the text in the RFC that describes what they mean but let
us please not make gratuitously incompatible changes.

R's,
John

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

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

[John Levine]

In article  you write:
>Maybe _discardable_ should be used instead.
>
>Why do I have a feeling of deja vu?

Gee, I can't imagine.

R's,
John

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

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

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

Post Scriptum: DMARC can say one of two things:
-- all mails for a domain are DKIM-signed and aligned, according to the
domain owner
-- not all mails for a domain are DKIM-signed and aligned (e.g. when
the DMARC policy is absent, or p=none) according to the domain owner

Does the DMARC specification need to propose what to do with emails in
the first case above, when the DKIM-signature is not-valid/aligned? 
Some people will say yes.  I say no: there is no need to give one of
two possible advices on this (and there is no means to enforce the
advice)

Anyway, as I said I do not expect any consensus on this.

Please consider including in the DMARC specificaiton a discussion on
what is reasonable, e.g as outlined in the email below, and elaborate
pros and cons on r=reject and r=quarantine.

As the topic is controversal, it shall be presented as controversal in
the specification.

I do not follow the discussions here, I suppose that by now is
addressed, that „p=quarantine;pct=0“ should be interperted as „do MLM-
mungling”, and p=none to mean „no MLM mungling”.

⇐
From: Vladimir Dubrovin 
To: Dotzero , Vladimir Dubrovin

CC: IETF DMARC WG , Дилян Палаузов

Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Date: Fri, 14 Jun 2019 19:25:02 +0300

Nope, I mean 2 different things. 

1. Why quarantine is useful (with pct=0).  

For example this mailing list (dmarc@ietf.org) performs From rewrite
(aka From munging), e.g. dubro...@corp.mail.ru is replaced with
dubrovin=40corp.mail...@dmarc.ietf.org. It's because corp.mail.ru has a
strict DMARC policy (reject). dotz...@gmail.com is not overwritten,
because gmail.com has p=none and ietf.org only overwrites From only for
domains with "quarantine" and "reject" policies. It's quite common
behavior.

If you are implementing DMARC for a new domain (let's say example.org),
you usually start with "p=none". With p=none you receive reports for
failed DMARC for different lists, like ietf.org. Before switching to
stronger policy (p=reject), you may want to know which mailing list
will still fail DMARC, and which lists perform From munging and, as a
result, do not fail DMARC. For this purpose, before switching to
"p=reject" it's useful to switch to "p=quarantine;pct=0". After this,
you will only see mailing lists without From munging in DMARC reports.

2. Why quarantine should not be used with pct different from 0

If you start enforsing strong DMARC policy with "p=reject" and you have
some previously uncatched misconfiguration (e.g. wrong envelope-from
address in some once-in-the-month mailing), you see DMARC failures  in
your logs and you can react to this failures and even re-send the
messages affected. 
If you start with "p=quarantine" you have no feedback except reports,
and reports are received with a huge lag (up to 2 days) and do not
provide sufficient information to catch the exact problem and you can
not re-send the quarantined messages.

⇒⇒





On Wed, 2020-12-02 at 13:15 +0200, Дилян Палаузов wrote:
> 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] Ticket #39 - remove p=quarantine

[Michael Thomas]

On 12/2/20 10:12 PM, Jim Fenton wrote:


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.

If it's not clear that it's "this is what I'd do" rather than some 
requirements language imperative then maybe that could be made more clear.




Why do I have a feeling of deja vu?



No comment.

Mike

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

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

[Todd Herr]

On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins  wrote:

>
>
> On 3 Dec 2020, at 06:03, Jim Fenton  wrote:
>
> 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?
>
>
> What I am trying to say is that as I understand it from the folks who
> professionally deploy DMARC, they regularly use p=quarantine pct=0 as part
> of the deployment process. There are DMARC failures that go undetected in a
> p=none situation but that is detected in a p=quarantine  pct=0 situation.
> My understanding was this was related to indirect flows through mailing
> lists and how mailing lists are handling the header transformation but it’s
> possible I got that piece incorrect.
>
>
Time was (and may still be) that there was a very specific type of mailing
list for which p=quarantine, pct=0 was required to get accurate DMARC
reporting, and that was for mail that transited Google groups. There've
been a couple of public discussions of the topic over on mailop, including
a thread from April 2018 with the subject of "DMARC p=quarantine pct=0".


-- 

*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

[Dave Crocker]

On 12/2/2020 10:12 PM, Jim Fenton wrote:

The problem is that /quarantine/ and /reject/ are imperative verbs.


As I said, I suspect that changing the vocabulary is not operationally 
practical  at this point.  It would be great for the folk already using 
DMARC to state a willingness to employ alternative vocabulary; but I'm 
not expecting them to.


If we get feedback to the contrary, we can have a vocabulary debate.  My 
own advice would be to avoid vocabulary that is directive about 
disposition and more declarative about status.


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

[Laura Atkins]

> On 3 Dec 2020, at 06:03, Jim Fenton  wrote:
> 
> 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?

What I am trying to say is that as I understand it from the folks who 
professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of 
the deployment process. There are DMARC failures that go undetected in a p=none 
situation but that is detected in a p=quarantine  pct=0 situation.  My 
understanding was this was related to indirect flows through mailing lists and 
how mailing lists are handling the header transformation but it’s possible I 
got that piece incorrect. 

p=quarantine is valuable for other reasons as well, and I think it should be 
kept. 

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

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] 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] 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] 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] 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

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

[John Levine]

In article <327860af-2fa7-63ee-4b89-6e7e383f3...@crash.com> you write:
>> Do you think there was a shared understanding of how p=quarantine
>> would be implemented? ...

>quarantine." Rather that the Domain Owner is requesting whatever the 
>Receiver implements between rejecting the message and putting it in the 
>inbox, and is willing to apply.

I get that but I'm wondering if there is any consistency in what that turns out 
to be.

It is easy to explain what rejecting a message means, and pretty easy
to explain do what you would have done if DMARC didn't exist, but that
middle region is murky.

R's,
John

___
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/1/2020 7:03 PM, Steven M Jones wrote:
Rather that the Domain Owner is requesting whatever the Receiver 
implements between rejecting the message and putting it in the inbox, 
and is willing to apply. 


Yes, but...

The premise that an author domain owner can, in any way, direct the 
message disposition decisions of a receiving system is simply false. 
It's false to a level of silliness, if one adequately considers the 
complete independence of the receiver from the domain owner.


The domain owner can, perhaps, express something about the owner's own 
concerns for mail that fails dmarc, but that's different from saying 
anything about the receiver's decisions about how to respond to those 
expressed concerns.


That is, the language expressing the semantics should be changed to be, 
in a sense, egocentric.  How do I, the domain owner feel about (assess) 
the meaning of a DMARC failure?


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.  After all, we left "Mail From" in place, even 
after finally realizing it means "Error Return", which is completely 
different...


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/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

[Dotzero]

On Tue, Dec 1, 2020 at 8:43 PM Steven M Jones  wrote:

> On 12/1/20 4:16 PM, Douglas Foster wrote:
> >
> > I have always assumed that p=quarantine and pct<>100 were included to
> > provide political cover for "Nervous Nellies" who were afraid to
> > enable p=reject.
>
> p=none, p=quarantine, and the pct= option were all included so that
> organizations could set policies according to their own risk/reward
> evaluation, including changes to those evaluations over time.
>

Absolutely agree with Steve on this. The key phrase is "risk/reward
evaluation". As about the first person to publish DMARC records (before the
specification was public), I went straight to p=reject, but I had the
benefit of feedback from participating mailbox providers before we even had
an agreed upon reporting format. Even with that, I missed one oddball
server for both DKIM signing and SPF. The organization I worked for had a
number of heavily abused domains from a direct domain abuse perspective.
None of the mail was going through mailing lists or other intermediaries
other than a very small fraction of a percent going through vanity domains,
etc. My point is that if my circumstances were different I might have gone
through p=quarantine or even stayed there permanently.

>
>
> > Pct<>100 is pretty much similar.   A sender can specify pct=20, but
> > that does not mean that I am going to allow spam into my system 80% of
> > the time simply to make the sender happy.
>
> 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.
>

DMARC does one thing and one thing only - It mitigates direct domain abuse.
It does not stop spam, phishing or a multitude of other problems.

>
>
> > Leaving it deployed is a useful ruse to promote deployment.   I favor
> > leaving both mechanisms in place.
>
> While I deplore characterizing these policy elements as a "ruse," I
> agree that p=quarantine should be kept.
>

Again, I agree with Steve on this.

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

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

[John Levine]

In article  you write:
>On 12/1/20 4:16 PM, Douglas Foster wrote:
>>
>> I have always assumed that p=quarantine and pct<>100 were included to 
>> provide political cover for "Nervous Nellies" who were afraid to 
>> enable p=reject.
>
>p=none, p=quarantine, and the pct= option were all included so that 
>organizations could set policies according to their own risk/reward 
>evaluation, including changes to those evaluations over time.

Do you think there was a shared understanding of how p=quarantine
would be implemented? Put the mail in a spam folder? Put it in some
separate place that you can check? (Mimecast does that with some
dubious mail) Put it in the inbox with a warning label?

I have no idea, my mail system just ignores it so I was wondering what
other people do.

R's,
John

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

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

[Seth Blank]

Doug, please keep your arguments focused on the technical merits of the
matter, and do not make dismissive comments about users and their
motivations. Those you refer to as nervous nellies are the domain owners
who this protocol is designed for, many of whom are legitimately worried
about blocking good mail along with bad, especially in complicated
environments. We cannot dismiss a large class of users as being silly just
because their operational experience or business needs are different than
our own.

Seth, as Chair

On Tue, Dec 1, 2020 at 4:16 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have always assumed that p=quarantine and pct<>100 were included to
> provide political cover for "Nervous Nellies" who were afraid to enable
> p=reject.
>
> As an example, suppose Nellie makes the decision enable p=quarantine and
> then goes badly:
>
> If the recipient reports reject instead of quarantine, she can say:
>  "They were not supposed to review it!  They did not follow instructions!"
>
> If the recipient reports quarantine as requested, she can say:   "They
> agreed to look at it.   We can assume that they will release it to the user
> after seeing that the message is innocuous, but the quarantine disposition
> decision is not shown in the DMARC reports."
>
> --
>
> As an email gateway administrator, what I reject and what I quarantine
> will be determined by my confidence level in my system's risk assessment.
>  Sender request will have nothing to do with it.
>
> Pct<>100 is pretty much similar.   A sender can specify pct=20, but that
> does not mean that I am going to allow spam into my system 80% of the time
> simply to make the sender happy.   Nonetheless, p=quarantine and pct=20
> might allow some organizations to move away from p=none, thinking that they
> are taking "baby steps", and that is a good thing.
>
> Disabling a deployed feature is a big deal.   Leaving it deployed is a
> useful ruse to promote deployment.   I favor leaving both mechanisms in
> place.
>
> Doug Foster
>
>
>
>
> On Tue, Dec 1, 2020 at 6:56 PM 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.
>>
>>
>> If it is confusing to remove it, it is probably confusing to keep it,
>> albeit a different confusion.
>>
>> Since protocol specifications need to be precise in their semantics, so
>> they are understood the same way by both producers and consumers, I
>> suspect the issue, here, is a failure to adequately specify the meaning
>> or a failure to specify something that is mutually useful and desired.
>>
>> So rather that be administratively expeditious for the working group
>> process, I suggest this issue gets some meaningful discussion.  My email
>> archive indicates it hasn't gotten any discussion at all.
>>
>> Just waving this through because it will be a hassle to deal with it
>> invites random differences in its use, and that is death to
>> interoperability.
>>
>>
>> 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
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

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


I have always assumed that p=quarantine and pct<>100 were included to 
provide political cover for "Nervous Nellies" who were afraid to 
enable p=reject.


p=none, p=quarantine, and the pct= option were all included so that 
organizations could set policies according to their own risk/reward 
evaluation, including changes to those evaluations over time.



Pct<>100 is pretty much similar.   A sender can specify pct=20, but 
that does not mean that I am going to allow spam into my system 80% of 
the time simply to make the sender happy.


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.



Leaving it deployed is a useful ruse to promote deployment.   I favor 
leaving both mechanisms in place.


While I deplore characterizing these policy elements as a "ruse," I 
agree that p=quarantine should be kept.


--S.


___
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/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. 



If it is confusing to remove it, it is probably confusing to keep it, 
albeit a different confusion.


Since protocol specifications need to be precise in their semantics, so 
they are understood the same way by both producers and consumers, I 
suspect the issue, here, is a failure to adequately specify the meaning 
or a failure to specify something that is mutually useful and desired.


So rather that be administratively expeditious for the working group 
process, I suggest this issue gets some meaningful discussion.  My email 
archive indicates it hasn't gotten any discussion at all.


Just waving this through because it will be a hassle to deal with it 
invites random differences in its use, and that is death to 
interoperability.



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

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

[John R Levine]

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.

R's,
John



Is p=quarantine needed?

https://mailarchive.ietf.org/arch/msg/dmarc/fR905EgS6tXpsJTHzWCRCeR9L_0/

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