Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-06-01 Thread Murray S. Kucherawy
On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy > wrote: > >> Another way to look at it: A-R is meant to be a channel to record what >> authentication was done and what thing in the visible

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-06-01 Thread Kurt Andersen (b)
On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy wrote: > Another way to look at it: A-R is meant to be a channel to record what > authentication was done and what thing in the visible message got > authenticated So, for SPF which does not authenticate *anything* in

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-06-01 Thread Murray S. Kucherawy
On Wed, May 31, 2017 at 10:30 PM, Seth Blank wrote: > > So I guess returning to the original thread, there are two matters: > > 1) Should we stamp header.b in the A-R? (consensus seems to be yes) > It's defined, may as well use it. > 2) How should we transmit the source_ip

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-05-31 Thread Seth Blank
On Wed, May 31, 2017 at 9:20 PM, Murray S. Kucherawy wrote: > What we're seeking to do here is add it to A-R as a way to get that > information through to a place where DMARC can get it to include in > reports. If we want to redefine what A-R is to meet that requirement,

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-05-31 Thread Murray S. Kucherawy
On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > 2) smtp.client-id > > > > The goal here is to track the originating source_ip for DMARC > > categorization and reporting. Otherwise, all ARC messages will

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-05-30 Thread Kurt Andersen (b)
Barry et al, On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: > The current spec defines an arc authres method ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1). > > We believe there should also be registered ptypes and properties, that > should

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-05-30 Thread Seth Blank
I mean in the AR arc=result header.b=... header.b=... And then this gets captured in the AAR when a message is signed. Seth On Tue, May 30, 2017 at 4:43 PM, Brandon Long wrote: > I'm not clear, are you saying requiring the header.b for every dkim > resinfo in the AAR, or

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-05-30 Thread Seth Blank
On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > The current spec defines an arc authres method ( > https://tools.ietf.org/html/ > > draft-ietf-dmarc-arc-protocol-03#section-8.1). > > > > We believe there

Re: [dmarc-ietf] Authentication-Results stamp for ARC

2017-05-30 Thread Scott Kitterman
On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > The current spec defines an arc authres method (https://tools.ietf.org/html/ > draft-ietf-dmarc-arc-protocol-03#section-8.1). > > We believe there should also be registered ptypes and properties, that > should be stamped (but are not

[dmarc-ietf] Authentication-Results stamp for ARC

2017-05-30 Thread Seth Blank
The current spec defines an arc authres method (https://tools.ietf.org/html/ draft-ietf-dmarc-arc-protocol-03#section-8.1). We believe there should also be registered ptypes and properties, that should be stamped (but are not required, as they won't always be available). As long as AR stamping