Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Scott Kitterman
On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy" wrote: >On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman > >wrote: > >> Wouldn't a DMARC option to allow senders to specify only messages >that >> pass verification and alignment for BOTH

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Murray S. Kucherawy
On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote: > > Actually same message to same destination may be > > sent to different MTAs (e.g. different MXs with same weight). > > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > > lowercase the domain of

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Murray S. Kucherawy
On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin wrote: > 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form it > can not be implemented in most MTAs (see below) > 2. This standard

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Murray S. Kucherawy
On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman wrote: > Wouldn't a DMARC option to allow senders to specify only messages that > pass verification and alignment for BOTH SPF and DMARC accomplish the same > result with less complexity and without the layering violation

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Murray S. Kucherawy
On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany wrote: > Hi Murray. > Mark! > RFC6376 and even RFC4871, but now it's apparently happening > > I'd be interested to hear about the actual scenarios. Are the targeted > users somehow given an indication that the email verifies

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread ned+dkim
> 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form > it can not be implemented in most MTAs (see below) It wouldn't work at all in our MTA without modifications because our general filter interface currently

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Scott Kitterman
On November 13, 2016 1:50:05 AM EST, "Murray S. Kucherawy" wrote: >I've posted a draft that attempts to address an attack that's begun to >appear with DKIM. Interestingly, we called it out as a possible attack >in >RFC6376 and even RFC4871, but now it's apparently

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Martijn Grooten
On Sun, Nov 13, 2016 at 03:50:05PM +0900, Murray S. Kucherawy wrote: > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > > Comments welcome. Thanks for this. It isn't very clear to me how this proposal deals with receipients at different domains, including but not limited to blind

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

2016-11-13 Thread Mark Delany
Hi Murray. > RFC6376 and even RFC4871, but now it's apparently happening I'd be interested to hear about the actual scenarios. Are the targeted users somehow given an indication that the email verifies and it's from a credible domain and yet it contains a malevolent payload? This sounds like