Re: [dmarc-ietf] Abolishing DMARC policy quarantine

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

Hello Hector,

you state, that a domain owner can request p=quarantine over p=reject because 
of concers of false positives.

Why shall one have concers about false positives, but will not be willing to 
fix them?

I do repeat myself, but the way to fix the false positives is to introduce 
p=reject, see which emails fail and are
returned and then fix the DKIM implementation for that messages.  That said, if 
you have concerns of false positives and
want to get rid of them, the way to go is do p=reject.  If there are concerns 
about false positives, but nobody wants to
fix them, you end having an unreliable system.  Besides, I do not see when a 
false positive happens, due DKIM stuff not
running correctly, whose problem is this:
• Of the sending domain owner,
• Of the user sending the mail (the only one who has nothing to say, except 
switching the provider),
• Of the site receiving the mail,
• Of the user receiving the mail?

Among several valid answers, a correct one is, that this is a problem of the 
one who has wrong DKIM implementation and
this is either the sending or the receiving site.  Since the problem is not of 
the sender, the sender shall have no say.

Note, that quarintining a message for a user, that never checks her spam 
folder, is equivalent to discarding the message
and for such users the choise is in practice reject or discard.

On Thu, 2019-08-01 at 09:48 -0400, Hector Santos wrote:
> On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote:
> 
> How the receiver implements mail filters SHOULD always remain as local 
> policy.
> 
> [...]
> 
> If we take quarantine out, there is still going to be receivers who will 
> perform a quarantine concept regardless of a hard reject policy.
> 

This is not exactly what I’m proposing with abolishing policy quarantine.

I propose, that there are only two policies that can be annouced by the domain 
owner:
• “none”, meaning that not all mails have DKIM-Signature that alings to From: 
to that domain
• “not none”, meaning that the domain owner announces, that all messages From: 
that (sub)domain are supposed to have
valid, aligned DKIM-Signatures.

For pragmatical reasons, the name for “not none” will be “reject”.

Moreover, I propose, that when the policy is “not none”, the recipient decides 
how to punish messages, that fail DMARC
validation and the specification elaborates the possibilitis.

So, with “not none” policy, some recipients will do hard reject and others not. 
 Just like sites which have not
deployedd DMARC.

In any case, if the consens is to keep policy quarantine, and the specification 
states, that implementations can allow
receiving sites to override the policy to reject (or to quarantine) and 
implementations can allow individual users to
override the policy (to reject or to quarantine), recommending what to do with 
messages that go simultaneously to users
which have not overridden the policy and to users which have overriden the 
sender policy, then I am fine.

Regards
  Дилян

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos]

On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote:


On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski mailto:tjw.i...@gmail.com>> wrote:

 From our end user point of view, I'm against abolishing
quarantine, even with its current shortcomings.


Why's that?

-MSK, also hatless


My opinion.

How the receiver implements mail filters SHOULD always remain as local 
policy.


We have always kept the concept open ended for all the DKIM Author 
Domain policy proposals, including SPF where hard failures (SPF -ALL, 
SSP Exclusive Policy, ADSP DISCARDABLE, DMARC reject/quarantine are 
hard failures) can be handled as follows:


1- Immediate permanent rejection at SMTP
1.1 - with SPF before or after DATA state.
1.2 - with a DKIM POLICY after DATA state
2- Accept at SMTP, disconnect, silent discard.
3- Accept at SMTP, disconnect, import into User's non-primary in-box, 
if any.


With a reject policy, the Author Domain prefers #1 or #2. but it can 
be implemented all three ways by the receiver. The ultimate outcome is 
a domain preference for rejectable failures not to reach the user's 
eye balls.


With quarantine, the Author Domain is requesting #3 type of mail 
handling because of concerns for false positives.  Allow the user to 
see the mail, just in case.


But what if the implementation site does not offer a "Quarantine" mail 
storage capable design model?  If this type of implementation is not 
acceptable per DMARC design specification, then the spec will need to 
state this possibility:


  For Quarantine Policy support, the implementation SHOULD offer a 
multiple

  user mail folder storage and viewing capability. If the implementation
  can not offer quarantine support, then it SHOULD 
__.

  The author domain MUST be aware not all receivers can support a "Junk"
  folder concept were quarantine mail can be separated from the 
user's main

  mail pickup in-box.

So, I think, we should keep the quarantine policy because it does 
allow for the wider desirable design of for Mail Filtering Systems 
where multiple user folders can be supported and also for domains who 
are not yet 100% sure about issuing hard reject/discard directions.


If we take it out, there is still going to be receivers who will 
perform a quarantine concept regardless of a hard reject policy.



--
HLS


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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Murray S. Kucherawy]

On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski  wrote:

> From our end user point of view, I'm against abolishing quarantine, even
> with its current shortcomings.
>

Why's that?

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Alessandro Vesely]

On Sun 28/Jul/2019 12:49:12 +0200 Дилян Палаузов wrote:

> The penalty could be implemented with reply
> 550 Message failed DMARC validation and was delivered in the Junk folder of 
> the recipient
> 


Usually, receiving MTAs drop the message after replying 5xx.


> If an ESP wants to forget about delivery, the ESP likely does not care
> whether it has implemented DMARC correctly and then it does not need
> quarantine mode.

They may want to protect their brand, avoiding that more spam be attributed to
them than what they actually generated.


> • If policy quarantine will be kept, will the none>quarantine>reject order
> be abolished, meaning “quarantine” will not be handled as softer variant of
> “reject”?  Meaning with p=reject; pct=30 messages are either delivered or
> rejected, but the specification does state anything about quaratining 70% of
> the failed messages.

I can hardly corroborate my analysis by looking at what I received.  My DB of
sending domains has:

96260 domain names, of which
55110 are organizational domains;
 3887 have DMARC records, of which
 3046 have policy 'none',
  418 have policy 'reject',
  271 have policy 'quarantine',
   73 have both 'none' and 'reject',
   45 have both 'none' and 'quarantine',
   34 have both 'quarantine' and 'reject'.

393 of those DMARC domains are not organizational domains, yet 79 of them also
specify sp=.  There is some confusion about how to setup DMARC; some easy howto
seems to be missing.

On multiple policies, only 4 of the latter 34 have p=quarantine; sp=reject; the
other 30 have p=reject; sp=quarantine.  By comparison, the previous 73 + 45
have about the same ratio of p=hard/p=none; 45/28 for reject and 29/16 for
quarantine, so some 63% of those have p=hard; sp=none.  Can one infer from here
the intent of the 30 p=reject; sp=quarantine?

My feeling while looking at that data is that 'reject' is sometimes considered
/better/ than 'quarantine', which I don't think is true.  This confusion can
originate from the sequential order implied by that passage of Section 6.6.4
that Steve quoted.  I agree that that Section needs to be amended.  In
particular, the effect of pct=0 on From: rewriting should be mentioned.


Best
Ale
-- 









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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Tim Wicinski]

>From our end user point of view, I'm against abolishing quarantine, even
with its current shortcomings.

Tim
(no hat)

On Sun, Jul 28, 2019 at 8:48 AM Дилян Палаузов 
wrote:

