Vernon Schryver пишет:
I don't think you have a local DCC server, and you have not attracted
attention by using the public DCC servers to more than 100K msgs/day.
Therefore it seems likely that your mail systems are handling
fewer than 200K messages per day.
At the moment dcc is used for outgoing traffic only with local dcc server.
Incoming traffic averages per day are: 10M of recipients, 4.5 M connections, 400K messages are passed to mailboxes. I do not use global DCC servers because commercial filter does checksum-based filtering job and does it well. But we have special type of spam oriented only for our users, it is the reason I started the topic.

Writing files to disk is expensive (all stuff is in memory now, no any disk i/o), writing files into memory and frequent postprocessing them with script is an alternative,
but it does not look elegant and needs more memory.

If you don't have spare resources to write a 4K Byte log file, then you
surely do not have the larger resources needed to fork(), exec(), parse,
and run a script.
Script does batch job, so everything is not so bad as you said.
 Just creating the u area and the stack for the new
process for the script probably involves more than 4KBytes of I/O (of
course generally not to the disk).

It is likely that there is no difference between writing a new log file
of 100 bytes and writing a new log file of 4 KBytes, whether you
use a memory file system or classic disk.
Writes are buffered, so I believe short log is about 4k/100=40 times faster.
How are you using postfix+dccm?  That last time I checked, I found
that the postfix milter interface incompatible with the sendmail milter
interface as far as dccm is concerned.
With current versions of postfix I tried a lot of different milters, they all work as they should. The only difference is you should always use extended smtp codes for replies.
Why not use postfix with dccifd as a before-queue filter?  That's
the recommended DCC configuration with postfix.

Milter is before-queue too. With milter it is easier to track connections as all log records for particular connection always has the same ID (inode name). Also it is easier to manage system because all other filters are milters too.

> I predict that if you do change dccm, then in 6 months or a year from now you or your successor will discard those changes and probably stop using DCC.

That is not my case, sorry :)


_______________________________________________
DCC mailing list      [email protected]
http://www.rhyolite.com/mailman/listinfo/dcc

Reply via email to