Re: IPv6 recap

On Sat 06/Apr/2024 21:25:11 +0200 Sam Varshavchik wrote:
> 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 was thinking to do the opposite; that is, call rfc1035_resolve_multiple() instead of rfc1035_resolve_cname(), from harvest_records().  (Indeed, there should be no CNAMEs there).

Here's the log lines of the other day:

Apr  5 05:14:52 north courierd: newmsg,id=00000000005DC0E7.00000000660F6CAC.0000158F: dns; localhost (localhost [127.0.0.1])
Apr  5 05:14:52 north courierd: started,id=00000000005DC0E7.00000000660F6CAC.0000158F,from=<[email protected]>,module=esmtp,host=comcast.net,addr=<[email protected]>
Apr  5 05:14:52 north courierd: started,id=00000000005DC0E7.00000000660F6CAC.0000158F,from=<[email protected]>,module=local,[email protected]!redacted!117!117!/export/mail/tana.it/ale!!,addr=<[email protected]>
Apr  5 05:14:52 north courierd: Waiting.  shutdown time=none, wakeup time=none, queuedelivering=2, inprogress=3
Apr  5 05:14:52 north courierlocal: id=00000000005DC0E7.00000000660F6CAC.0000158F,from=<[email protected]>,addr=<[email protected]>,size=2301,success: Message delivered.
Apr  5 05:14:52 north courierd: Waiting.  shutdown time=none, wakeup time=none, queuedelivering=2, inprogress=2
Apr  5 05:14:52 north courieresmtp: id=00000000005DC0E7.00000000660F6CAC.0000158F,from=<[email protected]>,addr=<[email protected]>: 554 resimta-c2p-559421.sys.comcast.net resimta-c2p-559421.sys.comcast.net 2a02:29e1:500:6c00::4 Comcast requires that all mail s...
Apr  5 05:14:52 north courieresmtp: id=00000000005DC0E7.00000000660F6CAC.0000158F,from=<[email protected]>,addr=<[email protected]>,status: failure

Note that another message was successfully delivered to the IPv4 address of a Comcast MX _three minutes earlier_, so all addresses were cached, and DNS responses were not delayed:

05-Apr-2024 05:14:50.213 queries: info: client @0x7f1920ac5168 ::1#41019 (comcast.net): view internal: query: comcast.net IN MX + (::1)
05-Apr-2024 05:14:50.317 queries: info: client @0x7f191cccef68 ::1#33358 (mx2.mxge.comcast.net): view internal: query: mx2.mxge.comcast.net IN AAAA + (::1)
05-Apr-2024 05:14:52.041 queries: info: client @0x7f191cccef68 ::1#40640 (mx2.mxge.comcast.net): view internal: query: mx2.mxge.comcast.net IN A + (::1)
05-Apr-2024 05:14:52.109 queries: info: client @0x7f191ec40168 ::1#45689 (comcast.net): view internal: query: comcast.net IN MX + (::1)
05-Apr-2024 05:14:52.109 queries: info: client @0x7f1910e19168 ::1#59736 (mx1.mxge.comcast.net): view internal: query: mx1.mxge.comcast.net IN AAAA + (::1)
05-Apr-2024 05:14:52.213 queries: info: client @0x7f191bebb168 ::1#47877 (mx1.mxge.comcast.net): view internal: query: mx1.mxge.comcast.net IN AAAA + (::1)
05-Apr-2024 05:14:52.289 queries: info: client @0x7f191e23c168 ::1#58987 (mx1.mxge.comcast.net): view internal: query: mx1.mxge.comcast.net IN A + (::1)
05-Apr-2024 05:14:52.289 queries: info: client @0x7f1920ac5168 ::1#55800 (mx1.mxge.comcast.net): view internal: query: mx1.mxge.comcast.net IN A + (::1)


Best
Ale
-- 






_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users