On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy"
wrote:
>On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman
>
>wrote:
>
>> Wouldn't a DMARC option to allow senders to specify only messages
>that
>> pass verification and alignment for BOTH
On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote:
> > Actually same message to same destination may be
> > sent to different MTAs (e.g. different MXs with same weight).
> > 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> > lowercase the domain of
On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin
wrote:
> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form it
> can not be implemented in most MTAs (see below)
> 2. This standard
On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman
wrote:
> Wouldn't a DMARC option to allow senders to specify only messages that
> pass verification and alignment for BOTH SPF and DMARC accomplish the same
> result with less complexity and without the layering violation
On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany
wrote:
> Hi Murray.
>
Mark!
> RFC6376 and even RFC4871, but now it's apparently happening
>
> I'd be interested to hear about the actual scenarios. Are the targeted
> users somehow given an indication that the email verifies
> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form
> it can not be implemented in most MTAs (see below)
It wouldn't work at all in our MTA without modifications because our general
filter interface currently
On November 13, 2016 1:50:05 AM EST, "Murray S. Kucherawy"
wrote:
>I've posted a draft that attempts to address an attack that's begun to
>appear with DKIM. Interestingly, we called it out as a possible attack
>in
>RFC6376 and even RFC4871, but now it's apparently
On Sun, Nov 13, 2016 at 03:50:05PM +0900, Murray S. Kucherawy wrote:
> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
>
> Comments welcome.
Thanks for this.
It isn't very clear to me how this proposal deals with receipients at
different domains, including but not limited to blind
Hi Murray.
> RFC6376 and even RFC4871, but now it's apparently happening
I'd be interested to hear about the actual scenarios. Are the targeted
users somehow given an indication that the email verifies and it's
from a credible domain and yet it contains a malevolent payload?
This sounds like