Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Murray S. Kucherawy]

On Wed, May 29, 2019 at 10:13 AM John R Levine  wrote:

> As far as I can tell your proposal to break the document in two has
> gotten no support at all.  Can we stop now?
>

What's on topic for the group and what isn't is the purview of the
co-chairs and the charter.  Let's please not stifle discussions before they
die on their own absent chair action to the contrary.

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Hector Santos]

On 5/29/2019 1:13 PM, John R Levine wrote:

You seem to be suggesting that the standards-track DMARCbis should be
different because an informational, non-WG RFC has already been
published. From a process standpoint that's bad; standards-track RFCs
should go through exactly the same process regardless of whether or not
they were previously published as Informational.


As far as I can tell your proposal to break the document in two has
gotten no support at all.  Can we stop now?


"No support at all?"   For the record, I support the "split."  But I 
won't care it is remains.  I just think it will complicate a 
specification and extend the future work of completing a DKIM Policy 
Model proposed standard which is in need of a tremendous amount of work.


--
HLS


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Alessandro Vesely]

On Wed 29/May/2019 19:01:11 +0200 Jim Fenton wrote:

> One more point on this:
> 
> On 5/24/19 7:37 AM, John R Levine wrote:
>>
>> That's because they separated before they were published, so there was
>> nothing to be incompatible with.  If I knew what would break when
>> reorganizing and rewriting a document into pieces, I could fix it, but
>> since I don't, and nobody else does, let's not go there.
> 
> 
> You seem to be suggesting that the standards-track DMARCbis should be
> different because an informational, non-WG RFC has already been
> published. From a process standpoint that's bad; standards-track RFCs
> should go through exactly the same process regardless of whether or not
> they were previously published as Informational.


Albeit rfc7489 is informational, it is meant to be a spec.  So structural
changes to the document, however useful to first-time readers, would be a
nightmare for those who have already implemented DMARC and are checking what
has changed.  It would also disrupt many references, thereby invalidating a
large part of the literature.

A new companion rfc (or a new appendix, or a rewriting of Section 8) meant as
an implementation guide could host discussions about the points 1a... 4b listed
upthread.  It should recount the most useful tips we collected thus far, rather
than trying to establish normative duties, IMHO.


Best
Ale
-- 






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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Jim Fenton]

On 5/29/19 10:13 AM, John R Levine wrote:
>> You seem to be suggesting that the standards-track DMARCbis should be
>> different because an informational, non-WG RFC has already been
>> published. From a process standpoint that's bad; standards-track RFCs
>> should go through exactly the same process regardless of whether or not
>> they were previously published as Informational.
>
> As far as I can tell your proposal to break the document in two has
> gotten no support at all.  Can we stop now?
>

This was about a broader process issue and not specifically about
splitting the document into parts (I should have changed the subject
line). But yes, we can stop talking about the document split.

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John R Levine]

You seem to be suggesting that the standards-track DMARCbis should be
different because an informational, non-WG RFC has already been
published. From a process standpoint that's bad; standards-track RFCs
should go through exactly the same process regardless of whether or not
they were previously published as Informational.


As far as I can tell your proposal to break the document in two has 
gotten no support at all.  Can we stop now?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Jim Fenton]

On 5/27/19 11:19 AM, Dilyan Palauzov wrote:

Hello Jim,

Do you want to split yourself reporiting and policy and create two 
separate documents, or do you know somebody wiliing to perform the 
separation?  I cannot imagine why shall one want to read and 
understand only reporting or only policy and thus I do net understand 
for which target group will be these separated documents. The current 
documents are suitable to achieve their aim.  (Well, to contradict 
myself, I would like to read and understand all the RFCs, so a single 
RFC containing all current RFCs would be enough, but obviously, I 
cannot read and understand such RFC).



Dilyan,

I didn't follow the latter portion of your message entirely, but yes, I 
think I understand the problems that DMARC filtering and reporting are 
intended to solve.


To your initial question, unless a bunch of other people speak up in 
favor of the split I'm proposing, it won't have WG consensus so we don't 
need to consider who does the editorial work involved.


-Jim


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Jim Fenton]

On 5/27/19 11:25 AM, Dave Crocker wrote:

On 5/27/2019 10:23 AM, Jim Fenton wrote:

