On Jul 22, 2013, at 10:24 PM, Roland Turner <[email protected]> wrote:
> 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. STARTTLS is defined in RFCs. Any obligation, whether through governmental or corporate requirements, compliance is still likely dictated by RFCs. > 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. Some laws criminalize message source spoofing. Since no RFC currently mandates structural compliance, obligations in this case extend from law rather than any specific RFC other than to reference RFCs defining why a message is misleading. These legal violations not mandated by any RFC occur frequently when malefactors attempt to deceive recipients. DMARC is attempting to establish a compliance requirement not found elsewhere other than the law. Unfortunately, DKIM does not necessarily preclude spoofing which is why DMARC found it necessary to include partial checks for invalidly prefixed From header spoofing. Why was this check limited to only the From header field? There are several other header fields, that if not checked, will permit extensive abuse. DMARC should drop this check and instead require a general compliance check be annotated in conjunction with any reliant result. > 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 In many cases these benefits are enjoyed by bulk senders offering various forms of solicitation and depend on a weaker and fragile form of authorization rather than authentication of the server. These weaker forms of authorization are often promulgated and conflated as providing authentication much to the detriment of recipients' protection. > (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. Allowing "practitioners" to avoid accountability for abuse they facilitate is a reliable path toward a steady decline in use. Recipients will not tolerate the abuse "authorizations without authentication" schemes permit and why governments have taken extreme measures of mandating source "authentication". Due to macro capabilities in SPF, it offers no assurance even the source IP address is confirmed. With DKIM, there is no assurance what the recipients see is trustworthy even when they think the signing domain is trustworthy. DMARC does not go far enough at offering improved protections. >> 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. Such bad information being offered as an Internet Standard can prove destructive of interchange. The charter did not inhibit the WG from deprecating the SPF resource record type rather than continuing to overlay the TXT resource record at the domain apex. Macro use was actually below the level of use permitting the resource record deprecation. It is not accurate to describe the poor results as the fault of the WG charter. The premise of the authorization scheme used by SPF is wrong. The trend is toward increasingly powerful protocols such as XMPP that depend upon source authentication, or social networks such as FB or LI. IMHO, SMTP able to use XMPP authentication techniques would be much safer than even social networking schemes which remain prone to various browser extensions. > When RFCs are viewed as rules to be enforced rather than proposals to help > practitioners, confusion of this type is common. When compliance with an RFC fails to provide reasonable interchange, then even these "practitioners" are not helped. When recipients are not protected, the "practitioners" should cease their practice. >> 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. Requirements mandating server authentication makes protection easier, even in the case of IPv6. Only then can those offering true value for recipients prevail. Regards, Douglas Otis _______________________________________________ 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)
