[dmarc-discuss] Receiver [non-]obligations (Re: multiple from)

Roland Turner 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 
defend.

- Roland

-- 
   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 mailing list