> Hello Alessandro,
>
> abolishing policy quarantine means with p=reject that for failed messages
> there should be some penalty and the receiving
> site decides on the form of the penalty, e.g. quarantine or reject.
>
> In fact I see the DMARC specification updated to use consistently some
> neutral word, like penalty or punishment attached
> to p=reject, once p=quarantine is abolished.  This word is then dissected
> into “quarantine or reject” at the place where
> it elaborates on the possible penalties, or how to do reject right.
>
> The penalty could be implemented with reply
> 550 Message failed DMARC validation and was delivered in the Junk folder
> of the recipient
>
> This form has the advantage over either quarantine or reject, that for
> lost messages, the sender can call the recipient
> and the recipient can dig for the message.  So the message does not have
> to be resent and no surprizes happen.  I do not
> see how could this reply mess anything, except in the cases where the
> sender does not speak English.
>
> > OTOH, quarantine lets one forget about delivery, perhaps with a
> backhanded
> > thought of recipients rummaging through their spam folders in search of a
> > missing message.  That style seems to me to better suit ESPs, whose duty
> is
> > rather to have a lot of mails sent than to make sure that each message is
> > acknowledged, albeit they try and maximize the ratio.
> >
> > IMHO, by abolishing quarantine, we make the protocol less flexible than
> it is.
>
> If an ESP wants to forget about delivery, the ESP likely does not care
> whether it has implemented DMARC correctly and
> then it does not need quarantine mode.
>
> The penalty is applied to messages that are either sent by spammers or by
> the domain owner.  If messages are from
> spammers, for the domain owner it is irrelevant, what kind of penalty is
> applied, but for users doing reject means
> having to scan less messages in the Junk mailbox.
>
> If messages are from the domain owner and fail DKIM/DMARC validation, the
> only way to fix DKIM/DMARC is to use policy
> reject.  There is no other way to find out which messages fail DKIM/DMARC,
> as single message faiulure reports are rarely
> sent, and without knowing which messages fail DMARC fixing the problem is
> unnecessary complicated.
>
> So here, p=quarantine is in fact an option for providers, who do not care,
> whether they have implemented DMARC
> correctly.
>
> All that said:
>
> • Is there a consensus on abolishing policy quarantine?
> • If policy quarantine will be kept, will the none>quarantine>reject order
> be abolished, meaning “quarantine” will not
> be handled as softer variant of “reject”?  Meaning with p=reject; pct=30
> messages are either delivered or rejected, but
> the specification does state anything about quaratining 70% of the failed
> messages.
>
> The first argument in favour of keeping policy quarantine was exactly this
> order (quarantine is a softer variant of
> reject and before deploying reject one has to exercise with quarantine).
>
> Regards
>   Дилян
>
>
> On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote:
> > On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote:
> > > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy <
> superu...@gmail.com> wrote:
> > > >
> > > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins <
> st...@wordtothewise.com> wrote:
> > > > > It's interesting that the industry has decided to interpret
> "p=reject; pct=0" the way we intended "p=quarantine; pct=100".
> > > >
> > > > It's semi-explicitly defined that way in the RFC, isn't it?
> > > >
> > > > If so, we should fix it because (a) I don't think that's how we
> intended it, and (b) in any case, nothing in there should be only
> semi-explicit.
> > >
> > > rfc 7489 6.6.4
> > >
> > > "If email is subject to the DMARC policy of "reject", the Mail
> > >Receiver SHOULD reject the message (see  Section 10.3).  If the
> email
> > >is not subject to the "reject" policy (due to the "pct" tag), the
> > >Mail Receiver SHOULD treat the email as though the "quarantine"
> > >policy applies.  This behavior allows Domain Owners to experiment
> > >with progressively stronger policies without relaxing existing
> > >policy."
> > >
> > > It's pretty clear and well-defined; the case we're talking about,
> "p=reject; pct=0", is
> > > just a special case of this general rule.
> > >
> > > All emails will not be subject to the "reject" policy due to the pct=0
> tag, so the mail
> > > receiver should treat all emails as though the policy "quarantine"
> applies (which
> > > is the same as "p=quarantine; pct=100").
> >
> > I, for one, had missed that point.  Thanks for clarifying it.
> >
> > It seems to mean that the resulting steps are, for example:
> >
> >
> > "p=quarantine; pct=0"  (c

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

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

Hello Alessandro,

abolishing policy quarantine means with p=reject that for failed messages there 
should be some penalty and the receiving
site decides on the form of the penalty, e.g. quarantine or reject.

In fact I see the DMARC specification updated to use consistently some neutral 
word, like penalty or punishment attached
to p=reject, once p=quarantine is abolished.  This word is then dissected into 
“quarantine or reject” at the place where
it elaborates on the possible penalties, or how to do reject right.

The penalty could be implemented with reply
550 Message failed DMARC validation and was delivered in the Junk folder of the 
recipient

This form has the advantage over either quarantine or reject, that for lost 
messages, the sender can call the recipient
and the recipient can dig for the message.  So the message does not have to be 
resent and no surprizes happen.  I do not
see how could this reply mess anything, except in the cases where the sender 
does not speak English.

> OTOH, quarantine lets one forget about delivery, perhaps with a backhanded
> thought of recipients rummaging through their spam folders in search of a
> missing message.  That style seems to me to better suit ESPs, whose duty is
> rather to have a lot of mails sent than to make sure that each message is
> acknowledged, albeit they try and maximize the ratio.
> 
> IMHO, by abolishing quarantine, we make the protocol less flexible than it is.

If an ESP wants to forget about delivery, the ESP likely does not care whether 
it has implemented DMARC correctly and
then it does not need quarantine mode.

The penalty is applied to messages that are either sent by spammers or by the 
domain owner.  If messages are from
spammers, for the domain owner it is irrelevant, what kind of penalty is 
applied, but for users doing reject means
having to scan less messages in the Junk mailbox.

If messages are from the domain owner and fail DKIM/DMARC validation, the only 
way to fix DKIM/DMARC is to use policy
reject.  There is no other way to find out which messages fail DKIM/DMARC, as 
single message faiulure reports are rarely
sent, and without knowing which messages fail DMARC fixing the problem is 
unnecessary complicated.

So here, p=quarantine is in fact an option for providers, who do not care, 
whether they have implemented DMARC
correctly.

All that said:

• Is there a consensus on abolishing policy quarantine?
• If policy quarantine will be kept, will the none>quarantine>reject order be 
abolished, meaning “quarantine” will not
be handled as softer variant of “reject”?  Meaning with p=reject; pct=30 
messages are either delivered or rejected, but
the specification does state anything about quaratining 70% of the failed 
messages.

The first argument in favour of keeping policy quarantine was exactly this 
order (quarantine is a softer variant of
reject and before deploying reject one has to exercise with quarantine).

Regards
  Дилян


On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote:
> On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote:
> > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy  
> > > wrote:
> > > 
> > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins  
> > > wrote:
> > > > It's interesting that the industry has decided to interpret "p=reject; 
> > > > pct=0" the way we intended "p=quarantine; pct=100".
> > > 
> > > It's semi-explicitly defined that way in the RFC, isn't it?
> > > 
> > > If so, we should fix it because (a) I don't think that's how we intended 
> > > it, and (b) in any case, nothing in there should be only semi-explicit.
> > 
> > rfc 7489 6.6.4
> > 
> > "If email is subject to the DMARC policy of "reject", the Mail
> >Receiver SHOULD reject the message (see  Section 10.3).  If the email
> >is not subject to the "reject" policy (due to the "pct" tag), the
> >Mail Receiver SHOULD treat the email as though the "quarantine"
> >policy applies.  This behavior allows Domain Owners to experiment
> >with progressively stronger policies without relaxing existing
> >policy."
> > 
> > It's pretty clear and well-defined; the case we're talking about, 
> > "p=reject; pct=0", is
> > just a special case of this general rule.
> > 
> > All emails will not be subject to the "reject" policy due to the pct=0 tag, 
> > so the mail
> > receiver should treat all emails as though the policy "quarantine" applies 
> > (which
> > is the same as "p=quarantine; pct=100").
> 
> I, for one, had missed that point.  Thanks for clarifying it.
> 
> It seems to mean that the resulting steps are, for example:
> 
> 
> "p=quarantine; pct=0"  (check From: rewriting)
> "p=quarantine; pct=10" (some messages go to the spam folder)
> "p=quarantine; pct=20"
> 
> "p=quarantine; pct=100"
> "p=reject; pct=0"  (same as the previous step)
> "p=reject; pct=10" (some messages bounce back)
> "p=reject; pct=20"
> 
> 
> 
> Is that what we want to suggest?  In that case, we should be clearer.  Perhaps
> 

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Alessandro Vesely]

