Yes, Larry, it's a firewall configuration issue. If you receive responses from a few public DCC servers, your firewall is likely allowing DCC to do its job.
- Mark Rice > ---------- > From: Larry Gilson[SMTP:[EMAIL PROTECTED] > > > > According to reports from other people, the SpamAssassin > > > documentation does mention using `cdcc info` to see if the DCC > > > client is working, but doesn't say why it matters or what you're > > > supposed to look for. > > > > > > It would be swell if someone with access to SpamAssassin > > > mailing listsor something could encourage that documentation to > > > say that `cdcc info`should find at least one preferablly more > > > than half a dozen of the public DCC servers. If it doesn't, a > > > likely cause is an interferingfirewall. A common firewall > > > configuration passes outgoing DCC/UDP/IP requests to distant port > > > 6277 but rejects responses. That combined with the DCC client > > > code's retransmission mechanisms can multiply the outgoing > > > requests by more than 50 times. (Never mind that large > > > multiplication applies only to dccproc and that recent versions > > > of dccproc should throttle the flood to a dozen or two every > > > few minutes.) > > Is this for firewall configurations that specifically reject responses? > Is > the communication session based like HTTP in which a stateful inspection > would allow the server response by default? I assume by the post that if > `cdcc info` works correctly then the firewall is not an issue. Correct? > > Thanks Again, > Larry > > > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
