Subj : Nlcheck report
To   : Carlos Navarro
From : Michiel van der Vlist
Date : Sat Sep 23 2023 12:30:12

Hello Carlos,

On Saturday September 23 2023 09:16, you wrote to me:

 CN> I see most are EONs. IMHO those, as they are not Pvt, should at least
 CN> carry a flag that specifies their e-mail transport method (IUC, IMI,
 CN> ...).

You got it.  :-)

For starters: let me summarize what Nlcheck actually tests. Nlcheck checks if the nodelist contains sufficient information to make a connection with a non-Pvt node.  ANY connection. NLcheck is not an alternative for ErrFlags or some other nodelist validity test. Nlcheck just tests if there is /A/ way to connect to the node using the info in the nodelist. There must be information about WHERE to connect and HOW to connect. The "how" may be implicit. NLcheck does not test for other anomalies such as a Hub without downlinks.

So if there is a valid telephone number it does not look any further as there is a "where" and the "how" is implicit. (autonegotiation, V22b 2400 bps by default) There may be all kind of flag errors, but NlCheck does not report those, NLcheck marks the nodelist entry as "OK" if there is sufficient information to make /A/ connection. If there is no telephone number and the only flag is an INA flag with no acompanying protocol flag that is an error as there is no "how". There is no default connection method associated with the INA flag.

An EMA flag with an email address is considered insufficient information as there is a "where" but no "how".

Also note that Nlcheck checks host names and email addresses for correct syntax but does not test if a host name resolves or an email address exists.  Kees van Eeten runs a script that tests host names for resolving.


From FTS-5001:

  .4 Email Protocol Flags
   -----------------------

   E-mail Protocol Flags use the syntax:

   <flag>[:email address]

   To use the flag for any Email method providing for return receipts
   (currently ITX and ISE) a node *must* have them enabled and send
   such receipts within 24 hours of receiving a file.

   Flag    Description
   --------------------------


   ITX    TransX encoding for email tunnelling with receipts
          enabled.
   IUC    uuencoding of mail bundles
   IMI    MIME encoding of mail bundles
   ISE    SEAT protocol for Email tunnelling with receipts.
          enabled; should always be accompanied by IUC and/or IMI.
   EVY    Voyager-compatible
   EMA    Everything not defined by the aforementioned individual
          flags


   .5 E-mail Adress Flags
   ----------------------

   Email Address Flags use the synatx:

   <flag>:<email address>

   These flags are used to  specify an e-mail address for E-mail
   protocol Flags that do not specify an e-mail  address
   themselves.

   Flag   Description
   ------------------

   IEM    Indicates an unspecified mail tunnelling method (old
          usage), or sets the default e-mail address for other
          flags. (similar to INA)


 CN> Also it would be nice if they supported PING.

Indeed, Contrary to an IP connect such as binkd there is no live response from an email node. It may be a black hole. PING capability would make it easier to check if an email node is still alive.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
 * Origin: Nodelist Police Station (2:280/5555)

.