usefor-article-07 May 2002

5.6.5.  Suggested Verification Methods

   It is preferable to verify the claimed path-identity against the
   source than to make routine use of the '?' path-delimiter, with
   consequential 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, IP
   addresses, or other registered aliases that the receiving site has
   agreed to peer with.

   Since the source host may have several IP addresses, checking the
   claimed FQDN or IP address against the source IP, or finding a
   suitable FQDN to report with a '?' path-delimiter, may involve
   several DNS lookups, following CNAME chains as required. Note that
   any reverse DNS lookup that is involved needs to be confirmed by a
   forward one.

   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.

--- ../usefor-article-06/Suggested_Verification_Methods.out          November 2001
+++ ../usefor-article-07/Suggested_Verification_Methods.out          May 2002
@@ -1,45 +1,25 @@
 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.
+   It is preferable to verify the claimed path-identity against the
+   source than to make routine use of the '?' path-delimiter, with
+   consequential 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.
+   already have been checked against a list of known FQDNs, IP
+   addresses, or other registered aliases that the receiving site has
+   agreed to peer with.
 
-   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.
+   Since the source host may have several IP addresses, checking the
+   claimed FQDN or IP address against the source IP, or finding a
+   suitable FQDN to report with a '?' path-delimiter, may involve
+   several DNS lookups, following CNAME chains as required. Note that
+   any reverse DNS lookup that is involved needs to be confirmed by a
+   forward one.
 
    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.]