On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote:
>> On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy  
>> wrote:
>> 
>> On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins  wrote:
>> > It's interesting that the industry has decided to interpret "p=reject; 
>> > pct=0" the way we intended "p=quarantine; pct=100".
>> 
>> It's semi-explicitly defined that way in the RFC, isn't it?
>> 
>> If so, we should fix it because (a) I don't think that's how we intended it, 
>> and (b) in any case, nothing in there should be only semi-explicit.
> 
> rfc 7489 6.6.4
> 
> "If email is subject to the DMARC policy of "reject", the Mail
>Receiver SHOULD reject the message (see  Section 10.3).  If the email
>is not subject to the "reject" policy (due to the "pct" tag), the
>Mail Receiver SHOULD treat the email as though the "quarantine"
>policy applies.  This behavior allows Domain Owners to experiment
>with progressively stronger policies without relaxing existing
>policy."
> 
> It's pretty clear and well-defined; the case we're talking about, "p=reject; 
> pct=0", is
> just a special case of this general rule.
> 
> All emails will not be subject to the "reject" policy due to the pct=0 tag, 
> so the mail
> receiver should treat all emails as though the policy "quarantine" applies 
> (which
> is the same as "p=quarantine; pct=100").


I, for one, had missed that point.  Thanks for clarifying it.

It seems to mean that the resulting steps are, for example:


"p=quarantine; pct=0"  (check From: rewriting)
"p=quarantine; pct=10" (some messages go to the spam folder)
"p=quarantine; pct=20"

"p=quarantine; pct=100"
"p=reject; pct=0"  (same as the previous step)
"p=reject; pct=10" (some messages bounce back)
"p=reject; pct=20"



Is that what we want to suggest?  In that case, we should be clearer.  Perhaps
by adding an example in a new appendix.  However, I hardly see the above
sequence as progressive.

I had always considered quarantine and reject to be two more or less similar
alternatives.  Each has its merits and shortcomings, and can be chosen
according to a sender's needs.

An advantage of reject is that one gets NDNs, which are much more universally
adopted than failure reports.  Perhaps a bank or similar transactional sender
would rather prefer reject, because they can timely resend bounced transactions
or notices thereof in order to have their duties accomplished.

OTOH, quarantine lets one forget about delivery, perhaps with a backhanded
thought of recipients rummaging through their spam folders in search of a
missing message.  That style seems to me to better suit ESPs, whose duty is
rather to have a lot of mails sent than to make sure that each message is
acknowledged, albeit they try and maximize the ratio.

IMHO, by abolishing quarantine, we make the protocol less flexible than it is.


Best
Ale
-- 








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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Steve Atkins]

> On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy  wrote:
> 
> On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins  wrote:
> > It's interesting that the industry has decided to interpret "p=reject; 
> > pct=0" the way we intended "p=quarantine; pct=100".
> 
> It's semi-explicitly defined that way in the RFC, isn't it?
> 
> If so, we should fix it because (a) I don't think that's how we intended it, 
> and (b) in any case, nothing in there should be only semi-explicit.

rfc 7489 6.6.4

"If email is subject to the DMARC policy of "reject", the Mail
   Receiver SHOULD reject the message (see  Section 10.3).  If the email
   is not subject to the "reject" policy (due to the "pct" tag), the
   Mail Receiver SHOULD treat the email as though the "quarantine"
   policy applies.  This behavior allows Domain Owners to experiment
   with progressively stronger policies without relaxing existing
   policy."

It's pretty clear and well-defined; the case we're talking about, "p=reject; 
pct=0", is
just a special case of this general rule.

All emails will not be subject to the "reject" policy due to the pct=0 tag, so 
the mail
receiver should treat all emails as though the policy "quarantine" applies 
(which
is the same as "p=quarantine; pct=100").

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Dotzero]

On Wed, Jul 24, 2019 at 7:07 PM Murray S. Kucherawy 
wrote:

> On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins 
> wrote:
>
>> > It's interesting that the industry has decided to interpret "p=reject;
>> pct=0" the way we intended "p=quarantine; pct=100".
>>
>> It's semi-explicitly defined that way in the RFC, isn't it?
>>
>
> If so, we should fix it because (a) I don't think that's how we intended
> it, and (b) in any case, nothing in there should be only semi-explicit.
>
> -MSK
> ___
>

My recollection is that we definitely did not intend that.

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Murray S. Kucherawy]

On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins 
wrote:

> > It's interesting that the industry has decided to interpret "p=reject;
> pct=0" the way we intended "p=quarantine; pct=100".
>
> It's semi-explicitly defined that way in the RFC, isn't it?
>

If so, we should fix it because (a) I don't think that's how we intended
it, and (b) in any case, nothing in there should be only semi-explicit.

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Steve Atkins]

> On Jul 24, 2019, at 9:07 PM, Murray S. Kucherawy  wrote:
> 
> OK, I see what you're getting at..
> 
> It's interesting that the industry has decided to interpret "p=reject; pct=0" 
> the way we intended "p=quarantine; pct=100".

It's semi-explicitly defined that way in the RFC, isn't it?

Cheers,
  Steve


> 
> As for your proposal:
> 
> On Wed, Jul 24, 2019 at 12:52 PM Дилян Палаузов  
> wrote:
> And then, for p=none or any equivalent form of it, there is no need or 
> established practice for mungling, while for
> p=reject; pct=0, or any equivalent form of it, there is mungling.
> 
> This is the current specification.  I proposed on this regard in fact two 
> things:
> - specifying that p=quarantine; pct=0 (email from 10th May to dmarc@ietf) the 
> MLM does mungling
> - abolishing policy quarantine
> 
> That is: p=reject; pct=0 gets almost the same as p=none, except that there is 
> recommendatiton for MLM to mungle From:.
> 
> I'm a little worried about this, but maybe it's just The Way Of Things.  We 
> had intended the publication of a DMARC policy to be a message from the ADMD 
> owning a domain name to any ADMD receiving mail from it about how to handle 
> unauthenticated or unaligned messages.  It's actually morphed on its own into 
> also being a message to any MLM that might be in the way to take particular 
> rewriting actions.  I wonder if the standards track version of DMARC should 
> explicitly take this into account..
> 
> -MSK
> 
> ___
> 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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Murray S. Kucherawy]

OK, I see what you're getting at.

It's interesting that the industry has decided to interpret "p=reject;
pct=0" the way we intended "p=quarantine; pct=100".

As for your proposal:

On Wed, Jul 24, 2019 at 12:52 PM Дилян Палаузов 
wrote:

