gmane.mail.spam.dcc

Re: DCC and SpamAssassin

Vernon Schryver — 2012-01-12T15:29:56



DCC is still what it has always been, a mechanism for detecting and
somewhat quantifying the 'bulkness' mail.  Mail messages that have
hit some sort of a spam trap including the DCC.pm dcc_learn_score
mechanism has DCC target counts of "many" and should be considered
"very bulky."  The DCC target count of "many" is in fact 16777200
or the largest target count possible the DCC server databases,
client-server protocol, and server-to-server flooding protocol,
(It's not a coincidence that 16777200 is is approximately 0xffffff.)

The messages that contribute the pink areas in
http://www.rhyolite.com/dcc/graphs/?BIG=1
have target counts of "many" because they have hit some sort of
spam trap.



I recommend running dccifd (or dccm), setting the DCC thresholds
in /var/dcc/dcc_conf, and letting SpamAssassin (if you use SpamAssassin)
look for the string "bulk" in X-DCC headers that SpamAssassin gets
from dccifd or finds already present.

However, DCC.pm has always used the values of dcc_body_max,
dcc_fuz1_max, and dcc_fuz2_max to decide the threshold of DCC target
counts qualify as bad.  Michael Scheidell added dcc_rep_percent for
DCC Reputations.  The SpamAssasin dcc_{body,fuz1,fuz2}_max knobs
date from before dccifd when dccproc was the only way to for
SpamAssassin to invoke DCC.

See the "USER OPTIONS" section of the SpamAssass DCC.pm documentation
by running `perldoc lib/Mail/SpamAssassin/Plugin/DCC.pm`
after expanding your copy of the SpamAssassin tarball.
Or use `perldoc misc/DCC.pm` in your DCC build directory after
expanding a DCC tarball.
Or something like `perldoc /var/dcc/build/dcc/misc/DCC.pm`
after running /var/dcc/updatedcc to get the current DCC version.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

Re: DCC and SpamAssassin

Matus UHLAR - fantomas — 2012-01-12T13:34:29

Sorry for not getting to this e-mail sooner...

On 10.11.11 02:07, Vernon Schryver wrote:

So, is DCC no more a system for detecting bulkiness, but a 
spamminess of a message?


I was wondering, if I can change the MANY value for reporting and 
threshold for checking, outside of a DCC client (e.g. DCC.pm)

DCC version 1.3.141/2.3.141 released

Vernon Schryver — 2012-01-10T22:06:16

Version 1.3.141 of the DCC source is in
http://www.dcc-servers.net/dcc/source/dcc.tar.Z  and
http://www.rhyolite.com/dcc/source/dcc.tar.Z

Commercial version 2.3.141 of the DCC Reputation code is in the usual place.

The CHANGES file in
http://www.dcc-servers.net/dcc/dcc-tree/CHANGES and
http://www.rhyolite.com/dcc/dcc-tree/CHANGES and
starts with
    Fix "MTA-last" in dcc man page as suggested by Bram Grietens.
    Fix no_forced-discard typo reported by Bram Grietens.
    Fix dccm to honor `hackmc -R` and discard relay attacks.
    misc/DCC.pm, which is generated from misc/DCC.pm.in, is now very
similar to what will probably be in SpamAssassin 3.4.
    Fix problems finding native milter library for dccm pointed out by
Kevin A. McGrail.
    Improve documentation or help output from the nagios plugin,
/var/dcc/libexec/dcc-nagios
    Fix bug in misc/DCC.pm in dealing with mail that already has an
X-DCC header found and diagnosed by Herbert J. Skuhra.

dcc_learn_score probably would not help sites that have set their
DCC threshold below "many", but it seems to help the many
DCC+SpamAssassin installations that use the default "many" thresholds.
Late last year sites in Germany using SpamAssassin with DCC switched
to that new version of DCC.pm and turned on dcc_learn_score to
report mail declared spam by SpamAssassin to DCC.  Immediately after
that, server graphs for some other German DCC installations suggested
significantly improved DCC hit rates.  I theorize that there is
plenty of spam targeting mailboxes in Germany but not spam traps
in the U.S.

/var/dcc/libexec/updatedcc should automagically fetch, build, and
install the commercial or free version, depending on the .updatedcc_pfile
file, unless you have installed a version of Linux with the broken
default `sort` collating sequence since last upgrading.  If so, an
easy way to get the old updatedcc script working is to delete the
entire /var/dcc/build/dcc directory before running updatedcc.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

DCC and SpamAssassin

Vernon Schryver — 2011-11-10T02:07:52

For the last 18 months, the DCC source has included a new version of
the SpamAssassin DCC plugin.  As far as I know, it is completely upward
compatible.  Besides a general clean up of the Perl source and a bunch
of changes that should make DCC.pm faster and more robust, it includes
a mechanism that reports message detected as spam by SpamAssassin to DCC
with target counts of 'many'.

Two or three months ago a DCC installation started using that mechanism
on its incoming 750K messages/day.  The effect is to increase DCC
target counts for messages considered spam by SpamAssassin to 'many'.
That should have little effect on DCC installations that set DCC
thresholds to values below 1000.  750K messages/day is too few to
support certain conclusions, but judging from the DCC server graphs,
it has noticable effects on the majority of other DCC installatios
that use the DCC.pm default synonym of 9999999 for 'many'.

That increased target count of 'many' can not only help other DCC
installations, but also sites using the mechanism with the default
DCC.pm threshold of 999999.  For example, a message from an SMTP
client (mail sender) at an IP address in a DNS blacklist (DNSBLs)
can get a DCC target count of 'many'.  A later copy received via
an address not in a DNSBL can trigger a SpamAssassin+DCC rule.

To try the mechanism, make a copy of your current DCC.pm file and
install the DCC.pm file in your SpamAssassin installation from the
misc directory of your DCC build/installation tree.  (I would use
a symbolic link.)  If you have used /var/dcc/libexec/updatedcc,
look in /var/dcc/build/dcc/misc/DCC.pm
At worst, check the current DCC source tree at
http://www.dcc-servers.net/dcc/dcc-tree/misc/DCC.pm

Then set the DCC.pm parameter dcc_learn_score to whatever you use
for the global SpamAssassin threshold or perhaps a little more.
Depending on your SpamAssassin installation, you might then need
to restart an SA deamon.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

Re: open(/var/dcc/map): Permission denied

Vernon Schryver — 2011-09-23T14:28:11


According to http://spamassassin.apache.org/downloads.cgi
the current version is 3.3.2.  But I doubt that matters.



That shows that the problem is related to how dccproc is run for
real mail by postfix+SpamAssassin.  It also shows that postfix+SpamAssassin
is breaking access to the /var/dcc/dccifd socket.



That is my mistake.  /usr/var/dcc/build/dcc exists only after running
/var/dcc/libexec/updatedcc.  You can find DCC.pm in the dcc-1.3.140/misc
directory of the DCC tarball that you expanded and after you run ./configure.

I trust you used the DCC source tarball from
http://www.dcc-servers.net/dcc/#download or
http://www.dcc-servers.net/dcc/source/dcc.tar.Z
I have been wasting my time answering your email if you are trying
to use one of the "improved" (spelled b-r-o-k-e-n) DCC versions
redistributed by Linux repackagers.



Yes and then dccproc fails to find another file in /var/dcc.
Doesn't that tell you that SpamAssassin (spamd) and all of its
children are unable to reach /var/dcc, probably because of some sort
of chroot jail?



Do you really think no one else is using SpamAssassin with dccifd?
Didn't you say that postfix+spamd+DCC worked with your previous
Linux system?



cdcc uses /var/dcc/map in the same way with the same libclnt.a and
libdcc.a libraries as dccproc and dccifd to exchange UDP packets
with the DCC servers.  Cdcc does not check dccifd.  Dccifd, dccproc,
dccm, and cdcc are DCC clients that send DCC/UDP/IP requests to DCC
servers.  Cdcc controls DCC servers and gets their status by sending
UDP packets.  See `man cdcc`

That cdcc works and that the SpamAssassin DCC check works suggests
that the problem is related to however postfix+SpamAssassin runs
on real mail, probably with some sort of chroot jail.




That also supports my guess that chroot or a jail is involved with real
mail.  I bet that if you modify the DCC.pm used by SpamAssassin or
add a local SpamAssassin filter that does nothing but
`/bin/cp /var/dcc/dcc_conf /tmp/sa-test`, you will find
that SpamAssassin cannot reach any of /var/dcc.



You must tell dccproc, cat, or any program about the end of the
file you are typing.  Try typing control-D to end the file to dccproc.
I bet that you will find that dccproc, like cdcc, is working fine
outside postfix and spamd.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

Re: open(/var/dcc/map): Permission denied

Aldo Necci — 2011-09-23T09:57:15


Yes I have SpamAssassin 3.3.1 and this is its output:
# spamassassin -V
SpamAssassin version 3.3.1
  running on Perl version 5.10.1


I try this method of testing DCC with Spamassassin as described somewhere:
# spamassassin -D < /usr/share/doc/spamassassin-3.3.1/sample-nonspam.txt

and I got a lot of output, but this is the most important:
Sep 23 10:12:38.503 [2790] dbg: dcc: dccifd local socket chosen:
/var/dcc/dccifd
Sep 23 10:12:38.503 [2790] dbg: dns: entering helper-app run mode
Sep 23 10:12:38.503 [2790] dbg: dcc: connecting to a local socket
/var/dcc/dccifd
Sep 23 10:12:38.640 [2790] dbg: dcc: dccifd got response:
X-DCC-dcc1-Metrics: mbox2 1182; Body=many Fuz1=many Fuz2=many
Sep 23 10:12:38.640 [2790] dbg: dns: leaving helper-app run mode
Sep 23 10:12:38.642 [2790] dbg: dcc: listed: BODY=999999/999999
FUZ1=999999/999999 FUZ2=999999/999999 REP=0/90
Sep 23 10:12:38.644 [2790] dbg: rules: ran eval rule DCC_CHECK ======> got
hit (1)

So It seems to work right! There is *NOT* any warning like:
open(/var/dcc/map): Permission denied
in all the output and neither in the log file (in that moment of test
was running). But I got that warning, one for every incoming e-mail
processed by spamassassin.


I haven't any directory named "dcc" under the directory /var
# ls /usr/var/dcc/build/dcc/misc/DCC.pm
ls: cannot access /usr/var/dcc/build/dcc/misc/DCC.pm: No such file or
directory

I have this inside the package "spamassassin":
# rpm -ql spamassassin | grep -i dcc
/usr/share/man/man3/Mail::SpamAssassin::Plugin::DCC.3pm.gz
/usr/share/perl5/Mail/SpamAssassin/Plugin/DCC.pm
/usr/share/spamassassin/25_dcc.cf


The dccifd program is running, I show only the two lines of output:
# ps -ef
root      1505     1  0 09:45 ?        00:00:00 /var/dcc/libexec/dccifd
-tREP,20 -tCMN,5, -llog -wwhiteclnt -Uuserdirs -A -SHELO -Smail_host
-SSend
root      1506  1505  0 09:45 ?        00:00:00 /var/dcc/libexec/dccifd
-tREP,20 -tCMN,5, -llog -wwhiteclnt -Uuserdirs -A -SHELO -Smail_host
-SSend

As I show before in the output of debugging Spamassassin, there is
the right socket under /var/dcc/dccifd:
srw-rw-rw-. 1 root root 0 Sep 23 09:45 /var/dcc/dccifd
but it seems that every incoming e-mail causes Spamassassin to
ignore it and invoke dccproc. I think that /var/dcc/map is locked
by dccifd daemon and dccproc can't access it so the warning:
open(/var/dcc/map): Permission denied
This can be the right explanation, I think...
Oh no! I try to disable dccifd on his config file /var/dcc/dcc_conf:
DCCIFD_ENABLE=off
and restart all the server. After the boot, the dccifd daemon wasn't
started but in the log file /var/log/maillog there was that warnig:
# last
reboot   system boot  2.6.32-131.12.1. Fri Sep 23 11:06 - 11:25  (00:19)
and inside the /var/log/maillog (I replace the real name of server with
"-----")
Sep 23 11:26:13 ----- dccproc[2024]: open(/var/dcc/map): Permission denied


I also did as usual all the right links after installation of DCC:
lrwxrwxrwx. 1 root root 22 Sep 21 13:27 /etc/init.d/dcc ->
/var/dcc/libexec/rcDCC
lrwxrwxrwx. 1 root root 13 Sep 21 13:28 /etc/rc3.d/S40dcc -> ../init.d/dcc
This last link was made by the command "chkconfig dcc on" after the
command "chkconfig --add dcc".
Dccifd starts as well at the boot time, but *WHY* there is not any
connection on UDP even if I got this output from cdcc command:
# /usr/local/bin/cdcc "info -N"
# 09/23/11 11:00:45 CEST  /var/dcc/map
# Re-resolve names after 11:12:54  Check RTTs after 11:15:44
# 351.82 ms threshold, 224.35 ms average    12 total, 12 working servers
IPv6 on   version=3

dcc1.dcc-servers.net,-      RTT+1000 ms  anon
#  80.91.36.101,-         dcc1.aftenposten.no       dcc1.aftenposten.no ID
1215
#     100% of 11 requests ok  143.56+1000 ms RTT       100 ms queue wait
#  137.208.8.26,-         samantha.wu-wien.ac.at              wuwien ID 1290
#     100% of 11 requests ok  124.02+1000 ms RTT       100 ms queue wait
#  209.169.14.30,-        h5-vjs.colo.indra.com        x.dcc-servers ID 104
#     100% of 11 requests ok  250.56+1000 ms RTT       100 ms queue wait

dcc2.dcc-servers.net,-      RTT+1000 ms  anon
#  64.254.89.30,-         dcc-public.dmv.com                 dmv.com ID 1181
#     protocol version 9
#     100% of 11 requests ok  211.34+1000 ms RTT       100 ms queue wait
#  208.82.128.50,-        dcc.quonix.net                             ID 1282
#     protocol version 9
#     100% of 11 requests ok  212.86+1000 ms RTT       100 ms queue wait

dcc3.dcc-servers.net,-      RTT+1000 ms  anon
#  209.169.14.26,-        h1-vjs.colo.indra.com        x.dcc-servers ID 104
#     100% of 11 requests ok  250.87+1000 ms RTT       100 ms queue wait

dcc4.dcc-servers.net,-      RTT+1000 ms  anon
#  200.81.186.149,-       dcc1.sion.com                         SION ID 1111
#     protocol version 9
#     100% of 11 requests ok  356.52+1000 ms RTT       100 ms queue wait

dcc5.dcc-servers.net,-      RTT+1000 ms  anon
#  136.199.199.102,-      urts102.uni-trier.de                   URT ID 1060
#     100% of 11 requests ok  123.44+1000 ms RTT       100 ms queue wait
#  193.166.171.33,-       dcc1.stat.fi              STAT_FI_X86_64_VIRTUAL
ID 1245
#     100% of 11 requests ok  156.64+1000 ms RTT       100 ms queue wait

dcc.to.infn.it,-            RTT+0 ms    anon
#  192.84.137.21,-        birubiru.to.infn.it                INFN-TO ID 1233
#     100% of 11 requests ok  251.82+0 ms RTT          100 ms queue wait

dcc1.pa.iasf.cnr.it,-       RTT+0 ms    anon
# *194.119.212.6,-        mail2.ifc.inaf.it                     dcc1 ID 1182
#     100% of 20 requests ok  124.78+0 ms RTT          100 ms queue wait

dcc.ba.infn.it,-            RTT+0 ms    anon
#  192.135.10.194,-       dcc.ba.infn.it                      debian ID 1169
#     protocol version 9
#     100% of 11 requests ok  127.36+0 ms RTT          100 ms queue wait

################
# 09/23/11 11:00:46 CEST  greylist /var/dcc/map
# Re-resolve names after 11:21:30  Check RTTs after 11:15:44
# 1 total, 0 working servers
# continue not asking greylist server 31 seconds after 1 failures

< at >,-                         Greylist 32768 secret1425104514y957
# *127.0.0.1,6276         localhost
#      not answering


I use postfix and it is not chrooted, but I don't' know about jails.
The warning appears even when Spamassassin starts (I replace the real name
of server with "-----"):
Sep 23 11:34:10 ----- spamd[2719]: logger: removing stderr method
Sep 23 11:34:14 ----- dccproc[2722]: open(/var/dcc/map): Permission denied
Sep 23 11:34:16 ----- spamd[2721]: spamd: server started on port 783/tcp
(running version 3.3.1)
Sep 23 11:34:16 ----- spamd[2721]: spamd: server pid: 2721
Sep 23 11:34:16 ----- spamd[2721]: spamd: server successfully spawned
child process, pid 2724
Sep 23 11:34:16 ----- spamd[2721]: spamd: server successfully spawned
child process, pid 2726


I try this:
# /usr/local/bin/dccproc -C
asdf: asdf

asdf
^C#
the last line is a CTRL-C I pressed to exit from shell (how I can close
the shell?). There is no output.


Yes, I tried it as a last change, but it still remains the problem.


Thanks,
Aldo Necci




-----------------------------------------
This email was sent using SquirrelMail.
https://webmail.dia.uniroma3.it
Web Site: http://www.squirrelmail.org

Re: open(/var/dcc/map): Permission denied

Vernon Schryver — 2011-09-22T19:26:30



Are you using a current version of SpamAssassin?

Have you tried the SpamAssassin DCC test?   I've forgotten how to
invoke it and do not see it mentioned in
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Plugin_DCC.html

I understood that the SpamAssassin people were going to ship the
new version of the SpamAssassin DCC plugin in
/usr/var/dcc/build/dcc/misc/DCC.pm
If that file differs from the DCC.pm you are using, 
it might be entertaining to try it.



Is dccifd running?  If dccifd is running and SpamAssassin can reach
the UNIX domain socket at /var/dcc/dccifd, then SpamAssassin should
never try dccproc.  Since SpamAssassin cannot use dccproc to reach
/var/dcc/map, one might expect problems reaching /var/dcc/dccifd.

If dccifd is not running, then perhaps /var/dcc/libexec/rcDCC has
not been sym-linked to the right /etc/rc* directories.




Do the default settings involve jails or chroot?
I cannot guess after some Google for Scientific Linux.
Are you using sendmail, postfix, or something else?



What kind of nothing happens?  When you feed `dccproc -C` a test 
message like
    asdf: asdf

    asdf
does dccproc emit the X-DCC header?  Or do you see the complaint
about /var/dcc/map that SpamAssassin sees?



Could you re-install DCC to use the username/UID used by SpamAssassin?
That should make the setuid bit on /usr/local/bin/dccproc irrelevant.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

Re: open(/var/dcc/map): Permission denied

Aldo Necci — 2011-09-22T08:26:49


Scientific Linux 6 uses the dot after the permission bits as a symbol
of "this is the end of permission bits".


The command "cdcc" works as well and this is its permission bits:
-r-sr-xr-x.  1 root bin  179830 Sep 21 17:38 cdcc


No, the directory /usr/local/bin is on a filesystem under /


SpamAssassin is configured to use the right path, this is its configuration:
use_dcc 1
dcc_path /usr/local/bin/dccproc
dcc_home /var/dcc
dcc_dccifd_path /var/dcc/dccifd

Any explanation on
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Plugin_DCC.html

Even if I comment the second line and let SpamAssassin to find the
path for dccproc, I get the same log:
dccproc[1982]: open(/var/dcc/map): Permission denied

Another serious question is:
I don't see any UDP connection after dccifd started,
the output of the command "netstat -pu" is empty and
there isn't any firewall (I disabled the default software firewall).


No, I let the default settings.


Nothing, the log directory under /var/dcc/ is also empty.


Yes I think the same because on previous versions of Linux I used
(Scientific Linux 5) and previous
version of DCC everything was OK. The commands "./configure" and
"make install" don't send any error and work well.

Thanks,
Aldo Necci



-----------------------------------------
This email was sent using SquirrelMail.
https://webmail.dia.uniroma3.it
Web Site: http://www.squirrelmail.org

Re: open(/var/dcc/map): Permission denied

Vernon Schryver — 2011-09-21T16:45:24



What is the significance of the period (.) after the permission bits?


Just now I tried:
   pax -rzf ...
   cd dcc-1.3.*
   ./configure --homedir=/tmp/dcc --bindir=/tmp/dcc/bin --mandir=/tmp/dcc
   make install

That made:
  -r-sr-xr-x  1 root  wheel  919480 Sep 21 16:18 bin/dccproc*
  -rw-------  1 root  wheel    7668 Sep 21 16:18 map

I see no problems with dccproc:
    % bin/dccproc -C
    asdf: asdf

    asdf
    X-DCC--Metrics: calcite.rhyolite.com 0; Body=1
reported: 1               checksum
   Message-ID: d41d8cd9 8f00b204 e9800998 ecf8427e

Does the `cdcc` command also fail?  Cdcc is also installed set-UID
too the --with-uid value.

Is /usr/local/bin be mounted with an option that turns off set-UID
or set-UID=0?

Is it possible that that the dccproc used by SpamAssassin (or
whatever) is not /usr/local/bin/dccproc but some other file such
as /usr/etc/bin/dccproc?   If SpamAssassin is involved, is
SpamAssassin configured to use /usr/local/bin/dccproc?

Are you doing anything with "jails" or chroot in mail processing?

What happens with a manual invocation of dccproc like mine above?

It seems likely that the problem is related to something unique about
your system or DCC installation.  I think there are many installations
of version 1.3.140 using the default setting of root for --with-uid.

   ....


} From: "John R. Levine" <johnl-ShX0hXQ9Y8s< at >public.gmane.org>

} > OK. The UID is root and that file is private:
} > -rw-------. 1 root root 7668 Sep 21 17:21 /var/dcc/map
}
} The dcc process usually runs as user "dcc", so the file should belong to
} dcc, not to root.
}
} This is a familiar problem when an update doesn't work quite right.

