Tom T. wrote:What about adding the NATpin rule to all future "development builds" of NS, but *not* stable releases -- for a while?
I'll support any step in this direction. Surely, though, keeping it out of the stable build would be extra work for Giorgio?
If so, I'd suggest just letting it go through the regular development build cycle with that P2P exception included...
But it's *not* a P2P port. See above finding re: the "official" usage.
Port 182 doesn't even show in Wikipedia's list of well-known ports
, whereas it does show several that are commonly used for P2P.
It does note:
The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port numbers for specific uses. However, many unofficial uses of both well-known and registered port numbers occur in practice.
So far, we've found two (2) uses of Port 182, and 50% of them had poor reputations. (Did you send the d/l from the other 50% to VirusTotal?)
A larger sample of sites using 182 would be useful.
In any case, IMHO, the fact that a site chooses non-standard ports, when there are well-defined and -recognized ports for all common browsing functions (HTTP, SSL, FTP, etc.) would raise a red flag: Why? Why are they doing this? -- and investigate further.
Should the RFE then simply request that the original NATpin rule be standard from here on? I dislike the "test it on the user" philosphy, when the user doesn't know it's a beta, dev build, release candidate, etc.
Or add the rule with 182 excluded, see if any other ABE errors occur, and if not, add back 182 in a future verison? ... unless we can find widespread use of 182, but I'd still like to know why they chose it.
Would anyone else like to add an opinion before an RFE is drafted? Thanks.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20120306 Firefox/12.0