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