Yes, but dccproc runs as "dcc" (or some other user) only after an original
use of `./configure --with-uid=dcc` or a later use of
`/var/dcc/libexec/udpatedcc -c '--with-uid=dcc'`
Many people feel strongly about not running the DCC programs as root,
but many others don't.

In this case, dccproc appears to be set-UID root and /var/dcc/map 
seems to be readable and writable by root.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

Re: open(/var/dcc/map): Permission denied

John R. Levine — 2011-09-21T16:11:41

The dcc process usually runs as user "dcc", so the file should belong to 
dcc, not to root.

This is a familiar problem when an update doesn't work quite right.

Regards,
John Levine, johnl-ShX0hXQ9Y8s< at >public.gmane.org, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Re: open(/var/dcc/map): Permission denied

Aldo Necci — 2011-09-21T15:36:08


OK. The UID is root and that file is private:
-rw-------. 1 root root 7668 Sep 21 17:21 /var/dcc/map




I have done all. But the problem is still there:
dccproc[9126]: open(/var/dcc/map): Permission denied

The dccproc file is:
-r-sr-xr-x. 1 root bin 496487 Sep 21 17:21 /usr/local/bin/dccproc

Thanks,
Aldo Necci




-----------------------------------------
This email was sent using SquirrelMail.
https://email.dia.uniroma3.it
Web Site: http://www.squirrelmail.org

