-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Arnt,
On 31 Mar 2008 at 11:32, Arnt Gulbrandsen <arnt(_at_)oryx(_dot_)com> said:
Adding IPv6 support to internet mail forces a question: If there isn't an
MX RR for a given domain, does the SMTP client fall back to looking up an A
RR, A or AAAA, or A and AAAA? We have to choose, and all of them represent
a change.
Why? As John has pointed out, all 2821bis is saying you have to do as an
Internet mailer is to imagine that there's an MX record of preference 0
with the target of the recipient domain for that same recipient domain
when there isn't one already. That's how it's always been, and all this
bother about whether or not it's appropriate to deny mail to recipients
without an MX record in the IPv6 case is apparently appealing only to
people who want it that way for purely anti-abuse motives (not, FWIW, that
I'm saying they're inherently a bad idea - but they have no place on a
draft-standard-to-be, for which they are entirely unmoving reasons for
breaking this longstanding rule). OTOH, the wording of the spec lends
itself to this sort of non-semantic thinking, so perhaps a slight touch to
emphasise the synthesis of the MX record more clearly rather than as a
fallback to address records (but to be fair to John, he's made it as
generic as he possibly can) might help.
In reality, for me at least, it's obvious what has to happen: you
synthesise the MX record, then act on it according to your supported
address families as you would with any other non-synthesised record -
connect to whatever you can. If you're feeling desperate, send the mail
to someone else to relay it into the other network for you (this wasn't
mentioned in the spec either, I find).
I can accept that, from an implementation point of view, there may well be
subtle differences between uses of the synthesised MX record and the real
thing. For instance, you can't rely on Additional Section replies in DNS
to include all relevant information when an MX query is made. You have to
make the queries for supported address types yourself. I'm not sure you
can rely on the Additional section anyway (DNS gurus, please advise).
Also, there's the matter of how one actually processes the MX target; for
standard resolver routines in system libraries that support IPv6, though,
you'll end up with results to suit your stack(s), and most MTAs are doing
that anyway. For instance, gethostbyname(3) or getaddrinfo(3), which,
with a little bit of coaxing, generally do the right thing or at least do
it well enough. This is clean, consistent with other protocols and
sensible and, unless preference is given to a particular address family, I
think giving multiple families of address for a single dual-stacked
machine in the DNS for a single hostname is preferable to using individual
MX records. You can then depend on the right thing happening even when MX
is absent, no matter with IPv4, IPv6 or both.
Someone please tell me I missed something so I can put the coffee machine
back on and get back into my terrible habbit. :-)
Cheers,
Sabahattin
- --
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/
-----BEGIN PGP SIGNATURE-----
Version: PGP 8
Comment: QDPGP - http://community.wow.net/grt/qdpgp.html
iQA/AwUBR/JWkSNEOmEWtR2TEQLlnwCeJFLDwHbUeVGOm/LQx8eRB3+H1Z0Anj6s
mf8jQCJbM4Tt+goQATOKNE28
=sG1K
-----END PGP SIGNATURE-----