One other question

Vernon Schryver vjs@calcite.rhyolite.com
Fri Nov 29 20:34:56 UTC 2002


> From: "John R Levine" <johnl@iecc.com>
> To: "Dave Lugo" <dlugo@etherboy.com>
> Cc: "dcc@rhyolite.com" <dcc@rhyolite.com>

> ...
> > http://www.spamassassin.org/tests.html
> >
> > Search the above page for "DCC".
>
> It's supported in an odd way, trying to run DCC from inside itself.  I'd
> rather run it separately, either via milter or dccproc, then add a rule to
> spamassassin to look for the X-DCC line with the results.


] From: Daniel V Klein <dvk@lonewolf.com>

]                                                            ...  I would like
] to use SpamAssassin on a server-wide basis (that is, for the 85+ domains that
] I MX) while still using DCC and Sendmail.
]
] Is there a kind soul who has gone through this process that would be willing
] to tell this lazy hacker where to start?  My concern is that to keep the
] server load low and DCC use high (I may be misguided here), I'd like to
] milter through DCC before I milter through SpamAssassin. ...


I've met people who have tried to use SA milter implementations.  Some
say they work, while others emphatically disagree.  I have the impression
that the SA milters are maintained by third parties.  I don't understand
why they seem to be stand-alone filters instead of hooked to one of
the popular Perl milters.  If you do use one of the SA milters, check
the sendmail parameters for the SA milter you choose; 15 minute timeouts
make no sense to me.
 
It is more common to use SpamAssassin in the delivery path via .forward
files or other mechanisms.  The SA Milter people have evidently not
figure out how to do per-addressee customizing; there are some ugly
and unavoidable choices in that area.  Most SA users who also use the
DCC tell SA to run dccproc.  That strikes me as undesirable in a busy
system, but I can't get enthused about running any Perl program on
every incoming message on a busy system.  I'm working on a DCC client
daemon that can be used with Perl or other programs and that should
be less inefficient than fork()/exec(dccproc).
 
If I used SA with sendmail, I would let dccm+sendmail to their things,
and use SA in the delivery path as an independent filter.   Besides
being fastest, this leaves both filters in their favorite environment.
I would at least look for X-DCC headers added by dccm instead of
running dccproc in SA.  I understand that a forthcoming version of SA
will do that automatically, but will still run dccproc if the X-DCC
header line is absent or says the message is ok.  This is necessary
if SA isn't certain the X-DCC header line was added by the local system
or if SA doesn't know the brand names of the locally chosen DCC servers.
Otherwise spammers could get creative with X-DCC headers.
 
 
Vernon Schryver    vjs@rhyolite.com




More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.