usefor-article-05 July 2001

5.6.5.  Suggested Verification Methods

   The following approaches for common transports are suggested in order
   to meet a site's verification obligations. They are not required, but
   following them should avoid the necessity for wasteful double-entry
   Path additions.

   If the incoming article arrives through some TCP/IP protocol such as
   NNTP, the IP address of the source will be known, and will likely
   already have been checked against a list of known FQDNs or IP
   addresses that the receiving site has agreed to peer with (this will
   have involved a DNS lookup of a known FQDN, following CNAME chains as
   required, to find an A record containing that source IP).

   1. Where the path-identity is an FQDN (or even an arbitrary name
      starting with a '.') it is now a simple matter to check that it is
      the proper FQDN for the source, or some known registered alias
      thereof. Alternatively, where the FQDN in the path-identity has an
      associated A record, an immediate DNS lookup as above can be used
      to verify it.

   2. Where the path-identity is an encoding of an IP address which does
      not immediately match the known IP address of the source, a
      reverse-DNS (in-addr.arpa PTR record) lookup may be done on the
      provided address, followed by a regular DNS "A" record lookup on
      the returned name. There may be A records for several IP
      addresses, of which one should match the path-identity and another
      should match the source.

   3. If the path-identity fails to match any known alias for the source
      (requiring the insertion of an extra path-identity for the true
      source followed by a '?'), simply doing a reverse DNS (PTR) lookup
      on the source IP address is not sufficient to generate the true
      FQDN. The returned name must be mapped back to A records to assure
      it matches the source's IP address.

   If the incoming article arrives through some other protocol, such as
   UUCP, that protocol MUST include a means of verifying the source
   site. In UUCP implementations, commonly each incoming connection has
   a unique login name and password, and that login name (or some alias
   registered for it) would be expected as the path-identity.
[The above description may still contain more detail that we would wish.
My aim so far was to retain everything in Brad's original, but expressed
in a more palatable manner. We can now decide how much of it we want to
keep.]

--- ../usefor-article-04/Suggested_Verification_Methods.out          April 2001
+++ ../usefor-article-05/Suggested_Verification_Methods.out          July 2001
@@ -4,6 +4,7 @@
    to meet a site's verification obligations. They are not required, but
    following them should avoid the necessity for wasteful double-entry
    Path additions.
+
    If the incoming article arrives through some TCP/IP protocol such as
    NNTP, the IP address of the source will be known, and will likely
    already have been checked against a list of known FQDNs or IP