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:
(1) Whether or not to
(a) Enumerate the recipients, or some representation of them, outside the
DKIM hash, and sign that, or
(b) Include
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
e
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 Murra
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 narrowed it down to (0)(b),
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
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
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
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
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
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
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."
>
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.
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 complain
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 avoid
> the risk Ro
(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 the sender, yes, but not
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 addin
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 it's trying to address.
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 document makes th
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 read 4.1.4)?
> The spa
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 thought.
>>
>
> You m
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 and the email leaves the ADMD
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 document makes th
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 email and signed with the
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 compatible (ignored tags
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 p
> -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-
> kucherawy-dmarc-rcpts
>
> On
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 into
> production.
>
>
Y
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
mailto:michael.st...@lrz.de>> wrote:
Thanks, I see. That means the recipient is bound to the message and an attacker
cannot delete or chan
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 tags. Great solution, I like
>it,
>> though I do
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 t
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 the consequences when th
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 change means
> the email wa
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
con
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 proposal
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 w
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,
> and can be used aga
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 extends this to the recipie
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 years
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 is
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 mai
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.
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 defined as a multi-recipie
42 matches
Mail list logo