Re: host or alias? - TCP-IP

This is a discussion on Re: host or alias? - TCP-IP ; KDGS> MX records must point to a mail server host record, never an alias. False. Read John Navas' analysis at the end of section 6.5 of the "comp.protocols.tcp-ip.domains" FAQ document (ignoring what precedes it, which John Navas' analysis demonstrates to ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: host or alias?

  1. Re: host or alias?

    KDGS> MX records must point to a mail server host record, never an alias.

    False. Read John Navas' analysis at the end of section 6.5 of the
    "comp.protocols.tcp-ip.domains" FAQ document (ignoring what precedes
    it, which John Navas' analysis demonstrates to be wrong and was
    intended to rebut).




  2. Re: host or alias?

    Jonathan de Boyne Pollard wrote:
    > KDGS> MX records must point to a mail server host record, never an alias.

    True.

    See rfc2181 section 10.3


    In addition it makes no sense to use an alias as RHS in an MX,
    you better use the "real name" to reduce the number of lookups.



    > False. Read John Navas' analysis at the end of section 6.5 of the
    > "comp.protocols.tcp-ip.domains" FAQ document (ignoring what precedes
    > it, which John Navas' analysis demonstrates to be wrong and was
    > intended to rebut).


    >
    >


    --
    Peter Håkanson
    IPSec Sverige ( At Gothenburg Riverside )
    Sorry about my e-mail address, but i'm trying to keep spam out,
    remove "icke-reklam" if you feel for mailing me. Thanx.

  3. Re: host or alias?

    Give the person a break.
    They said
    "must point to a mail server host record"
    which, taking this to mean an A RR, is correct.
    This is even noted in the FAQ
    http://intac.com./~cdp/cptd-faq/section6.html#MXCNAMEA
    you point out, where it does correctly refer to the RFCs saying
    "The letter of the law is that an MX record should point to an A record. "

    The poster then appears to fall into the all-to-common
    trap of referring to a CNAME RR as an "alias"
    Their intent however seems both discernable and correct.

    --
    Roger
    "Jonathan de Boyne Pollard" wrote in message
    news:40A6F85E.FAE946B5@Tesco.NET...
    > KDGS> MX records must point to a mail server host record, never an alias.
    >
    > False. Read John Navas' analysis at the end of section 6.5 of the
    > "comp.protocols.tcp-ip.domains" FAQ document (ignoring what precedes
    > it, which John Navas' analysis demonstrates to be wrong and was
    > intended to rebut).
    >
    >
    >




  4. Re: host or alias?

    JdeBP> False. Read John Navas' analysis at the end of section 6.5
    JdeBP> of the "comp.protocols.tcp-ip.domains" FAQ document (ignoring
    JdeBP> what precedes it, which John Navas' analysis demonstrates to
    JdeBP> be wrong and was intended to rebut).
    JdeBP>
    JdeBP>
    JdeBP>

    PH> See rfc2181 section 10.3

    Once again, I refer you to John Navas' analysis in the FAQ document
    for this newsgroup, which discusses RFC 2181 section 10.3.

  5. Re: host or alias?

    Jonathan de Boyne Pollard wrote:

    > KDGS> MX records must point to a mail server host record, never an alias.
    >
    > False. Read John Navas' analysis at the end of section 6.5 of the
    > "comp.protocols.tcp-ip.domains" FAQ document (ignoring what precedes
    > it, which John Navas' analysis demonstrates to be wrong and was
    > intended to rebut).
    >
    >
    >


    Hmm ...

    Are you sure? RFC 974 states ("Issuing a Query"):

    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 seems to clearly indicate that MX records can point to CNAME records.

    I'd say that part of RFC 974 is talking about a situation like

    a.example.com. IN CNAME b.example.com.
    b.example.com. IN MX 0 c.example.com.
    c.example.com. IN A ...

    where the target email address is some.name@a.example.com,
    so REMOTE is a.example.com. The next paragraph of 974 somewhat
    confuses the issue, however, by mentioning "aliases" plural:

    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.

    Later on it comments

    Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
    a alias and the alias is listed in the MX records for REMOTE. (E.g.
    REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
    can be avoided if aliases are never used in the data section of MX
    RRs.

    So it cautions against it, but doesn't prohibit it.

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

  6. Re: host or alias?

    Ronan Flood wrote:

    > Jonathan de Boyne Pollard wrote:


    >>KDGS> MX records must point to a mail server host record, never an alias.


    (snip)

    > Later on it comments
    >
    > Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
    > a alias and the alias is listed in the MX records for REMOTE. (E.g.
    > REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
    > can be avoided if aliases are never used in the data section of MX
    > RRs.
    >
    > So it cautions against it, but doesn't prohibit it.


    It is my understanding that the algorithm only breaks if other
    than the first (lowest numbered) MX points to a CNAME.

    As far as I know, though, newer versions of NAMED will refuse
    to load such zone, so it doesn't matter much anymore.

    -- glen


  7. Re: host or alias?

    KDGS> MX records must point to a mail server host record, never an
    KDGS> alias.

    JdeBP> False. Read John Navas' analysis at the end of section 6.5
    JdeBP> of the "comp.protocols.tcp-ip.domains" FAQ document (ignoring
    JdeBP> what precedes it, which John Navas' analysis demonstrates to
    JdeBP> be wrong and was intended to rebut).
    JdeBP>
    JdeBP>
    JdeBP>

    RF> Hmm ...
    RF>
    RF> Are you sure? RFC 974 states ("Issuing a Query"):

    Am I sure of what ? That John Navas' analysis is in the FAQ document ?
    Yes, I've even given you the URL. That John Navas' analysis was
    intended to rebut the same assertion that Kevin made ? Yes, I've given
    you the URL for that, too.

    By the way: Your quoting is very unclear. You are mixing your own text
    with that of John Navas' analysis without making any division between
    the two at all. (In your last line above, you mixed the two together
    on one line, with no indication that the two were distinct.)

    RF> Later on [RFC 974] comments
    RF>
    RF> Note that the algorithm to delete irrelevant RRs breaks if
    RF> LOCAL has a alias and the alias is listed in the MX records
    RF> for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS
    RF> has a CNAME of LOCAL). This can be avoided if aliases are
    RF> never used in the data section of MX RRs.
    RF>
    RF> So it cautions against it, but doesn't prohibit it.

    This caution against using client-side aliases is now out of date,
    and has been out of date for almost three years now, when by common
    agreement the poor design decision that led to it was scrapped. SMTP
    Relay clients _now_ have the onus of knowing _all_ of "the names or
    addresses by which [the corresponding SMTP Relay server for the same
    system] might be known in mail transactions". This caution against
    using client-side aliases is now unnecessary.

    Of course, requiring that the administrator supply an explicit list
    of "all of my own IP addresses (that cannot be determined implicitly)"
    is how modern MTS softwares have worked (in one fashion or another)
    for some time.




  8. Re: host or alias?

    Jonathan de Boyne Pollard wrote:

    > JdeBP>
    >
    > RF> Hmm ...
    > RF>
    > RF> Are you sure? RFC 974 states ("Issuing a Query"):
    >
    > Am I sure of what ? That John Navas' analysis is in the FAQ document ?
    > Yes, I've even given you the URL. That John Navas' analysis was
    > intended to rebut the same assertion that Kevin made ? Yes, I've given
    > you the URL for that, too.


    That was part of the quote from the FAQ, not a question.

    > By the way: Your quoting is very unclear. You are mixing your own text
    > with that of John Navas' analysis without making any division between
    > the two at all. (In your last line above, you mixed the two together
    > on one line, with no indication that the two were distinct.)


    Perhaps just block-indenting the quote was unclear, sorry, but no I
    did not mix. "Are you sure?" etc is a direct quote from the section
    of the FAQ at the given URL attributed to John Navas.

    My point was, his interpretation of that paragraph of RFC 974 that it
    "seems to clearly indicate that MX records can point to CNAME records"
    is incorrect, as I read it. Which doesn't invalidate the rest of the
    analysis, but neither does it cast the best light on it.

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

+ Reply to Thread