Re: [dmarc-ietf] DMARC policy overrides

[Scott Kitterman <[e-mail]>]

Franck Martin <[e-mail]> wrote:

>
>On Jul 2, 2013, at 2:53 PM, Scott Kitterman <[e-mail]>
> wrote:
>
>> On Tuesday, July 02, 2013 01:59:15 PM Dave Crocker wrote:
>>> On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote:
>>>> It seems to me that prose which spells this out, including the
>costs of
>>>> the "override" (namely processing through to the end of DATA), is
>>>> potentially a fine compromise.
>>> 
>>> Since the horse is possible still having some spasms, whether alive
>or
>>> not, I'll beat it some more:  My comments are about language, not
>>> technical details.  My concern is that the language many folk are
>using
>>> can lead to misunderstanding what is inside or outside the spec.
>>> 
>>>> I also think it's necessary to consider some current realities.  In
>an
>>>> architecture such as the one I use, filters operate serially on the
>>>> data.  The SPF module runs ahead of DKIM, which in turn runs ahead
>of
>>>> DMARC.  If the SPF module decides to act on a "-all" and reject the
>>>> message, DMARC and DKIM simply can't happen.  DMARC, by saying
>SHOULD
>>>> over SPF, is attempting to require that the SPF module change what
>it's
>>>> doing.  That means, at least in my local example, that DMARC is not
>a
>>>> pure overlay atop SPF and DKIM.
>>> 
>>> Right. It's not.
>>> 
>>> As for DMARC 'replacing' some SPF portions, yeah, it's doing that.
>>> 
>>> If someone thinks the text is not sufficiently clear about what is
>>> specified to do or why, we know how to fix that.  As for /whether/
>to do
>>> it, again, one can choose to live within DMARC or...
>> 
>> Ah, so DMARC is what it's defined as, so by definition any suggestion
>that it 
>> should be changed is incorrect.  Got it.  Glad we cleared that up.
>> 
>
>Scott,
>
>There are more than 20 people that developed this spec, we reached
>consensus on this is the best path and we deployed it and we have not
>seen it should be done otherwise. Any suggestion that it should be
>changed is not incorrect, it needs more support than the 20 people or
>so behind it... 
>
>As Barry said, review the current spec, build support and the spec will
>be changed.
>
>It seems I'm flogging a dead horse here.

This isn't an IETF working group with an established consensus that I'm seeking to overturn. Please stop pretending it is.

That group wasn't representative of senders, so I question the relevance to the IETF of your private consensus. 

Scott K