How to solve this?

Vernon Schryver
Tue Nov 12 17:39:07 UTC 2002

> From: Peter Beckman <>

> When spammers use the same To: address as the From: address, it is for that
> e-mail only.  Yes, your From: email hash will go into the database, but it
> will be counted once, and therefore not rejected.  Most spammers either use
> a fake From: address, the same as the recipient, or a random From: address
> to prevent blocking of their spam.

How are the From and To address related to the spam filtering done
by the DCC, except for white- or blacklisting known-good or bad
sources or non-participating destinations?  Unless you are running
a private DCC server with -Kfrom, From addresses are not put into
any DCC database I know about.

>                                     I don't think there has been a case
> where a spammer uses one real recipient's email address as the From: for
> all the spam that they are sending.

What about the famous case at ?

Afer that and until recently, most spammers have not been using
valid addresses that were not their own (e.g. free provider drop-boxes).
The many bounces and "remove requests" that spam targets are receiving
show that some spammers are now using addresses from their target
lists as From values.  A high profile legal action or two against
those forgers would help, but who knows when or if that might happen?

> However, what I don't know is what happens when I do "dccproc -t many" on a
> message that may contain the same From: and To: address -- does the server
> return "many" for emails FROM me if I accidentally run dccproc that way
> manually?

None of the DCC servers in the global network I know about run with -KFrom
or -Kenv_from and so none of them put anything about from addresses into
their database.  DCC clients do not send Env_To hash values to servers.
See the main DCC man page and the dccd man page.


On Tue, 12 Nov 2002, Valentin Chopov wrote:

] I got the following problem.
] When the spam  sent with the same "from:" and "to:" address,  the
] sender mail server return the DCC rejected message to the recipent.
] ...

Some of this spam might be avoided by using a blacklist of spam sources
including open relays.  However, all of the public open relay blacklists
that I know of send unsolicited bulk email as tests, including to systems
that have not sent (including relayed) any unsolicited bulk mail.

Bouncing spam can be avoided by discarding instead of rejecting spam,
such as with `dccm -aDISCARD`.
The difficulty with this tactic is false positives such as solicited
but not-white-listed bulk mail will disappear without complaints
to the sender.   This might be tolerable if you use per-user logging
and convince your users to check their logs with something like the cron
script and CGI scripts in /var/dcc/cgi-bin.

More information about the DCC mailing list

Contact by mail or use the form.