Thanks Alan -- I've fixed the 2nd one, but the 1st one (appending the newline)
I'm going to leave as-is.  Basically, if I change that, I'll be changing the
protocol -- which really should require a bump in the version.  I don't want
to do that if I can avoid it, again.  And I don't
think anyone really finds it particularly hard to parse without a trailing
newline anyway, it just looks a little ugly.

It's not a change of protocol -- spamd always used to end the SYMBOLS with a
newline (all other output does end with a newline still, I think), I assumed
that the lack of a newline in this new spamd was simply an erroneous oversight.

It's probably OK in my program (I haven't checked without the newline yet),
however it would be good to be consistant!

Subject: Re: [SAdev]  spamd response headers 


> It's not a change of protocol -- spamd always used to end the SYMBOLS with a
> newline (all other output does end with a newline still, I think), I assumed
> that the lack of a newline in this new spamd was simply an erroneous oversigh
> t.

did it?  bugger. ;)   Must verify that when I get a chance, may have to
refix that...

--j.

It seems this has still not been corrected in the latest versions, could you
please apply the fix to the CVS version? spamd always used to end that line with
a "\r\n", and this omission has caused a few incompatibilities when I brought
some new spamd servers online recently. Thanks.

IIRC -- I can't find the bug now -- we decided to keep compat with 2.5x
and *not* add an extra newline, since there was no point flip-flopping
between 2.4x and 2.5x behaviour.
(and it's trivial to decode either way once you know about it).
the doco was updated to note:

> SYMBOLS command returns the same as CHECK, followed by a line listing all the
> rule names, separated by commas.  Note that some versions of the protocol
> terminate this line with "\r\n", and some do not, due to an oversight; so
> clients should be flexible on this point.

since the change was made consciously, I'm reclosing the ticket.

Sorry, I missed that change in the documentation. Anyway, I could sit here and
churn out a long list of why it should be reverted to the original behaviour,
but I won't :)  Instead, this seems to be a good compromise:

        elsif($method eq "SYMBOLS") {
           $msg_resp = $status->get_names_of_tests_hit;
+                 $msg_resp .= "\r\n" if ($version < 1.3);
         }

Would you be willing to consider that? The omission of "\r\n" coincided with the
change in spamd protocol from 1.2 to 1.3, so this would ensure maximum
compatibility.

looking at the Changes log, you're dead right -- the change was made just before
the protocol version number got bumped, and both changes occured within one
release.  So that's a good idea.

Created attachment 1246 [details]
fix as described

Here it is as a patch.

Created attachment 1247 [details]
additional cleanup of doco

Add more details on where clients should be flexible in parsing
the results from these verbs.

bumping pri

+1

+1 okay

applied