[RFE]: DNSBL Spam Blacklist

VERIFIED DUPLICATE of bug 121146

Status

MailNews Core
Filters
--
enhancement
VERIFIED DUPLICATE of bug 121146
16 years ago
7 years ago

People

(Reporter: alphawolf_, Assigned: Navin Gupta)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611
BuildID:    

There are various places on the net that store blacklists of spam abusing domain
names, which are quite effective. Normal filters can be avoided by spambots,
which makes them almost pointless. However, blacklists look for the name of the
server that the email is coming from, and compare that to one or more databases
of known offenders. These work quite well, and some ISPs use them at the mail
servers end, however most do not. There are some middleware programs that will
filter out mail based on these lists for people whose ISPs don't subscribe to
them. It would be nice to actualy have this built into mozilla mail.

For more information about spam blacklists, go to www.mail-abuse.org or
www.spews.org.

Reproducible: Always
Steps to Reproduce:
n/a

Actual Results:  n/a

Expected Results:  n/a

n/a

*** This bug has been marked as a duplicate of 121146 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 2

16 years ago
I dnon't agree, spamcop is a different system. It works by using volunteers to
manually forward suspicious mails. When they're recognized as spams, this
knowledge can be used in the spamcop.net mail-server, or in a local client.

What the author proposed here was a RBL- or ORDB-style system, which works
through DNS. It's normally implemented in the SMTP-servers, to refuse
connections from blacklisted hosts. But it's also possible in the client.

Both systems are ok, but different. And I think a DNS-based system is much
easier to implement, as long as you have fast parallel DNS-queries. It's only a
reverse lookup of the ip-address of all the mail-servers which were used in the
message.
(Reporter)

Comment 3

16 years ago
Basicaly what johan.rh.hermans@alcatel.be said. I guess either method would
work, but the DNS Blacklists would be more effective in that you can actualy
block any unidentified, never seen before spam from a domain name who is known
to spam. Also spamcops system seems like it could end up blacklisting simply
because somebody accidently marked a message as spam, whereas the DNS blacklists
are maintained by groups who will take steps to be aware of who it is they are
blocking, and try to work with the offenders to correct the situation if they
simply have an insecured/exploited mail server.

BTW: Heres an example of a client side implimented DNSBL:
http://www.twinlobber.org.uk/spampal

It's the only spam filter I've ever used that actualy works, and from the looks,
theres not that much spammers can do to get around it.

Comment 4

16 years ago
marking verified as a duplicate
Status: RESOLVED → VERIFIED
*** Bug 183874 has been marked as a duplicate of this bug. ***
*** Bug 198451 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 273455 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core

Comment 8

7 years ago
I don't understand why this bug was marked as a duplicate of 121146.

This bug is about implementing a spam filter based on DNS blacklist requests (examples of popular providers include bl.spamcop.net, psbl.surriel.com, cbl.abuseat.org, zen.spamhaus.org, dnsbl.sorbs.net, etc). Each message received would trigger a reverse DNS request and according to the result the email would be tagged as spam or ham.

The bug 121146 is about implementing a way to report spam to spamcop upon user request.

While it isn't altogether unrelated (spamcop maintains a DNSBL, although I am not sure if it contains IPs reported by spamcop users), it seems different enough to deserve a separate bug report.
You need to log in before you can comment on or make changes to this bug.