"Stephen D. Williams" <s...@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 cypherpu...@somenode.com and cypherpu...@othernode.com in addition
to cypherpu...@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
! cypherpu...@somenode.com
:0c
* !^X-Loop:.*othernode.com
! cypherpu...@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
