[Last-Call] Re: [Emailcore] Re: Re: Dnsdir last call review of draft-ietf-emailcore-rfc5321bis-31

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Steffen, Ted,

A comment below, but this issue has been referred to the EMAILCORE
mailing list. Please conduct further discussions there until the WG
decides what to do about it.

--On Friday, October 18, 2024 21:59 +0200 Steffen Nurpmeso
<steffen@xxxxxxxxxx> wrote:

> Ted Lemon wrote in
>  <CAPt1N1kDJ2qY_13zOv5jcsxYZcOK6Kxn4S3Cb-Zwd-bANCZ2sA@xxxxxxxxxxxxx
> m>:  |That's fair, but it seems like then it might be good to
> actually say that  |in the document. As an implementor I would be
> inclined to treat a CNAME  |here as invalid and ignore it based on
> the text as written.
> 
> Indeed i spoke nonsense and missed that this is about domain names
> that come from exactly MX records.  I thought CNAME in general and
> thought above 5321 2.3.5, which says
> 
>   For example, a domain may refer to an alias (label of a CNAME
>   RR) or the label of Mail eXchanger records to be used to deliver
>   mail instead of representing a host name.  See RFC 1035 [2] and
>   Section 5 of this specification.
>   ...
>   Only resolvable, fully-qualified domain names (FQDNs) are
>   permitted when domain names are used in SMTP.  In other words,
>   names that can be resolved to MX RRs or address (i.e., A or
>   AAAA) RRs (as discussed in Section 5) are permitted, as are
>   CNAME RRs whose targets can be resolved, in turn, to MX or
>   address RRs.  Local nicknames or unqualified names MUST NOT be
>   used.
> 
> which is "crystal clear".
> But then i do not understand why you struggle, since then, if it
> is exactly a domain name returned via a MX record, 5321 as well as
> the referenced 2181 are also very clear that in that case "never
> a CNAME RR" may result from looking it up.
> 
> So *i* am silent now and take back what i said, since i can
> understand the reasoning why an explicitly placed MX record shall
> not go over CNAME (again), .. (on the other hand relaxing this and
> suggesting "an overall loop limit" i could also understand, given
> how deeply nested for example SPF records and other such new
> standards explore the DNS).

I don't know if it the source of some of the confusion and/or
discussion, but it might be worth remembering that RFC 974 says:

* If one asks the DNS for an MX record and gets a CNAME, that is ok:
the query is just repeated "with the canonical domain name"

* The arguments to MX are the preference value and "the name of a
host".  That was widely interpreted as not allowing any name in that
field that would resolve to anything but an address record.

In addition, RFC 1123 requires (Section 5.2.2) that the domain name
in the MAIL or RCPT commands MUST either be a domain literal,
identify a host directly, or lead to MX record(s); it cannot be a
CNAME.

* Also from 1123:  Names that lead to MX records cannot be used in
HELO (5.2.5)

Several of those restrictions have been relaxed over the years but
the relationship between the original rules and the relaxed ones have
been (or at least were for many years) a source of confusion about
the behaviors that can be expected by systems that conforming to one
spec or another.

I suspect that some of the text in the current draft that now looks
convoluted (substantially none of which was written later than RFC
5321) may be due to that original text and efforts to relax the
rules.   I have no idea whether similar confusion is driving some of
the recent discussion, but would encourage people to think about it.  

Again, further discussion to emailcore@xxxxxxxx only, please -- I've
very concerned that, if new issues are raised on the Last Call list,
they may get lost in the back-and-forth about this one.

thanks,
    john

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux