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.