> 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. Mark
