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 that clarity in purpose and outcome is going to be critical for
the supporters of DMARC in their likely goal to convincing others to
adopt and implement DMARC. Supporters need to provide solid
implementation benefits to those who may not feel they want to make the
investment in human capital, infrastructure disruption or actual costs
to implement DMARC or simply feel they do not need it.
"We are part of bigger infrastructures than you ever will be and have
also thought long and hard about all this over a Kirk burger" is just
probably not going to provide many folks with the warm fuzzies they want
to have in their justifying making a choice to move forward with DMARC.
Alan M.
On 7/7/2012 10:56 AM, Michael Adkins wrote:
That's exactly what I gain from it. I used to have a spoofing problem.
I
don't anymore.
By 'don't have a spoofing problem anymore', do you mean there are still
active attempts that are not delivered due to your SPF policy or that
there are no longer active attempts?
_______________________________________________
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)
_______________________________________________
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)
