On 07/20/2013 05:08 AM, Douglas Otis wrote:
SPF macros are a rarely used option, when combined with DMARC, becomes an
obligatory role for receivers on behalf of senders.
Nothing is obligatory upon receivers. Indeed, any assumption that an RFC has
this effect is invalidated by the actual behaviour of receivers above a certain
size with respect to this particular feature, exactly to avoid the consequences
of this error in the RFC.
Since DMARC is related to improving policy enforcement of sensitive domains, it
is reasonable to anticipate resulting bureaucratic obligations that expect RFC
compliance.
No, it isn't. There are never, ever, any obligations upon Mail Receivers
as the result of the contents of an RFC. In limited circumstances there
are contractual obligations built atop RFCs, as in rules for banks using
STARTTLS in public exchange with other banks, but (a) these obligations
do not arise from the RFC and (b) in the vast majority of cases such
overlaid obligations aren't in effect.
What RFCs provide Mail Receivers (and practitioners generally) with is a
set of tools for use in communication on the public Internet; perhaps
they use them, perhaps they don't, there are no obligations.
It follows that the opportunity for RFC authors is to (a) present
practices with which adherence will benefit the practitioner and the
organisation in which (s)he works and (b) to make that case in a way
that is persuasive both to the practitioner and to the organisation.
Thinking in terms of obligations actively stymies this because it takes
RFC authors' eyes off the target (the benefit to the practitioner and
communicating same) and substitutes an attempt to control the behaviour
of practitioners in the name of the greater good. This latter approach
is a pretty reliable way to slow adoption.
You are right about large providers already ignoring SPF macro provisions
which can destroy interchange.
I have not suggested such a thing and, indeed, it is a patently false
claim. SPF interchange is working perfectly well in the real world,
albeit not in the way that SPF's authors intended, nor - due to a
Working Group chartering error - in the way that spfbis will describe.
When RFCs are viewed as rules to be enforced rather than proposals to
help practitioners, confusion of this type is common.
Nevertheless, DMARC is building its foundation on shifting sand that means
receivers are not easily defended.
It's the Internet, everything is shifting sands, everything is hard to
defend.
- 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)
