"Stephen D. Williams" <sdw@lig.net> wrote:
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.
Yes. Really, procmail is all you need. If the local node is mynodename.com, then make the posting address (cypherpunks@) go to the procmailrc below and an internal address (_cypherpunks@) go to the local mailman instance. So your /etc/aliases might have lines like: cypherpunks: |procmail -m /etc/procmailrcs/procmailrc_cpunks _cypherpunks: |mailman post cypherpunks Note that you will have to tell mailman to accept messages addressed to cypherpunks@somenode.com and cypherpunks@othernode.com in addition to cypherpunks@mynodename.com. As I said in my previous message, the harder part is sender whitelisting. More on that below. One more note: the scripts I used during the CDR days are available from https://web.jfet.org/cpunk/cpunks-src.tgz See also https://web.jfet.org/cpunk/howto.html #----begin /etc/procmailrcs/procmailrc_cpunks---- # This script is very similar to how the "backbone" operated in the # original CDR, updated with the assumption that the nodes run mailman. # NOTE that I have not tested this!!! :) # nuke messages from MAILER-DAEMON or the local list instance :0 * (^From:.*MAILER-DAEMON@|^list-id.*cypherpunks.mynodename.com) /dev/null # keep a cache of message-IDs so that each message is only processed once :0 Wh: msgid.lock | formail -D 1280000 msgid.cache # maybe add a rule here to delete administrivia # check whether this message is "backbone" traffic that we've already seen :0c * !^X-Loop:.*mynodename.com ! _cypherpunks@localhost # now add an X-Loop header :0f | formail -A "X-Loop: mynodename.com" # now bounce to other nodes :0c * !^X-Loop:.*somenode.com ! cypherpunks@somenode.com :0c * !^X-Loop:.*othernode.com ! cypherpunks@othernode.com #----end /etc/procmailrcs/procmailrc_cpunks----
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.
This is a nice thought, but it has two pretty major issues. First, one of the reasons to have many nodes is so that nodes can apply their own filtering policies to the traffic. But naively operating the setup you describe would apply that filtering policy to mail going from that node to other nodes, which is bad---the "backbone" traffic should be unfiltered. It's possible to get around this issue, but (e.g.) vanilla mailman can't do it. Second, in the setup you describe, posting to the list instantly reveals to everyone which node you're subscribed to, which is information I was trying to keep hidden in the design I proposed. If it's OK to reveal to other node operators which list a poster is subscribed to, a simple solution is having the nodes share blinded (e.g., hashed and salted) subscriber lists with one another (note that this hides subscription information from everyone other than node operators).
We ought to create a Docker or similar recipe for setting up a new node with a single step.
In my estimation, this is not a good idea. The reason is that adding nodes to the network takes work from existing node owners. If the incentive structure is such that it's almost no work to set up a new node, then people will be incentivized to start nodes ("hey, that sounds fun"), but not to keep them running ("ugh, too much work"). This will result in a bunch of node churn, which is bad. Plus, what sane person would run a Docker image put together by a bunch of strangers from Cypherpunks? Finally, lowering the bar for people to run nodes sounds like a good idea until you're subscribed to a node whose operator is ignorant or malicious. Node operators are in a semi-trusted position. Having a barrier to entry is probably a good thing. -=rsw