Re: [dmarc-ietf] ARC RFC status to target

On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan wrote: > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be determined. I think that is aligned with (but not entailed by) >

Re: [dmarc-ietf] using selectors to identify sources

On 7/7/2017 3:42 PM, Seth Blank wrote: As a domain owner, the keys I use to sign messages are well known to me. Determining which key was used at the beginning of an ARC flow is impossible without transmitting the selector. transmitting to whom? and the issue isn't carriage of the selector.

Re: [dmarc-ietf] using selectors to identify sources

On 7/7/2017 1:44 PM, Steve Atkins wrote: That a particular major ISP uses (or claims to use, or used to claim to use) selectors to identify particular senders is (or was, or was and continues to be) a major reason that some ESPs refuse to rotate keys at all. Then it would be helpful to the

Re: [dmarc-ietf] using selectors to identify sources

The philosophical questions about how DKIM should best be used, best practices for selector usage, or how receivers determine reputation, are besides a very practical concern here that we're trying to address: As a domain owner, the keys I use to sign messages are well known to me. Determining

Re: [dmarc-ietf] using selectors to identify sources

On Friday, July 07, 2017 01:33:58 PM Seth Blank wrote: > On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman > > wrote: > > I think it depends on what is meant by 'source'. > > > > Imagine a scenario where I'm the mail admin for a shop that has 5 outbound > > servers. As a

Re: [dmarc-ietf] using selectors to identify sources

> On Jul 7, 2017, at 1:37 PM, Dave Crocker wrote: > > On 7/7/2017 1:33 PM, Seth Blank wrote: >>Receivers know the selector. If they feed domain and selector into >>their >>Bayesian processors and get a useful distinction, they are going to >>use it. >>No

Re: [dmarc-ietf] using selectors to identify sources

On 7/7/2017 1:33 PM, Seth Blank wrote: Receivers know the selector. If they feed domain and selector into their Bayesian processors and get a useful distinction, they are going to use it. No RFC will change that. If there's some statistically significant difference

Re: [dmarc-ietf] ARC RFC status to target

On Friday, July 07, 2017 03:12:51 PM Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: > > Would there be a proposed schedule for that evaluation to take place? I > > don't so much disagree with the description of how Experimental status > > /should/ work,

Re: [dmarc-ietf] ARC RFC status to target

On 07/07/2017 12:12, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: >> Would there be a proposed schedule for that evaluation to take place? > It's a good question, but I have two responses: > > 1. IETF timelines are worth approximately what one pays for

Re: [dmarc-ietf] ARC RFC status to target

On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: > Would there be a proposed schedule for that evaluation to take place? I > don't so much disagree with the description of how Experimental status > /should/ work, and including evaluation criteria would make sense. But > I'm not

Re: [dmarc-ietf] using selectors to identify sources

On 7/7/2017 9:12 AM, Tim Draegen wrote: I just caught up on the "selectors in AAR" thread, but wanted to go back to this early statement about key rotation and pairing of "s=" and "d=" to identify a single source. Thus a new Subject: is born. It's true key rotation is rare. People are figuring

Re: [dmarc-ietf] selectors in AAR.

On 6/26/2017 5:26 PM, Gene Shuman wrote: I definitely support this idea, as having the selectors available is extremely useful to us as part of service authentication. And putting them into the AR headers seems to be the appropriate solution. I guess the next question is how we would actually

Re: [dmarc-ietf] ARC RFC status to target

On 7/7/17 11:29 AM, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: >> Experimental status is exactly for this purpose. > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would >

Re: [dmarc-ietf] ARC RFC status to target

On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: > > Experimental status is exactly for this purpose. > > Thoughts? I always feel like experimental status ought to come with some description of what success or failure would mean and how that would be determined. I think that is

[dmarc-ietf] ARC RFC status to target

G'day. Noting the considerable efforts and progress on ARC specification, implementation and testing, I've given some though to the status that makes sense for the RFC that will result. The obvious assumption is Proposed Standard. I've come to believe that it makes more sense, at this

Re: [dmarc-ietf] using selectors to identify sources

On Friday, July 07, 2017 09:12:37 AM Tim Draegen wrote: > > On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy > > wrote: > > > > Based on discussions with Seth and Gene earlier, it sounds like the > > industry has sadly not taken up the habit of key and selector rotation, > >

Re: [dmarc-ietf] selectors in AAR.

> On Jul 6, 2017, at 9:25 PM, Seth Blank wrote: > > In the case of a direct mail flow, the receiver has all the needed > information from the SMTP connection and A-R payload to create a report. None > of this information is present once a message arrives at a receiver in an

[dmarc-ietf] using selectors to identify sources

> On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy wrote: > > Based on discussions with Seth and Gene earlier, it sounds like the industry > has sadly not taken up the habit of key and selector rotation, and instead > the pairing of "s=" and "d=" now identifies a single