-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Arnt,
On 31 Mar 2008 at 11:32, Arnt Gulbrandsen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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-----