> And then, for p=none or any equivalent form of it, there is no need or
> established practice for mungling, while for
> p=reject; pct=0, or any equivalent form of it, there is mungling.
>
> This is the current specification.  I proposed on this regard in fact two
> things:
> - specifying that p=quarantine; pct=0 (email from 10th May to dmarc@ietf)
> the MLM does mungling
> - abolishing policy quarantine
>
> That is: p=reject; pct=0 gets almost the same as p=none, except that there
> is recommendatiton for MLM to mungle From:.
>

I'm a little worried about this, but maybe it's just The Way Of Things.  We
had intended the publication of a DMARC policy to be a message from the
ADMD owning a domain name to any ADMD receiving mail from it about how to
handle unauthenticated or unaligned messages.  It's actually morphed on its
own into also being a message to any MLM that might be in the way to take
particular rewriting actions.  I wonder if the standards track version of
DMARC should explicitly take this into account.

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

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

Hello,

(I repeat what was said here, just in case)
 
As it was pointed out, p=quarantine; pct=0; is the same as p=none; and 
p=reject; ptc=0; is the same as p=quarantine;
pct=100, therefore p=quarantine; pct=0 is not the same as p=reject; pct=0 
currently, per 
https://tools.ietf.org/html/rfc7489#section-6.6.4 (RFC DMARC, Section Message 
Sampling)

And then, for p=none or any equivalent form of it, there is no need or 
established practice for mungling, while for
p=reject; pct=0, or any equivalent form of it, there is mungling.

This is the current specification.  I proposed on this regard in fact two 
things:
- specifying that p=quarantine; pct=0 (email from 10th May to dmarc@ietf) the 
MLM does mungling
- abolishing policy quarantine

That is: p=reject; pct=0 gets almost the same as p=none, except that there is 
recommendatiton for MLM to mungle From:.

Regards
  Дилян
On Wed, 2019-07-24 at 19:36 +0300, Vladimir Dubrovin wrote:
> 
> Hello Murray,
> 
> Yes, rewriting depends on policy. Look at From: headers for this mailing list 
> (dmarc@ietf.org), you can see it only munges From address for domain with 
> strict DMARC policy (if RFC5322.From domain publishes "quarantine" or 
> "reject" policy). This is very common behavior, it can also be seen in Google 
> Groups.
> 
> But, as it was correctly pointed by Dilyan Palauzov, there should be no 
> difference between "p=quarantine;pct=0" and "p=reject;pct=0" for valid DMARC 
> Mail Receiver implementation, so "p=reject;pct=0" can probably be used 
> instead. 
> 
> 24.07.2019 18:27, Murray S. Kucherawy пишет:
> > On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin 
> >  wrote:
> > > 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.
> > > 
> > 
> > I'm confused; is this claiming that those rewrites happen by virtue of the 
> > fact that "p=quarantine" is the published policy?  Seems to me that 
> > rewriting will happen irrespective of what the published policy is for the 
> > From domain.
> > 
> > Or is it the case that this changes the content of the aggregate reports in 
> > a way you find meaningful?
> > 
> > -MSK
> > 
> > 
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
> 
> 
> -- 
> Vladimir Dubrovin 
> @ mail.ru

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Vladimir Dubrovin]

Hello Murray,

Yes, rewriting depends on policy. Look at From: headers for this mailing
list (dmarc@ietf.org), you can see it only munges From address for
domain with strict DMARC policy (if RFC5322.From domain publishes
"quarantine" or "reject" policy). This is very common behavior, it can
also be seen in Google Groups.

But, as it was correctly pointed by Dilyan Palauzov, there should be no
difference between "p=quarantine;pct=0" and "p=reject;pct=0" for valid
DMARC Mail Receiver implementation, so "p=reject;pct=0" can probably be
used instead.

24.07.2019 18:27, Murray S. Kucherawy пишет:
> On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin
>  > wrote:
>
> 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.
>
>
> I'm confused; is this claiming that those rewrites happen by virtue of
> the fact that "p=quarantine" is the published policy?  Seems to me
> that rewriting will happen irrespective of what the published policy
> is for the From domain.
>
> Or is it the case that this changes the content of the aggregate
> reports in a way you find meaningful?
>
> -MSK
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladimir Dubrovin
@ mail.ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Murray S. Kucherawy]

On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin  wrote:

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

I'm confused; is this claiming that those rewrites happen by virtue of the
fact that "p=quarantine" is the published policy?  Seems to me that
rewriting will happen irrespective of what the published policy is for the
>From domain.

Or is it the case that this changes the content of the aggregate reports in
a way you find meaningful?

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos]

On 6/15/2019 6:13 PM, Steve Atkins wrote:




On Jun 15, 2019, at 9:25 PM,  wrote:

Hello,

p=reject; pct=0 is equivalent to p=quarantine; pct=0.


I've not been following this thread too closely so I might
be missing something, but under current DMARC spec I don't
think that's so - see section 6.6.4.

If I've missed the point ... never mind, carry on.



If I follow myself, I think it could be expressed as:

p=reject; pct=0; is effectively equivalent to p=quarantine; pct=100;

Given the order of mail "restriction" or "filtering" from high to low 
of reaching the user's eyeballs:


  p=reject   never accepted or accepted/discarded
  p=quarantine   accepted, imported into spam box, outside inbox
  p=none accepted, imported into inbox

The "pct" effectively forces a fallback to the next lower applicable 
policy once the pct of failed mail has been processed:


  p=reject; pct=X;  fallback to p=quarantine
  p=quarantine; pct=X;  fallback to p=none
  p=none;  pct=X  fallback to UNDEFINED, N/A

where X can be 0 to 100.

When pct=100, which is the default, then the fallback would not apply 
since the explicit domain policy is applied to all DMARC failed 
messages. The receiver rejects mail with p=reject and quarantines mail 
with p=quarantine.


If there is an explicit pct=0, then effectively, the fallback is to be 
applied immediately, thus:


p=reject; pct=0; is effectively equivalent to p=quarantine; pct=100;

and

p=quarantine; pct=0; is effectively equivalent to p=none; pct=100;

Because of the fallback and quarantine implementation complexity and 
how failed messages can reach users, the OP is proposing to abolish 
the quarantine policy.



--
HLS


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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Steve Atkins]

> On Jun 15, 2019, at 9:25 PM, Дилян Палаузов  wrote:
> 
> Hello,
> 
> p=reject; pct=0 is equivalent to p=quarantine; pct=0.

I've not been following this thread too closely so I might be missing 
something, but under current
DMARC spec I don't think that's so - see section 6.6.4.

If I've missed the point ... never mind, carry on.

Cheers,
  Steve

