http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4861

           Summary: DCC plugin should handle dccifd to dccproc failover
                    properly and pass them correct options
           Product: Spamassassin
           Version: 3.1.1
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Plugins
        AssignedTo: [email protected]
        ReportedBy: [EMAIL PROTECTED]


There are a number of issues regarding the DCC plugin that the DCC developers
brought up. This may have to be split into multiple bug reports.

1. Using dccifd instead of dccproc imposes much less of a load on the DCC
servers. We should code the DCC plugin so that spamd will find dccifd even if
the dccifd daemon is started after spamd. Right now it looks like spamd checks
only when it starts up and caches the result.

2. If dccifd does fail while spamd is running, spamd should fail over to using
dccproc. From a  cursory look at the code I think that the plugin will just
continue to try to use dccifd and fail every time.

3. Even if dccproc is used, whether because dccifd is not available at startup
or because of failover, spamd should try dccifd again after, say, 30 minutes, in
case it is only a temporary failure, because of the impact dccproc has on the
DCC servers.

4. We should be using the -a option when calling dccproc and should be passing
the client ip, name, and HELO values in the protocol send to dccifd so that the
use of DCC is not dependent on the system's DCC configuration correctly matching
SpamAssassin's trusted_networks and internal_networks settings.

5. As long as we are making changes, I think we should add a dccifd_options
configuration variable to the plugin to correspond for dccifd to the dcc_options
we already have for dccproc. I don't see a specific use for it right now, but if
a use does appear it will be better to have the plugin config option already
documented.

I'm targeting this for 3.1.2 because it seems like a trivial change (more
trivial than this long description would indicate) and the DCC people are
getting hammered by it, e.g.,
http://www.rhyolite.com/pipermail/dcc/2006/003150.html



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to