Bug 1936 - RFE: specify multiple hosts for "spamc -d"
Summary: RFE: specify multiple hosts for "spamc -d"
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other AIX
: P4 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard: needs code
Keywords:
: 1937 1938 1943 1945 1949 4971 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-21 06:31 UTC by Jack Gostl
Modified: 2008-04-03 12:39 UTC (History)
1 user (show)



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 Jack Gostl 2003-05-21 06:31:36 UTC
I would like to see spamc accept multiple hosts rather than depend on RR 
records. Our registrar doesn't support this and running our own DNS, 
particularl with the monthly bug litany agains these servers, is something I'd 
like to avoid.

I've looked at the spamc code... I don't think it would be that hard to add 
something like -d1 first_alternate -d2 second_alternate , etc.

Thank you for your considerations
Comment 1 Justin Mason 2003-07-06 23:16:29 UTC
(a) just wondering -- how does the registrar control this?  it should be
possible to add lines to /etc/hosts to do it,

   ip.add.rr.1      realname1 failovername
   ip.add.rr.2      realname2 failovername
   ip.add.rr.3      realname3 failovername

(b) we'd accept a patch ;)  I would suggest that it be implemented as a new
option which takes a comma-separated list of hostnames in its arg, "spamc -D
host1,host2,host3".  -D may already be taken.  but you get the idea...
Comment 2 Rich Puhek 2004-03-01 15:46:23 UTC
Not sure if my C skills are up to providing a patch, but it might be possible to
just have the transport_setup sub in libspamc.c check to see if tp->hostname
contains a comma. If so, split the variable at the comma(s), and perform the
gethostbyname on each. Could drop (and log) hosts with problems, and just keep
the ones that are good.
Comment 3 Daniel Quinlan 2005-03-30 01:08:27 UTC
move bug to Future milestone (previously set to Future -- I hope)
Comment 4 Michael Parker 2006-08-02 03:58:00 UTC
*** Bug 4971 has been marked as a duplicate of this bug. ***
Comment 5 Adam Katz 2008-02-05 14:41:12 UTC
The man page for spamc(1) (v 3.0.0 and 3.2.3) suggests that this is already
implemented:  [ from http://linux.die.net/man/1/spamc ]

   -d host[,host2], --dest=host[,host2]
       In TCP/IP mode, connect to spamd server on given host (default:
       localhost).  Several hosts can be specified if separated by commas.

This suggests that this feature request has been implemented
and the RFE for this feature has been completed.
This bug should have been closed when that happened.

However, the implementation does not work.
Enter bug 4971, which was marked as a duplicate of this bug,
mostly due to the fact that bug 1936 was never closed.

I can confirm the fact that this feature does not work:
the command "spamc -d host,host2 <test.eml" will never try host2.
(Debian Etch, package spamassassin 3.2.3-0.volatile1)

If nobody is working on this, the documentation should be changed to reflect the
fact that the -d flag does NOT accept a comma-delimited list.

If somebody is actually working on this, this bug should be closed and bug 4971
should be re-opened to take over where this bug left off.
Comment 6 Ty! Boyack 2008-04-02 15:11:30 UTC
Specifying multiple hosts can work, however, it seems that only the first host will be used unless 1) that host is down, or 2) you also specify '-H' or '--randomize' on the command line.  With that flag set it does spool spam to more than one spamd server.

I think this might be a common misunderstanding of the use.  I'm wondering if it makes sense to change the default behavior to normally enable '--randomize' and maybe add a new option of something like '--spamd-hosts-in-order' for the cases where someone really wants to specify an order to their spamd servers.  But most people I have talked with are thinking along the lines of spamd farms that they would like load balanced.



(In reply to comment #5)
> The man page for spamc(1) (v 3.0.0 and 3.2.3) suggests that this is already
> implemented:  [ from http://linux.die.net/man/1/spamc ]
> 
>    -d host[,host2], --dest=host[,host2]
>        In TCP/IP mode, connect to spamd server on given host (default:
>        localhost).  Several hosts can be specified if separated by commas.
> 
> This suggests that this feature request has been implemented
> and the RFE for this feature has been completed.
> This bug should have been closed when that happened.
> 
> However, the implementation does not work.
> Enter bug 4971, which was marked as a duplicate of this bug,
> mostly due to the fact that bug 1936 was never closed.
> 
> I can confirm the fact that this feature does not work:
> the command "spamc -d host,host2 <test.eml" will never try host2.
> (Debian Etch, package spamassassin 3.2.3-0.volatile1)
> 
> If nobody is working on this, the documentation should be changed to reflect the
> fact that the -d flag does NOT accept a comma-delimited list.
> 
> If somebody is actually working on this, this bug should be closed and bug 4971
> should be re-opened to take over where this bug left off.

Comment 7 Daryl C. W. O'Shea 2008-04-02 16:15:45 UTC
(In reply to comment #6)
> I think this might be a common misunderstanding of the use.  I'm wondering if
> it makes sense to change the default behavior to normally enable '--randomize'
> and maybe add a new option of something like '--spamd-hosts-in-order' for the
> cases where someone really wants to specify an order to their spamd servers.

I'd rather not change the default and then and a new option to get the default back.  spamc is old enough that the people who know how it works understand how it works and will be surprised by a a change.  The people who don't know how it works will have to figure it out anyway.

FWIW, I've setup a lot of MX/spamd farms that specifically rely on the host order not being randomized (first they scan on their local system and then hunt around for a spamd server that is up).  I'm not sure if there is a clear cut most common case out there to justify a change of behaviour.
Comment 8 Justin Mason 2008-04-03 01:44:56 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > I think this might be a common misunderstanding of the use.  I'm wondering if
> > it makes sense to change the default behavior to normally enable '--randomize'
> > and maybe add a new option of something like '--spamd-hosts-in-order' for the
> > cases where someone really wants to specify an order to their spamd servers.
> 
> I'd rather not change the default and then and a new option to get the default
> back.  spamc is old enough that the people who know how it works understand how
> it works and will be surprised by a a change.  The people who don't know how it
> works will have to figure it out anyway.

I agree.   however I'd be happy to apply a patch to the POD docs for -d which explicitly calls out this behaviour, and how to fix it using --randomize...
Comment 9 Ty! Boyack 2008-04-03 12:39:35 UTC
That sounds like the best solution to me - leave the behavior as it is, but make it a bit more explicit in the docs.  Thanks!