INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             July 2001

5.6.5. Suggested Verification Methods

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.]

Diffs to previous draft

--- {draft-04}	Wed Jul 11 21:55:28 2001
+++ {draft-05}	Wed Jul 11 21:55:28 2001
@@ -43,3 +43,5 @@
 in a more palatable manner. We can now decide how much of it we want to
 keep.]
 
+
+