You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/08/31 18:54:33 UTC

[Bug 6187] New: Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

           Summary: Mail::SpamAssasin::Client ping may erronesously result
                    in broken pipe.
           Product: Spamassassin
           Version: 3.2.5
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: Libraries
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: jonas@frukt.org


The ping method of Mail::SpamAssassin::Client send an extra $EOL after the $EOL
that terminates the PING command.

spamd breaks the connection after answering PONG to the PING.

If spamd has answered and hung up before the extra $EOL is sent, the ping
method gets a broken pipe even though tyhe connection is fine and it got a
PONG.

For any client using Mail::SpamAssassin::Client and prudently doing a ping
before deciding that the connection is usable, this is obviously a problem.

/Jonas

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

Mark Martinec <Ma...@ijs.si> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Mark Martinec <Ma...@ijs.si> 2009-12-07 04:10:33 UTC ---
Closing.
Please re-open if any concern pops up.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187





--- Comment #3 from Jonas Eckerman <jo...@frukt.org>  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.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

--- Comment #9 from Mark Martinec <Ma...@ijs.si> 2009-11-27 04:53:01 UTC ---
  Bug 6187 - Mail::SpamAssasin::Client ping may erronesously
  result in broken pipe. Bumps spamc protocol vesion to 1.5.
Sending build/announcements/3.3.0-beta1.txt
Sending lib/Mail/SpamAssassin/Client.pm
Sending spamc/libspamc.c
Sending spamd/PROTOCOL
Sending spamd/spamd.raw
Committed revision 884863.


Please review the change carefully (svn diff -c884863).

I tested it with old and new spamc, as well as with old and
new Client.pm, but more eyes can see better...

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187





--- Comment #6 from Justin Mason <jm...@jmason.org>  2009-09-03 13:30:47 PST ---
hmm, actually, if we need to break compatibility, now's the time to do it --
just before 3.3.0.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187


Justin Mason <jm...@jmason.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P2
            Version|3.2.5                       |3.3.0
   Target Milestone|Undefined                   |3.3.0




-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

Justin Mason <jm...@jmason.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1

--- Comment #7 from Justin Mason <jm...@jmason.org> 2009-11-17 07:43:17 UTC ---
fix before beta.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187





--- Comment #4 from Mark Martinec <Ma...@ijs.si>  2009-09-03 09:56:22 PST ---
In absence of a protocol specification, I'll leave this PR
to them who devised it. Once the protocol is known, we can
then decide where the implementation bug lies.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

--- Comment #8 from Warren Togami <wt...@redhat.com> 2009-11-21 23:04:02 UTC ---
This is the only remaining bug with P1 blocking 3.3.0 beta.  What will it take
to move forward?

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187





--- Comment #2 from Mark Martinec <Ma...@ijs.si>  2009-09-03 05:29:43 PST ---
> 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).

> spamd breaks the connection after answering PONG to the PING.

Seems consistent with other commands.

> If spamd has answered and hung up before the extra $EOL is sent, the ping
> method gets a broken pipe even though tyhe connection is fine and it got a
> PONG.
> 
> For any client using Mail::SpamAssassin::Client and prudently doing a ping
> before deciding that the connection is usable, this is obviously a problem.

Right, that is a problem. Just don't know what the proper solution is
(your proposed patch doesn't seem to be the right solution).

I wonder if this handshake issue can be a problem with other commands too.

Seems to me the proper solution would be to let the client side terminate
the connection (for all commands), unless there is a serious breakage in
the protocol (garbage or timeout) so that server may hang up on a
problem client.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markt@apache.org

--- Comment #9 from Mark Thomas <ma...@apache.org> 2009-11-30 13:34:08 UTC ---
Restoring comment originally made by Mark Martinec

Bug 6187 - Mail::SpamAssasin::Client ping may erronesously result in broken
pipe. Bumps spamc protocol vesion to 1.5. Sending
build/announcements/3.3.0-beta1.txt Sending lib/Mail/SpamAssassin/Client.pm
Sending spamc/libspamc.c Sending spamd/PROTOCOL Sending spamd/spamd.raw
Committed revision 884863.

Please review the change carefully (svn diff -c884863).

I tested it with old and new spamc, as well as with old and new Client.pm, but
more eyes can see better...

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187


Justin Mason <jm...@jmason.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jm@jmason.org




--- Comment #5 from Justin Mason <jm...@jmason.org>  2009-09-03 13:30:20 PST ---
(In reply to comment #3)
> 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).

Yes, this was the intention of the protocol designer. (ie me ;)

Also see spamd/PROTOCOL, which is reasonably clear about it:

    The first line from spamc is the command for spamd to execute (PROCESS a
    message is the command in protocol<=1.3) followed by the protocol version.

    There may be additional headers following the command, which are as yet
    undefined.  Servers should ignore these, and keep looking for headers which
    they do support, or the "\r\n\r\n" end-of-headers marker.


> Of course, making spamd wait for the (normally empty) body might break existing
> third party clients if they send a PING without a body.

True.  We need to take that into account somehow, if possible...

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|markt@apache.org            |

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6187] Mail::SpamAssasin::Client ping may erronesously result in broken pipe.

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6187





--- Comment #1 from Jonas Eckerman <jo...@frukt.org>  2009-08-31 09:56:43 PST ---
Created an attachment (id=4523)
 --> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4523)
Comments out the extra $EOL

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.