Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Thu, Jun 1, 2017 at 2:43 PM, Gene Shuman wrote: > I don't have particularly strong opinions here. I can see no reason for > the d= to differ, but also no harm in allowing it do so. So I think the > question of what to do here is slightly more philosophical. I think I >

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) >> wrote: >> >>> There's another question that had been

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

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] Clarifying question: AAR coverage by AMS

I don't have particularly strong opinions here. I can see no reason for the d= to differ, but also no harm in allowing it do so. So I think the question of what to do here is slightly more philosophical. I think I generally fall on the side of reducing user flexibility when nothing is actively

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Jun 1, 2017 11:48 PM, "Seth Blank" wrote: I'm slightly confused. I have a strong sense that the d= tag should be the same between the AS and AMS within an ADMD. I can absolutely see why the s= might legitimately vary. However, I can't seem the harm in the d= tag differing.

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

I'm slightly confused. I have a strong sense that the d= tag should be the same between the AS and AMS within an ADMD. I can absolutely see why the s= might legitimately vary. However, I can't seem the harm in the d= tag differing. If the signatures validate, why should this matter? Might this

[dmarc-ietf] dmarc - Update to a Meeting Session Request for IETF 99

An update to a meeting session request has just been submitted by Barry Leiba, a Chair of the dmarc working group. - Working Group Name: Domain-based Message Authentication, Reporting Conformance Area Name: Applications and Real-Time

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

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] Clarifying question: AAR coverage by AMS

On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy wrote: > On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) > wrote: > >> There's another question that had been raised by Seth about whether d= >> needs to match within an ARC set. The answer is yes,

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

> On 1 Jun 2017, at 05:23, Murray S. Kucherawy wrote: > >> On Wed, May 31, 2017 at 5:47 AM, Barry Leiba wrote: >> I agree with this. If there's stable documentation on DMARC usage >> that we can cite, there's little value in adding our own, which

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

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