Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Murray S. Kucherawy 
On Fri, Jan 22, 2021 at 6:44 PM Tim Wicinski  wrote:

> (this is really for Murray)
>
> On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy 
> wrote:
>
>>
>> Looks good to me where it is.  I would add "(PSL)", introducing the
>> acronym, right after its first use if we decide to leave it there.
>>
>> A formatting thing to take care of at some point: Anyplace you refer to
>> DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
>> policy"); anyplace you refer to DMARC, the specification (e.g., "Section
>> a.b.c of DMARC" or similar), it should be the  ...
>>  sorta deal so that it pops out as a reference.
>>
>>
> So the xref for RFC7489 were created of this form:
>
> DMARC
>
> and submitted into the submission system, the HTML document will have this 
> look:
>
>
> DMARC [RFC7489]   (Link is mapped to [RFC7489])
>
> and the HTML is
>
> [RFC7489]However, when I run 
> xml2rfc (v3.5.0) locally the
>
>
> However, when I run xml2rfc (v3.5.0) locally, the HTML shows the text "DMARC" 
> as a link
>
> and the HTML is
>
> DMARC
>
>
> So this makes my brain hurt. I'm going to revisit this in the morning.
>

For the ones that should actually be document references, try just .

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Tim Wicinski 
(this is really for Murray)

On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy 
wrote:

>
> Looks good to me where it is.  I would add "(PSL)", introducing the
> acronym, right after its first use if we decide to leave it there.
>
> A formatting thing to take care of at some point: Anyplace you refer to
> DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
> policy"); anyplace you refer to DMARC, the specification (e.g., "Section
> a.b.c of DMARC" or similar), it should be the  ...
>  sorta deal so that it pops out as a reference.
>
>
So the xref for RFC7489 were created of this form:

DMARC

and submitted into the submission system, the HTML document will have this look:


DMARC [RFC7489]   (Link is mapped to [RFC7489])

and the HTML is

[RFC7489]However, when I
run xml2rfc (v3.5.0) locally the


However, when I run xml2rfc (v3.5.0) locally, the HTML shows the text
"DMARC" as a link

and the HTML is

DMARC


So this makes my brain hurt. I'm going to revisit this in the morning.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Murray S. Kucherawy 
On Fri, Jan 22, 2021 at 4:58 PM Kurt Andersen (b)  wrote:

> On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b) 
>> wrote:
>>
>>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:
>>>

 Here's the paragraph in question

  To determine the organizational domain for a message under
 evaluation,
 and thus where to look for a policy statement, DMARC makes use
 of a Public Suffix
 List. The process for doing this can be found in Section 3.2 of
 the DMARC
 specification.

>>>
>>> The concern that I have with this wording is that it is (potentially)
>>> misleading. "How" DMARC determines the org domain does not matter at all to
>>> this spec. The important point is that we go to "org-1" in the tree for
>>> this extra lookup.
>>>
>>
>> This is just establishing context for why we're doing what the rest of
>> the document says (i.e., what problem we're solving).  Leaving this out
>> seems to me to paint an incomplete picture; Section 3 basically describes a
>> delta, but a delta to what?
>>
>
> And if DMARC changes how it determines the org domain, where does that
> leave this spec?
>

Do we need more than the reference(s) to RFC 7489?

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Tim Wicinski 
Kurt

Since this is an experiment, Appendix A discusses the updates that happen.
we don't actually say explicitly "if the experiment is a success, the
following changes will be made" and perhaps I should add some wording like
that.

On Fri, Jan 22, 2021 at 7:58 PM Kurt Andersen (b)  wrote:

> On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b) 
>> wrote:
>>
>>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:
>>>

 Here's the paragraph in question

  To determine the organizational domain for a message under
 evaluation,
 and thus where to look for a policy statement, DMARC makes use
 of a Public Suffix
 List. The process for doing this can be found in Section 3.2 of
 the DMARC
 specification.