On 5/25/19 1:53 PM, Dave Crocker wrote:


Ultimately, you are asking marketing questions, not technical ones.



OK, so let me ask a technical question: What is the technical 
justification for the requirements in Section 8? For other protocols, 


A section like that typically seeks to establish a basis for minimum 
capability of usable implementations.  It sets expectations for 
capabilities and limits.  An amusing bit about this particular one is 
that, in spite of having the word "requirements' in the section title, 
none of the content language is normative.



I hadn't noticed the lack of normative language in this section. In that 
case I would propose removing it because it does not serve any purpose 
and because it might mislead others who, as I did, misinterpreted the 
word "requirements" in the section title.


-Jim


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John R Levine]

On 5/25/19 1:53 PM, Dave Crocker wrote:
A section like that typically seeks to establish a basis for minimum 
capability of usable implementations.  It sets expectations for capabilities 
and limits.  An amusing bit about this particular one is that, in spite of 
having the word "requirements' in the section title, none of the content 
language is normative.


It's certainly confusing.  I understand what the list of items is but I 
don't understand what anyone is supposed to do about them.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Dave Crocker]

On 5/27/2019 10:23 AM, Jim Fenton wrote:

On 5/25/19 1:53 PM, Dave Crocker wrote:


Ultimately, you are asking marketing questions, not technical ones.



OK, so let me ask a technical question: What is the technical 
justification for the requirements in Section 8? For other protocols, 


A section like that typically seeks to establish a basis for minimum 
capability of usable implementations.  It sets expectations for 
capabilities and limits.  An amusing bit about this particular one is 
that, in spite of having the word "requirements' in the section title, 
none of the content language is normative.



there are mandatory-to-implement requirements (RFC 6376 section 3.3 for 
example) that exist in order to ensure interoperability between senders 
and receivers. But implementation of DMARC policy and DMARC reporting 
can separately be useful without the other.


I don't understand how your last sentence, here, applies to the subject 
Section 8.



Aren't the requirements in Section 8, which effectively say "you need to 
do this and this to call yourself a DMARC implementation" really a 
marketing, not a technical consideration? Does this belong in the spec?


"to call yourself" is a perspective neither offered nor implied by the 
section.  A marketing goal might choose to use it for that purpose, but 
there's nothing in the language or substance of the section suggesting 
that use or designed for that use.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John R Levine]

Aren't the requirements in Section 8, which effectively say "you need to do 
this and this to call yourself a DMARC implementation" really a marketing, 
not a technical consideration? Does this belong in the spec?


I agree that it'd makes sense to remove it, or rewrite it to say it's 
about identifying what you're doing, not about compliance.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Dilyan Palauzov]

Hello Jim,

Do you want to split yourself reporiting and policy and create two  
separate documents, or do you know somebody wiliing to perform the  
separation?  I cannot imagine why shall one want to read and  
understand only reporting or only policy and thus I do net understand  
for which target group will be these separated documents. The current  
documents are suitable to achieve their aim.  (Well, to contradict  
myself, I would like to read and understand all the RFCs, so a single  
RFC containing all current RFCs would be enough, but obviously, I  
cannot read and understand such RFC).


if you implement DMARC filtering on incoming emails you get less spam.

If you implement DMARC filtenig on outgoing emails (say publish policy  
p=reject), you deploy DKIM and then some trust/reputation can be built  
in the DKIM domain, similar to IP reputation, so that your future  
emails are more likely to be delivered, at least in theory.


You do not have interest to name this magic anyhow, you have interest  
on getting less spam and higher deliveribility of your emails.


You do not have to implement section 8 in order to achive the  
aforementioned goals.  When filtering incoming emails, obviously,  
without having to articulate this explicilty, you have to follow  
section 6.6.


To verify that your DMARC works as expected, the reports mentioned in  
section 8 are a nice mean.


You can call your product a DMARC implementation even if it does not  
do DKIM signing/verifying correctly.


Why do my mails for jo...@taugh.com get rejected, unless I send them  
over the MLM?


A propos “Is there any recommendation to send DMARC message-specific  
failure reports FROM:<>”:


