Bugzilla

I'm not currently opposing this feature, but I'd like to point out that the complete handling of this feature will require application behavior that could be considered as difficult to perceived by the user.

The idea to automatically trust keys doesn't align well with our current model, which requires the user to explicitly decide which keys they accept.

In my opinion, a solution at the mailing list manager level would be much easier to understand, and it could already be used today.

For example, the schleuder.org remailer allows you to setup a dedicated machine that defines the members of mailing lists. A single key is used for the list, so every person sending email only needs to have the list's public key. No synching of information to the user's computer is required.

Could you say there is a disadvantage, because the administrator of the re-mailer computer (running the Schleuder software) can intercept and read all messages. However, I'd like to note that with the mechanism described in this bug, the administrator has similar powers. If the administrator of the key and rules synchronization mechanism has malicious intentions, they can add another member to group definitions, which will also receive the messages. A difference is, with the group definition rules, you will have an audit trail, because the rogue addition of another group member could be discovered.

I'm not currently opposing this feature, but I'd like to point out that the complete handling of this feature will require application behavior that could be considered as difficult to perceived by the user.

The idea to automatically trust keys doesn't align well with our current model, which requires the user to explicitly decide which keys they accept.

In my opinion, a solution at the mailing list manager level would be much easier to understand, and it could already be used today.

For example, the schleuder.org remailer allows you to setup a dedicated machine that defines the members of mailing lists. A single key is used for the list, so every person sending email only needs to have the list's public key. No synching of information to the user's computer is required.

You could argue there is a disadvantage, because the administrator of the re-mailer computer (running the Schleuder software) can intercept and read all messages. However, I'd like to note that with the mechanism described in this bug, the administrator has similar powers. If the administrator of the key and rules synchronization mechanism has malicious intentions, they can add another member to group definitions, which will also receive the messages. A difference is, with the group definition rules, you will have an audit trail, because the rogue addition of another group member could be discovered.

I'm not currently opposing this feature, but I'd like to point out that the complete handling of this feature will require application behavior that could be perceived as confusing by Thunderbird users.

The idea to automatically trust keys doesn't align well with our current model, which requires the user to explicitly decide which keys they accept.

In my opinion, a solution at the mailing list manager level would be much easier to understand, and it could already be used today.

For example, the schleuder.org remailer allows you to setup a dedicated machine that defines the members of mailing lists. A single key is used for the list, so every person sending email only needs to have the list's public key. No synching of information to the user's computer is required.

You could argue there is a disadvantage, because the administrator of the re-mailer computer (running the Schleuder software) can intercept and read all messages. However, I'd like to note that with the mechanism described in this bug, the administrator has similar powers. If the administrator of the key and rules synchronization mechanism has malicious intentions, they can add another member to group definitions, which will also receive the messages. A difference is, with the group definition rules, you will have an audit trail, because the rogue addition of another group member could be discovered.