Bug 3991 - RFE: spamd should allow listen on both UNIX and TCP sockets
Summary: RFE: spamd should allow listen on both UNIX and TCP sockets
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.0.1
Hardware: Other other
: P5 enhancement
Target Milestone: 3.2.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 4560
  Show dependency tree
 
Reported: 2004-11-23 12:49 UTC by Justin Mason
Modified: 2007-04-10 05:38 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2004-11-23 12:49:07 UTC
at some stage, we should fix spamd to support listening on multiple listen
sockets -- namely a TCP/IP socket as default, *and* a UNIX domain socket at the
same time.   this would greatly ease deployment of UNIX-domain spamd, which is
faster, but currently requires that all users of spamc change their commandlines
to use.
Comment 1 Justin Mason 2004-11-23 12:49:28 UTC
aiming (optimistically) at 3.1.0
Comment 2 Daniel Quinlan 2005-04-03 03:02:21 UTC
pessimising -> 3.2.0
Comment 3 Justin Mason 2006-05-26 10:16:57 UTC
This was a suggested idea for the Google Summer of Code 2006;
I'm adding it to the bugzilla for future use, and in case anyone feels
like implementing it.

Subject ID: spamassassin-spamd-unix-and-tcp
Keywords: spamd, unix-domain, sockets, networking, perl
Description: http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3991 :
currently spamd supports either UNIX-domain or TCP/IP sockets for incoming scan
requests.  It should support both simultaneously, in the one set of daemon
processes.
Possible Mentors: Justin Mason (jm at jmason.org)
Comment 4 Justin Mason 2006-11-03 10:31:13 UTC
actually, not that hard after all; now implemented and in trunk:

: jm 241...; svn commit -m "bug 3991: spamd can now listen on UNIX domain, TCP,
and SSL sockets simultaneously.  Command-line semantics extended slightly,
although fully backwards compatibly; add the --ssl-port switch to allow TCP and
SSL listening at the same time"
Sending        MANIFEST
Sending        lib/Mail/SpamAssassin/SpamdForkScaling.pm
Sending        spamd/spamd.raw
Adding         t/spamd_unix_and_tcp.t
Transmitting file data ....
Committed revision 470934.
Comment 5 Sidney Markowitz 2006-11-10 13:21:04 UTC
This is breaking t/spamd_ssl.t when SpamAssassin is built with ENABLE_SSL=yes
Running spamd with ssl breaks in the same way.

I wasn't paying attention to this until now, so it may just be that command line
options are not backwards compatible like the comments in the patch say they are
supposed to be, but I'm reopening this bug until this is resolved.

The debugging output and error message from t/spamd_ssl.t and from running spamd
with --ssl looks like spamd is trying to open two sockets on the same port:

t/spamd_ssl....spamd start failed: log: [10577] dbg: logger: adding facilities: all
[10577] dbg: logger: logging level is DBG
[10577] dbg: spamd: creating SSL socket:
[10577] dbg: spamd: Listen: 128
[10577] dbg: spamd: LocalAddr: 127.0.0.1
[10577] dbg: spamd: LocalPort: 43339
[10577] dbg: spamd: Proto: 6
[10577] dbg: spamd: ReuseAddr: 1
[10577] dbg: spamd: SSL_cert_file: data/etc/testhost.cert
[10577] dbg: spamd: SSL_key_file: data/etc/testhost.key
[10577] dbg: spamd: SSL_verify_mode: 0
[10577] dbg: spamd: Type: 1
[10577] dbg: spamd: creating INET socket:
[10577] dbg: spamd: Listen: 128
[10577] dbg: spamd: LocalAddr: 127.0.0.1
[10577] dbg: spamd: LocalPort: 43339
[10577] dbg: spamd: Proto: 6
[10577] dbg: spamd: ReuseAddr: 1
[10577] dbg: spamd: Type: 1
[10577] error: spamd: could not create INET socket on 127.0.0.1:43339: Address
already in use
spamd: could not create INET socket on 127.0.0.1:43339: Address already in use

Comment 6 Sidney Markowitz 2006-11-10 14:13:27 UTC
What t/spamd_ssl.t and the way I run spamd have in common is that they use --ssl
and --port arguments to spamd. My guess from the comments in the patch is that
specifying --ssl and  --port without specifying --ssl-port in interpreted to
mean open both plain and ssl sockets and to use --port for the value of --ssl-port.

For backwards compatibility, --ssl --port=n should mean that only an ssl socket
is opened. I think a good way of handling it would be to test if the port and
ssl-port are equal once they are decided on, and if they are not open a non-ssl
socket. If the command line explicitly says --port=n --ssl-port=n that could
trigger a warning, but I don't think it has to be an error.
Comment 7 Sidney Markowitz 2006-11-10 14:51:39 UTC
That does seem to be the problem. The sanity check of the options in spamd first
checks if --ssl is specified without --ssl-port and in that case disables
listening on an inet socket. Then it checks other options including --port to
decide to enable listening on an inet socket, undoing the effect of the previous
test.

I've checked in a trivial fix that moves the check for --ssl-port not specified
into the test for whether there will be listening for ssl, as that is the right
place to decide that listening on an ssl socket precludes using --port for an
inet socket.

Committed revision 473556.
Comment 8 Justin Mason 2007-04-10 05:38:42 UTC
note -- this shouldn't be on the Google SOC list anymore, as it's been implemented!