Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Murray S. Kucherawy
On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin wrote: > 15.11.2016 2:07, Murray S. Kucherawy пишет: > > On Mon, Nov 14, 2016 at 10:36 PM, wrote: > >> Let's break this down. If we're going to include recipients in the DKIM >> signature, it seems we have at least three key design decisions to

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Martijn Grooten
On Tue, Nov 15, 2016 at 08:07:38AM +0900, Murray S. Kucherawy wrote: > This is not reversible so nothing is leaked, but as we've all conceded by now > it's not hard to attack this to recover the hashed address especially since > one > might have good guesses as to what that address would be. I ca

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

2016-11-15 Thread Martijn Grooten
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 d

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

2016-11-15 Thread Scott Kitterman
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 to eventually bite >the >> bu

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

2016-11-15 Thread Martijn Grooten
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 understandin

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

2016-11-15 Thread Michael Thomas
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 th

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

2016-11-15 Thread Murray S. Kucherawy
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 email that you know is bad do

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

2016-11-15 Thread Michael Thomas
On 11/15/16 11:57 AM, Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten mailto:mart...@lapsedordinary.net>> 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 b

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

2016-11-15 Thread Murray S. Kucherawy
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 $HIGH_REPUTATION_MAIL_SERVE

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Murray S. Kucherawy
There's been a lot of great feedback here. I just cranked out an update based on the discussion so far: https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01 I forgot to update the title of Section 3, but other than that I think I captured what's been discussed. Please let me know wha

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Scott Kitterman
Note: Not cc'ing the DMARC list as this is a DKIM only draft. Given the discussions about twice ranging implications of a change like this (the end of email where RCPT TO changes in transit to start), the document needs far more discussion regarding the impact on the current email architecture

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Murray S. Kucherawy
On Wed, Nov 16, 2016 at 10:56 AM, John R Levine wrote: > https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01 >> >> I forgot to update the title of Section 3, but other than that I think I >> captured what's been discussed. Please let me know what I've missed. >> > > How come rh= has

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Murray S. Kucherawy
On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote: > Large email receivers forward tons of email. This proposal causes email > from DMARC-passing messages to be incapable of forwarding. As a large email > receiver who gets tons of complaints about breakage of DKIM signatures on > forwarded messa

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-15 Thread Murray S. Kucherawy
On Wed, Nov 16, 2016 at 1:05 PM, John R Levine wrote: > > So far this exercise has mostly served to persuade me that putting > envelope info in the DKIM signature is a bad idea, and our advice to people > who have problems with recipients remailing spam they've signed remains > "don't do that." >