* Scott, the purpose of such a recommendation is to have a system,  
which does not cause mail loops, ending with stored copies of 60 000  
sent reports.  If that site published TXT record for  
mail.modernwebsite.pl, it does not ensure that in half an year I will  
not enter another mail loop (half an year ago I had a similar one).


* I do sent now my reports ENV FROM:<> and from the correspondence so  
far neither somebody said that there is such a recommendation already,  
nor that such a recommendadion is bad.  The purpose of the  
<>-recommendation is to prevent others falling in such a mail loop  
trap.  Under this circumstances I put the case under “Collecting DMARC  
issues and nits for DMARC WG phase III - DMARC standardization”.


Regards
  Дилян
- Message from Jim Fenton  -
   Date: Mon, 27 May 2019 10:23:42 -0700
   From: Jim Fenton 
Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
 To: Dave Crocker , John R Levine 
 Cc: dmarc@ietf.org



On 5/25/19 1:53 PM, Dave Crocker wrote:


Ultimately, you are asking marketing questions, not technical ones.



OK, so let me ask a technical question: What is the technical  
justification for the requirements in Section 8? For other  
protocols, there are mandatory-to-implement requirements (RFC 6376  
section 3.3 for example) that exist in order to ensure  
interoperability between senders and receivers. But implementation  
of DMARC policy and DMARC reporting can separately be useful without  
the other.


Aren't the requirements in Section 8, which effectively say "you  
need to do this and this to call yourself a DMARC implementation"  
really a marketing, not a technical consideration? Does this belong  
in the spec?


-Jim

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



- End message from Jim Fenton  -


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Jim Fenton]

On 5/25/19 1:53 PM, Dave Crocker wrote:


Ultimately, you are asking marketing questions, not technical ones.



OK, so let me ask a technical question: What is the technical 
justification for the requirements in Section 8? For other protocols, 
there are mandatory-to-implement requirements (RFC 6376 section 3.3 for 
example) that exist in order to ensure interoperability between senders 
and receivers. But implementation of DMARC policy and DMARC reporting 
can separately be useful without the other.


Aren't the requirements in Section 8, which effectively say "you need to 
do this and this to call yourself a DMARC implementation" really a 
marketing, not a technical consideration? Does this belong in the spec?


-Jim

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John R Levine]

On Sat, 25 May 2019, Dave Crocker wrote:

2. Along similar lines, I get confused when I hear that x% of {some set
of domains} has "deployed DMARC". What does that mean? Have they


Ultimately, you are asking marketing questions, not technical ones.


Right.  It's easy enough to imagine soemone handing out Official DMARC 
Compliance certificates, but that someone sure wouldn't be the IETF.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Dave Crocker]

On 5/24/2019 10:35 AM, Jim Fenton wrote:

I hope this isn't devolving into a "we can't make any changes, because
it might break something" argument.


We are quite a long ways from that.  In fact we are in the "please make 
a case for their being a serious problem that needs fixing" argument, 
combined with the "please explain how the proposed solution will fix the 
serious problem" argument.




1. When an MTA product says that it "supports DMARC", does that mean


That's a generic issue that applies to many circumstances.  And since 
there is no standard meaning for "supports x", it has marketing utility, 
not technical.  That's not going to get fixed in this wg.




that it has to support both policy and reporting? RFC 7489 Section 8


There are multiple opportunities for ambiguity.  Another is:  Does it 
mean publishing or interpreting?


Splitting the documents doesn't solve any of this.



2. Along similar lines, I get confused when I hear that x% of {some set
of domains} has "deployed DMARC". What does that mean? Have they


Ultimately, you are asking marketing questions, not technical ones.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Jim Fenton]

On 5/24/19 10:55 AM, Brandon Long wrote:
>
>
> On Thu, May 23, 2019 at 10:01 PM Jim Fenton  > wrote:
>
> On 5/23/19 3:52 PM, John Levine wrote:
> > In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net
> > you
> write:
> >> There are domains that would like to receive reports, but whose
> usage of
> >> mail doesn't make it useful to express a policy. Conversely,
> there are
> >> domains that want to express a policy but aren't interested in
> reports.
> >> I'd like to advocate that DMARC be split up into two different
> documents
> >> dealing with reporting and policy separately. If it's useful to
> have a
> >> separate document that defines what it means to be
> "DMARC-compliant"
> >> that is referenced by both, that would be OK.
> > Given that we already have one document, I would be very strongly
> > opposed to this.  It's fine to fix things that are wrong, but trying
> > to restructure it retroactively will inevitably lead to accidental
> > incompatibilities.
>
>
> MTA-STS and TLSRPT started out as one document as well, and separated
> quite cleanly IMO. I'm not sure what kind of incompatibilities you
> think
> might be created.
>
>
> Does TLSRPT support both MTA-STS and DANE?  I would think that
> provides a logical
> reason to separate them that doesn't exist for DMARC.


