ietf-dkim
[Top] [All Lists]

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

2016-11-22 10:16:10
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.

People who've measured say the elapsed time is faster, and the extra bytes on the wire don't matter. This is an old argument, and not one you're going to win.

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.

See previous messages, particularly the ones from Ned Freed. Any sort of multi-recipient signing is subject to guessing attacks.

This isn't saying that signing the recipient is a good idea, but signing them individually is no worse than signing them together and avoids the leakage.

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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

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