>>>
>>> The concern that I have with this wording is that it is (potentially)
>>> misleading. "How" DMARC determines the org domain does not matter at all to
>>> this spec. The important point is that we go to "org-1" in the tree for
>>> this extra lookup.
>>>
>>
>> This is just establishing context for why we're doing what the rest of
>> the document says (i.e., what problem we're solving).  Leaving this out
>> seems to me to paint an incomplete picture; Section 3 basically describes a
>> delta, but a delta to what?
>>
>
> And if DMARC changes how it determines the org domain, where does that
> leave this spec?
>
> --Kurt
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Kurt Andersen (b) 
On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy 
wrote:

> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b) 
> wrote:
>
>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:
>>
>>>
>>> Here's the paragraph in question
>>>
>>>  To determine the organizational domain for a message under
>>> evaluation,
>>> and thus where to look for a policy statement, DMARC makes use
>>> of a Public Suffix
>>> List. The process for doing this can be found in Section 3.2 of
>>> the DMARC
>>> specification.
>>>
>>
>> The concern that I have with this wording is that it is (potentially)
>> misleading. "How" DMARC determines the org domain does not matter at all to
>> this spec. The important point is that we go to "org-1" in the tree for
>> this extra lookup.
>>
>
> This is just establishing context for why we're doing what the rest of the
> document says (i.e., what problem we're solving).  Leaving this out seems
> to me to paint an incomplete picture; Section 3 basically describes a
> delta, but a delta to what?
>

And if DMARC changes how it determines the org domain, where does that
leave this spec?

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Murray S. Kucherawy 
On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b)  wrote:

> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:
>
>>
>> Here's the paragraph in question
>>
>>  To determine the organizational domain for a message under
>> evaluation,
>> and thus where to look for a policy statement, DMARC makes use of
>> a Public Suffix
>> List. The process for doing this can be found in Section 3.2 of
>> the DMARC
>> specification.
>>
>
> The concern that I have with this wording is that it is (potentially)
> misleading. "How" DMARC determines the org domain does not matter at all to
> this spec. The important point is that we go to "org-1" in the tree for
> this extra lookup.
>

This is just establishing context for why we're doing what the rest of the
document says (i.e., what problem we're solving).  Leaving this out seems
to me to paint an incomplete picture; Section 3 basically describes a
delta, but a delta to what?

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Kurt Andersen (b) 
On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski  wrote:

>
> Here's the paragraph in question
>
>  To determine the organizational domain for a message under
> evaluation,
> and thus where to look for a policy statement, DMARC makes use of
> a Public Suffix
> List. The process for doing this can be found in Section 3.2 of
> the DMARC
> specification.
>

The concern that I have with this wording is that it is (potentially)
misleading. "How" DMARC determines the org domain does not matter at all to
this spec. The important point is that we go to "org-1" in the tree for
this extra lookup.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Tim Wicinski 
On Fri, Jan 22, 2021 at 6:25 PM Murray S. Kucherawy 
wrote:

> On Fri, Jan 22, 2021 at 3:05 PM Tim Wicinski  wrote:
>
>>
>> Thinking twice, perhaps we don't need to introduce the PSL until Section
 3.4.
 In that case, strike the last two sentences of the above paragraph.

>>>
>>> It's not obvious to me that this is better, but sure, let's discuss it.
>>>
 Here's the paragraph in question
>>
>>  To determine the organizational domain for a message under
>> evaluation,
>> and thus where to look for a policy statement, DMARC makes use of
>> a Public Suffix
>> List. The process for doing this can be found in Section 3.2 of
>> the DMARC
>> specification.
>>
>>
>>
>> The more I look at this, you need it near the top because that is where
>> the discussion
>> of the policy.  But also open to be convinced.
>>
>
> Looks good to me where it is.  I would add "(PSL)", introducing the
> acronym, right after its first use if we decide to leave it there.
>

Will do


> A formatting thing to take care of at some point: Anyplace you refer to
> DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
> policy"); anyplace you refer to DMARC, the specification (e.g., "Section
> a.b.c of DMARC" or similar), it should be the  ...
>  sorta deal so that it pops out as a reference.
>
>
Argh yes - I was removing the RFC7489 references which had the XML  bits.
 oh let me do that fix up

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Murray S. Kucherawy 
On Fri, Jan 22, 2021 at 3:05 PM Tim Wicinski  wrote:

>
> Thinking twice, perhaps we don't need to introduce the PSL until Section
>>> 3.4.
>>> In that case, strike the last two sentences of the above paragraph.
>>>
>>
>> It's not obvious to me that this is better, but sure, let's discuss it.
>>
>>> Here's the paragraph in question
>
>  To determine the organizational domain for a message under
> evaluation,
> and thus where to look for a policy statement, DMARC makes use of
> a Public Suffix
> List. The process for doing this can be found in Section 3.2 of
> the DMARC
> specification.
>
>
>
> The more I look at this, you need it near the top because that is where
> the discussion
> of the policy.  But also open to be convinced.
>

Looks good to me where it is.  I would add "(PSL)", introducing the
acronym, right after its first use if we decide to leave it there.

A formatting thing to take care of at some point: Anyplace you refer to
DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
policy"); anyplace you refer to DMARC, the specification (e.g., "Section
a.b.c of DMARC" or similar), it should be the  ...
 sorta deal so that it pops out as a reference.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Tim Wicinski 
On Tue, Jan 19, 2021 at 9:19 AM Murray S. Kucherawy 
wrote:

> On Tue, Jan 19, 2021 at 2:31 AM Alessandro Vesely  wrote:
>
> > To determine the organizational domain for a message under
>> evaluation,
>> > and thus where to look for a policy statement, DMARC makes use of a
>> > Public Suffix List.
>> > The process for doing this can be found in Section 3.2 of the DMARC
>> > specification.
>>
>> Couldn't we skip that kind of functional intro and say something general,
>> such
>> as anticipating Section 2.2:
>>
>>  Public Suffix Domains (PSDs) are domain names publicly accessible for
>>  domain registration.  As explained in Section 2.2, they include all
>> top
>>  level domains and some more.  The way delegations occur on the global
>>  Internet makes it difficult to establish whether a domain is a PSD.
>> A
>>  community maintained Public Suffix List (PSL) exists for that
>> purpose.
>>
>> Thinking twice, perhaps we don't need to introduce the PSL until Section
>> 3.4.
>> In that case, strike the last two sentences of the above paragraph.
>>
>
> It's not obvious to me that this is better, but sure, let's discuss it.
>
>> Here's the paragraph in question

 To determine the organizational domain for a message under
evaluation,
and thus where to look for a policy statement, DMARC makes use of a
Public Suffix
List. The process for doing this can be found in Section 3.2 of the
DMARC
specification.



The more I look at this, you need it near the top because that is where the
discussion
of the policy.  But also open to be convinced.

tim



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

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread John Levine 
In article  
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I think spammers would only get two things from the DMARC reports:
>1) Have they setup their configuration correctly?
>2) Consume resources from the mailbox provider to generate reports.
>
>Only if #2 is a concern for the mailbox provider I think there is a need to
>filter who gets a report and who does not.

