Re: [apps-discuss] Revised DMARC working group charter proposal

[Scott Kitterman <[e-mail]>]

On Monday, April 15, 2013 05:15:32 PM Dave Crocker wrote:
> Scott,
> 
> At the risk of this going too far afield from a chartering discussion --
> it might be worth moving this thread to [e-mail]:
> 
> On 4/15/2013 1:02 PM, Scott Kitterman wrote:
> > On Saturday, April 13, 2013 04:37:47 AM Dave Crocker wrote:
> >> The specification has been public for considerably more than a
> >> year, including a press release and a public discussion list, with
> >> adoption covering roughly 60% of the world's mailboxes.  That's not
> >> a small base of experience.  So there's been plenty of opportunity
> >> for community review and input, including requests for changes.
> >> And yet, there is so far no such list of requests.
> > 
> > Not true.  There was a long thread, almost a year ago on the
> > interaction of DMARC policy with policy aspects of other domain
> > authentication technologies (SPF and DKIM/ADSP) that starts here:
> > 
> > http://www.dmarc.org/pipermail/dmarc-discuss/2012-July/001104.html
> 
> I apologize for being unclear.  I didn't mean that no individuals had
> any requests.  I meant that there has been no demonstration of community
> support -- a rough consensus kind of support -- for changes.
> 
> To my own reading, the thread you cite nicely demonstrates this:
> community interest, community discussion, but no community support for
> change.  If you feel otherwise, please document it.
> 
> > While some of the issues addressed in that thread have been addressed
> > (the most critical one that DMARC policy of none should not alter
> > processing for SPF or DKIM/ADSP in particular), I don't think the
> > issue is fully resolved.
> 
> I don't see that thread as having created items to be resolved.  Again,
> feel free to document otherwise.
> 
> And given considerably more of one year for that public discussion, we
> haven't identified any items that might show community support for
> modifying the base specification.
> 
> > Here's the current, relevant snippet from the draft submitted to the
> > 
> > IETF:
> >> DMARC-compliant Mail Receivers SHOULD disregard any mail directive
> >> discovered as part of an authentication mechanism (e.g., ADSP,
> >> SPF) where a DMARC policy is also discovered that specifies a
> >> policy other than "none". {R7} To enable Domain Owners to receive
> >> DMARC feedback without impacting existing mail processing,
> >> discovered policies of "p=none" SHOULD NOT modify existing mail
> >> disposition processing. Note that some Mail Receivers may reject
> >> email based upon SPF policy mechanisms before email enters
> >> DMARC-specific processing.
> > 
> > I think the initial SHOULD represents a layering violation that is
> > technically inappropriate from a design perspective, will
> > substantially complicate implementation, and is not needed.  Details
> > to follow.
> 
> FWIW, with respect to policy mechanisms, I think this is less a matter
> of "layering" than of "replacement". DMARC is asserting authority over
> the topic of policy, to the extent is has /overlap/ (rather than
> layering) with SPF or ADSP.
> 
> >>> Things that were written
> >>> 
> >>> by people who already "know" what the spec is supposed to mean
> >>> are often less clear to those outside the group. Until a broader
> >>> group actually reviews it, there's no way to know.
> >> 
> >> You are correct, of course.  However the range of implementers now
> >> goes considerably beyond the original group, and yet there is so
> >> far no concrete list of interesting changes being requested.
> > 
> > The current implementers don't need the IETF spec.  The RFC should be
> > oriented towards future implementers
> 
> Perhaps you missed the part about there now being a number of
> implementers who were not part of the writing team?  Again, one would
> have expected significant critical feedback from them, about problems
> with the writing, over the last 1+ year.  (But then, the latest draft
> does contain revisions...)
> 
> In any event, with an area director strongly against a "just improve
> the writing" work item, and no list of changes to be made to the base,
> there doesn't seem to be much to discuss about it.
> 
> > Absent a working group to actually do some independent review,
> > there's no way of knowing what would come up.
> 
> You seem to think that it's ok to start a working group when there is no
> known work other than "review the document and figure out what might
> need doing".  By contrast, my long-standing model of a working group
> charter is that there is a clear set of problems to solve and/or
> enhancements to add and that this is clear /before/ chartering.
> 
> >> Well, that's what we originally submitted for chartering, but at
> >> least one AD didn't like it.
> > 
> > Right, but the direction that the AD didn't like it was that the
> > previous proposal constrained the working group too much.
> 
> He didn't seem to want any meaningful constraint.  While he, you, or
> whoever might feel that's fine, the folks currently holding the spec
> need more assurance of stability for the specification than that, given
> how recent the investment in it has been.
> 
> >  It seemed to me that there were
> > 
> > a number of reasonable suggestions, including coming from the AD in
> > question, that did a nice job of balancing the concerns of existing
> > implementers without handcuffing the proposed working group.
> 
> That doesn't match my own reading of the thread(s).
> 
> >>> The one thing I think does need to be changed is the policy
> >>> override approach.  Changing SPF policy based on DMARC is a
> >>> layering violation at the very least.
> 
> ...
> 
> > See the text quoted above for the specific reference.
> 
> You mean:
>  >    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
> 
> ...
> 
>  >    mechanisms before email enters DMARC-specific processing.
> 
> ?
> 
> Where is there a demonstration of community support for changing this?
> 
> > In order to implement DMARC it's necessary for the component of a
> > mail system that does SPF processing to have access to the 5322.From
> > extracted from the body of the message (because of the SHOULD to skip
> > SPF related policy decisions for domains that have a DMARC policy !=
> > none and 5322.From provides the domain needed to determine if a DMARC
> > policy is relevant for the message).
> > 
> > Requiring data from the message body to do operations on the envelope
> > is not a good idea.
> 
> Strictly speaking, it's not doing an operation /on/ the envelope, but in
> any event, the linkage to SPF's use of envelope information and DMARC's
> use of rfc5322.From information is rather basic to DMARC.
> 
>  From what I can tell, the change that you are concerned with, is
> DMARC's overriding SPF's /disposition/ mechanism, rather than its
> authentication mechanism.
> 
> In any event who supports the change besides you?  You've voiced it for
> awhile, so there ought to be some indication of support by now.
> 
> > The requirement to have access to the body of the message to do SPF
> > checking in a DMARC environment is an architectural mess.
> 
> I guess I'm not seeing it as doing SPF checking.
> 
> >>> Not only is the current design wrong, it's nor needed to solve
> >>> the problem DMARC was meant to solve.
> >> 
> >> Sounds like a protocol change.  That's rather more than merely
> >> improving the text.
> > 
> > Yes, but not one that would require implementations to be changed to
> 
> ...
> 
> >> The idea that one can change a design, without having to change
> >> code, is new to me.  Please explain.
> > 
> > If you change a SHOULD requirement to a MAY requirement then nothing
> > forces existing implementations to change.
> 
> You mean beyond reducing the likelihood that it will get implemented;
> are you asserting that this won't affect interoperability?
> 
> But again, this is frankly moot, absent a community desire to change the
> base specification.
> 
> >>> Fundamentally, rubber stamping the work of a private design team
> >>> is not the IETF way.
> >> 
> >> What part of the work in the latest draft charter would produce
> >> rubber stamping?
> >> 
> >> But since you are being pedagogical about how the IETF does
> >> things, please note that working group charters are supposed to
> >> specify the nature of the work to be done.  Working groups that
> >> start without a sense of what problem they are trying to solve to
> >> tend to have poor outcomes.  If you can specify the nature of the
> >> technical, work to be done, sufficiently to garner support for it,
> >> then it's certainly worth considering.
> > 
> > I'm aware of one technical issue that I believe to be significant
> > that needs to be addressed and wasn't addressed by the private design
> > group.  Unless it's in scope for a working group to review the input
> > of that work to the IETF, there is not likely to be the same level of
> > review.
> 
> Scott, yes it's clear that you believe the issue is significant.  What's
> missing is an indication that the rest of the community wants a change.
> 
> > Additionally, I think it is very odd to submit the base spec as an
> > independent submission and then form a working group to extend it.
> 
> Not "typical", no.  So?
> 
> > As I understand it, part of a working group effort is to get
> > consensus around technical efforts. I'm not sure how you get
> > consensus to extend something for which there is no IETF consensus.
> 
> The question will be consensus around the extensions.  Isn't modularity
> nice?
> 
> > I might even think that perhaps that the bit in RFC 4846 about the
> > IESG review where it mentioned independent submissions shouldn't be
> > an end run around the working group process might be relevant.
> 
> OK.  Please point to an existing IETF effort that this might be
> considered an end-run around.  That's what that reference was/is
> intended to mean.  And who else shares this view?
> 
> >  It
> > 
> > also seems to me that if the DMARC base spec seeks to modify
> > processing for IETF RFCs,
> 
> It doesn't.
> 
> > I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and
> > there was not also a parallel proposal for an IETF working group to
> > extend DMARC, then independent submission would not be inappropriate,
> 
> So, you think that ARP was inappropriate to have as an IETF effort,
> given that essentially all of the media specifications over which it
> operates -- that is, which it "extends" -- are outside of the IETF?

