On 12/14/2012 7:10 AM, Mark Martinec wrote:
I think we will focus on 3.4 released with the fix.
People using 3.3 can apply the patch, yes?
This is certainly an option. Timeliness of this depends much
on the responsiveness of popular Unix/Linux distributions,
I'd expect that a majority of end-users are reluctant
to apply local patches if they get their software prepackaged
through some distro.
Comment 3 on bug 6872? The adding @ and space?
I think it's a horrible kludge, sorry.
It looks horrible, but comes from the RFC 1035 section 5.1
syntax specs for a zone file syntax:
<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ". Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash).
It is very unfortunate that the Net::DNS chose the syntax of a zone
file for its API (which need not be constrained to 7-bit ascii text).
It is also very unfortunate that SpamAssassin in many places
ignores this fact and assumes an 8-bit clean API to Net::DNS.
By a lucky coincidence, in most cases (plain text labels and data)
both forms happen to be the same (apart from double quotes).
The RFC 1035 section 5.1 text makes double quotes optional
around a simple text with no spaces, and this is the reason
the Net::DNS chose now to drop this optional double quotes
unless the string contains funny characters.
So the bug lies on our wrong assumption that Net::DNS API
provides access to data with no zone file encodings.
Adding a space or an @ makes Net::DNS choose the double-quote
form, which is what sa-update 3.3 unfortunately expects.
So yes, it is a kludge, but not a freevolous hack, but
something that comes directly from RFC 1035.
Thanks. This is really well researched and defends Net::DNS's choice to
make this change quite well.
From SA's perspective, I believe we should follow the RFC and release
versions that work with the newer Net::DNS. This means if we have to
drop support for older Net::DNS, I would support that as well.
Right now, as I understand it:
A) you've already patched sa-update in trunk to handle this and it works
with older and newer Net::DNS versions
B) Rather than change our backend automated DNS to add the kludgey
entries and hope they work and aren't destroyed in the DNS ecosystem, if
the community demand exists, we push a new 3.3 release with the same patch.
Overall, 3.4 has been far too long in the making and contains a
wonderful number of bug fixes. Running 3.3 at this point is just not
what I would recommend to anyone.
Regards,
KAM