We have a decade of experience with DMARC and I don't ever recall
anyone having a practical issue with who they send reports to.

As someone said, the better the spammers align their stuff, the better
we can filter it.

Close this, please.

R's,
John

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Tim Wicinski 
On Tue, Jan 19, 2021 at 5:31 AM Alessandro Vesely  wrote:

> On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote:
> > [...]
>
>
> I guess "[this document]" refers to the RFC number to be.  I think it's
> useless
> and can be safely removed, all of the five occurrences of it.
>
> It is clearer and more useful to specify the referred document when it is
> /not/
> this document.  For example:
>
>  Changes in Section 6.5 of RFC 7489 "Domain Owner Actions"
>
> The above is going to be rendered with the correct anchor in the htmlized
> version of the document.  It can be expressed in xml as:
>
>  
>
> so as to generate correct links whenever possible.
>

two things:  1) to be accurate I would want to target the section anchor.
But actually the real answer is 2) the RFC editor owns the final XML and I
believe
they perform a bunch of this work during the AUTH48 process.

Now saying that, someone will politely explain how wrong I am.

In fact, those are the two terms appearing in the title.  BTW, I'd change
> the
> title to:
>
>  Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
>  Extension For Public Suffix Domains (PSDs)
>

I went with the Murray;s "Experimental DMARC Extension For Public Suffix
Domains"

And Murray restructured the Intro and it feels much cleaner.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

2021-01-22 Thread Tim Wicinski 
On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy 
wrote:

