I agree with Scott. We do need to be that blunt given what people have thrown out there because DMARC doesn't say it's not ok. One thing we have been firm about is that if there isn't a DMARC record it isn't DMARC. For "other things", people are free to go off and experiment with consenting parties. If their experiment is interesting and potentially beneficial they are free to submit an RFC. Running code and rough consensus.
For example, I accept the group consensus regarding sister domains. Once the group publishes the final document I will publish my statement of the problem and what I perceive as the fix. I will include specific examples of how such attacks, using real domains, can be performed. Mail receiving domains have one approach to mitigation. Affected sending domains have another path. Concerned parties will take steps outside DMARC as local policy. Those who are unconcerned will not. At some later point it may get folded into DMARC, or it may not. Michael Hammer On Sat, Aug 27, 2022 at 6:30 PM Scott Kitterman <skl...@kitterman.com> wrote: > I do. Maybe I'm wrong and I've just read far to many crazy ideas preceded > by > "It doesn't actually say you CAN'T do that". I would strongly prefer we > be as > direct and blunt about this as possible, even though that's probably > insufficient to the task in at least some cases. > > I know Ale liked your change because it was 'nicer'. I guess I dislike it > for > roughly the same reason. > > Scott K > > On Saturday, August 27, 2022 5:50:10 PM EDT Barry Leiba wrote: > > You really think it needs to be BCP 14 key words, rather than saying in > > plain English that if there’s no DMARC record we are outside the realm of > > DMARC? > > > > Barry > > > > On Sat, Aug 27, 2022 at 5:15 PM Scott Kitterman <skl...@kitterman.com> > > > > wrote: > > > On Friday, August 26, 2022 11:51:51 AM EDT Alessandro Vesely wrote: > > > > On Fri 26/Aug/2022 17:21:09 +0200 Barry Leiba wrote: > > > > > Personally, I'm fine with the text here, but I would also be happy > > > > > with removal of the BCP 14 key words here, like this: > > > > > > > > > > NEW > > > > > If the set produced by the DNS Tree Walk contains no DMARC policy > > > > > > record > > > > > > > > (i.e., any indication that there is no such record as opposed to a > > > > > transient DNS error), then the DMARC mechanism does not apply to > this > > > > > message and Mail Receivers need to use other means to decide how to > > > > > handle the message. > > > > > END > > > > > > > > This is nicer than MUST NOT. It makes more sense, since we also > removed > > > > the SHOULD when the record is found and the test fails. > > > > > > I very much disagree. If there's no DMARC record, whatever you do > after > > > that > > > is not DMARC and we should say so. Softening this language opens the > door > > > for > > > all kinds of nonsense. People can and will do nonsensical things, but > we > > > need > > > to make it very clear that this isn't what this document is about. > > > Tampering > > > with the opt-in nature of DMARC is a recipe for interoperability > problems. > > > > > > 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
