On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote: > I've been following the discussion but haven't contributed anything until > this point. Comment below. > > On Fri, Jul 19, 2019 at 3:29 AM Ian Levy <ian.levy= > > 40ncsc.gov...@dmarc.ietf.org> wrote: > > > I think this is one of those "you must be this tall to ride on this > > > ride" > > > situations. DNS comes equipped with multiple footguns and you have to > > > > know a bit about what you're doing to make sure you get the effects you're > > after. > > > > This. DMARC today allows people to disconnect their outgoing mail from the > > rest of the world. Admittedly, the PSD-level policies would have a much > > greater effect, but your PSD/TLD operator can already bork you if they're > > not competent. > > There are two different buckets of risk in my view, though : > > 1) New TLDs are effectively greenfield sites and can enforce appropriate > > requirements on their customers from the start to minimize the chance of > > unintended consequences (for example, by requiring domain DMARC labels). > > 2) Existing TLDs, where there are many subdomains with wildly variable > > implementations, policies and use and here we are going to have to be > > really careful. Careful and methodical testing will be necessary to make > > sure that introduction of the PSD-level policies doesn't break anything > > important. It took us 6 months to get to synthesizing p=reject for > > non-existent subdomains of .gov.uk. A lot of that was analysing the data > > we got back and fixing stuff that we never expected (like Kerberos - don't > > ask!). I don't see why it would be different with the np= tag, but it will > > hopefully be much more limited in what we could mess up. > > > > I think we're really all worried about the second of these cases. If > > that's true, then I'm with Scott - if you don't understand this stuff, > > don't go and set an np tag on your PSD and cross your fingers. It's going > > to end badly. One of the things about doing the experiment is surely to > > help us understand how badly these can go wrong, so we can write down a > > bunch of ways not to do things. > > > > We can write in the document that scissors are sharp and running with > > sharp things can cause problems. But in the end, someone is going to run > > with scissors and get hurt. We can't code for every single case here and > > we > > surely must assume a level of competence of people implementing something > > like this. > > The problem, which we know or should know, is that DNS records are > apparently difficult to get right. We have a large corpus of data points to > back this up based on decades of experience. Even large, supposedly > experienced and technically qualified organizations shoot themselves in the > foot. Speaking as an original participant in the dmarc.org team, I can't > emphasize enough the education and evangelization effort involved related > to adoption (and misunderstanding of how it works... or doesn't work). > > I think you are incorrect with your assumption regarding scenario #1. I > recently had a discussion with an owner/operator of a number of "new" TLDs. > They have no clue regarding this effort. So even if a TLD is new, that does > not mean it will implement from day 1. This means scenario #2 is more > likely the scenario to be dealt with (default) rather than #1. Perhaps > after some extended period of pain or if ICANN mandates something, #1 will > become the default, but I wouldn't hold my breath. > > With regard to scenario #2, it is not enough to simply say "don't run with > scissors". Some group, M3AAWG or ICANN or ISOC, will need to educate and > evangelize those outside the inner circle, so to speak. I'm sure that > companies like Agari, Dmarcian, Valimail, etc. will gladly provide > assistance., That TLD owner/operator I mentioned earlier is not overly > familiar with the space or those vendors. > > It is not enough for the creators of a proposed standard to state it's > technical validity. This implies a deployment document based on the > experiences of early adopters.
I agree, but I think solving that is outside the scope of the current document. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