> 
> The rest of this email is about (against) handling p=reject and p=quarantine 
> differently.  Namely, where a server
> rejects on p=reject and “quarantines” on p=quarantine.
> 
> There are more examples, all under the category p=quarantine, where the spam 
> filter does not think a message is spam and
> DMARC fails (e.g. missing DKIM-Signature):
> 
> — an autoresponder.  The incoming email will be delivered as non-spam, as the 
> spam filter does not classify the email as
> spam.  Would you suppress the autorespond (out-of-office/vacation) message, 
> or will you take the risk to send bad
> backscatters, risking lowering your IP reputation.  Is it up to the domain 
> owner of the original message decide on you
> sending backscatters, by publishing slightly different dmarc policies?  If 
> you handle quarantine as reject there is no
> such risk of getting bad IP reputation (under these concrete conditions).  If 
> no auto-responder is sent and the mail is
> not classified as spam, the user will rely on the fact, that an autoresponder 
> was sent… big fuzz.
> 
> — an 1:1 alias to a different server.  If your server thinks the email is not 
> spam, but the server to which the alias is
> redirected thinks the message is spam, or if the user marks it as spam, your 
> IP reputation gets worse.  If you handle
> quarantine as reject there is no such risk.
> 
> — a MLM (1:many alias), where anybody can send messages - same problem as 
> above, just bigger damage.
> 
> p=reject and p=quarantine both communicate, that all messages from a domain 
> must have aligned, valid dkim signature or
> aligned, valid spf result and that for messages from the domain failing 
> DMARC, there must be some penalty.
> 
> How many distinct penalty levels does a sending domain owner need?
> 
> One, or more than one?  Are two penalty levels enough?  Is there 
> justification for two penalty levels?  Can the same 
> justification be used to introduce a third penalty level?  What does the 
> domain owner/sending domain want do
> communicate, by using the first, second, or third penalty level?
> 
> Currently the decisions on handling quarantine/reject in different ways are 
> taken by:
> * domain owners, who own a domain
> * spammers, who use the domain of the domain owner, and let's say are 
> distinct from the domain owners
> * mailbox operators
> 
> Not taken into account are the users.  Why shall a user want to have more 
> messages in its spam folder (assuming that the
> quarantined message was at the end classified as spam and the email operator 
> handles Reject and Quarantine differently)
> versus handling p=quarantine as p=reject and having less Spam to pay 
> attention for?
> 
> About the costs, Quarantine meaning neither deliver, not reject, but 
> something different, can be implemented in this
> way: the operator does not deliver the emails failing DMARC for a domain with 
> p=querantine to the users, but arranges
> staff, to decide what to do.  The costs for that staff, are the extra costs 
> for having distinct handling of
> Reject/Quarantine.  If there is no such staff, and the decisions are taken by 
> the users, then the costs are the same,
> these just are shifted to the users.
> 
> Finally, while DMARC can be used to communicate that all emails from a domain 
> must PASS DMARC rules, why there is a need
> to communicate what to do with emails that fail DMARC from: the domain?  The 
> DMARC specification can be simplified, by
> leaving the hanlding of such emails ultimately up to the receiving host and 
> then there is no need to iterate the options
> at protocol level for the sending domain. (The option, that all emails from a 
> domain must have aligned DKIM signatures,
> but it is up to the recipient what to do with messages without valid 
> dkim-signature or spf result is anyway missing)j
> 
> Regards
>  Дилян
> 
> On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote:
>> On 6/14/2019 5:58 PM, Дилян Палаузов wrote:
>>> Hello Ken,
>>> 
>>> effectively I proposed handling p=reject and p=quarantine the same way.
>>> 
>>> ..
>>> 
>>> Lets have an example for p=quaranite:
>>> majordomo@domain is an address where commands are sent and the software 
>>> receiving the
>>> command always sends an answer, even if the command is unclear.  An email 
>>> is sent
>>> to majordomo@domain.  The sending domain has published policy Quarantine.  
>>> This address
>>> has no spam/junk folder attached to it.  The options for an email are:
>>>  * reject the email during the SMTP dialog
>>>  * accept the email and let majordomo send an answer to it
>>>  * arrange a human to decide which

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

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

Hello,

p=reject; pct=0 is equivalent to p=quarantine; pct=0.

The rest of this email is about (against) handling p=reject and p=quarantine 
differently.  Namely, where a server
rejects on p=reject and “quarantines” on p=quarantine.

There are more examples, all under the category p=quarantine, where the spam 
filter does not think a message is spam and
DMARC fails (e.g. missing DKIM-Signature):

— an autoresponder.  The incoming email will be delivered as non-spam, as the 
spam filter does not classify the email as
spam.  Would you suppress the autorespond (out-of-office/vacation) message, or 
will you take the risk to send bad
backscatters, risking lowering your IP reputation.  Is it up to the domain 
owner of the original message decide on you
sending backscatters, by publishing slightly different dmarc policies?  If you 
handle quarantine as reject there is no
such risk of getting bad IP reputation (under these concrete conditions).  If 
no auto-responder is sent and the mail is
not classified as spam, the user will rely on the fact, that an autoresponder 
was sent… big fuzz.

— an 1:1 alias to a different server.  If your server thinks the email is not 
spam, but the server to which the alias is
redirected thinks the message is spam, or if the user marks it as spam, your IP 
reputation gets worse.  If you handle
quarantine as reject there is no such risk.

— a MLM (1:many alias), where anybody can send messages - same problem as 
above, just bigger damage.

p=reject and p=quarantine both communicate, that all messages from a domain 
must have aligned, valid dkim signature or
aligned, valid spf result and that for messages from the domain failing DMARC, 
there must be some penalty.

How many distinct penalty levels does a sending domain owner need?

One, or more than one?  Are two penalty levels enough?  Is there justification 
for two penalty levels?  Can the same 
justification be used to introduce a third penalty level?  What does the domain 
owner/sending domain want do
communicate, by using the first, second, or third penalty level?

Currently the decisions on handling quarantine/reject in different ways are 
taken by:
* domain owners, who own a domain
* spammers, who use the domain of the domain owner, and let's say are distinct 
from the domain owners
* mailbox operators

Not taken into account are the users.  Why shall a user want to have more 
messages in its spam folder (assuming that the
quarantined message was at the end classified as spam and the email operator 
handles Reject and Quarantine differently)
versus handling p=quarantine as p=reject and having less Spam to pay attention 
for?

About the costs, Quarantine meaning neither deliver, not reject, but something 
different, can be implemented in this
way: the operator does not deliver the emails failing DMARC for a domain with 
p=querantine to the users, but arranges
staff, to decide what to do.  The costs for that staff, are the extra costs for 
having distinct handling of
Reject/Quarantine.  If there is no such staff, and the decisions are taken by 
the users, then the costs are the same,
these just are shifted to the users.

Finally, while DMARC can be used to communicate that all emails from a domain 
must PASS DMARC rules, why there is a need
to communicate what to do with emails that fail DMARC from: the domain?  The 
DMARC specification can be simplified, by
leaving the hanlding of such emails ultimately up to the receiving host and 
then there is no need to iterate the options
at protocol level for the sending domain. (The option, that all emails from a 
domain must have aligned DKIM signatures,
but it is up to the recipient what to do with messages without valid 
dkim-signature or spf result is anyway missing)j

Regards
  Дилян

On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote:
> On 6/14/2019 5:58 PM, Дилян Палаузов wrote:
> > Hello Ken,
> > 
> > effectively I proposed handling p=reject and p=quarantine the same way.
> > 
> > ..
> > 
> > Lets have an example for p=quaranite:
> >  majordomo@domain is an address where commands are sent and the software 
> > receiving the
> >  command always sends an answer, even if the command is unclear.  An email 
> > is sent
> >  to majordomo@domain.  The sending domain has published policy Quarantine.  
> > This address
> >  has no spam/junk folder attached to it.  The options for an email are:
> >   * reject the email during the SMTP dialog
> >   * accept the email and let majordomo send an answer to it
> >   * arrange a human to decide which emails to discard (handle an imaginary 
> > Spam folder for the account).
> 
> Oh I see your concern/point/proposal now.
> 
> Yes, I highlighted this basic issue in years past in regards to the 
> handling semantics debates. Even with SPF,  how -ALL (FAIL) was 
> interpreted and handled was questioned. Some believed a -ALL FAIL 
> policy is more like a quarantine because "no one actually rejects."
> 
> But overall, this would be an implementation

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos]