> In the interests of getting this document on its way, I'd like to suggest
> the following edits in response to Dale's most recent message.  If the
> working group concurs, we can finally get this out to Last Call.
>
> My goal as an AD here is just to get the GenART feedback addressed, but
> the text is being submitted as a WG contribution for discussion and
> consensus consideration, not as a demand.   Please process accordingly; I
> believe the agreement is to do another WGLC on the document before it goes
> on its way, so the sooner consensus is reached on all of this, the sooner
> it goes.
>
> First, a suggestion of my own that I think I saw elsewhere, but it's not
> in Dale's reply: In several places there's a reference to "DMARC
> [RFC7489]".  That's appropriate the first time the reference is made, but I
> think after that you can just say "DMARC" when referring to the protocol
> generally, or to "RFC 7489" when you need to make a specific section or
> text reference.  They don't need to appear together everywhere.
>
> I think Dave's original feedback has been addressed -- good stuff -- so
> here are my suggestions around what's left:
>
> On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley  wrote:
>
>> My apologies for not tending to this promptly.
>>
>> In regard to the description of the experiments, the result criteria are
>> rather subjective, but I don't see that as a problem.  It does seem to
>> me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
>> too narrow, as only the 3rd experiment seems to be about privacy
>> issues.  A title as generic as "PSD DMARC Experiments" would be fine.
>>
>
> That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
> we want to treat it all as one common thing.
>
>
>> Although I note that even the -09 does not define "PSD", only "longest
>> PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
>> equal to "PSO Controlled Domain Name", though, or rather to some related
>> set of them.  That needs to be cleaned up in some way.
>>
>
> PSD appears to be well defined in Section 2.2.
>
> In section 3.5 and later there is the phrase "[this document] longest
>> PSD".  I'm not sure, but I think this is supposed to be "longest PSD
>> ([this document] section NN.NN)".
>>
>
> Agreed.
>
> I believe that my strongest critique was that section 1 is difficult to
>> understand if one does not already understand DMARC, and it does not
>> seem that the section has been revised.  Re-reading it, I notice that it
>> says "DMARC leverages public suffix lists to determine which domains are
>> organizational domains."  Ignoring that I dislike this use of
>> "leverage", a critical point is that it takes the existence of public
>> suffix lists a priori -- indeed, this use of "leverage" generally means
>> that the leveraged thing already exists and one is now extracting
>> additional benefit from that.  Whereas I've never heard of public suffix
>> lists and would naively expect that they are difficult to create and
>> maintain.  It might be better to say "DMARC uses public suffix lists to
>> determine which domains are organizational domains.  Public suffix lists
>> are obtained/maintained/distributed by ..."
>>
>
> Replace all of Section 1 with this (ignore funny line wrapping):
>
>DMARC [RFC7489 ] provides a mechanism 
> for publishing organizational
>policy information to email receivers.  DMARC allows policy to be
>specified for both individual domains and for organizational domains
>and their sub-domains within a single organization.
>
>To determine the organizational domain for a message under evaluation,
>and thus where to look for a policy statement, DMARC makes use of a Public 
> Suffix List.
>The process for doing this can be found in Section 3.2 of the DMARC 
> specification.
>
>DMARC as specified presumes that domain names present in a PSL are not
>organizational domains and thus not subject to DMARC processing; domains
>are either organizational domains, sub-domains of organizational
>domains, or listed on a PSL.  For domains listed in a
>PSL, i.e., TLDs and domains that exist between TLDs and
>organization level domains, policy can only be published for the
>exact domain.  No method is available for these domains to express
>policy or receive feedback reporting for sub-domains.  This missing
>method allows for the abuse of non-existent organizational-level
>domains and prevents identification of domain abuse in email.
>
>This document specifies experimental updates to the DMARC and PSL 
> algorithm cited
>above, in an attempt to mitigate this abuse.
>
>
Done

>
> Looking at the second paragraph of section 1, I notice that despite all
>> the special terms for classifying domain names in section 2, the example
>> in this section does not describe which of

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread Douglas Foster 
Ok

On Fri, Jan 22, 2021, 10:31 AM Seth Blank  wrote:

> Douglas, what I'm hearing in this thread is that the information in a
> DMARC report is well understood, and mailbox receivers are especially
> sensitive to information leakages to spammers who could abuse that, and
> after seven years of operational experience, are telling you such leakage
> does not occur from DMARC aggregate reports.
>
> I'm not opposed to saying such a thing in the considerations if there's
> group consensus to do so, but let's wrap this thread and move on to others
> tickets now, please.
>
> Seth, as Chair
>
> On Fri, Jan 22, 2021 at 7:19 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Your second point seems to address my question, asserting that the value
>> of information sharing exceeds the risk.   This is debatable, so I think it
>> should be documented in security considerations and reacting options should
>> be articulated.
>>
>> The first point still escapes me.  If we are providing information about
>> all messages received, and are providing disposition information about all
>> those messages, then it includes information about messages that were
>> acceptably authorized.  Sender policy is irrelevant.  All that matters is
>> which messages are reported with disposition results.
>>
>> On Fri, Jan 22, 2021, 9:16 AM Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>>
>>> On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster <
>>> dougfoster.emailstanda...@gmail.com> wrote:
>>>
 Not sure what is unclear about my concern.

 The spec provides for reporting whether the actual disposition was
 different from the sender policy request, and the reason that this was 
 done.


>>> "DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
>>> means that my system needs 20 messages to learn how to identify bad content"
>>>
>>>
>>> As I said, the above is not an example of the 'actual disposition being
>>> different from the sender policy request', because the sender policy
>>> request does not cover the scenario where DMARC passed. It only applies to
>>> those cases where DMARC fails. There is no facility for a domain owner to
>>> use DMARC to request message treatment when the DMARC validation result is
>>> 'pass', nor should a domain owner assume that a message that passes DMARC
>>> checks will be accepted solely based on that information.
>>>
>>>
>>>
 Ale suggests that "disposition" must be narrowly defined to mean only
 the disposition based on DMARC staus.  This still means that local policy
 is revealed under some circumstances.

 I do not see why local policy should be revealed at all.

