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

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Nov 17, 2016 at 3:09 AM, Terry Zink <[e-mail]>
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 point of view DKIM will not be needed anymore because it has now
> the same
> > function as SPF - verifiying the origin of direct emails - and SPF is
> easier to implement
> > for most administrators.
>
> +1.
>
> It basically (almost) turns DKIM into SPF. That's not that appealing a
> solution.


Yep, it does.  And as we've already said on this thread, "Don't do that"
(i.e., don't sign spam in the first place) is far and away the preferred
solution, but it does happen resulting in increased reputation-enhanced
spam delivery to inboxes.  So we have a choice now between not doing
something like this which enables the attack described in the document to
continue, or doing something like this and making DMARC have to go through
some kind of unpleasant permutation.

It's funny you should mention ARC, because this was first raised on the
mailing list where ARC is developed, and then discussed further at MAAWG
this fall, and then brought to us to brainstorm on a solution.  So far,
this is where we've landed as being the least damaging thing to do when
"don't sign spam in the first place" is rejected as a solution.

Maybe we should take this back to the MAAWG technical discussions list.
I'll do that later today.

-MSK

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html