On 5/3/2014 12:23 PM, Dave Crocker wrote:
On 5/2/2014 1:05 PM, Fred Baker (fred) wrote:
3. The limitations of DMARC have been well understood, including
by both Yahoo and AOL. There is never any way for the IETF community
to protect against an organization's choosing to apply a protocol in a
way that is known to have damaging effects.
I find this philosophy quite concerning since the protocol is by
design, offering strong deterministic policies, options and features
to select from to both publish and honor -- its part of the protocol
logic. Its not there just to "look good" or for show. Its there to be
used.
Even if only a "small use" case was the purpose, the receivers still
had to be ready for it. The problem here is not applying the same
protocol principles equally and across all would-be compliant domains.
Let me ask, what if a fedex.com employee use this email domain for
subscribing to the IETF list? Fedex.com exposes their DKIM signing
practice very clearly with both an ADSP "dkim=discardable" and a DMARC
"p=reject" policy. They wanted to cover a wider net of either
ADSP/DMARC receivers. So why would you treat yahoo.com or
facebook.com "p=reject" policy any different than Fedex.com?
Facebook.com assigns facebook.com email address now for your account.
So its technically possible to use it on a list.
At what point do you adjust to a new DKIM+POLICY layered world?
4. There is, in fact, a draft BCP about DMARC use that was
posted and awaits pursuit, preferably in the IETF.[1] Working on it
got stalled by the gyrations of trying to decide how to process the
DMARC base specification. Perhaps we should focus our energies into
firing up an IETF engine to develop and progress the BCP?
Repeating, highlighting, emphasizing in a BCP not to publish
restrictive DMARC policies isn't going to solve the problem.
--
HLS