Re: IPv6 recap
Alessandro Vesely <[email protected]>
| Newsgroups | gmane.mail.imap.courier.general |
|---|---|
| Message-ID | <[email protected]> |
On Sat 06/Apr/2024 19:07:45 +0200 Sam Varshavchik wrote: > Alessandro Vesely writes: > >> It happened again. Yesterday I sent 19 messages to Comcast, 18 were >> successfully delivered, one failed after trying to use IPv6. I'd guess >> Comcast's server answers after about 4.9 secs, so that when the first query >> randomly fails Courier tries the second address. >> >> I tried to look back at the rfc1035 code to recall how it works. It seems >> that if A and AAAA are queried simultaneously, the query fails unless a >> response is received for both. In that case, the choice between IPv4 and >> IPv6 would be deterministic, wouldn't it? Should I try a patch? > > The call to rfc1035_mxlist_create_x from do_esmtp_connect_to passes in the > RFC1035_MX_IGNORESOFTERR flag. > > A failure in rfc1035_resolve_cname() is deemed RFC1035_MX_SOFTERR; but if at > least one A or AAAA record was included in the MX response, or if at least one > additional A or AAAA lookup succeeded, then the lookup is deemed successful, so > it should be doing this already. When I dig comcast.net mx I get no additional section, so harvest_records() must query each address in turn, starting from A. Are you saying that all A queries have gone through all three timeouts before resorting to AAAA? > The "after trying to use IPv6" is a red herring. You're seeing this because the > IPv6 address was simply the last one that was tried. All A and AAAA addresses > were tried, and they were offline. They have 2 MXes at priority 5 and 6 at priority 50. Of course, after a connection succeeds and replies 554 no more retries are possible... Best Ale -- _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users