John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
--On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:
The "update" of RFC2821 is making a _significant_
architectural change to SMTP by explicitly stating AAAA
records are within a list of SMTP server discovery records.
Well, to be very precise, 2821 is ambiguous on the subject.
Agreed.
Some people have read (and implemented) it as if the text said
"address records", implying a default MX for the AAAA case as
well as the A one. Others have read it more narrowly and only
supporting the default for A RRs. To the extent to which
2821bis is expected to eliminate ambiguities that were present
in 2821, it had to say something on this subject.
It might, however, be best to simply document the ambiguity.
I suspect that implementation reports would show some implementations
querying for both AAAA and A RRs, while others query only for A RRs.
I am not convinced that 2821bis _should_ try to resolve this.
If it says "address records" (as the current text does),
Actually, it says "address RR" (if I understand what text we're
discussing). I believe we're discussing Section 5.1 of
http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-09.txt
where it says
"
" The lookup first attempts to locate an MX record associated with the
" name. If a CNAME record is found instead, the resulting name is
" processed as if it were the initial name. If no MX records are
" found, but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA
" RR, or their successors) is found, the address RR is treated as if it
" was associated with an implicit MX RR, with a preference of 0,
" pointing to that host.
(Please correct me if I misunderstand what text we're discussing.)
you (and perhaps Mark and others) dislike the consequences and
claim "significant architectural change". If it is changed to
explicitly indicate that only A RRs can be used to imply an
MX record, then I assume that those who read 2821 the other way
and are now supporting AAAA records to generate an implied MX
would claim "significant architectural change".
Indeed, that seems likely (though not demonstrated).
But regardeless, we're on shaky ground if we try to force either
kind of implementation to change. May I suggest a different starting
point:
I think there's very strong consensus that the presence of an
MX RR demonstrates the intention to receive email addressed to the
domain in question. I don't think there's any consensus that the
presence of an AAAA or A RR demonstrates such an intent.
There is, however, considerable history that the presence of an
address RR _in_combination_with_ a process listening on port 25
of the IP address in question indicates a willingness to receive
email for a domain identical to the domain of that address RR.
Whether or not we have any consensus that this historical
practice should be deprecated (I would vote YES!), rfc2821-bis
is not, IMHO, the right place to deprecate it.
(If I may digress a bit, let me explain that this implied-MX rule
is a real pain to me as an ISP, in that we maintain a SMTP server
on the same IP address as a number of virtual web services; and
the implied-MX rule brings us rather significant spam traffic that
I'd _much_ rather be sending to a different IP address than the web-
server for the domain in question.)
Getting back to my point, what would be wrong with changing this
language in Section 5.1 to document the ambiguity instead of trying
(probably unsuccessfully) to prescibe a single way of resolving it?
Thus, I suggest:
" ...
" If no MX records are
" found, but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA
" RR, or their successors) is found, the address RR
" is treated as if it
^^
s/is/MAY be/
" was associated with an implicit MX RR, with a preference of 0,
" pointing to that host.
I think that is a much better description of actual practice.
Given that, the document can't win. The choices are between
ambiguity (which I hope is the lowest preference for all of us)
and picking an option that some people won't like.
I do not share John Klensin's distaste for ambiguity in evolving
standards. Were we starting afresh, I would put a lot of effort into
clarity, but when progressing a decades-old animal like SMTP to
Draft Standard, I think compatibility rates higher (and that we're
only fooling ourselves to claim that all existing implementations
will be changed to reflect what we write).
Thus, I believe we'll be better served leaving the choice of
whether to infer a non-existent MX record to implementors and
administrators. As currently practiced, this implied-MX rule leads
to temporary errors (not reported for many hours) on typos, instead
of immediate permanent errors. Giving the immediate error, IMHO,
should be an option available to administrators.
Even without the anti-spam argument that you raise, I think
there are mail performance and DNS reasons (one cited by Mark)
for declaring the utility of implicit MX records, even those
built on A RRs, to be at an end.
I quite agree. (But I don't think 2821-bis can go there.)
... I'd recommend the BCP path I comments on in an earlier note.
To tell truth, I dislike writing I-Ds. But I'd be willing to
help in the writing of such a document. Any other volunteers?
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf