ietf-dkim
[Top] [All Lists]

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

2016-11-22 10:12:16
Am 2016-11-19 15:22, schrieb John R. Levine:
The negative side of the proposal is the requirement to split all multi-recipient-emails to single-recipient-emails, which is a show stopper for me.

I'm with Murray -- why is this a problem?  Single recipient has been
the de-facto standard for years, and unless you are extremely
bandwidth constrained, it's faster.

No, it's not faster, see my answer to Murray. It's wasting a lot of ressources.


 But I don't think this requirement is needed. I would allow a list of
recipients and have a paragraph which states ...

See previous discussion.  We rejected multi-recipient signatures
because of the bcc recipipient leakage.

John, did you read my email? The whole text is about how the leakage of the BCCs can be prevented and the feature of a multi-recipient email be preserved. If you see an error in the algorithm, please explain.


Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

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

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