Bug #: 6654
Summary: Make sa-update and its infrastructure usable over IPv6
Version: SVN Trunk (Latest Devel Version)
AssignedTo: dev@... ReportedBy: Mark.Martinec@... Classification: Unclassified
Collected some posts from the 'private' SA ML on the topic:
Using sa-update on an IPv6-only host is currectly a nightmare, none of the
mirrors nor the spamassassin.apache.org base site are accessible over inet6.
One has to fetch rules on some other host and transfer them over.
Other than that the SpamAssassin is perfectly usable on such host
(except Razor, which does not work).
Any new mirrors added should be accessible over both protocols IMO,
and so should the spamassassin.apache.org if kept as a sa-update
I've started teh process to have a block of IPv6 allocated to me and
will start seeing if I can get it working, etc. Assume we'll just
publish an A record and an AAAA record for sa-update.pccc.com and then
open a bug to get sa-update to use IPv6 if available?
Great, thank you! - that is the most straightforward route.
Btw, I just realized that the ClamAV project has
28 mirrors on the IPv6: db.ipv6.clamav.net
and that freshclam can speak both protocols just fine.
> No IPv6 support for spamassassin.apache.org.
Which could be solved by moving this to use sa-update.pccc.com
if we had to once I have IPv6, correct?
I don't have a problem providing resources that ASF can't. When it's
duplicative, I try and push to ASF-ify things.
There are three steps in how sa-update gets its data:
- a DNS TXT query against a hard-coded spamassassin.apache.org
(channels query) to get the version number of current updates.
For this the spamassassin.apache.org DNS zone does not need to
offer IPv6 accessibility - on the same grounds that RBL servers
will likewise not commonly be available any time soon over IPv6,
so a host running SpamAssassin will willy-nilly need to use
a resolving/recursive DNS server on some nearby host capable
of IPv4, even if the host running SpamAssassin is IPv6-only.
- fetching a MIRRORED.BY file using HTTP from spamassassin.apache.org.
This request comes from a host running sa-update (unlike the DNS TXT
request which comes from a resolving/recursive DNS server), so
spamassassin.apache.org needs to be TCP-accessible over a protocol
family available to the sa-update host. For this we'll eventually
need to poke ASF infra I think.
- fetching rules from one of the mirror sites. So at least one
mirror site needs to be TCP-accessible over a protocol family
available to the sa-update host. That would be daryl.dostech.ca
and sa-update.pccc.com currently. So if the later would become
dual-protocol with both A and AAAA records, that would satisfy
both the IPv4-only as well as the IPv6-only clients.
There is one problem we'll still need to resolve ourselves:
the sa-update use LWP::UserAgent module, which is not yet
IPv6-aware, despite years of people poking its maintainers.
There are some possible workarounds which we'll need to address
eventually, but there is no immediate rush.
As it stands now, the LWP uses IO::Socket::INET, which only
cares about IPv4 and A records, so nothing will change for
existing users running SA 3.3.* even if sa-update.pccc.com
acquires an AAAA record in addition to the A record.
The only beneficiaries in the immediate future would be
the early adopters (SVN/trunk/3.4.0) of sa-update if/when
we make it capable of fetching HTTP over both protocols.
Even then the decision of using one family over the other
can best be lest for the underlying layer to decide.
We'll cross that bridge when we come to it.
Thanks Mark. Great recap and it all gels with my fuzzy memory. Should
we open a ticket for this and cut and paste your recap below? I think
we need to target this for 3.4.0 and if I can get an IPv6 system, we
could try and make this a goal of a major release.
> A ticket in the SA bugzilla? Yes, that would be the right thing to do.
Make it a 3.4 blocker.