Re: Good Netkeeping Seal of Approval (GNKSA)

[Sudish Joseph <sudish@mindspring.com>]

Rich Pieri writes:
> No, you should be able to type "foo@zub.fi".  To get at the "local" fi
> subdomain you should be typing the full host name, which is required for
> *ALL* Internet mail, even if zub.fi.cs.cmu.edu is literally right next
> to the one you are sending from.  Local names should only be used
> locally, that is, on the same machine (and really then only if the
> machine is not on any network).

No.  822 explicitly allows compression of domain names--which is quite
funny, coz it has no relevance to what happens between co-operating
hosts.  Like that other pastime, they can do whatever it is that
tickles the parts they like tickled.

Here's the ref in the interests of stillborn speculation,
-Sudish

[ RFC 822, I snipped a page divider ]

     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION

        Since any number of  levels  is  possible  within  the  domain
        hierarchy,  specification  of  a  fully  qualified address can
        become inconvenient.  This standard permits abbreviated domain
        specification, in a special case:

            For the address of  the  sender,  call  the  left-most
            sub-domain  Level  N.   In a header address, if all of
            the sub-domains above (i.e., to the right of) Level  N
            are  the same as those of the sender, then they do not
            have to appear in the specification.   Otherwise,  the
            address must be fully qualified.

            This feature is subject  to  approval  by  local  sub-
            domains.   Individual  sub-domains  may  require their
            member systems, which originate mail, to provide  full
            domain  specification only.  When permitted, abbrevia-
            tions may be present  only  while  the  message  stays
            within the sub-domain of the sender.

            Use of this mechanism requires the sender's sub-domain
            to reserve the names of all top-level domains, so that
            full specifications can be distinguished from abbrevi-
            ated specifications.

        For example, if a sender's address is:

                 sender@registry-A.registry-1.organization-X

        and one recipient's address is:

                recipient@registry-B.registry-1.organization-X

        and another's is:

                recipient@registry-C.registry-2.organization-X

        then ".registry-1.organization-X" need not be specified in the
        the  message,  but  "registry-C.registry-2"  DOES  have  to be
        specified.  That is, the first two addresses may  be  abbrevi-
        ated, but the third address must be fully specified.

        When a message crosses a domain boundary, all  addresses  must
        be  specified  in  the  full format, ending with the top-level
        name-domain in the right-most field.  It is the responsibility
        of  mail  forwarding services to ensure that addresses conform
        with this requirement.  In the case of abbreviated  addresses,
        the  relaying  service must make the necessary expansions.  It
        should be noted that it often is difficult for such a  service
        to locate all occurrences of address abbreviations.  For exam-
        ple, it will not be possible to find such abbreviations within
        the  body  of  the  message.   The "Return-Path" field can aid
        recipients in recovering from these errors.