The reliability aspect is realistic to set a high bar. The decision to allow unregulated users to publish to the zones of Hotmail.com/outlook.com/msn.com/live.com/Hotmail.ca/outlook.ca/live.ca... etc. is one that comes with its own security challenges. This now no longer a way to allow indirect mailflow to pass DMARC, but instead how to figure out a way to secure your DNS zone. For the amount of work that would be, I would rather just inventory all mailing lists and if an email comes from it into a domain filtered by Microsoft, suppress DMARC.
It's not just Microsoft's consumer brands. Office 365 hosts email for small, medium, and large businesses - each with their own DNS zone. If we have 500,000 domains [1] and there are 100,000 mailing lists, are we going to publish DNS records for the full matrix of combinations - 50 billion? Or even 1 billion? We don't control customer's DNS zones, so we'd have to convince our customers to publish these records and to do it on a regular basis. I can see nobody agreeing to do that. And if it won't work for Office 365 then it won't work for Hotmail, outlook.com, live.com, etc. I can't see the solution of publishing things in your DNS zone as a workable solution. That's why I like the conditional @fs DKIM signature better (or some variant of it) - it's done on the MTA level. A customer domain, example.com, can sign up for the Office 365 service and not have to publish any mailing list third party authorization in their zone. Instead, the sending MTA adds the required DKIM signatures and the receiving MTA decodes the incoming receiving signatures and does the right thing. The process is transparent to end users, most of whom don't want to update their DNS zones. -- Terry [1] I don't know exactly how many domains we have, I just picked this as an example. -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos Sent: Saturday, May 9, 2015 10:13 AM To: dmarc@ietf.org Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note Your bar is too unrealistically high for typical IETF project work that is still in the experimental stages. You should be thankful, we didn't apply this bar to the SPF experiment. -- Hector Santos http://www.santronics.com > On May 9, 2015, at 10:09 AM, Scott Kitterman <skl...@kitterman.com> wrote: > >> On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" <step...@xemacs.org> >> wrote: >> Murray S. Kucherawy writes: >> >>> Agreed again. And as Terry has said and I think we can infer about >>> other large operators, it's incorrect to assume (and plain wrong to >>> assert) that this is an easy problem for them to solve in a >>> reliable way. >> >> Please define "reliable." I gather you all think that missing some >> mailing lists is a bigger problem than missing all of them, but for >> the life of me, I cannot see why. > > How many solutions do you think operators will be willing to implement? As I > indicated in my utility assessment framework, I think we get a maximum of one > solution that requires cooperative implementations in multiple parts of the > originator/mediator/receiver trilogy. Given that, it had better be reasonably > comprehensive. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
