Re: bind timeouts

From: Don Lewis (truckman_at_FreeBSD.org)
Date: 05/18/04

  • Next message: Matthew D. Fuller: "Re: bind timeouts" 
    Date: Tue, 18 May 2004 01:04:07 -0700 (PDT)
To: fullermd@over-yonder.net

    On 18 May, Matthew D. Fuller wrote:
    > On Tue, May 18, 2004 at 08:14:04AM +0200 I heard the voice of
    > Christian Hiris, and lo! it spake thus:
    >>
    >> As far as i know MX records _must_ have an A record.
    >
    > RFC1035 states:
    > MX records cause type A additional section processing for the host
    > specified by EXCHANGE. The use of MX RRs is explained in detail
    > in [RFC-974].
    >
    > RFC974 says:
    > There is one other special case. If the response contains an
    > answer which is a CNAME RR, it indicates that REMOTE is actually
    > an alias for some other domain name. The query should be repeated
    > with the canonical domain name.

    That covers the intial lookup, meaning that a CNAME pointing to an MX is
    legal.

    Pointing an MX at a CNAME is likely to break the RFC 974 mail loop
    prevention algorithm. Just below the paragraph you quoted:

       If the response does not contain an error response, and does not
       contain aliases, its answer section should be a (possibly zero
       length) list of MX RRs for domain name REMOTE (or REMOTE's true
       domain name if REMOTE was a alias). The next section describes how
       this list is interpreted.

    [ snip ]

       It is possible that the list of MXs in the response to the query will
       be empty. This is a special case. If the list is empty, mailers
       should treat it as if it contained one RR, an MX RR with a preference
       value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
       MX). In addition, the mailer should do no further processing on the
       list, but should attempt to deliver the message to REMOTE. The idea
       here is that if a domain fails to advertise any information about a
       particular name we will give it the benefit of the doubt and attempt
       delivery.

       If the list is not empty, the mailer should remove irrelevant RR's
       from the list according to the following steps. Note that the order
       is significant.

          For each MX, a WKS query should be issued to see if the domain
          name listed actually supports the mail service desired. MX RRs
          which list domain names which do not support the service should be
          discarded. This step is optional, but strongly encouraged.

    The WKS lookup is deprecated ..

          If the domain name LOCAL is listed as an MX RR, all MX RRs with a
          preference value greater than or equal to that of LOCAL's must be
          discarded.

    This is the important part. If an MX points to an alias for LOCAL, the
    MTA may fail to trim this MX record (and the MX records with the same or
    greater preference values) from the list, which may cause the MTA to
    connect to itself in an attempt to deliver the message, or it may cause
    the MTA to attempt to deliver the message using an MX record with a
    higher preference number, which might loop the message right back to
    this host.

    The only ways of preventing this undesirable behavior are:

            Configure the MTA with a list of all the aliases (CNAMEs) for
            LOCAL. The MTA must be reconfigured whenever an alias is added
            or deleted.

            Look up the IP addresses for the domain names listed by the
            MX records an compare the list of IP addresses to the IP
            addresses of the MTA host. This may require a number of DNS
            queries to be made before the first delivery attempt can be
            made. It is not possible to attempt delivery if a domain name
            specified by one of the MX RRs with the lowest preference value
            is unresolvable due to a temporary DNS failure.

    Example of the latter problem:

    $ORIGIN example.com.
            IN MX 0 mail.subdomain1.example.com.
            IN MX 10 mail.subdomain2.example.com.

    Using the latter anti-looping algorithm, the MTA must do a DNS lookup of
    the IP address(es) of mail.subdomain1.example.com to verify that a
    delivery attempt to mail.subdomain1.example.com would not connect back
    to the local host. If the MTA is unable to resolve the IP address(es)
    of mail.subdomain1.example.com, it must not attempt to deliver the
    message to mail.subdomain2.example.com because this could result in a
    mail loop.

    Disallowing MX RRs from pointing to CNAMEs and only using the official
    host name means that the MTA can just do a simple string comparision to
    prevent a loop.

    > RFC2821 obsoletes 974, but says substantially the same in regards to
    > CNAME's. So, by the RFC's it's allowed.

    RFC 2821 modifies this part of RFC 974:

       If it determines that it should relay the message without rewriting
       the address, it MUST sort the MX records to determine candidates for
       delivery. The records are first ordered by preference, with the
       lowest-numbered records being most preferred. The relay host MUST
       then inspect the list for any of the names or addresses by which it
       might be known in mail transactions. If a matching record is found,
       all records at that preference level and higher-numbered ones MUST be
       discarded from consideration. If there are no records left at that
       point, it is an error condition, and the message MUST be returned as
       undeliverable. If records do remain, they SHOULD be tried, best
       preference first, as described above.

    Which seems to say that the MTA must do IP address lookups on the names
    specified by the MX records ...

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Matthew D. Fuller: "Re: bind timeouts"

    Relevant Pages

    • Re: Sendmail Question
      ... if you did not define your ISP's SMTP server as your SMART_HOST ... mail host to be able to send him a mail. ... What's partly right in your opinion is the idea, that the receiving MTA ... either authenticate against that ISP's mail host to be able to relay ...
      (Fedora)
    • Re: How to use only submit.cf on a sendmail SMTP client
      ... The "msp" feature only applies to mail addressed to the host itself, ... In many cases (at least when the MTA is sendmail) it would make more ... The standard rewrite rules will make sure all addresses are ...
      (comp.mail.sendmail)
    • Re: Newbie to Exchange needs MX record info
      ... This is accomplished by designating a host as a mail handler (MX is ... It is a best practice to designate a MX record that specifies a host by it's ... During a SMTP transaction, the MTA ...
      (microsoft.public.exchange.setup)
    • Re: Newbie to Exchange needs MX record info
      ... This is accomplished by designating a host as a mail handler (MX is ... During a SMTP transaction, the MTA ... To have the sending and receiving ...
      (microsoft.public.exchange.setup)
    • =?iso-8859-1?q?=A33,000_budget_to_buy_4_x_4?=
      ... I'm moving to a pretty remote part of the countryside and need a 4 x 4 ... Able to pull a trailer with a 1000kg load (1,000 litre water ... Either manual or auto - I don't have a preference, ...
      (uk.rec.cars.4x4)
    Loading