>>>
>>> Consider the opposite case, one where a hypothetical financial
>>> institution publishes a policy of p=reject and receives aggregate reports
>>> showing mail that it did not originate failing DMARC but not being
>>> rejected. That is information that might prompt a conversation between the
>>> financial institution and the DMARC validator, in an effort to ensure that
>>> its mutual customers aren't exposed to possible abuse vectors.
>>>
>>> Yes, that would still be communicated in your scenario of highly trusted
>>> correspondent domains, but I don't believe that the work necessary to
>>> curate such a list provides enough ROI for the report generator to override
>>> whatever minimal risk there might be in revealing its DMARC handling
>>> policies to miscreants. DMARC aggregate reports are not the only source of
>>> such information for the miscreant; the bad guys already have accounts at
>>> their target mailbox providers, and they're sending mail to those accounts
>>> and learning what happens from those accounts and from their own bounce
>>> logs.
>>>
>>> --
>>>
>>> *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
>>>
>> ___
>> 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

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread Seth Blank 
Douglas, what I'm hearing in this thread is that the information in a DMARC
report is well understood, and mailbox receivers are especially sensitive
to information leakages to spammers who could abuse that, and after seven
years of operational experience, are telling you such leakage does not
occur from DMARC aggregate reports.

I'm not opposed to saying such a thing in the considerations if there's
group consensus to do so, but let's wrap this thread and move on to others
tickets now, please.

Seth, as Chair

On Fri, Jan 22, 2021 at 7:19 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Your second point seems to address my question, asserting that the value
> of information sharing exceeds the risk.   This is debatable, so I think it
> should be documented in security considerations and reacting options should
> be articulated.
>
> The first point still escapes me.  If we are providing information about
> all messages received, and are providing disposition information about all
> those messages, then it includes information about messages that were
> acceptably authorized.  Sender policy is irrelevant.  All that matters is
> which messages are reported with disposition results.
>
> On Fri, Jan 22, 2021, 9:16 AM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> Not sure what is unclear about my concern.
>>>
>>> The spec provides for reporting whether the actual disposition was
>>> different from the sender policy request, and the reason that this was done.
>>>
>>>
>> "DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
>> means that my system needs 20 messages to learn how to identify bad content"
>>
>>
>> As I said, the above is not an example of the 'actual disposition being
>> different from the sender policy request', because the sender policy
>> request does not cover the scenario where DMARC passed. It only applies to
>> those cases where DMARC fails. There is no facility for a domain owner to
>> use DMARC to request message treatment when the DMARC validation result is
>> 'pass', nor should a domain owner assume that a message that passes DMARC
>> checks will be accepted solely based on that information.
>>
>>
>>
>>> Ale suggests that "disposition" must be narrowly defined to mean only
>>> the disposition based on DMARC staus.  This still means that local policy
>>> is revealed under some circumstances.
>>>
>>> I do not see why local policy should be revealed at all.
>>>
>>
>> Consider the opposite case, one where a hypothetical financial
>> institution publishes a policy of p=reject and receives aggregate reports
>> showing mail that it did not originate failing DMARC but not being
>> rejected. That is information that might prompt a conversation between the
>> financial institution and the DMARC validator, in an effort to ensure that
>> its mutual customers aren't exposed to possible abuse vectors.
>>
>> Yes, that would still be communicated in your scenario of highly trusted
>> correspondent domains, but I don't believe that the work necessary to
>> curate such a list provides enough ROI for the report generator to override
>> whatever minimal risk there might be in revealing its DMARC handling
>> policies to miscreants. DMARC aggregate reports are not the only source of
>> such information for the miscreant; the bad guys already have accounts at
>> their target mailbox providers, and they're sending mail to those accounts
>> and learning what happens from those accounts and from their own bounce
>> logs.
>>
>> --
>>
>> *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
>>
> ___
> 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

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread Douglas Foster 
Your second point seems to address my question, asserting that the value of
information sharing exceeds the risk.   This is debatable, so I think it
should be documented in security considerations and reacting options should
be articulated.

The first point still escapes me.  If we are providing information about
all messages received, and are providing disposition information about all
those messages, then it includes information about messages that were
acceptably authorized.  Sender policy is irrelevant.  All that matters is
which messages are reported with disposition results.

On Fri, Jan 22, 2021, 9:16 AM Todd Herr  wrote:

