--On Wednesday, August 24, 2016 09:00 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
On 8/24/2016 8:41 AM, John C Klensin wrote:
IMO, 5321 really should have said
is that am implementation utilizing, rather than refusing to
follow, such a MX -> CNAME -> <something> set of DNS entries
was not conforming to the standard and that anyone who did it
anyway needed to be extra careful to be sure they didn't get
tangled up in DNS entry loops (e.g., MX -> CNAME1 -> CNAME2
-> CNAME1) or other weirdnesses (e.g., MX1 -> CNAME1 -> MX2
-> ???) and to have good diagnostics if they did.
I've been noting some tendency for specs to try to make
substantive statements about behaviors that are out of scope.
A spec needs to be explicit about 'interesting' behaviors that
are out of scope. It might benefit from explaining why it is
out of scope. What it should /not/ do is make any substantive
statements or statements that imply substance -- such as
guidance to be careful (whatever that means) -- since that
effectively makes the topic /in/ scope.
Dave,
First, and most important, 5321 is not pretty old, at least in
Internet time. I was trying to report on what happened and why
that "awkward" text is the way it is and not to suggest that we
should have done anything different, even though my personal
preference at the time lay much closer to either the proposal
Ned mentioned or explicitly forbidding MXs whose DATA resolved
to something with a CNAME record. The disadvantage of the
latter was the there were a lot of examples of that being done
and working fine; the group was reluctant to try to
retroactively ban such a practice, and Ned's proposal was the
nearest reasonable compromise.
I have little option about evolving trends about such statements
and no opinion at all as to whether we would make the same
situation today. I am, however, fairly confident that, if we
made a serious effort to start work on a full Standard version
of 5431bis, we would reopen and rehash all of those arguments.
Again, that is another reason, perhaps the primary one, that I
haven't pushed that work -- so far, I have been convinced me
that the community has higher priorities.
As to the general principle, I agree with you, but note that, at
least since RFC 2821 replaced 974, SMTP really is the primary
spec for the MX RRTYPE, what is allowed in the DATA and how the
latter is interpreted. It seems to me to be is as reasonable
for such a document to specify what should be done if the stated
requirements are not met as to say "if you encounter that
situation, you are on your own" (we certainly make that type of
statement elsewhere) so, at least for that example, whether a
more explicit requirement is in or out of scope is a consensus
judgment call rather than any matter of broad principle about
the scope of the specification.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp