On 7/7/2012 12:42 PM, Franck Martin wrote:
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.
Franck,
Thank you for the additional and helpful data on flow. I am really glad
to have read your post and learned that I was incorrect.
That being the case, then it seems that DMARC really does ride on other
existing services like SPF rather than being a replacement. If so, then
fantastic news.
When someone on the list talked to not paying attention to valid SPF
-all constructs, the alarm bells started going off. Sorry if I overreacted.
If for no other reason than just isolation for testing and debugging
purposes in environments employing other existing protocols, the p=none
construct makes a whole lot of sense.
Best,
Alan M.
_______________________________________________
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)