TLSRPT does support both MTA-STS and DANE, but the same logical reason
probably exists for domains that want to generate or receive reports but
do not want to publish or honor policy assertions. Although I will admit
that publishing an MTA-STS policy is considerably more involved than
with DMARC.

-Jim


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Luis Muñoz]

On 24 May 2019, at 10:55, Brandon Long wrote:

> Does TLSRPT support both MTA-STS and DANE?  I would think that provides a
> logical
> reason to separate them that doesn't exist for DMARC.

My reading of RFC-8460 says it does:

   Recipient domains may also use the mechanisms defined by MTA-STS
   [RFC8461] or DANE [RFC6698] to publish additional encryption and
   authentication requirements; this document defines a mechanism for
   sending domains that are compatible with MTA-STS or DANE to share
   success and failure statistics with recipient domains.

Best regards

-- 

Luis Muñoz
Director, Registry Operations


http://www.uniregistry.link/
400 Spectrum Center Drive
Suite 1660
Irvine, CA 926128

Office +1 949 706 2300 x 4242
l...@uniregistry.link
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Alessandro Vesely]

On Fri 24/May/2019 17:04:28 +0200 Peter M. Goldstein wrote:

> I can personally attest that this [splitting] was very confusing.

+1.  Let's not split, please.


Best
Ale

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Peter M. Goldstein]

Agree with Dave here.

There's no actual usage issues that are being addressed that merit the
split (and the work involved).  If you want to receive reports, but not
have receivers enforce a policy, set 'p=none' and a rua.  If you want to
set a policy but not receive reports, set 'p=' and an empty rua.  I
don't see why that's considered confusing or problematic.

It's also worth noting that the the precedent isn't an actual operational
precedent yet.  There's only one major receiver who is sending SMTP TLS
reports, and if you follow RFC 8460 to the letter you will not actually
receive them.  Unless you implement the DNS records described in RFC 8461,
you don't get any reports.  As someone who recently dealt with this, and
had a back and forth with the receiver, I can personally attest that this
was very confusing.  The first data point from operational deployment seems
to indicate that splitting RFC 8460/8461 may have been a mistake.  It's
either confusing for the implementing receiver (they are doing something
they shouldn't be doing) or for the domain owner (RFC 8460 isn't enough to
get reports by themselves).

Best,

Peter



On Fri, May 24, 2019 at 6:03 AM Dave Crocker  wrote:

> On 5/23/2019 1:35 PM, Jim Fenton wrote:
> > There are domains that would like to receive reports, but whose usage of
> > mail doesn't make it useful to express a policy. Conversely, there are
> > domains that want to express a policy but aren't interested in reports.
> > I'd like to advocate that DMARC be split up into two different documents
> > dealing with reporting and policy separately. If it's useful to have a
> > separate document that defines what it means to be "DMARC-compliant"
> > that is referenced by both, that would be OK.
>
>
> I'm not clear what technical or operational problem you are trying to
> solve.  That is, you seem to be proposing a document split without any
> technical changes.  Yes?
>
> While separating or joining segments of specification makes a
> difference, you haven't described what actual usage issues there have
> been that warrant the effort to split this document.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> 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] DMARCbis issue: Separating reporting and policy

[Hector Santos]

On 5/23/2019 4:35 PM, Jim Fenton wrote:

In response to Seth Blank's call for issues of 9 May 2019:

DMARC contains what are really two distinct mechanisms, a reporting
mechanism and a policy mechanism. The policy mechanism is largely a
request to the verifier about what to do in the event that a message is
received that does not comply with policy.

