moving on (multiple future forks)

Stephen D. Williams sdw at lig.net
Wed Aug 31 23:58:03 PDT 2016


On 8/23/16 10:10 AM, Riad S. Wahby wrote:
> Georgi Guninski <guninski at guninski.com> wrote:
>> IMHO two or more future lists won't hurt. Everyone can set a
>> cypherpunks list (but won't get the past reputation of this one, if any).
> This is how cpunks was run from 1997 until mid-2005, when this
> became the only node. It was called the CDR (Cypherpunks Distributed
> Remailer).

Cool.  On the previous question of replicated email and mailman servers, I was recently looking into ways to do that.  Since all
email messages have unique IDs already, it isn't difficult to replicate messages at any point while avoiding duplicates and loops. 
I was concerned with Postfix, Dovecot (in mbox mode), and Mailman.  This is a link dump on that subject.  More stars mean more
promising / less obsolete:
http://wiki.dovecot.org/Replication
* http://blog.dovecot.org/2012/02/dovecot-clustering-with-dsync-based.html
* https://www.lowendtalk.com/discussion/50955/postfix-dovecot-distributed-setup
** http://wiki2.dovecot.org/Tools/Doveadm/Sync
* http://www.linuxmail.info/postfix-backup-mx/
http://serverfault.com/questions/303554/how-to-build-a-high-availability-postfix-system

>
> It's a nice idea in theory, but (with all respect) the original
> implementation was far from pretty; kudos to Jim Choate and Igor
> Chudov for making it work at all :)
>
> In principle it should be pretty straightforward to make a "distributed
> mailman" setup work.  The high-level idea is that all the servers
> accept messages, and all messages get forwarded to all servers. Then
> each server decides based on local policy which messages get delivered
> to users. For example, someone might decide they want to run a cpunks
> node that's moderated, and the important thing is that only their
> subscribers would see the moderated version of the list---subscribers
> to another node could get the full feed.
>
> The server-server forwarding stuff is like 10 lines of procmail, and
> requires no changes to mailman. The part that gets slightly hairy is
> implementing subscriber-only filtering [1]. In a naive setup, every
> node needs to know every other node's subscriber list. In addition
> to the (completely surmountable but sometimes annoying) issues with
> distributed synchronization, this is potentially a privacy concern
> for list subscribers.
>
> One step toward fixing this would be for lists to blind their
> whitelists. For example, a list could publish a set of SHA256 hashes
> of suscriber addresses, or maybe even something more clever, e.g.,
>     https://arxiv.org/abs/1412.8356
> But this still isn't perfect. For example, when a subscriber sends an
> email, each server gets to see which whitelist the subscriber matched
> against, which means that servers can keep track over time and build
> up a mapping from active posters to home nodes. This might not be
> a problem, but it's worth considering whether there's some approach
> that would fix this without too much computational overhead.

If people posted to the server that they are subscribed to and if servers accept email from subscribers including fully
authenticated other mailman servers, that would seem to work.  By not sending copies of posted messages back to the sender, the
originating mailman wouldn't get a second copy.  If the From was preserved in messages rather than a sister-mailman-ID, mailman
could still be made to be sure that it came from a trusted server.  A slight tweak to Mailman (or a procmail recipe) could support
signing the message or similar to indicate that it had been blessed on the sister system.  Or a sister-mailman ID could be used for
cross-mailman forwarding, with the original email ID in headers, possibly restored by a posting step.

I'd be fine running another node whenever someone wants to mess with it.  We should set up a test list to hack on it for a while. 
We ought to create a Docker or similar recipe for setting up a new node with a single step.

>
> [1] I understand that there are reasons to have a fully unregulated
>     list, but in my view subscriber-only filtering plus whitelisting
>     known remailers gives a good balance between ease of posting
>     and good SNR. If I recall correctly, the LNE.com CDR node was
>     the first to implement this policy, and I followed Eric's lead
>     because it was far and away better than what came before it.
>
> -=rsw

sdw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6084 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20160831/b600414f/attachment.txt>


More information about the cypherpunks mailing list