Kouji Okada writes: > [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.
But you seem to ignore what has happened in the past. To many receivers (including some of the largest freemail providers as well some enterprise providers) "p=reject" already means "be careful", not "reject".[1] For at least one 800-lb gorilla in the field, since *before* April 2014. If you try to make quarantine or reject mandatory for non-participants, many sites will simply ignore your protocol, and many others will weaken it as is already done for explicit policies. Why do you think they would do otherwise? > I understand that the ultimate goal of DMARC is to defend mail > users from malicious activities such as phishing or spoofing. It is. That doesn't mean it's possible to do so perfectly, and we've had ample demonstration that the DMARC p=reject protocol is imperfect. (That doesn't mean it is inherently flawed; it just means that it is insufficient for perfect protection.) Earlier in this thread, Franck Martin (who represents the original DMARC use case of "transactional" mail flows such as banks) wrote "I'm worried that a large mail provider doesn't reject when the apparent originator says reject", and Terry Zink (who represents a general provider of mail services, whose users receive indirect flows putatively from p=reject sites) replied "that would harm our users, so we do something different to keep them safe." Most sites that don't publish DMARC records just plain don't need them, and would publish "none" anyway if forced to. Receivers won't wait for them to catch up, so Franck will be displeased by the proliferation of sites that disregard reject in favor of alternative disposition, and Terry will continue to provide users with exactly those alternatives. This is already an unpleasant situation, your proposal can't make it better (unless you can get rid of "p=none", too!), and arguably will make it worse. > [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. If there is no published DMARC record, you're just guessing. A DMARC record might be published at any level of para.subsub.sub.domain.tld. I don't see how you can say that m...@sub.domain.tld would necessarily exhibit DMARC From alignment or not, because "Administrative Domain" is poorly defined. In DMARC practice it's an heuristic for guessing where to query for a DMARC record. This cannot be deduced from the DKIM signature. On the other hand, some efforts are being made to come up with an effective protocol for determining the responsible administrative domain. What if they succeed, and disagree with your procedure? That would be a mess, and hardly helpful. Nevertheless, for a receiver with good records of historical mail flows, appropriate analytical capability, and mail admins who know what they're doing, "implicit From alignment" might be a useful variable for their filtering and reputation systems. Similarly, it might be a useful factor for spam filtering applications and services to consider. Nobody denies that. The problem is that your I-D trying to impose behavior on receivers that is not beneficial to their users: they will Just Say No. Footnotes: [1] Of course "be careful" is parametrized by domain: for these receivers, for mail from bankofamerica.com "be careful" means "reject", while for mail from stanford.edu it means "quarantine" (at worst). _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