Re: open(/var/dcc/map): Permission denied

Vernon Schryver — 2011-09-19T16:10:59


The /var/dcc/map file must be private and readable only by owner,
because it can contain client-IDs and passwords for accessing private
DCC servers.  (The anonmous client-ID of 1 does not use a password.)

`make install` installs dccproc set-UID to the UID specified with
`./configure --with-uid=UID`  The default UID is 0 or root.

It is quite possible that running /var/dcc/libexec/updatedcc
would fix the problem.  Configure builds updatedcc with the
./configure parameters including with-uid.
After fetching the tarball, updatedcc uses `./configure` and `make
install` to `chown` and so forth.
Updatedcc checks to see if it needs to be run by root so that `make`
can `chown` and so forth.

/var/dcc/dcc_conf-new is also built by updatedcc,
and can usually be installed as /var/dcc/dcc_conf


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

open(/var/dcc/map): Permission denied

Aldo Necci — 2011-09-19T14:25:38

Hi,

does anyone know why the following would appear in the logs:
dccproc[2304]: open(/var/dcc/map): Permission denied

I'm using last version (dcc-1.3.140) on Scientific Linux release 6.1
and when spamassassin (ver 3.3.1) process an e-mail I get that message.

The same configuration on Scientific Linux CERN SLC release 5.7
and DCC version 1.3.134 works without that message:
DCCD_ENABLE=off
DCCM_ENABLE=off
DCCIFD_ENABLE=on

