On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely <vesely(_at_)tana(_dot_)it>
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 Rolf points out.
The document makes that risk clear, or so I thought. I'd be happy to get
proposals for stronger language if needed.
Why does it need its own header field? It's harmless expressed as tags in
the existing header field since they're ignored by verifiers that don't
know the new tags.
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:.
Yes, I agree.
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.
I don't follow. There's no additional encryption going on here.
Adding a "Disclosed-BCC" field guarantees disclosure, rather than only
disclosing if the MDA adds a Delivered-To. I don't think we should make
that worse.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html