On Wednesday, April 15, 2015 02:41:36 PM Hector Santos wrote: > On 4/15/2015 2:08 PM, Murray S. Kucherawy wrote: > > On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink <[email protected]> > > > > wrote: > >> 1. For Hotmail, every mailing list that our users are signed up for would > >> result in a new DNS entry. How do we manage the lifecycle around that? > >> Should we automate its addition? Should we automate its removal? Do we > >> delay email before the DNS entries are published? Should we thereby > >> bypass > >> the change review process? If so, how do we audit what's going in and > >> what's coming out of the Hotmail zone? > >> > >> 2. For Office 365, we can't publish DNS entries for most of our > >> customers. > >> We could tell them what to publish but I guarantee you almost none of > >> them > >> would for every single mail list their users signed up for, if they had > >> to > >> do it every day. Most of them probably wouldn't even do it once. > >> > >> That's the part that doesn't scale. > > > > +1. The mechanism of generating DNS records is not the issue; we even > > have > > an RFC that shows how that could be done in theory. It's the processes > > themselves that simply won't scale or would fail to thrive. > > -1. > > There is no proof of this other than it hasn't been tried at large > scale. Nonetheless, software guys can produce the tools for anyone to > do this, today, successfully. Once again, by far, and I hope you > agree, most domains will not need the level of scale that would begin > to make it too complex to manage. Not everyone has the "complex > processes" which I believe has been overblown and used as a flat out > reason for excluding the most feasible idea we have. > > From a pure protocol standpoint, it is a natural fit. We are talking > about satisfying the ADID != SDID condition lacking in DMARC which can > be a protocol option: > > DMARC Receivers MAY use DSAP mechanisms for ADID != SDID conditions. > > which can translate into product configuration options. > > [X] Support DMARC > [X] Support ATPS Extension > [X] Support @FS= > (o) Global (sign all) > (_) Selective (Disabled, Future) > > > It is unreasonable to impose more complex changes to both signers and > receivers, all of them, with no option to do a simple lookup which is > all that is required. I am open to having both a direct and inband > methods with direct being the most efficient and least costly. You > can not impose costly changes on all when it is clearly not necessary. > > IMV, the IETF should not be in a put into position where it is > creating situations for Mail and DNS folks to battle over the highly > subjective belief that it is just too hard to manage DNS records, thus > lets make the mail less DKIM secured and more DKIM complex with more > in-band (RFC5322) information. It isn't going to fly too well.
For the umpteenth time, the issue isn't managing a DNS zone. That's the easy part. The hard part is knowing what to put in it. Many companies, not even the really big ones, have thousands of domains. Go publish SPF, DKIM key, and DMARC records for 4,000 domains and then tell me it's all easy to then figure out what the right list of authorized forwarders should be for each one. ScottK P.S. I'm done on the topic of is keeping a list of forwarders a useful solution for the group to work on. No matter how you wrap it up, it's not. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
