Re:Schleuder: A GPG-enabled mailinglist with remailing-capab...
by kazinator on Wednesday July 26, 2017 @03:21PM
(#14859296)
I'm interested in how non-subscribers are handled.
(And, by the way, applaud the Schleuder project's recognition and support for that, since I believe that mailing lists should be easily usable by non-subscribers. This modern widespread phenomenon of lists insisting on subscription before you can post is deplorable, and raises the bar for people to report issues to FOSS projects and such.)
The traditional plain text mailing list handles non-subscribers simply via two mechanisms: the Cc: header, and the use of "Reply-All" by participants when they reply to the mailing list. So messages are going not just through the mailing list robot but directly between people, and that keeps non-subscribers in the loop for conversations that they started.
This direct reply mechanism can't work for the encrypted case, clearly. A direct reply requires that we have the key for that party. So it must be that the encrypted list manager goes out of its way to handle the non-subscribers. The message must be relayed with a "Reply-to" header set to the list, and the list must then remember that the conversation includes an outside party that must stay in the loop somehow. The robot must also have the public key of the non-subscriber.
So effectively, the non-subscriber must become an "effective subscriber" for the conversation that they started. The robot remembers that person in a membership-like list.
Or, perhaps a special header can be used as a cookie, storing the non-subscriber's pubkey. If all the conversation participants relay this header back to the robot reliably, it doesn't have to keep it anywhere. (And the robot can also sign that pubkey so it doesn't have to blindly trust that the members are relaying it correctly.)
(And, by the way, applaud the Schleuder project's recognition and support for that, since I believe that mailing lists should be easily usable by non-subscribers. This modern widespread phenomenon of lists insisting on subscription before you can post is deplorable, and raises the bar for people to report issues to FOSS projects and such.)
The traditional plain text mailing list handles non-subscribers simply via two mechanisms: the Cc: header, and the use of "Reply-All" by participants when they reply to the mailing list. So messages are going not just through the mailing list robot but directly between people, and that keeps non-subscribers in the loop for conversations that they started.
This direct reply mechanism can't work for the encrypted case, clearly. A direct reply requires that we have the key for that party. So it must be that the encrypted list manager goes out of its way to handle the non-subscribers. The message must be relayed with a "Reply-to" header set to the list, and the list must then remember that the conversation includes an outside party that must stay in the loop somehow. The robot must also have the public key of the non-subscriber.
So effectively, the non-subscriber must become an "effective subscriber" for the conversation that they started. The robot remembers that person in a membership-like list.
Or, perhaps a special header can be used as a cookie, storing the non-subscriber's pubkey. If all the conversation participants relay this header back to the robot reliably, it doesn't have to keep it anywhere. (And the robot can also sign that pubkey so it doesn't have to blindly trust that the members are relaying it correctly.)