From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <81c3dbeae5484ab21859acd28a26c725@quanstro.net> From: erik quanstrom Date: Sun, 24 Aug 2008 08:32:11 -0400 To: arisawa@ar.aichi-u.ac.jp, 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dns failure in smtp Topicbox-Message-UUID: 0675f5ca-ead4-11e9-9d60-3106f5b1d025 assuming that my mxdial.c is up-to-date (sources is failing in a wierd way), that's not the full story. mxdial calls callmx. callmx has this code static int callmx(DS *ds, char *dest, char *domain) { int fd, i, nmx; char addr[Maxstring]; /* get a list of mx entries */ nmx = mxlookup(ds, domain); if(nmx < 0){ /* dns isn't working, don't just dial */ return -1; } if(nmx == 0){ if(debug) fprint(2, "mxlookup returns nothing\n"); return dial(dest, 0, 0, 0); } [...] so if there is no mx record, the normal address is dialed. (in this case the check against a returned address of 127.0.0.1 is skipped. i would think if this check is necessary for mx records, it is also necessary for a records. but i can't see why plan 9 cares. if you do have a loopback, it's likely for venti.) in any event that's not what's happening. using upas/spf (it's on sources & submitted) we see that that two mx records are found rfcmail.nanosouffle.net and sounine.nanosouffle.net: ; upas/spf -d nanosouffle.net 75.58.233.41 dnsquery(/net, nanosouffle.net, txt) -> dom nanosouffle.net txt v=spf1 mx -all dnsquery(/net, nanosouffle.net, mx) -> dom nanosouffle.net pref 1 mx rfcmail.nanosouffle.net dom nanosouffle.net pref 10 mx sounine.nanosouffle.net dnsquery(/net, rfcmail.nanosouffle.net, any) -> dom rfcmail.nanosouffle.net ip 75.58.233.40 dnsquery(/net, sounine.nanosouffle.net, any) -> dom sounine.nanosouffle.net ip 75.58.233.41 i would guess that dns cs may be or have been confused. to eliminate the possibility of continuing confusion, have you tried telnet /net.alt/tcp!sounine.nanosouffle.net!smtp - erik