spamassassin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Hartmeier <dan...@benzedrine.cx>
Subject spamd SIGPIPEs
Date Sun, 04 Apr 2004 17:30:22 GMT
I'm connecting to spamd locally through TCP from a libmilter plugin. The
way libmilter gets the mail, it would be easiest for the plugin to not
have to tell spamd the size using Content-length: in advance.

Some trial and error showed that I can send a request like

  << SYMBOLS SPAMC/1.2\r\n
  << User: dhartmei\r\n
  << \r\n
  << From: test\r\n
  (...entire mail)

and then shutdown(SHUT_WR) the socket, triggering spamd to see the end
of input and returning the result, which I can still read. When spamd
has finished sending the result, it closes the connection, my read()
returns 0, and I close() the socket.

Everything appears to work fine, but I do see spamd logging SIGPIPEs
like

  spamd[pid]: SIGPIPE received - reopening log socket 

This occurs even with small test mails, when no timeouts are reached,
which leads me to suspect the scheme described above might not be
perfectly valid. :)

Is this signal caused by the client connection, or is the 'log socket'
something else completely? When I shutdown(SHUT_WR) the client
connection on the client, but keep reading until read() returns 0, how
can spamd get a SIGPIPE? As I understand it, that means it tried to
write to a socket which was closed?

Is there a better way to get a result from spamd without knowing the
size of the mail in advance? libmilter doesn't always give the size in
advance, and caching the entire mail just so I can tell spamd in advance
sounds expensive.

And, somewhat related, can spamd possibly start returning results before
it has read all input?

Daniel

Mime
View raw message