(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...

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.

move bug to Future milestone (previously set to Future -- I hope)

*** Bug 4971 has been marked as a duplicate of this bug. ***

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.

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.

(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.

(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...

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!