ietf-dkim
[Top] [All Lists]

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

2016-11-16 04:59:16
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 complaints about breakage of DKIM
signatures on forwarded messages which causes DMARC failures [1], this
proposal is not all that appealing.

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.

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 Rolf points out.

Besides forwarding, use of this method worsens mailing lists breakage further, which makes it totally out of scope for dmarc-ietf. At this point, I follow Dave's directive and remove that Cc:.

Finally, if you stick to one recipient per message, why do you rack your brains about encryption? I suggest adding a Disclosed-BCC: header field with the recipient address in the same 5322.address-list cleartext format as the other address fields, and sign it FWIW. It won't break more privacy than Delivered-To: does.

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

<Prev in Thread] Current Thread [Next in Thread>