> On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Not sure what is unclear about my concern.
>>
>> The spec provides for reporting whether the actual disposition was
>> different from the sender policy request, and the reason that this was done.
>>
>>
> "DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
> means that my system needs 20 messages to learn how to identify bad content"
>
>
> As I said, the above is not an example of the 'actual disposition being
> different from the sender policy request', because the sender policy
> request does not cover the scenario where DMARC passed. It only applies to
> those cases where DMARC fails. There is no facility for a domain owner to
> use DMARC to request message treatment when the DMARC validation result is
> 'pass', nor should a domain owner assume that a message that passes DMARC
> checks will be accepted solely based on that information.
>
>
>
>> Ale suggests that "disposition" must be narrowly defined to mean only the
>> disposition based on DMARC staus.  This still means that local policy is
>> revealed under some circumstances.
>>
>> I do not see why local policy should be revealed at all.
>>
>
> Consider the opposite case, one where a hypothetical financial institution
> publishes a policy of p=reject and receives aggregate reports showing mail
> that it did not originate failing DMARC but not being rejected. That is
> information that might prompt a conversation between the financial
> institution and the DMARC validator, in an effort to ensure that its mutual
> customers aren't exposed to possible abuse vectors.
>
> Yes, that would still be communicated in your scenario of highly trusted
> correspondent domains, but I don't believe that the work necessary to
> curate such a list provides enough ROI for the report generator to override
> whatever minimal risk there might be in revealing its DMARC handling
> policies to miscreants. DMARC aggregate reports are not the only source of
> such information for the miscreant; the bad guys already have accounts at
> their target mailbox providers, and they're sending mail to those accounts
> and learning what happens from those accounts and from their own bounce
> logs.
>
> --
>
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread Todd Herr 
On Fri, Jan 22, 2021 at 9:02 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Not sure what is unclear about my concern.
>
> The spec provides for reporting whether the actual disposition was
> different from the sender policy request, and the reason that this was done.
>
>
"DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
means that my system needs 20 messages to learn how to identify bad content"


As I said, the above is not an example of the 'actual disposition being
different from the sender policy request', because the sender policy
request does not cover the scenario where DMARC passed. It only applies to
those cases where DMARC fails. There is no facility for a domain owner to
use DMARC to request message treatment when the DMARC validation result is
'pass', nor should a domain owner assume that a message that passes DMARC
checks will be accepted solely based on that information.



> Ale suggests that "disposition" must be narrowly defined to mean only the
> disposition based on DMARC staus.  This still means that local policy is
> revealed under some circumstances.
>
> I do not see why local policy should be revealed at all.
>

Consider the opposite case, one where a hypothetical financial institution
publishes a policy of p=reject and receives aggregate reports showing mail
that it did not originate failing DMARC but not being rejected. That is
information that might prompt a conversation between the financial
institution and the DMARC validator, in an effort to ensure that its mutual
customers aren't exposed to possible abuse vectors.

Yes, that would still be communicated in your scenario of highly trusted
correspondent domains, but I don't believe that the work necessary to
curate such a list provides enough ROI for the report generator to override
whatever minimal risk there might be in revealing its DMARC handling
policies to miscreants. DMARC aggregate reports are not the only source of
such information for the miscreant; the bad guys already have accounts at
their target mailbox providers, and they're sending mail to those accounts
and learning what happens from those accounts and from their own bounce
logs.

-- 

