X-RT-Original-Encoding: utf-8
Content-Transfer-Encoding: binary
Message-ID: <rt-4.4.4-4540-1585684504-305.8809-0-0@mit.edu>
Content-Disposition: inline
X-RT-Interface: Web
X-Mailer: MIME-tools 5.507 (Entity 5.507)
MIME-Version: 1.0
References: <MDAEMON-F201905232317.AA174457md50000021921@sequoia-grove.secure-endpoints.com> <RT-Ticket-8809@mit.edu> <rt-4.4.4-60459-1585635138-1693.8809-0-0@mit.edu>
Content-Type: text/html; charset="utf-8"
In-Reply-To: <rt-4.4.4-60459-1585635138-1693.8809-0-0@mit.edu>
RT-Send-CC:
Content-Length: 1286

<div>Jeff encountered a mail delivery issue updating the ticket; here is his response:<br />
&nbsp;
<pre>
RFC 2743 Section 4.1 states that the second component will be treated as
a hostname regardless of whether or not a DNS lookup succeeds.

   &quot;When a reference to a name of this type is resolved, the &#39;hostname&#39;
   may (as an example implementation strategy) be canonicalized by
   attempting a DNS lookup and using the fully-qualified domain name
   which is returned, or by using the &#39;hostname&#39; as provided if the DNS
   lookup fails.  The canonicalization operation also maps the host&#39;s
   name into lower-case characters.&quot;

In the case of a name which begins with a leading underscore the DNS
lookup is guaranteed to fail.  I will call out two items in the above a
paragraph:

 1. Canonicalization by attempting a DNS lookup is optional.

 2. If the optional DNS lookup fails, the &#39;hostname&#39; will be used
    as provided.

What I have pointed out in this ticket is that a getaddrinfo() query
will always fail for a name beginning with a leading underscore and that
the failure might take a long time.  Therefore, there is no benefit to
issuing the query and the canonicalization step described in Section 4.1
should be skipped.</pre>
</div>