[Enigmail] About Supprting BCCed Recipients

[Patrick Brunschwig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Daniel Kahn Gillmor wrote:
> 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.

Of course I'm aware of the implications. But unfortunately, it seems
that GnuPG also tries to alwys probe the anonymous key ID's -- even if
some known key ID with existing secret key is available. But that's a
different story. In any case, I would not introduce a potential
compatibility issue with other systems without informing or asking the user.

> 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.

Unfortunately this option is not always feasible (which is the main
reason for the poll). Imagine an email sent to R1 and R2, bcc: to B1 and
B2. For whatever reason R2 and B2 don't have a key corresponding to
their email address, nor any defined per-recipient rules. The key
selection dialog is opened and the user selects the two additional keys.
But ... which of the selected keys belongs to B2 and should be hidden?
The dialog can't link the not found email addresses with the selected
keys. All it does is to create a list of key ID's, starting with some
given email addresses plus user input to (de-)select keys.

- -Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBSgs0HncOpHodsOiwAQjNywf/T1KT2jY8HOFXXuCi4rmFO0Gu9JPM5/Y1
0n7T6dgFDlbgMMqBRWmySW0jzm6I/ixDvq9EiSXfYLBffwX+Wx0KydElNs0MuWT8
LWGIM2OPC/ore6N5e7QCCMVWkEJ0CmPPZVTpeYInjULS0mpwaujw2S5awyK7hSrd
WMR3MvaoJT8Zdx4fJQQ+VjJxHQZe0oh+pY8bEgXDugahKiC6/C901tBRAJOy8XY+
ZiSIpc4n6Qc4FAJ8V9enNsh85540oruQb4324TYnWO2RShMmr4kF+xJvpF7AxSNY
qrTl3U4cGJGBX2X5/suTxE3Flsdd4v+9oV24NOkbutm7t+vOqvuySg==
=bJT1
-----END PGP SIGNATURE-----