thanks,
Aldo Necci


-----------------------------------------
This email was sent using SquirrelMail.
https://email.dia.uniroma3.it
Web Site: http://www.squirrelmail.org

Re: Using "ok env_From" to whitelist mail from whole domain

Vernon Schryver — 2011-08-27T16:42:11


You are right, and the FAQ is wrong.

To whitelist mail from the single mailbox such as, test-hcDgGtZH8xNBDgjK7y7TUQ< at >public.gmane.org,
use a line like this:

  OK      env_Fromtest-hcDgGtZH8xNBDgjK7y7TUQ< at >public.gmane.org

With the contents of /var/dcc/dcc_conf that are in the official source
(i.e. not from a third party), the following line will whitelist mail
from all mailboxes at the domain name:

  OK      substitute mail_host test-hcDgGtZH8xNBDgjK7y7TUQ< at >public.gmane.org


Thanks for pointing out the FAQ error,
Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

Using "ok env_From" to whitelist mail from whole domain

Matthew Richardson — 2011-08-27T15:32:57

The FAQ at http://www.rhyolite.com/dcc/FAQ.htm has an entry about
whitelisting incoming email FROM a whole domain saying:-


My tests indicate that this does not work as described.  Whereras:-

OK      env_Fromtest-hcDgGtZH8xNBDgjK7y7TUQ< at >public.gmane.org

