Subject: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?)

From: Kurt Andersen <[email-masked]>
Date: Thu, 23 Oct 2014 14:21:09 -0400

On Thu, Oct 23, 2014 at 2:04 PM, Hector Santos <[email-masked]> wrote:

> We always know that DMARC always fails on a SPF failure as well.
>
>    DMARC =  DKIM + SPF
>
> So any failure on DKIM or SPF is part of a DKIM failure.  If that is not
> TRUE, then it needs to be part of the discussion.  A SPF failure fails
> DMARC despite how verifiable the DKIM layer is.
>

This is completely incorrect and false. I'm not sure why the falsity of
this contention should be any part of the discussion. DMARC = DKIM ^ SPF
not DKIM & SPF.

--Kurt Andersen

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Oct 2014 08:11:00 -0400

Hi Kurt,

If we are going to be picky about logic, then lets consider the 
symbolic correctness with short circuiting optimization, and it would be:

    DMARC = SPF or DKIM

which can be computed with a plus ('+') not with a caret ('^').  A 
caret symbolically represents an "exclusive or" logic [1] within many 
languages, i.e. C/C++ and finally SPF would be first computed logic 
for short circuiting.

I think there is a major presumption that processing DMARC requires 
the SMTP processor to delay its SMTP Level (before DATA) SPF 
processing until the PAYLOAD is receive, i.e. wait until the DKIM can 
be processed and 5322.From domain can read to lookup the DMARC AUTHOR 
DOMAIN POLICY.

The practical reality is that SPF will most likely be processed first 
by implementations of SPF at the SMTP level before DATA is reached. 
But until DMARC, SPF never needed the PAYLOAD.  Actually, if your 
package is still supporting SENDER-ID, it could be delaying SPF until 
the payload is reached or it supports the optimizing extended SMTP 
extension, the SUBMITTER protocol [2].

Murray always wanted to delay SPF processing or at least get actually 
explicit assistance from a "Domain Policy" to determine how to handle 
a SPF failure.   Remember that idea of rejections due to SPF fails was 
argued and weaken down in the original SPF specs.

Have a great day, Mr. Andersen.

-- 
HLS

[1] http://msdn.microsoft.com/en-us/library/3akey979.aspx
[2] http://tools.ietf.org/html/rfc4405

On 10/23/2014 2:21 PM, Kurt Andersen wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 24 Oct 2014 10:22:35 -0400

> symbolic correctness with short circuiting optimization, and it would be:

<snip>

Am I missing something here?  As I understand it, DMARC is MORE than SPF 
and DKIM.  Specifically, as I understand it,  sender field alignment, 
that's bit all of us who run mailing lists, is specific to DMARC.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Oct 2014 10:30:33 -0700

On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman <[email-masked]>
wrote:

> Hector Santos wrote:
>
>> Hi Kurt,
>>
>> If we are going to be picky about logic, then lets consider the symbolic
>> correctness with short circuiting optimization, and it would be:
>>
>>    DMARC = SPF or DKIM
>>
>>
> <snip>
>

You're not missing anything.

aligned SPF pass OR aligned DKIM pass = DMARC pass

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2014 11:30:08 -0700

> aligned SPF pass OR aligned DKIM pass = DMARC pass

+1

And the presence of the alignment requirement is what makes DMARC "more
than" either of those individual mechanisms.

This is not a small point of additional requirement.

That one change imposes the policy requirement that the owner of the
domain name in the rfc5322.From field and the operator of the
originating ADMD explicitly coordinate operation.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Oct 2014 11:56:25 -0700

On Oct 27, 2014, at 10:30 AM, Mike Jones <[email-masked]> wrote:

> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman <[email-masked]> wrote:
> Hector Santos wrote:
> Hi Kurt,
> 
> If we are going to be picky about logic, then lets consider the symbolic correctness with short circuiting optimization, and it would be:
> 
>    DMARC = SPF or DKIM
> 
> <snip>
> 
> Am I missing something here?  As I understand it, DMARC is MORE than SPF and DKIM.  Specifically, as I understand it,  sender field alignment, that's bit all of us who run mailing lists, is specific to DMARC.
> 

Dear Mike,

Agreed.  To further clarify the obvious, the WG needs to deal with large ISPs asserting DMARC p=reject against normal user accounts where, for legitimate messages, the From header field offered by various third-party services can not be aligned with either SPF or DKIM.

Possible mitigations: 

1) Develop a scheme for the DMARC domain to assert domain specific policy exceptions in the case of legitimate third-party services.

2) Create a group syntax able to bypass DMARC p= policy assertions by offering visual indications in the From header field that an exception may have been made.

3) Munge the domain of the From header field and expect users to hand edit addresses.

4) Adopt a new generic method (not list specific) conditionally replacing the role of the From header field with a new (invisible) header field.

IMHO, options 3 and 4 should be avoided. 

Regards,
Douglas Otis

---

From: Brett McDowell <[email-masked]>
Date: Mon, 27 Oct 2014 16:55:25 -0400

Doug, you missed (at least) one option which I will characterize as “transient trust”.  I suggest transient trust could be implemented at scale (for many use cases) via something like OAR [1] and a companion BCP.

-Brett

[1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00 <http://tools.ietf.org/html/draft-kucherawy-original-authres-00>

> On Oct 27, 2014, at 2:56 PM, Douglas Otis <[email-masked]> wrote:
> 
> 
> On Oct 27, 2014, at 10:30 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman <[email-masked] <mailto:[email-masked]>> wrote:
>> Hector Santos wrote:
>> Hi Kurt,
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Oct 2014 14:17:27 -0700

On Oct 27, 2014, at 1:55 PM, Brett McDowell <[email-masked]> wrote:

> [1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00

Dear Brett,

Original-Authentication-Results Header Field should fall under option 4 which is trivially spoofed.  OAR represent a new (invisible) header not signed by the DMARC domain.  Such information can not safely be trusted unless authorized by DMARC domain, i.e. TPA-Labels which falls under option 1.  TPA-Label has provisions covering OAR requirements among other elements.

Regards,
Douglas Otis

---

From: Brett McDowell <[email-masked]>
Date: Mon, 27 Oct 2014 17:20:20 -0400

Thanks Doug.  I may not agree with your assessment of OAR, but it is good to know you had it in mind.  As for TPA-Labels, it’s been a long time since I looked at that proposal and I’ll be brushing up on it between now and IETF91.

-Brett

> On Oct 27, 2014, at 5:17 PM, Douglas Otis <[email-masked]> wrote:
> 
> 
> On Oct 27, 2014, at 1:55 PM, Brett McDowell <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Oct 27, 2014, at 2:56 PM, Douglas Otis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>