I'll let Stephen speak for his own opinion on the chartering constraint issue.  
In my opinion, there's a reasonable way to write a charter that allows 
meaningful discussion and consideration of the current design, but that 
provides appropriate constraint on trivial changes.

As for the current issue I have with the design, I haven't particularly 
attempted to gather a constituency for it.  It was my impression from when we 
discussed it almost a year ago there would be an eventual IETF working group 
to work through this and any other issues people found.

I think that if a draft is submitted as a candidate working group work item 
and the sponsors don't like the result of the chartering discussion and that 
draft is suddenly an independent submission, that's pretty well, by definition, 
an end around the working group process.

2119 SHOULD words about how to change SPF and DKIM/ADSP processing are 
certainly modifying the intent of IETF RFCs.  Once again, it's pretty 
obviously the case and the only reason to avoid accepting it is to have a safe 
dodge of the ISE path to avoid an IETF working group and some need to get 
consensus outside of the private design group.

I keep hearing the IETF is about getting technology right and not about votes 
or who people work for.  The current design is wrong and in a way that it 
doesn't need to be wrong because all domains that don't want mail rejected on 
the basis of SPF or DKIM/ADSP need to do is publish policy records that say 
that.  DMARC trying to replace that existing functionality is utterly 
unnecessary.

Scott K