On 6/14/2019 5:58 PM, Дилян Палаузов wrote:

Hello Ken,

effectively I proposed handling p=reject and p=quarantine the same way.

..

Lets have an example for p=quaranite:
 majordomo@domain is an address where commands are sent and the software 
receiving the
 command always sends an answer, even if the command is unclear.  An email is 
sent
 to majordomo@domain.  The sending domain has published policy Quarantine.  
This address
 has no spam/junk folder attached to it.  The options for an email are:
  * reject the email during the SMTP dialog
  * accept the email and let majordomo send an answer to it
  * arrange a human to decide which emails to discard (handle an imaginary Spam 
folder for the account).


Oh I see your concern/point/proposal now.

Yes, I highlighted this basic issue in years past in regards to the 
handling semantics debates. Even with SPF,  how -ALL (FAIL) was 
interpreted and handled was questioned. Some believed a -ALL FAIL 
policy is more like a quarantine because "no one actually rejects."


But overall, this would be an implementation consideration, not a 
protocol design consideration. The protocol is correct to have a 
handling semantics describing both ideas - reject and quarantine.


All we can do is highlight the existence of backend mail storage 
designs and legacy MUA protocol(s) that can not handle a quarantine 
safely. So at best, you can basically highlight the security design 
concerns and possible requirements to implement a quarantine concept.


There is much mail design history and evolution to consider. The 
concept of quarantine came with the integrated mail design premise that:


- The backend offers user folders or separate mail streams for normal 
in-box mail and quarantine, spam, junk mail separations. While this is 
common today for ESPs, this was not always the case for all backend 
designs.  It was often proprietary in nature.  No standard here unless 
we assume everyone using an "Microsoft Exchange" (MAPI) concept or 
IMAP which is not reality. This coincides with the premise,


- The broad range of online and offline MUAs all support the 
multi-folders provided by the backend.  This is again not reality and 
not always the case.


I'll give you a perfect example -- POP3.

POP3 is a single mail stream pick up protocol standard. So for a 
backend that provides POP3 service available to its customers and for 
the user using MUA with POP3 support, the backend POP3 server MUST NOT 
merge any suspicious, spam, junk or quarantine mail with the user's 
normal in-box mail pick up stream.


While an advanced POP3 backend server can emulate a single stream 
consolidation of multi-user folders, it would a major security loop 
hole to expose POP3 users to quarantined mail merged into the user's 
pop3 mail stream.  For this to work securely, this advanced POP3 
server must assume the MUAs are advanced enough or users are advanced 
enough to write MUA scripts that will separate the single pop3 stream 
into spam, junk and quarantine folders again.


All we can do is highlight how "rejects" can be interpreted 
differently.  After much discussion with SPF, while it didn't provide 
an specific example using POP3, it was generically described under 
Local Policy Considerations:


   https://tools.ietf.org/html/rfc7208#appendix-G.2

It should also be highlighted for DMARC-bis, if not already.

--
HLS


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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Alessandro Vesely]

On Fri 14/Jun/2019 18:25:02 +0200 Vladimir Dubrovin wrote:

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


I still don't get why "p=quarantine;pct=0" is better than "p=reject;pct=0".


Best
Ale
-- 







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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

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

Hello Ken,

effectively I proposed handling p=reject and p=quarantine the same way.  Shall 
I read in your answer, that failed DMARC
validation is weighted differently in the overall spam evaluation, for p=reject 
and for p=quarantine?

> A use case for p=quarantine is that when deploying DMARC for any reasonably
> complex site, it forms part of a graduated approach (perhaps in conjunction
> with pct=x) utilising aggregated reports to moving towards p=reject. 

There is no ordering between the policies.  p=quarantine is not a softer 
variant of p=reject, it is just different. 
Switching from Quarantine to Reject is not a graduate approach.  But if some 
subscribers here see it as such, perhaps
more discussions are necessary.

In the counter example for extra work, having support queries for rejected 
emails (p=reject) or for emails arriving
misteriosly as spam (p=quarantine) is the same amount of support, extra work.

Lets have an example for p=quaranite:
  majordomo@domain is an address where commands are sent and the software 
receiving the command always sends an answer,
even if the command is unclear.  An email is sent to majordomo@domain.  The 
sending domain has published policy
Quarantine.  This address has no spam/junk folder attached to it.  The options 
for an email are:
 * reject the email during the SMTP dialog
 * accept the email and let majordomo send an answer to it
 * arrange a human to decide which emails to discard (handle an imaginary Spam 
folder for the account).

The third option is expensive and causes delays.  The second option could send 
backscatters, so a caution has to be
payed when accepting an email.

After the total, complex spam evaluation, the spam filter is uncertain if the 
mail is spam or not.  DMARC evaluation on
its own fails.  Shall the email be rejected during the smpt dialog (handle 
Quarantine as Reject), shall the email be
accepted, or what do you suggest to do?

As for pct=0 on there was a discussion on ietf-s...@ietf.org whether From: 
shall be rewritten by the MLM on 25-26 Jan
2019 and the outcome is, that the behaviour is unclear (one cannot act wrong by 
rewriting or not RFC5822.From:).  So on
pct=0; further ellaboration is necessary.

On Wed, 2019-06-12 at 12:05 +0100, Ken O'Driscoll wrote:
> On Tue, 2019-06-11 at 21:00 +, Дилян Палаузов wrote:
> > Dear all,
> > 
> > when DMARC passes, there is no difference between p=reject and
> > p=quarantine.
> [...snip...]
> > However, it is ultimately up to the receiving site to decide, whether it
> > wants to accept this extra work.  If it does not accept the extra work,
> > it just handles quarantine as reject.  This does not violate the DMARC
> > specitification.
> 
> Even in a moderately complex spam filtering engine, DMARC is just one
> indicator / signal amongst many.
> 
> Who does the "extra work" is subjective. For example, a large mailbox
> provider may consider support queries about missing or rejected emails as
> unwanted "extra work" etc.
> 
> DMARC does not live in isolation - it's part to a greater ecosystem. 
> 
> > Do you have a story, why one wants to publish p=quaratnine?  What is the
> > use case for it?  It just makes emails less reliable, as they end as Junk
> > and this is very similar to discarding the emails.
> 
> There is a world of difference between requesting that a recipient flag an
> incoming message as spam as opposed to asking them to discard it outright.
> And that is regardless of how individual mailbox provides treat
> p=quarantine.
> 
> A use case for p=quarantine is that when deploying DMARC for any reasonably
> complex site, it forms part of a graduated approach (perhaps in conjunction
> with pct=x) utilising aggregated reports to moving towards p=reject. 
> 
> The proactive nature of DMARC means that its deployment needs to be
> properly planned with any risks mitigated as best as possible. The various
> stages of p= can easily be articulated on a project plan / risk register.
> 
> And such sites that require such planning are often starting from a
> position of improperly documented mail flows and inconsistently implemented
> SPF/DKIM. In addition they often operate in regulated sectors and are
> commonly top-heavy with risk-adverse middle management.
> 
> I accept that a small site with a simple mail flow which does not operate
> in a regulated space and has thin governance could likely move straight
> from p=none to p=reject without serious repercussions. Such sites are not
> the majority of DMARC deployments.
> 
> DMARC changes how recipient mailbox providers treat email and therefore it
> needs to be deployed in a controlled manner, p=quarantine being one
> component of that. 
> 
> > Imagine a mailing lists, where the recipient of an email address expands
> > to several mailboxes on different domains.  An incoming email fails DMARC
> > validation before being distributed over the ML.  The domain owner for
> > that mail origin has published p=quarantine, this email cannot 

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Vladimir Dubrovin]

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.



