[dmarc-discuss] Receiver [non-]obligations (Re: multiple from)
roland.turner at trustsphere.com
Mon Jul 22 22:24:43 PDT 2013
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
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
roland.turner at trustsphere.com | http://www.trustsphere.com/
More information about the dmarc-discuss