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

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 <doug.mtview@gmail.com> wrote:
> 
> 
> On Oct 27, 2014, at 1:55 PM, Brett McDowell <brettmcdowell@gmail.com <mailto:brettmcdowell@gmail.com>> wrote:
> 
>> 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>
> 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
> 
> 
> 
>>> On Oct 27, 2014, at 2:56 PM, Douglas Otis <doug.mtview@gmail.com <mailto:doug.mtview@gmail.com>> wrote:
>>> 
>>> 
>>> On Oct 27, 2014, at 10:30 AM, Mike Jones <mjones@mail.agari.com <mailto:mjones@mail.agari.com>> wrote:
>>> 
>>>> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman <mfidelman@meetinghouse.net <mailto:mfidelman@meetinghouse.net>> 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.
>>>> 
>>>> You're not missing anything.  
>>>> 
>>>> aligned SPF pass OR aligned DKIM pass = DMARC pass
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dmarc mailing list
>>> dmarc@ietf.org <mailto:dmarc@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
> 