Hector Santos <[EMAIL PROTECTED]> writes: > It appears to me that Microsoft wishes virtualize IPv6 (and IPv4) from > an application viewpoint. i.e, separate the communication layer.
Up-front disclaimer: I am purely and exclusively a UNIX developer and wouldn't know what to do with a Windows system without a fair bit of study. The last time I used Windows for long enough to understand what it was doing was Windows 3.1. So I can only really answer from the perspective of how the APIs are implemented on UNIX or Linux and what's in RFC 3493. > When its all said and done, an SMTP client would never need to know > about MX, A or AAAA records or any other record current or future for > that matter. > > If you want to send mail or even just check for SMTP hosting, all you need > is two variables possible three, and the getaddrinfo() function call. > > - host name > - service port > - flags for IPv4 only, IPv6 or both (passive mode). Passive mode is used by servers that want to listen to an interfaces, and it's orthogonal to IPv4 or IPv6. You can have any combination of AI_PASSIVE and family hints; one doesn't imply the other. > If done correctly, ideally the SMTP client will never need to worry > explicit MX or implicit MX records. > > Am I on track? Well, at least with the getaddrinfo implementation on UNIX, this doesn't work for SMTP because getaddrinfo doesn't handle service-specific DNS resolution. I suppose in theory it *could* given that you tell it what service you want to use, but that's just not how the code works or how the APIs are specified (and hence probably isn't how the code can ever work in the absence of a new hint flag). The service (either specified as a number or as a symbolic name) only does service resolution and fills in the port element of the structure. It doesn't do SRV or MX lookups or anything of the type. So, to connect to the mail server for a given address, the IPv6-enabled client still has to follow the same logic as an existing IPv4-only client, namely try to resolve the MX record, use the hostname in the lowest-priority (bleh) MX record if one is found (and possibly iterate if the first one fails), and fall back to trying to connect directly to the RHS if that fails. The MX lookup isn't done for you in getaddrinfo. > If so, my next question has to do with what are the requirements to make > it work. > > More specifically, right now our smtp code is using level 1 socket > commands. We have our own DNS resolver. > > Would a first step be to port over to level 2, and removing or rather > replace our GetDNSRecord() function with getaddrinfo() but use a IPv4 > only flag? getaddrinfo, at least in the UNIX world, is a replacement for gethostbyname and doesn't do anything more fancy DNS-wise than gethostbyname does other than support AAAA records. It still doesn't do an MX lookup and you still have to do that separately, usually using a more sophisticated DNS API that allows you to look for arbitrary record types. > Or should I go ahead and make it passive, and we will still not have > problems if the customer has an OS with no IPv6 stacks installed? AI_PASSIVE is only for servers and is unrelated to this problem. I think the flag that you're looking for is AI_ADDRCONFIG, which tells getaddrinfo to not return addresses using protocols for which there is no configured local interface. (So if you don't have an IPv4 interface, you won't get IPv4 addresses, and if you don't have an IPv6 interface, you won't get IPv6 addresses.) > PS: if you prefer to go offlist, I wouldn't mind that. :-) We probably should for further discussion, as I think we're moving farther afield from the purpose of the list. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
