Local DCC 'server' and MS?

[Ken Anderson]

Spicer, Kevin wrote:

> Tony Finch wrote:
>
>
>>Good grief! I'm inclined to run dccd, and I would do so on each of our
>>mail filtering machines, but that memory profile means we'd need to
>>upgrade... How much spam is "a lot"? tens of thousands per day?
>>hundreds of thousands? millions? (We're near 100,000 per day.)
>
>
>>From the site....
>
> Mail systems that handle more than 100,000 mail messages per day should have a local DCC server so that processing incoming mail is not delayed by the time required for the UDP packets used by the DCC client protocol to cross the Internet. Organizations that deal with more than 500,000 mail messages per day should have two or more local DCC servers to ensure that at least one local DCC server is available despite system maintenance. Organizations that deal with fewer than 100,000 mail messages per day use less bandwidth of their own and of the servers in the global network by using the public servers. The 100,000 mail messages/day threshold is implied by the fact that each DCC client-server operation involves about 100 bytes and a flood of checksums between servers is significantly more than 10,000,000 bytes/day.
>

Good pointer to the documentation...

fwiw, I've turned on dccifd this morning, and it seems to be humming
along nicely, and taken a small bite out of the load average vs. running
dccproc, although it's hard to tell yet exactly what the impact will be
when SA is 'busy' dealing with a spam attack. I won't have to wait too
long for that though...

Also, as far as the concern about running another daemon, it seems that
if it dies or is killed, SA simply reverts to using dccproc, so there's
no risk of SA/MS hanging or anything ugly like that.

Ken A.
Pacific.Net



>
> BMRB International
> http://www.bmrb.co.uk
> +44 (0)20 8566 5000
> _________________________________________________________________
> This message (and any attachment) is intended only for the
> recipient and may contain confidential and/or privileged
> material.  If you have received this in error, please contact the
> sender and delete this message immediately.  Disclosure, copying
> or other action taken in respect of this email or in
> reliance on it is prohibited.  BMRB International Limited
> accepts no liability in relation to any personal emails, or
> content of any email which does not directly relate to our
> business.
>
>