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

On 7/18/2017 4:34 AM, Kurt Andersen wrote: I realize that you can not vouch for yourself, but you can say that you participate in ARC for mediated mail. My concern is similar to what others already are expressing: I'm not clear what the security-related benefit would be. Publishing an 'I p

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

On 7/18/2017 8:52 AM, John Levine wrote: Well, yes, but for ARC you need a bottom turtle that tells you whether to mix the advice from the ARC chain into your message assessment. Not sure what the 'but' is meant to contrast with. In claiming that figuring out how to add the assessment compone

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

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 -- intermediary rather than originator. Well, yes, but for

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

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 mailing lists. If IETF wi

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

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 mailing lists. If IETF

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

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 mediat

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

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 mediat

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

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 internal > servers, how w

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

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 don't understand. Mediators ARC sign, th

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

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 identification, is it

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

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 mediator

Re: [dmarc-ietf] Comments on ARC specification

> 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 like to see examples

Re: [dmarc-ietf] Comments on ARC specification

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 for ARC-Message-Signature >> >>As with A

Re: [dmarc-ietf] Comments on ARC specification

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 of >header fields signed

[dmarc-ietf] Comments on ARC specification

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