What's the chances of switching to a mailing list system that doesn't expose your email address to everyone on the list when you reply?
On Fri, Aug 31, 2018, 18:06 Gary <jaffacakemonste...@gmail.com> wrote: > Hi, > > Yes I too got messages from Cynthia every few hours (wanting to meet) > until I blocked the email address. > > Thanks > > On Fri, 31 Aug 2018, 22:52 Matthew Glennon, <matthew@glennon.online> > wrote: > >> Anyone else getting nude photos and random links from Cynthia Coleman < >> cynthiacoleman843...@ru.irzum.com> attached to this (and other thread(s) >> lately? Spam obviously, but ugh. >> >> Matthew Glennon >> >> Want to make sure only I can read your message? Use PGP! >> (Then paste the encrypted text into an email for me to receive!) >> https://keybase.io/crazysane/ >> https://pgp.key-server.io/pks/lookup?op=get&search=0x92E43A8A9EF85EB4 >> >> >> On Fri, Aug 31, 2018 at 5:01 PM Conrad Rockenhaus <con...@rockenhaus.com> >> wrote: >> >>> Good God every conversation, now. Anyway. >>> >>> This exit isn’t bad exit material. Turkey has been known to block Tor >>> though, I’m actually proud of this guy for having the cajones (also known >>> as balls to those of you who don’t habla espanol) to operate an exit in >>> country such as Turkey, which absolutely hates freedom inducing >>> technologies such as Tor. Let’s give this guy (or gal) the atto-boy by >>> marking the exit as a bad-exit just because stuff gets blocked in >>> autocratic regimes that this operator has no control over. None, absolutely >>> none. They screw with the DNS servers over there, that’s why during the >>> last uprising they were tagging “8.8.8.8” on the walls. >>> >>> Now they’re doing things a little more sophisticated. Either way, this >>> guy gives us a window to see what is blocked and what isn’t blocked within >>> the Turkish thunderdome. >>> >>> -Conrad >>> >>> > On Aug 30, 2018, at 9:24 PM, Nathaniel Suchy <m...@lunorian.is> wrote: >>> > >>> > What if a Tor Bridge blocked connections to the tor network to >>> selective >>> > client IPs? Would we keep it in BridgeDB because its sometimes useful? >>> > >>> > On Thu, Aug 30, 2018 at 10:02 PM arisbe <ari...@cni.net> wrote: >>> > >>> >> Children should be seen and not herd. The opposite goes for Tor >>> relays. >>> >> Arisbe >>> >> >>> >> >>> >> On 8/30/2018 2:11 PM, Nathaniel Suchy wrote: >>> >> >>> >> So this exit node is censored by Turkey. That means any site blocked >>> in >>> >> Turkey is blocked on the exit. What about an exit node in China or >>> Syria or >>> >> Iraq? They censor, should exits there be allowed? I don't think they >>> >> should. Make them relay only, (and yes that means no Guard or HSDir >>> flags >>> >> too) situation A could happen. The odds might not be in your favor. >>> Don't >>> >> risk that! >>> >> >>> >> Cordially, >>> >> Nathaniel Suchy >>> >> >>> >> On Thu, Aug 30, 2018 at 3:25 PM grarpamp <grarp...@gmail.com> wrote: >>> >> >>> >>> This particular case receiving mentions for at least a few months... >>> >>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114 >>> >>> >>> >>> The relay won't [likely] be badexited because neither it nor its >>> upstream >>> >>> is >>> >>> shown to be doing anything malicious. Simple censorship isn't enough. >>> >>> And except for such limited censorship, the nodes are otherwise fully >>> >>> useful, and provide a valuable presence inside such regions / >>> networks. >>> >>> >>> >>> Users, in such censoring regimes, that have sucessfully connected >>> >>> to tor, already have free choice of whatever exits they wish, >>> therefore >>> >>> such censorship is moot for them. >>> >>> >>> >>> For everyone else, and them, workarounds exist such as,,, >>> >>> https://onion.torproject.org/ >>> >>> http://yz7lpwfhhzcdyc5y.onion/ >>> >>> search engines, sigs, vpns, mirrors, etc >>> >>> >>> >>> Further, whatever gets added to static exitpolicy's might move out >>> >>> from underneath them or the censor, the censor may quit, or the exit >>> >>> may fail to maintain the exitpolicy's. None of which are true >>> >>> representation >>> >>> of the net, and are effectively censorship as result of operator >>> action >>> >>> even though unintentional / delayed. >>> >>> >>> >>> Currently many regimes do limited censorship like this, >>> >>> so you'd lose all those exits too for no good reason, see... >>> >>> https://ooni.torproject.org/ >>> >>> >>> >>> >>> https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country >>> >>> >>> >>> And arbitrarily hamper spirits, tactics, and success of volunteer >>> >>> resistance communities and operators in, and fighting, such regimes >>> >>> around the world. >>> >>> >>> >>> And if the net goes chaotic, majority of exits will have limited >>> >>> visibility, >>> >>> for which exitpolicy / badexit are hardly manageable solutions >>> either, >>> >>> and would end up footshooting out many partly useful yet needed >>> >>> exits as well. >>> >>> >>> >>> >>> >>> If this situation bothers users, they can use... SIGNAL NEWNYM, >>> >>> New Identity, or ExcludeExitNodes. >>> >>> >>> >>> They can also create, maintain and publish lists of whatever such >>> >>> classes of nodes they wish to determine, including various levels >>> >>> of trust, contactability, verification, ouija, etc... such that >>> others >>> >>> can subscribe to them and Exclude at will. >>> >>> They can further publish patches to make tor automatically >>> >>> read such lists, including some modes that might narrowly exclude >>> >>> and route stream requests around just those lists of censored >>> >>> destination:exit pairings. >>> >>> >>> >>> Ref also... >>> >>> >>> https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit >>> >>> https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit >>> >>> >>> >>> >>> >>> In the subect situations, you'd want to show that it is in fact >>> >>> the exit itself, not its upstream, that is doing the censorship. >>> >>> >>> >>> Or that if fault can't be determined to the upstream or exit, what >>> >>> would be the plausible malicious benefit for an exit / upstream >>> >>> to block a given destination such that a badexit is warranted... >>> >>> >>> >>> a) Frustrate and divert off 0.001% of Turk users smart enough to >>> >>> use tor, chancing through tor client random exit selection of your >>> >>> blocking exit, off to one of the workarounds that you're equally >>> >>> unlikely to control and have ranked, through your exit vs one >>> >>> of the others tor has open? >>> >>> >>> >>> b) Prop up weird or otherwise secretly bad nodes on the net, >>> >>> like the hundreds of other ones out there, for which no badexit >>> >>> or diverse subscription services yet exist to qualify them? >>> >>> >>> >>> c) ??? >>> >>> >>> >>> Or that some large number of topsites were censored via >>> >>> singular or small numbers of exits / upstreams so as to be >>> >>> exceedingly annoying to the network users as a whole, where >>> >>> no other environment of such / chaotic widespread annoyance >>> >>> is known to exist at the same time. >>> >>> _______________________________________________ >>> >>> tor-relays mailing list >>> >>> tor-relays@lists.torproject.org >>> >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> tor-relays mailing listtor-relays@lists.torproject.orghttps:// >>> lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> >>> >> >>> >> -- >>> >> One person's moral compass is another person's face in the dirt. >>> >> >>> >> _______________________________________________ >>> >> tor-relays mailing list >>> >> tor-relays@lists.torproject.org >>> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> >>> > -- >>> > tor-talk mailing list - tor-t...@lists.torproject.org >>> > To unsubscribe or change other settings go to >>> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> _______________________________________________ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
