Anne Bennett writes: > ** A tiny rant ** > > Necessary as this flexibility is if this document is to be > finished any time soon,
That's not why the flexibility is there, though. The point of the flexibility is that *this* RFC is being published to document what is already "out there", based on the original non-IETF spec. Clarifying ambiguity only helps if we're pretty sure that in fact there aren't any implementations based on an alternative interpretation. If we're not sure enough, we're exposing you to additional risk. This is not to say that your technical points aren't well-taken. But the sooner we put *this one* to bed, the sooner we can get to work on a normative RFC, and *picking* interpretations of existing ambiguity that make it easier to configure the mail system and still enable filtering of malicious mail. Maybe even fixing unambiguous problems in the current spec (although propagating changes to deliberately chosen specifications to implementations is always a difficult task). > it causes problems for a person trying to create SPF and DMARC > records in a way that will not cause more problems than it solves! No, since this RFC is informational, it simply fails to help where it is ambiguous. Any actual problems already exist "out there" -- and there probably aren't going to be a lot of new ones because the DMARC consortium claims that 80% of mail is already protected by DMARC. If you stay away from SPF "-all" and use DMARC "p=none", I don't see that there's much risk. Steve _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
