On Fri, Dec 19, 2014 at 5:30 PM, Dave Crocker <d...@dcrocker.net> wrote:
> > 3.2 Organizational Domain > > > > I remain very concerned about this algorithm since I have been > > previously told very specifically not to do this by the DNS folks. I'm > > also concerned about the inconsistency (interoperability impact) that > > could result from different operators using different public suffix > lists. > > Everyone is concerned about it. But it's the best that is currently > available. > +1, and furthermore, -08's Section 3.2 and Appendix A.6 both admit the current method is flawed and DMARC operators should switch to something better as soon as such a thing becomes available. I don't know what more can be said at this point. > > 4. Policy > > > > Paragraph 4 basically says, if you don't want a particular > > authentication scheme to be considered by DMARC, don't use it at all. > > For a domain that is using SPF and DMARC (for example), this could be an > > impediment to their deployment of DKIM because they could not test with > > it without having it immediately affect recipients' message handling. > > One possibility would be to ignore DKIM if the testing (t=y) flag is > > set, although a campaign would be needed to get the many domains > > currently using t=y to turn it off. Another possibility would be to have > > a setting in DMARC to ignore a specific authentication method entirely. > > The first possibility isn't viabile, for the reason cited. The second > possibility might be worth pursuing in the DMARC working group, rather > than in a document that captures existing DMARC practice. > > There are, of course, other possibilities, such as not having DMARC > pursue operational nuance that makes the spec more complex, trying to > handle special cases. That is, if a site isn't ready to use DMARC, it > shouldn't. > The "pct" tag was also provided to address the concern that the impact of enabling DMARC is uncertain. > > 7.1 Verifying External Destinations > > > > Paragraph 3: "verification steps SHOULD be taken" These steps are to > > protect another domain from attack. It needs to be a MUST. > > 6.1 in -08. > > Given the problems with the search for org domain, a SHOULD is as far as > is practical here. > > I'd suggest noting that that's a reason this can't be a MUST. > I think it's SHOULD because at the time it was written, the verification process was untested. It's in production now (OpenDMARC implements it), so I agree that a MUST is appropriate. > > 8. Policy Discovery > ... > > 5.6.3 in -08 > > > > Second-to-last paragraph: "If the RFC5322.From domain does not exist in > > the DNS" is basically changing what RFC5321/5322 allow. This isn't the > > place to be making fundamental changes to the behavior of email. > > It isn't meant to be. > > -08 text says: > > "If the RFC5322.From domain does not exist in the DNS, Mail > Receivers > SHOULD direct the receiving SMTP server to reject the message. The > choice of mechanism for such rejection and the implications of those > choices are discussed in Section 9.3." > > I suggest removing it. Although a common anti-abuse mechanism, it's out > of scope for DMARC. > I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. > > 9. Domain Owner Actions > > 5.5 in -08 > > > Last paragraph doesn't seem like it fits. Suggest it be removed. > > While I could imagine a better place for it in the doc, having a /terse/ > pointer like this to some authentication pedagogy seems useful to me, in > an authentication-related spec... > +1. > > 11.1 Discovery > 6.2.1 in -08 > > > Mail Receivers can also discover reporting requests from the > > Organizational Domain. That should be mentioned here. But I'm a little > > confused why we have another Discovery section at all. > > The text's use of the word 'corresponds' handles the mapping to org > domain, IMO. > +1, and there isn't a second Discovery section anymore; there was a Great Consolidation at around the -05 version. > > 11.2.1 Email > > > > The whole thing about filenames needs to go away. Since it's only a > > SHOULD requirement, the Report Receiver needs to be able to handle > > reports that don't follow this format as well as those that do. > > "SHOULD" is a very strong normative statement. Note that it permits > non-conformance only in the presence of singular knowledge by the > non-conforming party. > > Filename labeling is generally considered useful. Why wouldn't it be > useful here? > +1, not to mention again that this is current practice among DMARC operators and doesn't seem to be an issue so far. > > 14.1 Data Exposure Considerations > > > > Last paragraph: what's an "unexpected Mail Receiver"? > Reworded. > > The privacy consideration here, which isn't obvious from the wording, is > > that users may currently use forwarding in a way that prevents the > > sender from determining the ultimate delivery address. DMARC has the > > potential to break that. This might be important in the case of a user > > that is trying to distance themselves from a stalker. > > How is that a DMARC-specific 'exposure' consideration? > DMARC creates the exposure. If A sends mail to B which forwards to C and then to D, D can send reports back to A, revealing the forwarding relationship from C to D. Reworded to accommodate. > > 14.2 Report Recipients > > > > Some potential exists for report recipients to perform traffic analysis: > > to obtain metadata about the receiver's traffic. In addition to > > verifying compliance with policies, receivers need to consider that > > before sending reports to a third party. > > +1 > Added. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
