Re: [bitfolk] Port 1720 filtered

Top Page

Reply to this message
Author: Andy Smith
Date:  
Subject: Re: [bitfolk] Port 1720 filtered
ubject=unsubscribe>
List-Archive: <http://lists.bitfolk.com/lurker/list/users.html>
List-Post: <mailto:users@lists.bitfolk.com>
List-Help: <mailto:users-request@lists.bitfolk.com?subject=help>
List-Subscribe: <https://lists.bitfolk.com/mailman/listinfo/users>,
    <mailto:users-request@lists.bitfolk.com?subject=subscribe>
X-List-Received-Date: Sun, 12 Feb 2012 00:37:38 -0000


On Sun, February 12, 2012 12:06 am, Daniel N=E9ri wrote:

> On Sun, Feb 12, 2012 at 00:13, Andy Bennett <andyjpb@???>
> wrote:
>> If your MX is down then senders' MX will
>> generally queue the message and retry for a few days. If DNS is down a=

nd
>> the MX record cannot even be resolved then the mail will bounce
>> immediately.
>
> This seems to be a common misconception.
>
> A properly implemented MTA must queue and retry also on temporary DNS
> lookup errors.


I don't believe such behaviour is particularly widespread, and hence I
would be reluctant to rely upon it in practice. Indeed, RFC2182 is quite
clear on the importance of having reachable DNS even if the referenced
services are affected by the same issue(s) (e.g. if sat on the same box):

-----
3.3. A Myth Exploded


An argument is occasionally made that there is no need for the domain
name servers for a domain to be accessible if the hosts in the domain
are unreachable. This argument is fallacious.

     + Clients react differently to inability to resolve than inability
       to connect, and reactions to the former are not always as
       desirable.
     + If the zone is resolvable yet the particular name is not, then a
       client can discard the transaction rather than retrying and
       creating undesirable load on the network.
     + While positive DNS results are usually cached, the lack of a
       result is not cached.  Thus, unnecessary inability to resolve
       creates an undesirable load on the net.
     + All names in the zone may not resolve to addresses within the
       detached network.  This becomes more likely over time.  Thus a
       basic assumption of the myth often becomes untrue.


It is important that there be nameservers able to be queried,
available always, for all forward zones.
-----

Mathew



From daniel.neri@??? Sun Feb 12 01:38:30 2012
Received: from mail-gy0-f176.google.com ([209.85.160.176])
    by mail.bitfolk.com with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16)
    (Exim 4.72) (envelope-from <daniel.neri@???>)
    id 1RwOOb-0005zR-P4
    for users@???; Sun, 12 Feb 2012 01:38:30 +0000
Received: by ghbz2 with SMTP id z2so2446817ghb.21
    for <users@???>; Sat, 11 Feb 2012 17:38:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
    h=mime-version:sender:in-reply-to:references:date
    :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
    bh=W3D5f3eUjiHfv+WNIW5Xu9Do1Aat/Igcuy4rlOmQZDg=;
    b=jHN0XlXaqLLHk7DOiJu1IZ+6rXvvJE54VU+ooM1/h4ttUrz0wQg9XsbsHRuYnY8W+g
    B0B6YwdtdbNdKDWmDFLGYqWaDA/TTviNRHpOCFQvgSA3qk0wRBN/dpBe9jA6r4GZ6cqc
    AlWQZQy1S1Bp/BejK2ycVy1QHQU72WE//eCcs=
MIME-Version: 1.0
Received: by 10.236.46.193 with SMTP id r41mr14631732yhb.123.1329010703429;
    Sat, 11 Feb 2012 17:38:23 -0800 (PST)
Sender: daniel.neri@???
Received: by 10.236.185.72 with HTTP; Sat, 11 Feb 2012 17:38:23 -0800 (PST)
In-Reply-To: <f8f0546071ef17ef800b142fac067e7d.squirrel@???>
References: <4F352183.4070708@???>
    <2AEAD09C-4403-484D-95BB-D0B313FC5DCD@???>
    <4F354B64.7040405@???> <4F35596E.3000906@???>
    <4F364EB3.3000604@???>
    <85f2071f1be555fe6f6a47eb6bafbb58.squirrel@???>
    <4F36BCE3.7080905@???>
    <20120211191946.GG23380@???>
    <4F36F62A.2060001@???>
    <CAOpGBFQGpg-Gy4ebtwtvW=orY_B2r5CHgGZwXe=5Cr+yqb45gg@???>
    <f8f0546071ef17ef800b142fac067e7d.squirrel@???>
Date: Sun, 12 Feb 2012 02:38:23 +0100
X-Google-Sender-