On 8/23/16 10:10 AM, Riad S. Wahby wrote:

Georgi Guninski [1]<guninski@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:
   [2]http://wiki.dovecot.org/Replication
   *
   [3]http://blog.dovecot.org/2012/02/dovecot-clustering-with-dsync-based.
   html
   *
   [4]https://www.lowendtalk.com/discussion/50955/postfix-dovecot-distribu
   ted-setup
   ** [5]http://wiki2.dovecot.org/Tools/Doveadm/Sync
   * [6]http://www.linuxmail.info/postfix-backup-mx/
   [7]http://serverfault.com/questions/303554/how-to-build-a-high-availabi
   lity-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.,
    [8]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

References

   1. mailto:guninski@guninski.com
   2. http://wiki.dovecot.org/Replication
   3. http://blog.dovecot.org/2012/02/dovecot-clustering-with-dsync-based.html
   4. https://www.lowendtalk.com/discussion/50955/postfix-dovecot-distributed-setup
   5. http://wiki2.dovecot.org/Tools/Doveadm/Sync
   6. http://www.linuxmail.info/postfix-backup-mx/
   7. http://serverfault.com/questions/303554/how-to-build-a-high-availability-postfix-system
   8. https://arxiv.org/abs/1412.8356