On Thu, Jun 20, 2019, at 4:26 AM, Richard Damon wrote: > On 6/20/19 1:27 AM, Jim Ziobro wrote: > > It sounds like this is a proposal to somehow use information from one > > list to affect the behavior of another list. If the two lists are > > operating in different security/administrative domains then it means > > information is leaking from one domain into another. I can see some > > interesting behavior possible by sharing information. What is the goal? > > > > For example j...@af.mil is subscribed to two lists: > > moscow-soccer-sco...@kremlin.ru > > monthly-nuclear-launchc...@whitehouse.gov > > > > At some point the joe's postmaster forbids non-work-related emails so > > moscow-soccer-scores gets bounced. > > In an ideal case what should happen to joe's subscription to > > monthly-nuclear-launchcode? > > > > > > Ciao, > > I don't think anyone presumes that the subscription/bounce information > will be transferred between different instances of Mailman, but is an > attempt to better use information fro one mailing list about > deliverability in another list run by the same instance of Mailman. > > Your question does bring up an interesting point (maybe for different > domains than you used) about how much information SHOULD be exchanged > between lists that just happen to share the same host, perhaps a host > that is providing as a commercial enterprise to many customers who > operate lists. > > One very useful thing is to be able to look at the bounces to see what > the problem is, and if Mailman is going to disable/unsubscribe someone > from a list I am running, due to a bounce from another mailing list, I > would like to be able to see that bounce, but I very well would not want > someone else running a completely different list that just happens to be > on the same host, to see bounces from my subscribers.
Unless they are on the same Mailman instance, there is really no way to actually communicate this information. We are still debating if bounces from one list should affect other lists and you seem to have a good point that it shouldn't. > > This says that the 'global' sharing across a server of bounce > information needs to be purely optional, or Mailman would not be > suitable for shared servers. Even having the same domain name isn't good > enough, as I could easily want to run a mailing list hosting service, > similar to things like ConstantContact, where different customers > shouldn't have access to other customers information. > > This does bring up an interesting question on the structure of Mailman 3 > itself. It seems that this implies that a subscriber to multiple mailing > lists gets leaked the fact that two mailing list, even though they may > have nothing naturally in common, are hosted on the same installation of > mailman, something the list managers might not even be aware of. Even > Mailman 2 could leak this information if you look at the mail headers, > or carefully at the domains the lists interfaces fall back to, but this > becomes much more in your face, you go to subscribe to a list and find > you already have an 'user account' on that machine. Doing a reverse lookup of the web_host attribute in a domain should make that search easier. And yes, Mailman IMO wasn't designed to serve two entities who would want complete secrecy from one another but would still opt to use a shared Mailman server. -- thanks, Abhilash Raj (maxking) _______________________________________________ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