There are domains that would like to receive reports, but whose usage of
mail doesn't make it useful to express a policy. Conversely, there are
domains that want to express a policy but aren't interested in reports.
I'd like to advocate that DMARC be split up into two different documents
dealing with reporting and policy separately. If it's useful to have a
separate document that defines what it means to be "DMARC-compliant"
that is referenced by both, that would be OK.

There was a similar situation with MTA-STS which had both a policy and a
reporting mechanism, and that was broken into two standards-track RFCs:
RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport
Security). I consider this to be a relevant precedent.


Hi Jim.

+1.  I agree with the split, if it helps with the focusing of 
completing a Proposed Standard (PS) DKIM-POLICY  framework that 
includes codification for the Author Domain Lookup method, 
clarification for alignment and most important, finally recognizing 
extended 3rd party authorization policies and protocol add-on 
capabilities.


I always felt reporting offered little payoff, added lots of overhead 
to the process, in particular more complex coding requirements, i.e. 
you really don't need JSON, XML, etc layers to do a simple DNS DKIM 
policy check, and there was a high potential for abuse.  In my 2006 
DSAP (DKIM Signature Authorization Protocol) proposal, a reporting 
option was offered but it was made clear it can be abused, so it 
should be limited. 
(https://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-16)


As you recall, the the past DKIM WG did the same with DKIM when it was 
decided to split the proposed standard's inherent POLICY model (SSP) 
component into two Proposed Standard DKIM Working Group work item 
documents;  DKIM-BASE and DKIM-POLICY. SSP was replaced with ADSP with 
reduced policies, ironically, the 3rd party policies were removed -- 
deemed too complex.  It focused on the principle 1st party domain 
policy, neglecting the 3rd party domain signature and how they should 
be evaluated.


Nonetheless, the split was a success in allowing us to finished 
DKIM-BASE.


But the negatives in the split, as some (including myself) with split 
concerns had predicted might happen, a lost of interest in finishing 
the Proposed Standard DKIM Policy work, coupled with a mis-directed 
attention (wishy future) with reputation methods, eventually, DKIM 
Policy would be abandoned.  I think we lost the interest of many 
policy advocates during this time, in particular when there was a 
resistance towards recognizing the "ADID"  (Author Domain IDentity) 
and not including it as part of the into the DKIM-base "Assessment" 
model.


So can the same happen if DMARC reporting was split from a PS 
DMARC-bis work?


IMO, yes, it could happen. I personally do not have any interest in 
reporting in its current form. I have all received reports gated into 
a NNTP newsgroup for private viewing. I don't see any consistency and 
value from them. So that item that can be done -- more consistency. 
It can discuss XML/JSON viewers, ad-hoc reporting methods to help with 
with labeling patterns.  I believe ARC will also need be part of the 
reporting as well. This can be very complex but also highly subjective 
design ideas. They can be discussed separately and independent of a 
straight forward DKIM author domain policy framework.


Finally, the key issue remains, to this day, over 12-15 years,  the 
dearth of 3rd party authorization concepts.


That is where the fuzziness remains.  To me, this is what DMARC-bis 
has to help finish.  The "Authorized Third Party Signature" (ATPS) 
model need to be recognized and put into the DKIM-POLICY framework, 
allowing it to get endorsed and explored at small to high deployment 
scenarios.  We have allowed the brush back by the "Big Guy" (who can't 
seem to figure it out) deter the possible benefits for all other 
smaller scales.  That is what happen before just to do 1st party and 
ADSP paid the price only to be replaced later with Super ADSP - DMARC. 
 So they were wrong with ADSP, they are probably wrong with ATPS as 
well.  As a smaller organization with a well defined set of domains, 
well-defined network usage of where my domains are used.  Some are 
exclusive, very private, some are used in mailing list, like here. I 
know who is allowed to sign mail on my behalf.  That is all defined in 
published DKIM+ADSP/DMARC+ATPS DNS records.


--
HLS


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John R Levine]

MTA-STS and TLSRPT started out as one document as well, and separated
quite cleanly IMO. I'm not sure what kind of incompatibilities you think
might be created.


That's because they separated before they were published, so there was 
nothing to be incompatible with.  If I knew what would break when 
reorganizing and rewriting a document into pieces, I could fix it, but 
since I don't, and nobody else does, let's not go there.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Scott Kitterman]