in the global whiteclnt file does cause both greylisting and checking to be
bypassed, a similar entry for the whole domain seems to be completely
ignored.

Should this feature work, or is the FAQ somehow mistaken?

I am using DCC 1.3.134 with Postfix using DCCM as a milter.

With many thanks.

Best wishes,
Matthew

[PATCH] Parsing clientwhitelist: unrecognized "optionno-forced-discard"

Bram — 2011-08-03T15:05:41

There appears to be a typo in the parsing of the clientwhitelist file.
When  option no-forced-discard is added then it produces the message:

'unrecognized "option no-forced-discard"'

- "no-forced-discard" is used 13 times in the package
- "no_forced-discard" is used 1 time in the package

=> I'm guessing this is a typo, a patch (against dcc-1.3.140) for this  
is attached.

Best regards,

Bram

Re: [PATCH] Create the socket of dccifd in the rundir

Vernon Schryver — 2011-08-03T15:33:38


dccifd is not a sendmail (or postfix) milter.


I agree that the dccifd socket by defailt should be created in the
run directory.  


However, changing the default location of the dccifd socket would break
many existing installations.

It is not necessary to patch the dccifd source to put the socket
anywhere you like.  Simply use -p, perhaps by adding -p/var/run/dcc
to DCCIFD_ARGS in /var/dcc/dcc_conf See the dccifd man page, perhaps
at http://www.dcc-servers.net/dcc/dcc-tree/dccifd.html#OPTION-p



} From: Bram <dcc-RusutVdil2g+VrKNYHDOSw< at >public.gmane.org>

}                   option DNSBL4-off
}                   MTA-last

} The last line should read "option MTA-last" instead of "MTA-last"

