# BinkD-compatible nodelist extraction - Fri Sep 7 00:02:29 2018 # # Created by binkd_nodelister.pl version 1.3 - 14 April 2007 # Copyright (c) 2002, 2003, 2007 by Jerry Schwartz and Write by Night # # Zone Nodelist for Friday, September 7, 2018 -- Day number 250 : 14422 # # The Sportnet(r) NodeList, a listing of the systems within Sportnet. # # ******** ******** ******** ******** ********** **** **** ******** ********** # * * * * * * * * * * * * * * * * * * # * ***** * ** * * ** * * ** * **** **** * * * * * ***** **** **** # * * * ** * * ** * * ** * * * * * * * * * * * # * ***** * * * ** * * * * * * ** * * *** * * # * * * ***** * ** * * ** * * * * * * * * * # ***** * * * * ** * * * * * * * * * *** * * # * * * * * ** * * ** * * * * ** * * * * * # ***** * * * * ** * * * * * * * * * * * * ***** * * # * * * * * * * * ** * * * * * * * * * * # ******** **** ******** **** * **** **** *** ******** **** # # Copyright 2016, Sportnet Software. All rights reserved except for the following: # # # o The Sportnet NodeList is compiled so that computer systems within Sportnet # may communicate with each other. Use and intra-Sportnet distribution # rights are granted to all Sportnet system operators for the purposes of # communication within Sportnet or applying for a Sportnet node number. # # o This is a compilation of individual nodelist segments contributed by the # drafters and compilers of those segments. Contribution of these segments # to this compilation does not diminish the rights of the contributors. # # # NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE # --------------------------------------------- # ATTENTION: # # Please check the END of the nodelist for updated additional technical # information. # # Node 24:24/0@sportnet ftn.tequilamockingbirdonline.net - Node 24:24/1@sportnet hub.tequilamockingbirdonline.net:24555 - Node 24:10/0@sportnet phoenix.bnbbbs.net:24555 - Node 24:10/1@sportnet phoenix.bnbbbs.net:24555 - Node 24:100/0@sportnet ftn.tequilamockingbirdonline.net - Node 24:100/1@sportnet ftn.tequilamockingbirdonline.net - Node 24:100/3@sportnet bbs.bnbbbs.net - Node 24:100/4@sportnet necrobbs.strangled.net - Node 24:100/5@sportnet battlestarbbs.dyndns.org - Node 24:100/9999@sportnet * - Node 24:110/0@sportnet binkp.deckersheaven.com - Node 24:110/1@sportnet binkp.deckersheaven.com - Node 24:110/2@sportnet bbs.deckersheaven.com - Node 24:110/3@sportnet livewirebbs.ddns.net - Node 24:110/4@sportnet mystic.dynu.net - Node 24:110/5@sportnet bbs.archaicbinary.net - Node 24:120/0@sportnet ftn.tequilamockingbirdonline.net - Node 24:120/1@sportnet ftn.tequilamockingbirdonline.net - Node 24:120/2@sportnet ERROR404BBS.DDns.net - Node 24:120/3@sportnet bbs.mojosworld.net - Node 24:120/4@sportnet vintagebbsing.com:24556 - Node 24:120/5@sportnet bbs.br-ranchbbs.com - Node 24:120/7@sportnet binkp.eothnet.com - Node 24:120/9999@sportnet * - Node 24:140/0@sportnet time.synchro.net - Node 24:140/1@sportnet time.synchro.net - Node 24:140/2@sportnet time.synchro.net - Node 24:150/0@sportnet bbs.castlerockbbs.com - Node 24:150/1@sportnet bbs.castlerockbbs.com - Node 24:150/2@sportnet bbs.castlerockbbs.com - Node 24:150/6@sportnet Razor's_Domain_3.141592;bbs.razorsdomain.com - Node 24:150/7@sportnet endofthelinebbs.com - Node 24:150/9999@sportnet * - Node 24:160/0@sportnet bbs.quinnnet.org - Node 24:160/1@sportnet bbs.quinnnet.org - Node 24:160/2@sportnet bbs.inktwo.com - Node 24:160/22@sportnet bbs.quinnnet.org - Node 24:160/23@sportnet * - Node 24:20/0@sportnet bbs.darkrealms.ca - Node 24:20/1@sportnet bbs.darkrealms.ca - Node 24:20/2@sportnet bbs.darkrealms.ca - Node 24:220/0@sportnet thecubebbs.darknet.org - Node 24:220/1@sportnet thecubebbs.darknet.org - Node 24:220/2@sportnet thecubebbs.darknet.org - Node 24:240/0@sportnet trmb.synchro.net - Node 24:240/1@sportnet trmb.synchro.net - Node 24:240/2@sportnet trmb.synchro.net - Node 24:30/0@sportnet applewood.linkpc.net;81.174.171.9: - Node 24:30/1@sportnet applewood.linkpc.net;81.174.171.9: - Node 24:30/2@sportnet applewoodbbs.linkpc.net;81.174.171.9: - Node 24:300/0@sportnet applewood.linkpc.net;81.174.171.9: - Node 24:300/1@sportnet applewoodbbs.linkpc.net;81.174.171.9: - Node 24:300/4@sportnet bbs.unicyber.co.uk - Node 24:301/0@sportnet blackice.bbsindex.de - Node 24:301/1@sportnet blackice.bbsindex.de - Node 24:301/2@sportnet bashbox.ufud.org - Node 24:302/0@sportnet velenobbs.ddns.net - Node 24:302/1@sportnet velenobbs.ddns.net - Node 24:40/0@sportnet agency.bbs.nz - Node 24:40/1@sportnet agency.bbs.nz - Node 24:400/0@sportnet agency.bbs.nz - Node 24:400/100@sportnet ipv4.agency.bbs.nz:24555 - Node 24:400/101@sportnet freeway.vkradio.com - Node 24:400/102@sportnet 1stchoicecore.co.nz - Node 24:400/103@sportnet telnet.fusionbbs.online - # # Flags authorized for use in the Sportnet nodelist segment: # # A: OPERATING CONDITION FLAGS: # # Flag Meaning # # CM Node accepts mail 24 hours a day # MO Node does not accept human callers # LO Node accepts calls Only from Listed # FidoNet addresses # ICM Node accepts 24/7 IP-mail but has limited # "open"-hours only via PSTN and/or ISDN # # B. MODEM FLAGS: # The following flags define modem protocols supported: # # Flag Meaning # # V21 CCITT V.21 300 bps full duplex # V22 CCITT V.22 1200 bps full duplex # V29 CCITT V.29 9600 bps half duplex # V32 CCITT V.32 9600 bps full duplex # V32b ITU-T V.32 bis 14400 bps full duplex # V32T V.32 Terbo # V33 CCITT V.33 # V34 CCITT V.34 # HST USR Courier HST # H14 USR Courier HST 14.4 # H16 USR Courier HST 16.8 # H96 Hayes V9600 # MAX Microcom AX/96xx series # PEP Packet Ensemble Protocol # CSP Compucom Speedmodem # ZYX Zyxel series # VFC V.Fast Class # Z19 Zyxel 19,200 modem protocol # V90C ITU-T V.90 modem Client # V90S ITU-T V.90 Server. # X2C US Robotics x2 client. # X2S US Robotics x2 server. # # The following flags define type of error correction available. A # separate error correction flag should not be used when the error # correction type can be determined by the modem flag. For instance # a modem flag of HST implies MNP. # # Flag Meaning # # MNP Microcom Networking Protocol error correction # of type MNP1 to MNP4 # V42 LAP-M error correction w/fallback to MNP # # C: COMPRESSION FLAGS: # # The following flags define the type(s) of compression of mail # packets supported. # # Flag Meaning # # MN No compression supported # # The following flags define the type(s) of data compression # available. # # V42b ITU-T V42bis # # D: FILE/UPDATE REQUEST FLAGS: # # The following flags indicate the types of file/update requests # supported. # # # |--------------------------------------------------| # | | Bark | WaZOO | # | |---------------------|---------------------| # | | File | Update | File | Update | # | Flag | Requests | Requests | Requests | Requests | # |------|----------|----------|----------|----------| # | XA | Yes | Yes | Yes | Yes | # | XB | Yes | Yes | Yes | No | # | XC | Yes | No | Yes | Yes | # | XP | Yes | Yes | No | No | # | XR | Yes | No | Yes | No | # | XW | No | No | Yes | No | # | XX | No | No | Yes | Yes | # |--------------------------------------------------| # # # # The following software is qualified to # use the appropriate file request flag # according to information provided by # developers: # # |-----------------------------------| # | Flag Software Package | # |-----------------------------------| # | XA Frontdoor 1.99b and lower | # | Frontdoor 2.01 and higher | # | Dutchie 2.90c | # | Binkleyterm 2.1 and higher | # | D'Bridge 1.2 and lower | # | Melmail | # | TIMS | # | Xenia | # |-----------------------------------| # | XB Binkleyterm 2.0 | # | Dutchie 2.90b | # |-----------------------------------| # | XC Opus 1.1 | # |-----------------------------------| # | XP Seadog | # |-----------------------------------| # | XR Opus 1.03 | # | Platinum Xpress | # |-----------------------------------| # | XW Fido 12N and higher | # | Tabby | # | TrapDoor No update processor| # | The Brake! | # |-----------------------------------| # | XX Argus 2.00 and higher | # | BeeMail # | D'Bridge 1.30 and higher | # | Frontdoor 1.99c/2.00 | # | InterMail 2.01 | # | McMail 1.00 | # | T-Mail | # | TrapDoor - Update Processor | # |-----------------------------------| # | None QMM | # |-----------------------------------| # # # E: GATEWAY FLAG: # # The following flag defines gateways to other domains (networks). # # Flag Meaning # # Gx..x Gateway to domain 'x..x', where 'x..x` is a string # of alphanumeric characters. Valid values for # 'x..x' are assigned by the FidoNet International # Coordinator. Current valid values of 'x..x' may # be found in the notes at the end of the FidoNet # nodelist. # # F: MAIL PERIOD FLAGS: # The following flags define the dedicated mail periods supported. # They have the form "#nn" or !nn where nn is the UTC hour the mail # period begins, # indicates Bell 212A compatibility, and ! # indicates incompatibility with Bell 212A. # # Flag Meaning # # #01 Zone 24 mail hour (01:00 - 02:00 UTC) # # G: ISDN CAPABILTY FLAGS: # # Nodelist Specification of minimal support required for this flag; # flag any additional support to be arranged via agreement # between users # # V110L ITU-T V.110 19k2 async ('low'). # V110H ITU-T V.110 38k4 async ('high'). # V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7, # modulo 8. # V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7, # modulo 8. # X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B # channel;Slayer 2 max.framesize 2048, window 2, non-ext. # mode (modulo 8);Slayer 3 transparent (no packet layer). # ISDN Other configurations. Use only if none of the above # fits. # # NOTE: No flag implies another. Each capability MUST be specifically # listed. # If no modem connects are supported, the nodelist speed field should # be 300. # # Conversion from old to new ISDN capability flags: # ISDNA -> V110L # ISDNB -> V110H # ISDNC -> X75 # # H: INTERNET CAPABILITY FLAGS: # # FLAG MEANING # # IBN - denotes a system that does BINKP # IFC - denotes a system that is capable of RAW or IFCICO # ITN - denote a system that does TELNET # IVM - denotes a system that is capable of VMODEM # IFT - denotes a system that allows FTP # ITX - denotes a system that uses TransX encoding for email # tunneling # IUC - denotes a system that uses UUEncode for email tunneling # IMI - denotes a system which uses MIME encoding for email # tunneling # ISE - denotes a system which supports SEAT receipts for anonymous # mail # IP - denotes a system that can receive TCP/IP connects using a # protocol that is not covered by any other flag. # IEM - is a deprecated flag, and new implementations must not # write it in nodelist entries. This was used as a single # placeholder for the InterNet address of the system if it # supported several transport methods. Instead of placing # the system address in the deprecated form specified below # in each flag, the address would be placed once only in this # flag. Implementations may need to parse this information # from nodelists created with older programs. # INA - Place to list a Fully Qualified Domain Name Or Static IP # Address, to be followed by applicable protocol flags # offered. Usage: INA:| # # # Conversion from R46/R50 Internet capabilty flags to the new flags: # # BND -> IBN # TEL -> ITN # TELNET -> ITN # VMD -> IVM # TCP -> IP # # The Internet Address should be placed in the BBS name field. # # Previous usage has placed the InterNet address as part of the # I-flag (for example ITX:r10_tx@thevision.net) # In this format the flag, colon, and address combined cannot exceed 32 # characters. However, this practice is deprecated, and new implementations # must not place address data in the flag section of the nodelist entry, # implementations may however be required to read this data from the # flag section. # # Telnet default port is 23. If the port is not 23 then the port # number must be placed after the ITN flag (eg ITN:60177) if the # Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then # the port number should be last (eg ITN:kraut.dynip.com:60177) always # remember that the flag cannot exceed 32 characters total. # # The default ports for other protocols are shown below, and changes # from the default port must be flagged in a similar way. # # Protocol Flag Default Port # # FTP IFT 21 # BINKP IBN 24554 # RAW/IFCICO IFC 60179 # VMODEM IVM 3141 # # Actual IP addresses can also be placed in the phone number field # using the country code of 000, however, the use of a FQDN is prefered. # # Note: All IP nodes *must* have mailer capabilities. E-Mail/FTP etc. denote # supplemental capabilities only. # # I: SYSTEM ONLINE TIME FLAGS # # The flag Tyz is used by non-CM nodes online not only during ZMH, # y is a letter indicating the start and z a letter indicating the # end of the online period as defined below (times in UTC): # # A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30, # D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30, # G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30, # J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30, # M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30, # P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30, # S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30, # V 21:00, v 21:30, W 22:00, w 22:30, X 23:00, x 23:30. # # For example TuB shows an online period from 20:30 until 1:00 UTC. # # Daylight saving time # # If a node changes online times with respect to UTC when daylight # saving time becomes effective (which would be the case with most # part time nodes), then this is to be taken into account when # assigning this flag. An online times flag assigned to a node should # not be altered for the specific purpose of adjusting due to # daylight saving time, since large difference files (NODEDIFF's) # would result if every node was allowed to do this, e.g. my node # used to be online from 2300 to 0800 in local time, which in winter # is UTC, but in the summer it becomes BST (British Summer Time). # This is one hour ahead of UTC, and the corresponding availability # times of my node during the summer period were 2200 to 0700 UTC. # Therefore my online times flag would have indicated availability # between the hours of 2300 and 0700 UTC, the daily time period # encompassing both times, so the flag would be TXH. # # J: BAUD RATES: # # The following baud rates are authorized for use in the nodelist: # # 300, 1200, 2400, 4800, 9600, 14400, 16800, 19200, 28800, 33600 # # K: Special flag: "PING" without any arguments # # Meaning: # # Nodes flying this flag will adhere to the following functionality: # # 1) PING-function: # """"""""""""""""" # If a message destined to "PING" arrives at its final destination # and this final destination flies the "PING"-flag, then the # receiving node will bounce the message back to the original # sender clearly displaying all the original via-lines. # # If a message destined to "PING" arrives at its final destination # but this final destination does _not_ fly the "PING"-flag then the # message may be deleted from the inbound-queue without further # follow-up. # # 2) TRACE-function: # """""""""""""""""" # If a message destined to "PING" arrives at a node which flies # the PING-flag but is merely passing-through to another destination # then the in-transit node will notify the sender of this occurence # and will forward the original mail unaltered towards its final # destination. # # # Userflags authorized for use in the nodelist # ------------ # A. FORMAT OF USER FLAGS # # U,x..x # A user-specified string, which may contain any # alphanumeric character except blanks. This string may # contain one to thirty-two characters of information # that may be used to add user-defined data to a specific # nodelist entry. The character "U" must not be # repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ". # The 32 character limitation is per userflag, not for # the total of all userflags. # # New implementations must place a comma after the # initial "U" before the user flags. Some # implementations will not place a separating comma # between the "U" and the first user flag, but this # practice is deprecated. Implementations should be # prepared to read flags in this format, and must strip # the "U" from the flag before analysis in this case. # # Entries following the "U" flag must be of a technical # or administrative nature. While experimentation of new # software functions using this flag is encouraged, # advertisement is strictly prohibited. # # For applications other than those shown, or if you # have questions concerning the use of this field, please # contact your Regional or Zone Coordinator. # # ZEC Zone EchoMail Coordinator. Not more than one entry # in the zone segment may carry this flag and that entry # must be the current Zone EchoMail Coordinator. # # REC Regional EchoMail Coordinator. Not more than one # entry in any region may carry this flag and that entry # must be the current Regional EchoMail Coordinator. # # NEC Network EchoMail coordinator. Not more than one entry # in any net may carry this flag and that entry must be # the current Network EchoMail Coordinator of that Net. # # # SDS Software Distribution System # # SMH SecureMail Hub - or one of the following variations, # indicating the specific level of the hub: # # NSMH - Net SecureMail Host - only one per net # RSMH - Region SecureMail Host - only one per region # ZSMH - Zone SecureMail Host - only one in Zone 1 # ISMH - International SecureMail Host - only one in Fidonet # # NC Network Coordinator. This flag is ONLY to be used by # the Network Coordinator of a net which has split the # duties of NC and Host and the NC does NOT occupy the # Net/0 position in the nodelist. #