On Friday, March 18, 2016 12:17:40 PM Kouji Okada wrote: > 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)
Because that is how non-participant results are recorded. > About SPF best guess, virtual DMARC verification does not “guess” anything > while SPF Best Guess guesses originated IP addresses. You are guessing that things like identifier alignment that are required to get a DMARC like pass are consistently available for a domain that has not opted into DMARC. > > ---------------------------------------------------------------------------- > - 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). The mail flows associated with feedback reporting can be non-trivial. It would not be appropriate to start providing feedback that is not requested. A default report address would not be appropriate. If DMARC turns out to be a good idea in the long run, people will adopt it, I don't think your steps 2 and 3 will be needed. If in 5 - 10 years it turns out to be needed, then write another draft then. There's no need to worry about it now. The future is not that predictable. > 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. What you are proposing is not DMARC since the correct DMARC result for these domains is none. What might be appropriate to standardize, is a name for this kind of check so that it can be distinguished between actual DMARC and the results associated with your proposal, although I don't particularly see the advantage to do so over just including the appropriate SPF or DKIM results. > - > 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. I don't have any good ideas about a name, but I do think it's important that it be something other than DMARC since it's not done in accordance with the DMARC processing. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
