Thank you very much for your comments. Here I summarize and answer to the comments.
First of all, I understand there are 3 topics we are discussing on the ML so far. 1. Virtual verification for "p=none" (step 1 on Roadmap) 2. Virtual verification for "p=quarantine and reject" (step 2, 3 on Roadmap) 3. Needs for documentation ---------------------------------------------------------- 1. Virtual verification for "p=none" (step 1 on Roadmap) ---------------------------------------------------------- [Points] - Discussion about step 1 on Roadmap - We can use PASS without DMARC record - If there are no DMARC records for a domain, we can use PASS status. - Except for “PASS”, we don't need to any changes to DMARC. - In case of no DMARC record, the Authentication-results code should be "none". (RFC7489 11.2) [Comments and Answers] - C.1-1 We should not verify the domains not ready for DMARC. “p=none” has no effect. A.1-1 Even in the case of “p=none”, we can use the authentication-result of “PASS”. For example, visual notifications to display the reliabilities of received mails, or white lists. Senders not ready for DMARC are not ready for 1. receiving reports 2. negative verification results for the mails they send ※ except none I think they are ready to be verified as “PASS”. Additionally, if DMARC must be opt-in, why does RFC 7489 define the authentication-results code in case of no DMARC record? (See 11.2 of RFC 7489) About SPF best guess, virtual DMARC verification does not “guess” anything while SPF Best Guess guesses originated IP addresses. ----------------------------------------------------------------------------- 2. Virtual verification for "p=quarantine and reject" (step 2, 3 on Roadmap) ----------------------------------------------------------------------------- [points] - problem of step 2 and 3(p=quarantine or p=reject) - default rua and ruf in step 2 and 3 [Comments and Answers] - C.2-2 In the deployment steps of 2 and 3, they cause massive loss of legitimate mails without reports. A.2-2 This is our 00 draft and we wrote about what we aim at for the future. I understand the deployment scenario needs to be discussed more in the DMARC communities, and we are ready to delete the deployment steps 2 and 3 from the document for now. Those steps might need more 10 years. However I think we should look ahead of the deployment after 5 or 10 years. I understand that the ultimate goal of DMARC is to defend mail users from malicious activities such as phishing or spoofing. Concerned with SPF, most of the operators still do not publish the SPF records with “-all”. When deployment steps 2 or 3 are applied, the operators who need the feedbacks just have to publish the DMARC records with “ruf” and “rua”. We could define the default value for those parameters (ruf, rua). Because security technologies always have difficulties in their deployments, I think we should make plans for the future deployment. --------------------------- 3. Needs for documentation (and editorial issues) --------------------------- [Points] - Do we need standard document? [Comments and Answers] C.3-1 It’s an internal processing issue and should not be standardized. A.3-1 I think we need some informational document about the procedure to add “DMARC=pass“ in the Authentication-Results without explicitly published DMARC records. The document may help operators who are trying to introduce DMARC capability to their MTAs as a current practice. - C.3-2 In the last paragraph of Section 3, something may be missed. A.3-2 I should have written this in the beginning of the paragraph. This was somehow lost in the editing. “When a DKIM verification passes utilizing the author domain signatures,” With this description, does the paragraph make sense? - C.3-3 Name. A.3-3 What would you think is suitable for the name of this verification? Any suggestions are welcome. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
