hi-

the subject expresses my uneducated hypothesis as to what might be causing a 
problem i seem to have encountered after upgrading to 3.4.2.

i have an additional channel defined [sought.rules.yerp.org], and updates of 
this channel seem to have broken upon updating to 3.4.2:

>sa-update -vvv --allowplugins --channelfile 
>/etc/spamassassin/sa-update-conf.d/channels.txt --gpgkeyfile 
>/etc/spamassassin/sa-update-conf.d/sa-update-keys.txt --gpghomedir 
>/var/lib/spamassassin/sa-update-keys
DNS TXT query: 2.4.3.sought.rules.yerp.org -> 3402014020421
Update available for channel sought.rules.yerp.org: -1 -> 3402014020421
DNS A query rules.yerp.org.s3.amazonaws.com/rules/stage failed: NXDOMAIN
DNS AAAA query rules.yerp.org.s3.amazonaws.com/rules/stage failed: NXDOMAIN
channel: could not find working mirror, channel failed
Update failed, exiting with code 4

we can see it find the txt record for mirrors:

>dig mirrors.sought.rules.yerp.org txt +short
"http://yerp.org/rules/MIRRORED.BY";

and successfully retrieves and reads the MIRRORED.BY file, which contains:

>curl 'http://yerp.org/rules/MIRRORED.BY'
http://rules.yerp.org.s3.amazonaws.com/rules/stage/

but then it seems to behave unexpectedly, and appears to not properly parse the 
hostname from within the url, instead attempting to lookup the entire url as 
though it were a hostname ["rules.yerp.org.s3.amazonaws.com/rules/stage"], 
which of course is invalid and doesn't exist.

query logs from the recursive nameserver confirm this:

09-Jan-2019 23:49:04.421 queries: info: client 198.19.20.50#57187 
(rules.yerp.org.s3.amazonaws.com/rules/stage): view internal: query: 
rules.yerp.org.s3.amazonaws.com/rules/stage IN A + (198.19.20.50)
09-Jan-2019 23:49:04.422 queries: info: client 198.19.20.50#39320 
(rules.yerp.org.s3.amazonaws.com/rules/stage): view internal: query: 
rules.yerp.org.s3.amazonaws.com/rules/stage IN AAAA + (198.19.20.50)

if we follow the url correctly, we can see there is a functional mirror:

>curl -LO 
>'http://rules.yerp.org.s3.amazonaws.com/rules/stage/3402014020421.tar.gz'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10462  100 10462    0     0  1712k      0 --:--:-- --:--:-- --:--:-- 2043k

>l
total 12K
-rw-r--r-- 1 root root 11K Jan  9 23:51 3402014020421.tar.gz

so this channel would be working, were the url parsed properly.

is my hypothesis wrong?  is this to be expected?  if not, how can i figure out 
why this is happening?

thanks!

Reply via email to