Tue Nov 12 17:39:07 UTC 2002
> From: Peter Beckman <email@example.com> > 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 Flowers.com case at http://www.google.com/search?q=%22flowers.%2Bcom%22+spam http://www.rahul.net/falk/zilkerjudge.txt ? 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