OK, so let's do it step-by-step!
But can I configure the "ORPort" field with any other port? Port 443 is used for default HTTPS communications;
Yes, you can choose whatever you wish from a free port list. But keep in mind if you will be launching Tor from unprivileged user from the very beginning, then you need to use port number greater than 1024(or 2048 on some OSes), also called as an unprivileged ports. But you better use 443. Why? Because if people are behind the too-strict firewalls, also called as "facist firewalls" in Tor docs, they do allow only a strict amount of ports on remote side to be accessed. If you will run a bridge, for example obfs3 or 4 - use it for bridge incoming port, otherwise use it as an ORPort, you will maximize your relay usability by improving it's "reachability" for other people.
So Second question: does that mean that a person who is browsing by Tor on an HTTP web page (port 80 or 8080) will not be able to navigate through my relay?
No, the ports for Tor itself are influentive only on the connectivity to the Tor network itself. Once "you're inn" - your requests are tunneled through Tor network by using Tor protocol and because of that fact it's completely unrelated. Your requests are packed into the crypto-onions that contain not just the request data but also a "destination address", i.e. host+port or hostname+port in case of hidden onion service.
Third question: Adding these parameters to the 'torrc' file, will I be an intermediate node only? Because I suppose to be an exit node the Exitpolicy field has to be configured with ports too, right? Example: ExitPolicy accept: *: 80, accept *: 110 Or has this changed?
Yes and no =) Tor nodes are basically all the same, the p2p nodes to be more specific. So unless you have specified ClientOnly 1 in your config - you're a full p2p node, a "middle node". They do have roles, that can also be referred as Flags, and roles are assigned differently. Some of them - like "Exit" and "V2dir" - are assigned only if configured by the user in the config of this very specific node. Others like Guard, Stable, HSDir, Fast - are assigned by network consensus. I do recommend you to add DirPort 80 to enable directory("V2Dir") functionality - it won't overload you at all and won't make traffic grow any sensible high, but it will make your node serve a signed cache copies of "Tor directories" that are responsible for network consensus. It will help a lot to all the nodes in your vicinity and in global scale. Some roles are disabling others, for example an "Exit" won't be used as a "Guard". If you're about to be an exit node - you need to explicitly enable via ExitPolicy accept xxx and ExitPolicy accept6 xxx for IPv4 and IPv6 respecitvely. And here is the trick: *:<port> means Any destination address to port. Don't try to be a censorship supporter and put there anything except an asterisk in host part. It's impossible, for example, to "reject all requests to Google to 443 port* - addresses are changing and you will overload your relay with rubbish. At the end always make a reject *:* and reject6 *:*(if you have IPv6).
Fourth question: This question is extremely curious. In an old example of the 'torrc' file (https://svn.torproject.org/svn/tor/tags/tor-0_0_9_5/src/config/torrc.sample.in) this was said:
########## This section is just for servers ##################### NOTE: If you enable these, you should consider mailing your identity. key fingerprint to the tor-ops, so we can add you to the list of servers that clients will trust. See the README for details.
In the example of the current 'torrc' file (https://gitweb.torproject.org/tor.git/tree/src/config/torrc.sample.in) this no longer appears. Why?
At the earlier days Tor - as all the software - was debugged, and this was needed to keep in touch with the people who were running some kind of functionality that was debugged and/or developed that particular moment. This is OK, for any software, not just Tor. Nowdays it's done and working properly so there's no need in it. That's why all the stuff about it was removed - it's obsolete. You don't need to email anyone and/or announce your contacts.
Fifth question: I have read that once the file 'torrc' has been modified, the directory authorities must vote and approve the node. Is this still so? And in that case, who votes that a node is valid or not? A human administrator? Automatic software?
Yes, network consensus and directories are making automatic voting possible, and that's how it should be. No human factor involved: it's the most mailfunctioning part in most of IT systems, the human factor...
- Does the first node (or entry guard) to the Tor network know the IP of the Tor client?
Yes it does, but it does not know what are you doing in/via Tor network. There's no risk, and in some "last resort" cases you can disable using entry guards by adding UseEntryGuards 0 in your config. But this is last resort ONLY method, you should not use it in normal case. To make it clear I'll describe such a last-resort case: you are behind a firewall that somehow syndicates the guard list and blocks access to these addresses on by-ip basis. So if you have "seeded" your instance of Tor in working connection and disabling the guards - you have a chance that the node will be used which is not blocked. Because the total node address pool is a quite a big to be blocked in a whole, and it's changing frequently - a "jailbreak" scenario here is the really last resort you have. In other cases do not disable it.
- I have read that to be an entry guard node it is necessary to have a good bandwidth and be a stable node. Who decides that I am prepared to be an input node? A human administrator, or software?
Actually - as my experience shows - you need a stable bandwidth and long-term-online node. 1Mibps is more than enough to become a guard and I think lesser speeds are too. But it must be stable. That makes a great sense: a guard's primary task is to be a gatekeeper, so it should be reachable, online when it's needed and it's connection should actually allow it to fullfill it's task(to let people in).
