Re: [tor-relays] tor-relays Digest, Vol 68, Issue 12
Hi Daniel One thing first: If you want to actively participate on this mailing list on a regular basis, it would be best if you switched your mailing-list-setting from digest to the actual mails (you can then either configure your inbox to put everything containing [tor-relays] into its own folder, or use a seperate email-address). This way, the Subject-lines are preserved when you answer, so it's easier to group the right messages together, automatically. Regarding relay vs. exit: Yes, there's a difference. I assume you're familiar with the basic workings of Tor (otherwise, read https://www.torproject.org/docs/faq.html.en#Torisdifferent and check out https://www.eff.org/pages/tor-and-https). An exit is a special kind of relay, as it is the one where your traffic leaves the Tor network and gets sent to the actual destination. This means that the destination sees the exit as the source of this traffic. So when somebody sends bad or illegal traffic, e.g. a hacker or someone downloading a movie, it looks like your exit is doing these things. Depending on the competence of your local law enforcement agencies, this could mean your computer (or all your computers in your home) might get seized, and you'll be a suspect. Therefore, it is not advisable to run an exit from home (since then you'll get all your computers taken away), or put anything else on the same server. Also, lawyers will file abuse complaints against your exit, which you'll have to deal with. It's perfectly fine to simply run a "normal" relay (you'll then be the middle hop), especially if you're running Tor on a system that's not online 24/7. Nice to see your relay is running now! Though I must admit that I have no idea what these "connection speed" notices mean. Probably nothing important, or they'd be warnings. Am 04.09.2016 um 06:52 schrieb daniel boone:
Ok, 1st on to MATT "I missed your SOCKS question." Well that doesnt matter because I took you advice on the first reply you sent explaing things so I commented all again as suggested. So all is well now on that part of the torrc file. What I did do was kept the ORPort at 9001. I tried 443 but in the terminal it showed me it could not bind so it would not work. As for the question on "hope this helps" you bet and well appricated. Thank you. *What I did on the exit on lines 186-190 here is what it is set at* *"#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports on IPv4 and IPv6 but no more #ExitPolicy accept *:119 # accept nntp ports on IPv4 and IPv6 as well as default exit policy #ExitPolicy accept *4:119 # accept nntp ports on IPv4 only as well as default exit policy #ExitPolicy accept6 *6:119 # accept nntp ports on IPv6 only as well as default exit policy ExitPolicy reject *:0 #no exits allowed: Minus the quotes natrually. this line is line 190* The links you sent me to look thru was interesting. Per what it says I believe port 443 for the ORPort would be best but until I get the bind issue I need to learn to do I best leave it set at 9001 for now. As for the reading on the relay ORPort 443 Exitpolicy reject *:* <stock in the box> Nickname ididnotconfig ContactInfo human@...
*{ORPort 9001 Exitpolicy reject *:* <how i set mine> Nickname danielboon ContactInfo human@...}* *back to line 190 I do have it UNCOMMENTED as you can see.* *{ExitPolicy reject *:0 #no exits allowed}* *Maybe i can comment line 190, I am not sure but u or Jen will get me right.* ................................................................................................ This part is Addressed to Jen
Regarding the exit settings: Is this relay running on a computer at your home, Daniel? *<answer is yes, my tower with a 64bit linux system duel core>*
Is there other important stuff stored/running on that computer? *<basically no important stuff. I do have some stuff but only mount the partitons when I need. Think I'm safe on that>*
If the answer to AT LEAST ONE of those two questions is yes, you should definitely set "ExitRelay 0" and "ExitPolicy reject *:*". Actually, you should set this, regardless of the answers, unless you know exactly, what it means to run an exit-relay and are willing and prepared to do this.
*<what I want to do is run a relay to help fuel the system. So is a relay and exit different?>* *and to the both of you I too will enjoying working with the group. I'm interested in many things at my age. I am self taught on all with books and just working with various OS's. Windows has been out for my many years once I got to now linux.* *As for both if you 2 are good enough to give me your names I can to that too. It is David so we can use that.*
I do have a setback here in the terminal I will post it>
*{Sep 03 23:57:39.000 [notice] Bootstrapped 0%: Starting Sep 03 23:57:47.000 [notice] Bootstrapped 80%: Connecting to the Tor network Sep 03 23:57:48.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Sep 03 23:57:49.000 [notice] Guessed our IP address as 108.79.14.224 (source: 154.35.175.225). Sep 03 23:57:49.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Sep 03 23:57:51.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Sep 03 23:57:51.000 [notice] Bootstrapped 100%: Done Sep 03 23:57:51.000 [notice] Now checking whether ORPort 108.79.14.224:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Sep 03 23:59:07.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes. Sep 04 00:07:45.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 100 buildtimes. Sep 04 00:11:48.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Sep 04 00:11:49.000 [notice] Performing bandwidth self-test...done.*
*{*Sep 04 00:11:56.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 104 buildtimes.}
*<what is going on with that. I did not change anything and I am not doing or using anything to set it back. Right with the MB too.}*
I'll check back in the morn. 21 hrs today is enough for my butt. C/Ya
*[snip quote of digest]* _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sun, Sep 4, 2016 at 8:17 AM, jensm1 <jensm1@bbjh.de> wrote:
you can then configure your inbox to put everything containing [tor-relays] into its own folder
This is non ideal as it continues the poor notion that bloating everyone's subject lines with, currently 13, characters of non content junk is a good idea, and it will cause mismatches on nonlist material. The proper way to segregate a list is to match on envelope headers such as the included X-BeenThere:, List-Id:, Sender:, not meta material in the body. Unix users can easily use fetchmail and maildrop to do this. Thunderbird and other clients should be able to. Webmails are typically junk so no guarantees there.
You're right, of course. The technically correct way would be to filter by the List-Id field and thunderbird supports this. I actually didn't know about this header field till now, thanks for pointing it out! But as you said, most webmails are crap (gmail apparently supports it, but not directly). The problem is, that this functionality is usually so well hidden, that even experienced users won't find it if they don't know exactly what they want to do, so filtering by subject/from/to - although technically "wrong" - is the only "visible" way to do it. Am 04.09.2016 um 15:28 schrieb grarpamp:
On Sun, Sep 4, 2016 at 8:17 AM, jensm1 <jensm1@bbjh.de> wrote:
you can then configure your inbox to put everything containing [tor-relays] into its own folder This is non ideal as it continues the poor notion that bloating everyone's subject lines with, currently 13, characters of non content junk is a good idea, and it will cause mismatches on nonlist material. The proper way to segregate a list is to match on envelope headers such as the included X-BeenThere:, List-Id:, Sender:, not meta material in the body. Unix users can easily use fetchmail and maildrop to do this. Thunderbird and other clients should be able to. Webmails are typically junk so no guarantees there.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Am 04.09.2016 um 06:52 schrieb daniel boone:
Ok, 1st on to MATT "I missed your SOCKS question." Well that doesnt matter because I took you advice on the first reply you sent explaing things so I commented all again as suggested. So all is well now on that part of the torrc file.
Disabling SOCKSPort on a relay is a good idea. You're not really anonymous if you use your relay as a client - its IP address is public, and so is its uptime/downtime. And there are statistical ways of matching relay and client traffic hiccups.
What I did do was kept the ORPort at 9001. I tried 443 but in the terminal it showed me it could not bind so it would not work. As for the question on "hope this helps" you bet and well appricated. Thank you.
Likely your tor process is running as a non-root user (this is good) without the CAP_NET_BIND_SERVICE capability, or your OS equivalent. And 9001 is a fine port, there's no need to change it to 443.
{Sep 04 00:11:56.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 104 buildtimes.}
<what is going on with that. I did not change anything and I am not doing or using anything to set it back. Right with the MB too.}
On 4 Sep 2016, at 22:17, jensm1 <jensm1@bbjh.de> wrote:
Nice to see your relay is running now! Though I must admit that I have no idea what these "connection speed" notices mean. Probably nothing important, or they'd be warnings.
Your network connections are timing out on a regular basis. This isn't great for a relay, it means that clients using your relay will be slowed down. This could be your ISP having poor connectivity, or actively closing long-lived connections. Or perhaps other traffic on your connection competes with the Tor traffic, and causes it to time out? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
participants (4)
-
daniel boone -
grarpamp -
jensm1 -
teor