{{ Apologies, it appears that an incomplete version of this response was
sent rather than saved as a draft. }}
On 03/06/2014 07:23 AM, J. Gomez wrote:
We probably inhabit different universes.
This is conceivable :-)
In mine, SPF -all "just works" and, most importantly, it allows the
receiver to outsource onto the sender 100% of the blame arising from
any non-deliveries because of SPF -all failures; also, in my universe
DMARC has not "succeeded" -- not yet, at least.
So:
* The test of SPF -all's effectiveness is not whether it can be turned
on without doing damage but whether it contributes materially to
preventing spoofing. It doesn't; spoofers can and do trivially pass SPF.
* Few receivers have the luxury of being able to blame others for
disrupting legitimate email flows. If you are one of those who can
get away with this, then by all means implement DMARC as-is. If it
suddenly turns out that your users aren't so blasé that "it's the
sender's fault" still washes, then you should of course either (i)
use it as an input to a more sophisticated defence strategy or (ii)
turn it off.
In terms of universes, I occupy the one in which >50% of all mailboxes
on Earth are already protected by DMARC filtering and which therefore
makes available to frequently spoofed domain owners a particularly
potent defensive tool. In this sense DMARC has already succeeded. (For
contrast note that SPF -all is implemented for far less than 50% of
mailboxes.)
The fact that this tool can't currently be used to prevent all spoofing
- and is never likely to be able to - doesn't mean that it hasn't
succeeded, merely that its application is limited, like any other tool.
For DMARC to be a viable option for receivers, it has to provide them
with a non-refutable answer/position for the cases when mail is not
delivered because of DMARC failures. If receivers are expected to
build a custom, fine-tuned, on-going maintenance-heavy local-only
system to deal with DMARC failure cases, because receivers cannot just
outsource onto senders the blame for DMARC failure cases, then most
receivers WILL NOT IMPLEMENT DMARC. My guess is many receivers will
not implement DMARC after having burned to much time and support costs
dealing with DMARC failure cases.
Two things:
* It's entirely likely that most receivers would decline to implement
DMARC with the current embryonic state of implementations and
supporting reputation data. This is not the same as saying that they
never will. In particular, much of the work of mapping reliable
forwarders and independent senders and competent/incompetent domain
owners can in principle be handled by reputation data providers just
as is currently the case for IP address blocklists (similarly,
creating IP address blocks lists is itself a task beyond reach for
most receivers but this isn't an argument for their not operating
mail-servers!) and, I'd suggest, such services are likely to appear
in the not-too-distant future.
* It may even be the case that most receivers will never implement. I
think this unlikely, but even if it happens this is hardly a
problem; the smallest 50% of receivers handle about 5% of all
mailboxes. Interdicting same-domain spoofing for only 95% of
mailboxes would be a pretty extraordinary success.
More broadly, DMARC has already succeeded, all additional receivers who
implement are just icing on the cake. Their participation is desirable
of course (blocking more spoofing is even better), and work to make that
easier is ongoing, but DMARC has already succeeded, it does not need
additional receivers in order to do so.
OK, this is perhaps the core of your misunderstanding. That a Domain
Owner expresses a policy which a receiver elects to ignore does not
mean that it's not a policy, merely that it's not binding upon the
receiver. One party's policy is the other party's recommendation,
suggestion or request.
One party's policy published for the consumption of the receivers, is a policy
expected to be treated as policy by the receivers, otherwise it would be the
first party's private-policy and not the first party's published-policy. If
what I publish as policy is to be regarded as a song, then why do I bother
publishing a policy instead of a song?
I have already published a policy that you give me all of your money. By
your reasoning, the fact that you haven't yet done so indicates that
there's something wrong with your behaviour.
This is not a contradiction, nor is it ex post
facto twisting; this is the plain English meaning of the word.
Policy is policy. That someone opts to not follow it, makes it an ignored
policy, not a non-policy.
Thank you for agreeing with me; your statement contradicts your earlier
position.
Therefore, DMARC's policy of p=reject is best to be ignored. Or, in other
words, there is not such a thing as a workable policy of REJECT in DMARC.
As has been pointed out to you ad nauseam, both of these assertions are
false.
- Roland
--
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)
_______________________________________________
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)
