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
10 matches
Mail list logo