On May 23, 2019 8:35:47 PM UTC, Jim Fenton  wrote:
>In response to Seth Blank's call for issues of 9 May 2019:
>
>DMARC contains what are really two distinct mechanisms, a reporting
>mechanism and a policy mechanism. The policy mechanism is largely a
>request to the verifier about what to do in the event that a message is
>received that does not comply with policy.
>
>There are domains that would like to receive reports, but whose usage
>of
>mail doesn't make it useful to express a policy. Conversely, there are
>domains that want to express a policy but aren't interested in reports.
>I'd like to advocate that DMARC be split up into two different
>documents
>dealing with reporting and policy separately. If it's useful to have a
>separate document that defines what it means to be "DMARC-compliant"
>that is referenced by both, that would be OK.
>
>There was a similar situation with MTA-STS which had both a policy and
>a
>reporting mechanism, and that was broken into two standards-track RFCs:
>RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport
>Security). I consider this to be a relevant precedent.

What do you see as the potential advantage of your proposal?

There isn't really a DMARC without expressing a policy.  One may choose to have 
a policy of none, but it's still there.  In the immortal words of Rush:

"If you choose not to decide
You still have made a choice".

I can see where it might make things a little easier if we were starting from 
scratch, but we aren't.

Scott K

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Dave Crocker]

On 5/23/2019 1:35 PM, Jim Fenton wrote:

There are domains that would like to receive reports, but whose usage of
mail doesn't make it useful to express a policy. Conversely, there are
domains that want to express a policy but aren't interested in reports.
I'd like to advocate that DMARC be split up into two different documents
dealing with reporting and policy separately. If it's useful to have a
separate document that defines what it means to be "DMARC-compliant"
that is referenced by both, that would be OK.



I'm not clear what technical or operational problem you are trying to 
solve.  That is, you seem to be proposing a document split without any 
technical changes.  Yes?


While separating or joining segments of specification makes a 
difference, you haven't described what actual usage issues there have 
been that warrant the effort to split this document.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Jim Fenton]

On 5/23/19 3:52 PM, John Levine wrote:
> In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write:
>> There are domains that would like to receive reports, but whose usage of
>> mail doesn't make it useful to express a policy. Conversely, there are
>> domains that want to express a policy but aren't interested in reports.
>> I'd like to advocate that DMARC be split up into two different documents
>> dealing with reporting and policy separately. If it's useful to have a
>> separate document that defines what it means to be "DMARC-compliant"
>> that is referenced by both, that would be OK.
> Given that we already have one document, I would be very strongly
> opposed to this.  It's fine to fix things that are wrong, but trying
> to restructure it retroactively will inevitably lead to accidental
> incompatibilities.


MTA-STS and TLSRPT started out as one document as well, and separated
quite cleanly IMO. I'm not sure what kind of incompatibilities you think
might be created.

-Jim


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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John Levine]

In article <20190523225213.c214620147b...@ary.qy>,
John Levine   wrote:
>In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write:
>>There are domains that would like to receive reports, but whose usage of
>>mail doesn't make it useful to express a policy. Conversely, there are
>>domains that want to express a policy but aren't interested in reports.
>>I'd like to advocate that DMARC be split up into two different documents
>>dealing with reporting and policy separately. If it's useful to have a
>>separate document that defines what it means to be "DMARC-compliant"
>>that is referenced by both, that would be OK.
>
>Given that we already have one document, I would be very strongly
>opposed to this.  It's fine to fix things that are wrong, but trying
>to restructure it retroactively will inevitably lead to accidental
>incompatibilities.

On the other hand, if you want to write separate non-normative
tutorials for the reporting part and the policy part, sure, go ahead.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[John Levine]

In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write:
>There are domains that would like to receive reports, but whose usage of
>mail doesn't make it useful to express a policy. Conversely, there are
>domains that want to express a policy but aren't interested in reports.
>I'd like to advocate that DMARC be split up into two different documents
>dealing with reporting and policy separately. If it's useful to have a
>separate document that defines what it means to be "DMARC-compliant"
>that is referenced by both, that would be OK.

Given that we already have one document, I would be very strongly
opposed to this.  It's fine to fix things that are wrong, but trying
to restructure it retroactively will inevitably lead to accidental
incompatibilities.

R's,
John

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