[Enigmail] About Supprting BCCed Recipients
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed May 13 13:12:23 PDT 2009
On 05/13/2009 03:31 PM, Patrick Brunschwig wrote:
> As with most features, it's possible to design simple ways to support
> them, like adding "--no-throw-keyids" (which would take me less than 1
> hour to implement and test), and complex solutions that go as far as
> extending the per-recipient rules (which would require at least several
> days of work).
I appreciate that extending per-recipient rules is more work. But
please don't just add --throw-keyids (note that the negation is a little
wacky on this option) in general, because it adds additional cost to
*every* recipient, not just the Bcc contacts. Each client will need to
try to decrypt every session key in turn until they find the one that is
encrypted to their key.
For messages with N recipients, this increases the time to decrypt the
message by a factor of N/2. As keysizes get larger, this cost scales up :(
> Given that I'm working on Enigmail during my very limited free time, you
> might agree that I'm probably better off developing something really
> useful, and not invest several days just to support the special case of
> a few users who want to fully automate the sending of encrypted messages
> to BCC'ed recipients who use software that doesn't fully support some
> specific optional part of the OpenPGP standard ;-)
If we're making those kind of tradeoffs (i think they're reasonable
tradeoffs to make), i'd say that adding --hidden-recipient for each
Bcc'ed recipient is the way to go, and leave per-recipient rules as a
later project if people complain. This keeps the the UI cleaner anyway.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: <http://www.mozdev.org/pipermail/enigmail/attachments/20090513/5e9840c4/attachment.bin>
More information about the Enigmail
mailing list