thanks.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

[DOC-PATCH] Error in man page

Bram — 2011-08-03T15:06:36

There appears to be an error in the dcc manpage:

Quote from man dcc:
"
                ....
                option MTA-first
                option MTA-last
                    consider MTA determinations of spam or not-spam  
first so they can be overridden by whiteclnt files, or last so that  
they can override whiteclnt files.
                ...
              In the absence of explicit settings, the default in the  
main whiteclnt file is equivalent to
                  option log-normal
                  option dcc-on
                  option greylist-on
                  option greylist-ignore-spam-off
                  option greylist-log-on
                  option DCC-rep-off
                  option DNSBL1-off
                  option DNSBL2-off
                  option DNSBL3-off
                  option DNSBL4-off
                  MTA-last
"

The last line should read "option MTA-last" instead of "MTA-last"

=> Patch (against dcc-1.3.140) attached.

Best regards,

Bram

[PATCH] Create the socket of dccifd in the rundir

Bram — 2011-08-03T15:04:09

Configure/the documentation suggest that the pid file and the sockets  
are created in the run directory:

 From ./Configure --help:
   --with-rundir=DIR    for PID files and milter socket

This however is not the case for dccifd.
It creates the socket in the homedir and not the run directory.

Attached is a patch (against dcc-1.3.140) that creates the socket for  
dccifd in the run directory and not in the homedir.


Best regards,

Bram

Re: errors in mail log

Vernon Schryver — 2011-07-05T13:25:21


It means that according to the entry in the /var/dcc/map file for
the DCC server at 127.0.0.1, the version number of the DCC client-server
protocol supposedly used by that DCC server is 0.  That suggests
that the DCC software has been modified, that the /var/dcc/map file
has been corrupted, or that the UNIX-like operating system being
used has bugs in its implementation of memory mapped files.

By the way, unless I'm confused, your current organization does not
have a DCC server connected to the global network of DCC servers.
The DCC mechanism is far less effective (and often useless) without
access to the real time reports of bulk email from the global network
of DCC servers.  In addition, running a DCC server that does not
exchange reports of bulk email with the global network violates the
license on the free version of the DCC software.


Vernon Schryver    vjs-w9Ndhk1xg/VWk0Htik3J/w< at >public.gmane.org

errors in mail log

Tom Kinghorn — 2011-07-05T09:49:09

Good morning all.

does anyone know why the following would appear in the logs

dccifd[29182]: impossible pkt_vers 0 for < at > (127.0.0.1,6277)

thanks

Tom