Am 2016-11-22 17:14, schrieb John R. Levine:
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.
Could it be, that we are talking about different things? I have no idea
what these people measured. I can only talk for my site. Splitting all
my internal traffic into single-recipient emails would mean an increase
of 55%. If our mail servers would receive only single-recipient emails
from the internet the traffic would increase by 13%. The processing of
an email generates directly real cost in form of electricity and cooling
etc. which has to be payed with real money. Processing all these
additional traffic will give me no advantage but cost me real money. We
try to avoid wasting ressources, Green IT is an important thing at our
site, see http://www.lrz.de/wir/green-it_en/
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.
Since this approach uses Neds alternative 0) b) for the BCC recipients
no information about BCCs is leaked. This is the part where
single-recipient emails are needed. But all other recipients can be put
together into one email because their addresses are already recorded in
the various header fields.
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
Michael
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html