Re: IPv6 recap

Sam Varshavchik <[email protected]> Sat, 06 Apr 2024 15:25:11 -0400
Newsgroups	gmane.mail.imap.courier.general
Message-ID	<[email protected]>
Alessandro Vesely writes:

> 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?

Yes, it'll do a query for all A or AAAA first, then a query for all of the  
other ones.

The selection to do A or AAAA depends on ESMTP_PREFER_IPV6_MX, and it's done  
in reverse order, since the returned linked list gets built up from the tail  
pointer. If ESMTP_REFER_IPV6_MX is set, the A records are queried first,  
then AAAA records. Each found record is added to the head of the linked list  
getting constructed, so AAAA records wind up being first.

I'm seeing possible behavior from my bind that might play into this. Even  
though the original MX query returns no records, if I manually do subsequent  
A and AAAA queries, followed by another MX query, then my bind returns some  
but not all of the cached A and AAAAs, as additional records in the MX  
response.

rfc1035 will not make additional queries for A and AAAA records if at least  
one of them is in the MX response, as a performance optimization. I can see  
how a luck of the draw ends up with only cached AAAA records getting  
returned. That's going to be a problem if you do not have IPv6 connectivity.

Looks like this performance optimization will need to be scrapped, and  
A/AAAA lookups are always needed.

I'm going with the following patch, that also simplifies a few things. The  
difference here is visible by running testmxlookup more than once, with and  
without it.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
signature.asc (application/pgp-signature, 228 B)