*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] Reports helping spammers? (#81)

2021-01-22 Thread Douglas Foster 
Not sure what is unclear about my concern.

The spec provides for reporting whether the actual disposition was
different from the sender policy request, and the reason that this was done.

Ale suggests that "disposition" must be narrowly defined to mean only the
disposition based on DMARC staus.  This still means that local policy is
revealed under some circumstances.

I do not see why local policy should be revealed at all.

On Fri, Jan 22, 2021, 8:41 AM Todd Herr  wrote:

> On Fri, Jan 22, 2021 at 7:00 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> My specific concern is with disposition information.Whether the
>> message presents with acceptable credentials is the sender's
>> responsibility, and I have no problem with documenting whether it passed
>> SPF or DKIM or both, including which DKIM scope was used for the
>> evaluation. I have no problem with reporting the sender policy that I
>> retrieved from DNS.
>>
>> But should I report the disposition applied, and the reason that my
>> disposition was different from the sender policy?That seems like
>> information leakage about my defenses which should only be revealed to
>> highly trusted correspondent domains.
>>
>> Consider what is likely to happen If I call an organization's help desk
>> and say,
>>  "My emails to Sally are not getting delivered, and I want to know
>> why?"
>> The answer should be, and usually is,
>>  "Have Sally open a ticket and we will discuss the problem with her!"
>> Should not the same policy apply here?
>>
>
>
>
>>
>> Possible misuse of disposition information:
>> - DMARC=(Fail), Disposition = (120 delivered) -- probably means that my
>> system does not enforce DMARC at all
>> - DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
>> means that my system needs 20 messages to learn how to identify bad content
>>
>> I suggest that disposition information should be redacted by default, and
>> only included on an exception basis for highly trusted source domains.
>>
>>
> You're using the phrase "disposition was different from the sender policy"
> in a way that I don't understand.
>
> Sender policy is a request for handling when a message fails DMARC
> validation checks. In your examples of possible misuse of disposition
> information, one you're citing is 100 rejected messages when DMARC passes;
> that's not a disposition that's different from sender policy, because DMARC
> pass is no guarantee of a message being accepted, and again, sender policy
> only concerns the state of DMARC failing validation checks. The DMARC
> policy statement isn't a vehicle for requesting handling when the message
> passes DMARC checks. Beyond that, I'm not even sure that a condition exists
> where a message would have a disposition of "rejected due to DMARC" when
> the DMARC validation result is pass, but I've been accused in the past of
> lacking imagination, so perhaps it could happen.
>
> For your example of DMARC failing and all 120 messages being delivered,
> I've never personally met a spammer (every conversation I ever had started
> with "I'm not a spammer")  but I can't conceive of a spammer configuring
> his domain with a DMARC policy of p=reject and sending mail that doesn't
> authenticate as a way of probing things, but I suppose it could happen.
> Because aggregate reports only come in once every 24 hours from most
> places, he's not going to get immediate gratification like he would simply
> by having a few test or seed accounts at the target domain, but maybe he's
> patient. Of course, DMARC isn't the sole arbiter of whether or not the
> message made it to the Inbox and not the Junk or Spam folder, so results
> would be inconclusive at best. His test accounts will tell him much more
> than DMARC reports will tell him.
>
> I can't speak for any mailbox providers, but I suspect that the work of
> updating their reporting tools to handle an exception list and curating
> such a list is more expensive to them than whatever risk might exist in
> generating a DMARC aggregate report for a few spam sending domains. Maybe a
> note in Security Considerations or something? *shrug*
>
>
> --
>
> *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
>
___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread Todd Herr 
On Fri, Jan 22, 2021 at 7:00 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My specific concern is with disposition information.Whether the
> message presents with acceptable credentials is the sender's
> responsibility, and I have no problem with documenting whether it passed
> SPF or DKIM or both, including which DKIM scope was used for the
> evaluation. I have no problem with reporting the sender policy that I
> retrieved from DNS.
>
> But should I report the disposition applied, and the reason that my
> disposition was different from the sender policy?That seems like
> information leakage about my defenses which should only be revealed to
> highly trusted correspondent domains.
>
> Consider what is likely to happen If I call an organization's help desk
> and say,
>  "My emails to Sally are not getting delivered, and I want to know
> why?"
> The answer should be, and usually is,
>  "Have Sally open a ticket and we will discuss the problem with her!"
> Should not the same policy apply here?
>



>
> Possible misuse of disposition information:
> - DMARC=(Fail), Disposition = (120 delivered) -- probably means that my
> system does not enforce DMARC at all
> - DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
> means that my system needs 20 messages to learn how to identify bad content
>
> I suggest that disposition information should be redacted by default, and
> only included on an exception basis for highly trusted source domains.
>
>
You're using the phrase "disposition was different from the sender policy"
in a way that I don't understand.

Sender policy is a request for handling when a message fails DMARC
validation checks. In your examples of possible misuse of disposition
information, one you're citing is 100 rejected messages when DMARC passes;
that's not a disposition that's different from sender policy, because DMARC
pass is no guarantee of a message being accepted, and again, sender policy
only concerns the state of DMARC failing validation checks. The DMARC
policy statement isn't a vehicle for requesting handling when the message
passes DMARC checks. Beyond that, I'm not even sure that a condition exists
where a message would have a disposition of "rejected due to DMARC" when
the DMARC validation result is pass, but I've been accused in the past of
lacking imagination, so perhaps it could happen.

For your example of DMARC failing and all 120 messages being delivered,
I've never personally met a spammer (every conversation I ever had started
with "I'm not a spammer")  but I can't conceive of a spammer configuring
his domain with a DMARC policy of p=reject and sending mail that doesn't
authenticate as a way of probing things, but I suppose it could happen.
Because aggregate reports only come in once every 24 hours from most
places, he's not going to get immediate gratification like he would simply
by having a few test or seed accounts at the target domain, but maybe he's
patient. Of course, DMARC isn't the sole arbiter of whether or not the
message made it to the Inbox and not the Junk or Spam folder, so results
would be inconclusive at best. His test accounts will tell him much more
than DMARC reports will tell him.

