On 02/25/2014 06:58 PM, J. Gomez wrote:
On Monday, February 24, 2014 6:43 AM [GMT+1=CET], Roland Turner wrote:
DMARC is best understood not as the FUSSP but as a pragmatic tool that
helps Domain Owners and receivers co-operate on an
otherwise-intractable
problem, consequently it doesn't attempt to solve the entire spoofing
problem, it merely attempts to make progress on part of the problem.
The
fact that the real-world email system contains situations where DMARC
can't make decisions as accurately as Domain Owners and receivers
would
like (e.g. legitimate forwarders and independent senders exist and
engage in a variety of perfectly reasonable behaviours that don't mesh
well with DMARC) isn't a vulnerability in DMARC (i.e. something that
can
be "exploited"), it's just a problem that DMARC doesn't purport to
solve.
So, in other words, there is not such a thing as a POLICY of REJECT in DMARC;
As others have pointed out, this is simply false. I may have a policy
that you give all of your money to me simply for continuing to read this
message, that doesn't mean that you will do so. The fact that you don't
do so doesn't mean that the policy doesn't exist, simply that it's not
binding upon you.
DMARC policies are similarly non-binding upon receivers. A Domain Owner
can have a range of policies and options (p, sp, pct). No such policy is
ever binding upon a receiver because the latter owns (and indeed, pays
for) its own equipment and therefore makes its own decisions. From the
perspective of a receiver, a Domain Owner's policy is a statement of
belief and advice, or simply a request, that receivers are free to
follow or ignore as they see fit.
and if there was ever one, you just cannot trust it nor follow it (as a
receiver).
Only a _*VERY*_ foolish receiver would blindly put control of their
security systems in the hands of unknown third parties. This is
essentially the same mistaken thinking that was behind SPF -all,
DomainKeys o=- and ADSP dkim=discardable and is a large part of the
reason that all three mechanisms failed. Attempting to shoehorn DMARC
into a mindset that has been exhaustively proven unworkable would be
self-defeating.
DMARC's development came about specifically in response to a
heavily-spoofed Domain Owner's discomfort at receivers who declined to
discard messages failing both SPF and DKIM because, from the receivers'
standpoint, a non-trivial number of failing messages were legitimate
messages. The solution to this problem was for co-operating receivers to
provide information about what message streams they could see and
samples of the messages that were failing authentication, in order to
allow the Domain Owner to discover and correct configuration errors and
oversights in their own environment. Once the false-positive-error
statistics get low enough, a participating receiver can then elect to
follow the Domain Owner's published policy. Those two feedback
mechanisms have since been standardised as DMARC's rua and ruf.
This is already working well for more than half of the world's
mailboxes. It's far too soon to declare victory, but this is already one
of the largest single pieces of progress against abuse in the last
decade. Your concerns would be tenuous even in the absence of this sort
of evidence but, given what's already been achieved, they are simply
unfounded.
At least we still have the reporting feature of DMARC, as something which is
actually useful (for the senders).
It is indeed the asynchronous[1] feedback mechanisms which most
conspicuously differentiate DMARC from its failed predecessors. Happily,
they also have various additional uses which are convenient for Domain
Owners generally.
- Roland
1: For particularly hardy souls, SPF can be used to construct a
synchronous feedback mechanism but (a) this is architecturally
problematic for many and (b) naturally, doesn't deal with DKIM.
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
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)
