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

On Tue, Nov 22, 2016 at 8:05 AM, John Levine wrote: > > > >And, if you think about it, spam is in the eyes of the recipient. If you > >take this message I'm composing right now and send a couple billions > copies > >to the top 10 mailbox providers, how many spam markings will it

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

Well, besides the obvious damage of phishing/spam mails that may make it through filters because of this, yes, this can also be used to damage the reputation of senders. Gmail can probably weather the reputation issue, since we're a large high volume service, and antispam folks would have to

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

On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas wrote: > So, when the filters catch up, it will then mark it as spam again > regardless of the DKIM signature. > > So what exactly is the problem here? > I suppose when the filters catch up, the spammer can no longer get

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

On 11/15/16 11:57 AM, Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten > wrote: My understanding is an attack where the email is sent to an outside address owned by the sender, who then gets a

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

On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten wrote: > My understanding is an attack where the email is sent to an outside > address owned by the sender, who then gets a copy of the email, signed > by the provider who didn't think the email was bad. > > Signing an

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

On 11/15/2016 11:17 AM, Martijn Grooten wrote: On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote: Not at all. As I understand the scenario, the provider knows it's bad, doesn't send the mail on to the outside world, but still gives a signed copy back to the originator (which is

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

On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote: > Not at all. As I understand the scenario, the provider knows it's > bad, doesn't send the mail on to the outside world, but still gives a > signed copy back to the originator (which is then available for > replay). My

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

On November 15, 2016 10:53:19 AM CST, Martijn Grooten wrote: >On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote: >> OK. Ultimately, "don't sign spam" has got to be the solution or >reputation is >> going to suffer, so I think they are going to have

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

On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote: > OK. Ultimately, "don't sign spam" has got to be the solution or reputation > is > going to suffer, so I think they are going to have to eventually bite the > bullet and fix it. I think you underestimate how difficult it is to

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

On 11/13/2016 1:50 AM, 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 happening and being annoying enough that people

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

On Monday, November 14, 2016 05:34:19 PM Murray S. Kucherawy wrote: > On Mon, Nov 14, 2016 at 4:37 PM, Scott Kitterman > > wrote: > > >Doesn't that presuppose point-to-point handling? The proposal here > > >doesn't. > > > > Your proposal breaks all non-point-to-point

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

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

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

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

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] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

> 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

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