I can't speak for any mailbox providers, but I suspect that the work of
updating their reporting tools to handle an exception list and curating
such a list is more expensive to them than whatever risk might exist in
generating a DMARC aggregate report for a few spam sending domains. Maybe a
note in Security Considerations or something? *shrug*


-- 

*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] Reports helping spammers? (#81)

2021-01-22 Thread Alessandro Vesely 

On Fri 22/Jan/2021 13:00:30 +0100 Douglas Foster wrote:


Possible misuse of disposition information:
- DMARC=(Fail), Disposition = (120 delivered) -- probably means that my system 
does not enforce DMARC at all
- DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly means 
that my system needs 20 messages to learn how to identify bad content


I suggest that disposition information should be redacted by default, and only 
included on an exception basis for highly trusted source domains.



There is a paragraraph in RFC 7489 that I cannot find in the draft:

   Aggregate reports are limited in scope to DMARC policy and
   disposition results, to information pertaining to the underlying
   authentication mechanisms, and to the identifiers involved in DMARC
   validation.

Can that be clarified better?  Se spec sometimes uses the term "final 
disposition" to mean what Doug calls "disposition information" in the text 
quoted above.


To wit, a DMARC filter acting between DATA and end-of-data doesn't actually 
know about final disposition.  It can reject, but cannot deliver to Inbox.


In fact, the  field refers to what the filter is configured to do, 
except that quarantine can only be signaled to downstream processes.  It 
reports "quarantine" if it did that signaling.  It reports "reject" if it 
rejects.  Otherwise reports "none".  (Did we conclude we want "pass"?)


Identifying bad content, possibly based on DMARC having identified a bad actor, 
or after actual content inspection, happens downstream.  A DMARC filter doesn't 
know and doesn't want to know the final outcome, and doesn't report it.


It is important to be very clear on this point, to avoid that receivers fail to 
enable aggregate reporting for fear of helping spammers.



Best
Ale
--




















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

Re: [dmarc-ietf] Reports helping spammers? (#81)

2021-01-22 Thread Douglas Foster 
My specific concern is with disposition information.Whether the message
presents with acceptable credentials is the sender's responsibility, and I
have no problem with documenting whether it passed SPF or DKIM or both,
including which DKIM scope was used for the evaluation. I have no
problem with reporting the sender policy that I retrieved from DNS.

But should I report the disposition applied, and the reason that my
disposition was different from the sender policy?That seems like
information leakage about my defenses which should only be revealed to
highly trusted correspondent domains.

Consider what is likely to happen If I call an organization's help desk and
say,
 "My emails to Sally are not getting delivered, and I want to know why?"
The answer should be, and usually is,
 "Have Sally open a ticket and we will discuss the problem with her!"
Should not the same policy apply here?

Possible misuse of disposition information:
- DMARC=(Fail), Disposition = (120 delivered) -- probably means that my
system does not enforce DMARC at all
- DMARC=(Pass), Disposition = (20 delivered, 100 rejected)  -- possibly
means that my system needs 20 messages to learn how to identify bad content

I suggest that disposition information should be redacted by default, and
only included on an exception basis for highly trusted source domains.

Doug Foster

On Thu, Jan 21, 2021 at 4:00 PM Brotman, Alex  wrote:

> Hello folks,
>
> Thought I'd see if we could come to a conclusion on this ticket.  The gist
> is that the reporter believes that (aggregate?) reports can help spammers
> to determine some effectiveness of their message attempts.
>
> Full Text:
> -
> Spammers could use DMARC reports to monitor the effectiveness of their
> campaigns, and we do not want to help them. Do existing implementations
> send reports to any domain that requests them, or only to those domains
> that are considered "acceptable"? If reports are only sent to acceptable
> domains, what sort of criteria have been useful?
>
> System administrators will appreciate such advice. Product developers will
> need guidance about the features they should provide so that a system
> administrator can control which domains do not receive reports.
> -
>
> >From an operator side, I don't agree with this assessment.  The reports
> do not show if/why a MBP may place a message in the Junk folder.  Could it
> be DMARC quarantine?  Sure.  It could also be any number of things from a
> large matrix of decisions, none of which are shown in a DMARC report.
> Also, the reports are typically sent once per day (seems like most ignore
> the 'ri'), quite likely some time after the end of the reporting period.
> Additionally, they probably have more efficient/immediate methods of
> evaluating their success rate.
>
> If you believe something has been overlooked, please feel free to share.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> ___
> 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