14.06.2019 18:42, Dotzero пишет:
>
>
> On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin
>  > wrote:
>
>
> p=quarantine with pct=0 is useful to test DMARC with mailing
> list/groups
> which perform "From" rewrite based on DMARC policy. It's safe, because
> it actually works like "none" but it causes From rewrites, because
> it's
> still considered as "quarantine".
>
> I would never recommend to use "quarantine" without pct=0, because it
> can  mask serious deliverability problems.
>
>
> If the only thing they are using to check deliverability is DMARC
> reporting, the person has other problems. You should be able to see
> whether it passed/failed DKIM and SPF but that does not tell you
> whether it was delivered to the end user (at all) or quarantined in a
> SPAM folder. Many if not most receiving domains perform all sorts of
> other checks on incoming mail.
>
> Michael Hammer
>
> Michael Hammer
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladimir Dubrovin
@Mail.Ru

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Dotzero]

On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin  wrote:

>
> p=quarantine with pct=0 is useful to test DMARC with mailing list/groups
> which perform "From" rewrite based on DMARC policy. It's safe, because
> it actually works like "none" but it causes From rewrites, because it's
> still considered as "quarantine".
>
> I would never recommend to use "quarantine" without pct=0, because it
> can  mask serious deliverability problems.
>

If the only thing they are using to check deliverability is DMARC
reporting, the person has other problems. You should be able to see whether
it passed/failed DKIM and SPF but that does not tell you whether it was
delivered to the end user (at all) or quarantined in a SPAM folder. Many if
not most receiving domains perform all sorts of other checks on incoming
mail.

Michael Hammer

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Vladimir Dubrovin]

p=quarantine with pct=0 is useful to test DMARC with mailing list/groups
which perform "From" rewrite based on DMARC policy. It's safe, because
it actually works like "none" but it causes From rewrites, because it's
still considered as "quarantine".

I would never recommend to use "quarantine" without pct=0, because it
can  mask serious deliverability problems.

12.06.2019 0:00, Дилян Палаузов пишет:
> Dear all,
>
> when DMARC passes, there is no difference between p=reject and p=quarantine.
>
> When DMARC fails validation, this means extra work for humans.  This work can 
> be done by the sending or by the receiving
> organization.
>
> With p=quaratine, the sending organization (domain owner) indicates, that the 
> extra work is supposed to be done by the
> receiving organization.  So for the senders it is just cheaper (in terms of 
> less work) to publish p=quarantine.
>
> With p=reject, the sending organization (domain owner) indicates, that the 
> extra work has to be performed by the sending
> server, which might be the domain owner or some suspects.
>
> However, it is ultimately up to the receiving site to decide, whether it 
> wants to accept this extra work.  If it does
> not accept the extra work, it just handles quarantine as reject.  This does 
> not violate the DMARC specitification.
>
> Do you have a story, why one wants to publish p=quaratnine?  What is the use 
> case for it?  It just makes emails less
> reliable, as they end as Junk and this is very similar to discarding the 
> emails.
>
> Imagine a mailing lists, where the recipient of an email address expands to 
> several mailboxes on different domains.  An
> incoming email fails DMARC validation before being distributed over the ML.  
> The domain owner for that mail origin has
> published p=quarantine, this email cannot be delivered in the Junk folder of 
> the recipient, because the mailing list
> itself does not have a junk folder.
>
> How about, deleting policy Quarantine and instead rephrasing policy Reject:
>
> It is up to the receiving server if it rejects messages failing DMARC, or 
> accepts and delivers them as Junk.
>
> (This does not change the protocol, just the wording)
>
> Regards
>   Дилян
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladimir Dubrovin
@Mail.Ru

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos]

On 6/12/2019 9:49 AM, Dotzero wrote:


Given that the 5322.from is crucial for DMARC, and the 5322.from
is transmitted after DATA, how can you evaluate DMARC before DATA?

You can't evaluate DMARC before DATA.


Sure you can. I explained how it can be explored today!

Right now, today, it can explored with an existing protocol just was 
recently made historic:


https://tools.ietf.org/html/rfc4405

The status change was done because this protocol was part of the 
SenderID vs SPF experiment and SenderID lost.  SPF was made a standard 
track protocol.   It does not mean we could not consider leveraging 
the exist SUBMITTER code for other purposes and its a right fit for a 
high overhead payload technology in DMARC. I will suggest it can offer 
a high optimization payoff:


  - Eliminate payload reception overhead, yet still
  - Provide DMARC reporting and disposition override capabilities.

I don't think its an "Horrible Idea."  I think its a great idea. :)

--
HLS


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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos]

On 6/12/2019 9:37 AM, Laura Atkins wrote:



On 12 Jun 2019, at 14:28, Hector Santos

 (o) Reject with 55x before DATA state


Given that the 5322.from is crucial for DMARC, and the 5322.from is
transmitted after DATA, how can you evaluate DMARC before DATA?



When SPF is taking into account.  But yes, overall, my comment was 
more about the whole "rejection" issue whether it was with SPF or with 
the DATA payload technologies since MARID; SenderID, Domainkeys, DKIM, 
 then ADSP, now DMARC.  The "To Reject or Not Reject" question was 
always there.


With SPF and DMARC, for example, if the receiver was made aware of the 
5322.From before the DATA state, this would preempt the need to 
receive the payload in order to get reporting information or perhaps 
get DMARC overriding deposition, i.e. p=quarantine overrides SPF -ALL 
rejection.


How?

Well today, we had the PRA/SUBMITTER protocol used to pass the 
Purported Responsible Address via MAIL FROM:


   C: MAIL FROM: SUBMITTER=pra

Many clients do use SUBMITTER. Enable it and they will pop up.  Since 
we deprecated submitter when SPF was made standard track, imto, it may 
be a good idea to explore leveraging this protocol to support DMARC at 
SMTP.


I know this is just an optimization. But I would prefer this 
optimization over the idea of accepting a potentially large payload of 
a SPF -ALL failure just to find out if there is a DMARC record because 
the operator may want to see such SPF only failures.



--
HLS


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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Dotzero]

On Wed, Jun 12, 2019 at 9:38 AM Laura Atkins 
wrote:

>
> On 12 Jun 2019, at 14:28, Hector Santos 
> wrote:
>
> On 6/11/2019 5:00 PM, Дилян Палаузов wrote:
>
>
> How about, deleting policy Quarantine and instead rephrasing policy Reject:
>
> It is up to the receiving server if it rejects messages failing DMARC, or
> accepts and delivers them as Junk.
>
> (This does not change the protocol, just the wording)
>
>
> I think that is how it was thought it would be handled.  Don't take
> "rejection" literally, in fact, it can be a discard concept as well.  This
> is all about local policy. A receiver has the option, based on Local Policy
> and the implementation software to offer:
>
>  (o) Reject with 55x before DATA state
>
>
> Given that the 5322.from is crucial for DMARC, and the 5322.from is
> transmitted after DATA, how can you evaluate DMARC before DATA?
>
>
You can't evaluate DMARC before DATA. On the other hand, evaluating DMARC
is not a MUST for SMTP email. It is at best a SHOULD and more likely a MAY.
Speaking as an original participant in the dmarc.org team, we recognized
that there was no way to mandate participation in the DMARC worldview and
that it would get implemented based on perceived value by both sending
domains and mailbox providers.

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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Laura Atkins]

