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
