On Jul 7, 2012, at 11:09 AM, Alan Maitland wrote: > At least in our case, the issue of domain names being used in spoofs is > pretty much moot. It was a problem, implementing SPF eliminated the problem. > Those who have MTAs that support SPF will know the senders are bogus and > deal with their messages accordingly. Those who don't can easily go check > the DNS records to see our policy and know that we don't send via the > machines from which the spoof arrived. In the latter case, there is a fairly > large positive reinforcement for wanting to implement SPF on their MTAs to > avoid junk processing. > > In this world, there will always be folks who try to destroy the work of > others. Around here, we publish the SPF records we do as an affirmative > claim about our environment. What others choose to do, we cannot control and > for those about whom we care, they can discover our sending machines from our > DNS published -all records. > > Reports on those who spoof seem interesting, but the reality is what can > administrators really do with that data? > > My hope in subscribing to this list was and is to glean the affirmative > reasons that one would want to look at and adopt DMARC. If DMARC breaks what > already works for us, then it would appear it is probably not the solution > for us. > > That said, it is even more disturbing that DMARC apparently has the potential > to break other protocols. If I understood correctly from an earlier comment > about DMARC not using the received envelope's "MAIL FROM" to interpret SPF > rules or its apparent failure to comply with a valid -all directive as > published by a domain holder, then it would appear that DMARC may have some > work in interoperability with already existing and widely adopted > infrastructure protocols. > > I really hope that I am wrong in my understanding, as I am trying to > understand the positives as to why we would want to adopt DMARC. > I think you are.
SPF tests have to pass on their own, before DMARC can consider the result. If SPF does not pass, then DMARC will not consider the result. However, personally I hear the case when p=none, to not override other protocol policies. At the moment, we are gearing up towards the interop, and some of you are coming. Bring these test cases. We want to interop, learn and then make another round of revisions to the spec. _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