> On 12 Jun 2019, at 14:28, Hector Santos  
> wrote:
> 
> On 6/11/2019 5:00 PM, Дилян Палаузов wrote:
>> 
>> How about, deleting policy Quarantine and instead rephrasing policy Reject:
>> 
>> It is up to the receiving server if it rejects messages failing DMARC, or 
>> accepts and delivers them as Junk.
>> 
>> (This does not change the protocol, just the wording)
> 
> I think that is how it was thought it would be handled.  Don't take 
> "rejection" literally, in fact, it can be a discard concept as well.  This is 
> all about local policy. A receiver has the option, based on Local Policy and 
> the implementation software to offer:
> 
>  (o) Reject with 55x before DATA state

Given that the 5322.from is crucial for DMARC, and the 5322.from is transmitted 
after DATA, how can you evaluate DMARC before DATA?

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] Abolishing DMARC policy quarantine

[Hector Santos]

On 6/11/2019 5:00 PM, Дилян Палаузов wrote:


How about, deleting policy Quarantine and instead rephrasing policy Reject:

It is up to the receiving server if it rejects messages failing DMARC, or 
accepts and delivers them as Junk.

(This does not change the protocol, just the wording)


I think that is how it was thought it would be handled.  Don't take 
"rejection" literally, in fact, it can be a discard concept as well. 
 This is all about local policy. A receiver has the option, based on 
Local Policy and the implementation software to offer:


  (o) Reject with 55x before DATA state
  (_) Reject with 55x after DATA state (allows for collection of payload)
  (_) Accept with 250 and Discard
  (_) Accept with 250 and Quarantine

Whether systems actually do rejections are not, this has been 
discussed and debated over the years.  But in my view, the thinking 
has evolved to a realization that dynamic rejections at SMTP are real 
which complicates DMARC with the presumption the DATA is always 
received.  My take is that early systems always accepted mail because 
of scale/bulk needs and/or their software didn't yet have dynamic 
hooking, shimming, spawning, scripting capabilities at the SMTP state 
points.  With the advent of advanced hardware, Dynamic SMTP processing 
at the state points is a relatively new capability, 10-15 years 
perhaps, where spawning filters at the state point became feasible 
with a small sacrifice in SMTP session time increases.


We even had the discussions about SMTP idle wait time and even 
explored the idea of a "Keep Alive" concepts using a heart beat reply 
code. But it was discovered, back then (10 years?), that not all SMTP 
clients would not be capable to support a kept alive concept while a 
SMTP server is processing a transaction.  In theory, a SMTP hook has 
about 5 mins to complete otherwise a SMTP client can time out.  The 5 
mins for time outs is pretty out-dated so don't be surprise to see 
SMTP servers lowering it down to a few minutes or less due to SMTP 
clients not hanging up causing scaling problems.  But we do expect the 
SMTP client to wait 5 mins. :)


--
HLS


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

Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Ken O'Driscoll]

On Tue, 2019-06-11 at 21:00 +, Дилян Палаузов wrote:
> Dear all,
> 
> when DMARC passes, there is no difference between p=reject and
> p=quarantine.
[...snip...]
> However, it is ultimately up to the receiving site to decide, whether it
> wants to accept this extra work.  If it does not accept the extra work,
> it just handles quarantine as reject.  This does not violate the DMARC
> specitification.

Even in a moderately complex spam filtering engine, DMARC is just one
indicator / signal amongst many.

Who does the "extra work" is subjective. For example, a large mailbox
provider may consider support queries about missing or rejected emails as
unwanted "extra work" etc.

DMARC does not live in isolation - it's part to a greater ecosystem. 

> Do you have a story, why one wants to publish p=quaratnine?  What is the
> use case for it?  It just makes emails less reliable, as they end as Junk
> and this is very similar to discarding the emails.

There is a world of difference between requesting that a recipient flag an
incoming message as spam as opposed to asking them to discard it outright.
And that is regardless of how individual mailbox provides treat
p=quarantine.

A use case for p=quarantine is that when deploying DMARC for any reasonably
complex site, it forms part of a graduated approach (perhaps in conjunction
with pct=x) utilising aggregated reports to moving towards p=reject. 

The proactive nature of DMARC means that its deployment needs to be
properly planned with any risks mitigated as best as possible. The various
stages of p= can easily be articulated on a project plan / risk register.

And such sites that require such planning are often starting from a
position of improperly documented mail flows and inconsistently implemented
SPF/DKIM. In addition they often operate in regulated sectors and are
commonly top-heavy with risk-adverse middle management.

I accept that a small site with a simple mail flow which does not operate
in a regulated space and has thin governance could likely move straight
from p=none to p=reject without serious repercussions. Such sites are not
the majority of DMARC deployments.

DMARC changes how recipient mailbox providers treat email and therefore it
needs to be deployed in a controlled manner, p=quarantine being one
component of that. 

> Imagine a mailing lists, where the recipient of an email address expands
> to several mailboxes on different domains.  An incoming email fails DMARC
> validation before being distributed over the ML.  The domain owner for
> that mail origin has published p=quarantine, this email cannot be
> delivered in the Junk folder of the recipient, because the mailing list
> itself does not have a junk folder.

DMARC was never originally intended / scoped to work with domains which
interacted with mailing lists. The 5322.from address rewriting kludge 
allows such interaction by removing future DMARC tests.

A mailing list operator can also choose to reject emails from domains which
have a DMARC record.

DMARC has no use case to offer when working with mailing lists.

> How about, deleting policy Quarantine and instead rephrasing policy
> Reject:
> 
> It is up to the receiving server if it rejects messages failing DMARC, or
> accepts and delivers them as Junk.
> 
> (This does not change the protocol, just the wording)

I think this is completely unwarranted for (at a minimum) the above
mentioned reasons.

Ken.

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

[dmarc-ietf] Abolishing DMARC policy quarantine

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

Dear all,

when DMARC passes, there is no difference between p=reject and p=quarantine.

When DMARC fails validation, this means extra work for humans.  This work can 
be done by the sending or by the receiving
organization.

With p=quaratine, the sending organization (domain owner) indicates, that the 
extra work is supposed to be done by the
receiving organization.  So for the senders it is just cheaper (in terms of 
less work) to publish p=quarantine.

With p=reject, the sending organization (domain owner) indicates, that the 
extra work has to be performed by the sending
server, which might be the domain owner or some suspects.

However, it is ultimately up to the receiving site to decide, whether it wants 
to accept this extra work.  If it does
not accept the extra work, it just handles quarantine as reject.  This does not 
violate the DMARC specitification.

Do you have a story, why one wants to publish p=quaratnine?  What is the use 
case for it?  It just makes emails less
reliable, as they end as Junk and this is very similar to discarding the emails.

Imagine a mailing lists, where the recipient of an email address expands to 
several mailboxes on different domains.  An
incoming email fails DMARC validation before being distributed over the ML.  
The domain owner for that mail origin has
published p=quarantine, this email cannot be delivered in the Junk folder of 
the recipient, because the mailing list
itself does not have a junk folder.

How about, deleting policy Quarantine and instead rephrasing policy Reject:

It is up to the receiving server if it rejects messages failing DMARC, or 
accepts and delivers them as Junk.

(This does not change the protocol, just the wording)

Regards
  Дилян

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