Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread John Levine
In article you write: >ARC is an underlying authentication mechanism that calls for a new >assessment mechanism, since the role of the authenticated entity is >different than the entities currently being assessed by filtering >engines --

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Dave Crocker
On 7/18/2017 7:20 AM, Murray S. Kucherawy wrote: On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen > wrote: Let's take ietf.org as an example. There are @ietf.org individuals and then there are all the

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Murray S. Kucherawy
On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen wrote: > > I don't understand. Mediators ARC sign, the header is everything you need >> for this identification, is it not? >> > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Steven M Jones
On 07/18/2017 01:00 PM, Kurt Andersen wrote: > > We've suggested (during M3AAWG sessions) that smaller recipients can > build out a whitelist of "commonly seen" mediators, but might there be > value in having a mediator publish some sort of DNS record that would > indicate that they ARC seal

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Steven M Jones
On 07/18/2017 01:00 PM, Kurt Andersen wrote: > > We've suggested (during M3AAWG sessions) that smaller recipients can > build out a whitelist of "commonly seen" mediators, but might there be > value in having a mediator publish some sort of DNS record that would > indicate that they ARC seal

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Seth Blank
On Tue, Jul 18, 2017 at 4:34 AM, Kurt Andersen wrote: > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the mailing lists. If IETF wished to assert to receivers > that all their mail was either mediated or came from designated

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Kurt Andersen
On Tue, Jul 18, 2017 at 1:30 PM, Seth Blank wrote: > On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen wrote: > >> During today's lunch conversation, the question of how we can reasonably >> scale recipients being able to identify mediators came up. >> > > I

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Seth Blank
On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen wrote: > During today's lunch conversation, the question of how we can reasonably > scale recipients being able to identify mediators came up. > I don't understand. Mediators ARC sign, the header is everything you need for this

[dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

2017-07-18 Thread Kurt Andersen
During today's lunch conversation, the question of how we can reasonably scale recipients being able to identify mediators came up. We've suggested (during M3AAWG sessions) that smaller recipients can build out a whitelist of "commonly seen" mediators, but might there be value in having a

Re: [dmarc-ietf] Comments on ARC specification

2017-07-18 Thread Alexey Melnikov
> On 18 Jul 2017, at 09:59, Kurt Andersen (b) wrote: > >> Examples need updating. > > Thanks - I'm sure that there's a lot more problems in the examples than just > the ones you listed :-/ I suspect that we should just entirely remove the > examples right now. I think I

Re: [dmarc-ietf] Comments on ARC specification

2017-07-18 Thread Alexey Melnikov
Hi Kurt, > On 18 Jul 2017, at 09:59, Kurt Andersen (b) wrote: > >> On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov >> wrote: >> I've started implementing ARC and have a few minor comments on the draft: >> >> 5.1.2.2. Computing the 'b' Tag Value

Re: [dmarc-ietf] Comments on ARC specification

2017-07-18 Thread Kurt Andersen (b)
On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov wrote: > I've started implementing ARC and have a few minor comments on the draft: > > 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature > >As with ARC-Seal and DKIM-Signature header fields, the order

[dmarc-ietf] Comments on ARC specification

2017-07-18 Thread Alexey Melnikov
I've started implementing ARC and have a few minor comments on the draft: 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature As with ARC-Seal and DKIM-Signature header fields, the order of header fields signed MUST be done in bottom-up order. Upon rereading this I am not sure

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-06.txt

2017-07-18 Thread Kurt Andersen (b)
On Tue, Jul 18, 2017 at 8:51 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance of the IETF. > > Title :

[dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-06.txt

2017-07-18 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt