Brad Knowles wrote:
Further, this will revealall recipients' key ids - something not wanted in anonymous lists.
True. A session key would be encrypted to each key id, so the keyids would be visible. However, subscriber information is not too hard to get from Mailman even when it's supposedly limited to being available only to the admin, so I think there may be bigger fish to fry elsewhere.
Right. And as it has already been pointed out, --throw-keyid should help.
Imho the tradeoff lies somewhere inbetween - encrypt messages to n recipients (yet to be implemented).
The problem is that encrypting a message is a very CPU-intensiveprocess, and you don't want to figure off thousands and thousands of message encryption processes for every single submission -- you'd DoS yourself to death. You'd have to make n pretty large in order to be able to make this scalable.
A quick test gave the following (254 bytes text file as input): lists indeed...
- ASCII-Armored result, 10 recipients: 4211 bytes
- ASCII-Armored result, 20 recipients: 8931 bytes
- ASCII-Armored result, 30 recipients: 14700 bytes
- ASCII-Armored result, 40 recipients: 19242 bytes Every recipient seems to increase file size by approx. 500 bytes. --throw-keyid didn't change file lenghts. Creating chunks larger than 20 or 30 recipients results in really large mails; repeated calls of gpg result in high load. Not good for large
Stefan.