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

On Tue, Nov 22, 2016 at 7:45 AM, Michael Storz wrote: > >> The negative side of the proposal is the requirement to split all >>> multi-recipient-emails to single-recipient-emails, which is a show >>> stopper for me. >>> >> >> That's curious; why? >> > > Because SMTP is

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

Am 2016-11-22 17:14, schrieb John R. Levine: I'm with Murray -- why is this a problem? Single recipient has been the de-facto standard for years, and unless you are extremely bandwidth constrained, it's faster. No, it's not faster, see my answer to Murray. It's wasting a lot of ressources.

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

Am 2016-11-22 03:15, schrieb Brandon Long: Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who normally has a good reputation needs to not sign spam, this is a way to steal reputation from any service allowing you to choose your own message, and can be used against any

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

I'm with Murray -- why is this a problem? Single recipient has been the de-facto standard for years, and unless you are extremely bandwidth constrained, it's faster. No, it's not faster, see my answer to Murray. It's wasting a lot of ressources. People who've measured say the elapsed time

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

Am 2016-11-19 15:22, schrieb John R. Levine: The negative side of the proposal is the requirement to split all multi-recipient-emails to single-recipient-emails, which is a show stopper for me. I'm with Murray -- why is this a problem? Single recipient has been the de-facto standard for

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

Am 2016-11-18 22:53, schrieb Murray S. Kucherawy: On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz wrote: Normal DKIM-Signatures give us a way to check if the body and/or header of an email has been changed on the way from the signer to the verifier. The new extension

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

On Nov 21, 2016 6:30 PM, "John R. Levine" wrote: Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who > normally has a good reputation needs to not sign spam, this is a way to > steal reputation from any service allowing you to choose your own message, >

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

Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who normally has a good reputation needs to not sign spam, this is a way to steal reputation from any service allowing you to choose your own message, and can be used against any mail receiver. Just wondering, roughly when

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

Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who normally has a good reputation needs to not sign spam, this is a way to steal reputation from any service allowing you to choose your own message, and can be used against any mail receiver. That said, I think this

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

The negative side of the proposal is the requirement to split all multi-recipient-emails to single-recipient-emails, which is a show stopper for me. I'm with Murray -- why is this a problem? Single recipient has been the de-facto standard for years, and unless you are extremely bandwidth

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

On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz wrote: > Normal DKIM-Signatures give us a way to check if the body and/or header of > an email has been changed on the way from the signer to the verifier. The > new extension extends this to the recipients of the email. A

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

Am 2016-11-17 21:57, schrieb Murray S. Kucherawy: On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz wrote: Thanks, I see. That means the recipient is bound to the message and an attacker cannot delete or change the new tags. Great solution, I like it, though I do not like

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

On 11/17/2016 9:34 AM, MH Michael Hammer (5304) wrote: For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC for that matter since the receiver (at least ours) will never accept the payload anyway, i.e. it never gets to the SMTP "DATA" state. SPF does not require you

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

On November 17, 2016 2:57:00 PM CST, "Murray S. Kucherawy" wrote: >On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz >wrote: > >> >> Thanks, I see. That means the recipient is bound to the message and >an >> attacker cannot delete or change the new

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

Subject: Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz <michael.st...@lrz.de<mailto:michael.st...@lrz.de>> wrote: Thanks, I see. That means the recipient is bound to the message and an atta

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

On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz wrote: > > Thanks, I see. That means the recipient is bound to the message and an > attacker cannot delete or change the new tags. Great solution, I like it, > though I do not like the consequences when this extension will go

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

> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos > Sent: Thursday, November 17, 2016 9:30 AM > To: dm...@ietf.org; Ietf Dkim > Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to > draft- >

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

On 11/16/2016 1:09 PM, Terry Zink wrote: This means ARC will be needed not only for mailing lists which modify the header or body of an email, but for EVERY mailing list and EVERY forwarded email or EVERYTIME the recipient has been modified and the email leaves the ADMD boundary. From a DMARC

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

On Thu, Nov 17, 2016 at 7:28 PM, Alessandro Vesely wrote: > > Yes. >> > > Well, if its title were *Incompatibility with Current Infrastructure*, I > would agree there is a statement on the risk of disrupting how DKIM works. > That section talks about some things that are

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

Am 2016-11-16 21:00, schrieb Murray S. Kucherawy: On Wed, Nov 16, 2016 at 11:50 PM, Michael Storz wrote: Ok, I see you have removed the hashing of the recipient together with the email itself. But how do you prevent a replay attack, if the new tag is not bound to the

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

On Wed 16/Nov/2016 21:12:45 +0100 Murray S. Kucherawy wrote: On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely wrote: That way it will stay dormant until someone gets hurt and has to activate it, at which time it may cause more damage than improvement. A loose cannon. The

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

On Thu, Nov 17, 2016 at 3:09 AM, Terry Zink wrote: > > This means ARC will be needed not only for mailing lists which modify > the header or > > body of an email, but for EVERY mailing list and EVERY forwarded email > or EVERYTIME > > the recipient has been modified

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

On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely wrote: > > That way it will stay dormant until someone gets hurt and has to activate >>> it, at which time it may cause more damage than improvement. A loose >>> cannon. >>> >> >> The document makes that risk clear, or so I

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

On Wed, Nov 16, 2016 at 11:50 PM, Michael Storz wrote: > > Ok, I see you have removed the hashing of the recipient together with the > email itself. But how do you prevent a replay attack, if the new tag is not > bound to the email and signed with the DKIM-key (that's how I

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

On Wed 16/Nov/2016 14:00:26 +0100 Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely wrote: That way it will stay dormant until someone gets hurt and has to activate it, at which time it may cause more damage than improvement. A loose cannon. The

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

Am 2016-11-16 14:03, schrieb Murray S. Kucherawy: (dropping DMARC again) On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz wrote: Version 01 is purely incremental, meaning you can just ignore the new tags if you're more worried about breakage of forwarding than the attack

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

On 11/16/2016 8:03 AM, Murray S. Kucherawy wrote: That's not correct. The verifying MTA, if it doesn't know the new tags, is unaffected by the new tags because RFC6376 directs the verifier to ignore them. It's as if they weren't there. Do you have any data with unknown tag recordings

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

(dropping DMARC again) On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz wrote: > Version 01 is purely incremental, meaning you can just ignore the new >> tags if you're more worried about breakage of forwarding than the >> attack it's trying to address. >> > > Optional for

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

On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely wrote: > That way it will stay dormant until someone gets hurt and has to activate > it, at which time it may cause more damage than improvement. A loose > cannon. I'd keep it in its own header field [Ned's (1)(a)], so as to

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

On Wed 16/Nov/2016 03:28:08 +0100 Murray S. Kucherawy wrote: 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

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

Version 01 is purely incremental, meaning you can just ignore the new tags if you're more worried about breakage of forwarding than the attack it's trying to address. Ah, I'd missed that you took out the magic hash goop. If it's optional, it's still a bad idea, but it breaks a lot less stuff.

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

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 >

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

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

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

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. >> > >

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

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

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

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

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

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

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 make: > [...] > That's a pretty excellent summary. A couple of points: I think you

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

Hi Rolf, On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > At the time SenderID was proposed, back in 2004 or something, the act of > propagating header information into the transport stream was seen by many > as a layering violation. The proposal of

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

On 14-11-16 14:00, John R Levine wrote: [ resent with a reasonably correct date header ] I can write this up as a draft if people think it's interesting. Murray's draft puts the envelope recipients into the DKIM hash, which means that the message sent to multiple MTAs be signed separately for