https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187
--- Comment #3 from Jonas Eckerman <[email protected]> 2009-09-03 08:13:38 PST --- (In reply to comment #2) >> The ping method of Mail::SpamAssassin::Client send an extra $EOL >> after the $EOL that terminates the PING command. > That seems consistent with other command (request header + empty body). It doesn't seem consistent with how spamd acts on commands. Neither SKIP nor PING waits for a body before replying and disconnecting. And just before the handling of the commands that spamd does get a body from, there is this comment: "If we get the PROCESS command, the client is going to send a message that we need to filter." To me it seems that spamd is written with the idea that only the commands which needs a body should have one. If the protocol specifies that at PING consists of a header and a body, then spamd should not send a PONG until the body has been sent (effectively waiting for the second $EOL before answering). If spamd did this, it would solve the problem while beeing consistent with a request format of header+body. (Additionally, it would make it possible to send a PING with a very big payload when diagnosing problems that might be network related). Of course, making spamd wait for the (normally empty) body might break existing third party clients if they send a PING without a body. In any case, I think it should be decided wether all commands must have a body or not, and that spamd and Mail::SpamAssassin::Client should be in agreement about it. Currently spamd acts as if a PING should not have a body, while Mail::SpamAssassin::Client acts as if it should have one. How does spamc act? Does it agree with spamd or Mail::SpamAssassin::Client? > Seems to me the proper solution would be to let the client side terminate > the connection (for all commands), Does the *protocol* contain obstacles to using multiple commands in one connection? If not, the proper solution in the long run might be for the server to keep the connection open until the client sends a QUIT command. This would also make it possible to follow a PING with a PROCESS; CHECK or TELL or other command without having to create a new connection. The quick fix to make things work until a proper solution has been implemented could still be to make spamd and Mail::SpamAssassin::Client follow the same protocol specs. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
