This is a list that MailPolice hosts and I have been running it for a few hours and it has already flagged some phish and fraud e-mails. Here is some info about the list: http://rhs.mailpolice.com/#rhsfraud
This is my configuration for SA 2.64 with the SpamCopURI plug-in:
uri MP_URI_RBL eval:check_spamcop_uri_rbl('fraud.rhs.mailpolice.com','127.0.0.2') describe MP_URI_RBL URI's domain appears in MailPolice fraud list tflags MP_URI_RBL net score MP_URI_RBL 2.0
And for SA 3.0 with the URIDNSBL plug-in:
urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A header URIBL_MP eval:check_uridnsbl('URIBL_MP') describe URIBL_MP URI's domain appears in MailPolice fraud list tflags URIBL_MP net score URIBL_MP 2.0
Bill
Hi!
This is a list that MailPolice hosts and I have been running it for a few hours and it has already flagged some phish and fraud e-mails. Here is some info about the list: http://rhs.mailpolice.com/#rhsfraud
This is my configuration for SA 2.64 with the SpamCopURI plug-in:
uri MP_URI_RBL eval:check_spamcop_uri_rbl('fraud.rhs.mailpolice.com','127.0.0.2') describe MP_URI_RBL URI's domain appears in MailPolice fraud list tflags MP_URI_RBL net score MP_URI_RBL 2.0
And for SA 3.0 with the URIDNSBL plug-in:
urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A header URIBL_MP eval:check_uridnsbl('URIBL_MP') describe URIBL_MP URI's domain appears in MailPolice fraud list tflags URIBL_MP net score URIBL_MP 2.0
Are those zones available for rsync (rbldnsd format) ? Can test it on my own cluster also then right now.
Nice to see more lists starting off.
Bye, Raymond.
Raymond Dijkxhoorn wrote:
Are those zones available for rsync (rbldnsd format) ? Can test it on my own cluster also then right now.
Nice to see more lists starting off.
The fraud list has been operating publically since around March. The zones are in rbldnsd format. I've been contemplating making them freely available, I just haven't gotten around to formally engineering a system to do this.
I suppose if anyone wants to, they can supply an ssh2 key, and I can set them up with rsync access.
On Friday, September 17, 2004, 3:10:48 PM, Jay Swackhamer wrote:
Raymond Dijkxhoorn wrote:
Are those zones available for rsync (rbldnsd format) ? Can test it on my own cluster also then right now.
Nice to see more lists starting off.
The fraud list has been operating publically since around March. The zones are in rbldnsd format. I've been contemplating making them freely available, I just haven't gotten around to formally engineering a system to do this.
I suppose if anyone wants to, they can supply an ssh2 key, and I can set them up with rsync access.
How about getting me rsync access to we can merge these in with the existing PH list. I'm sending you a public key privately.
How do you feel about the quality of the data.
David Hooton are you familiar with this effort? Got any feedback? :-)
Jeff C.
On Friday, September 17, 2004, 4:00:45 PM, Jeff Chan wrote:
On Friday, September 17, 2004, 3:10:48 PM, Jay Swackhamer wrote:
Raymond Dijkxhoorn wrote:
Are those zones available for rsync (rbldnsd format) ? Can test it on my own cluster also then right now.
Nice to see more lists starting off.
The fraud list has been operating publically since around March. The zones are in rbldnsd format. I've been contemplating making them freely available, I just haven't gotten around to formally engineering a system to do this.
I suppose if anyone wants to, they can supply an ssh2 key, and I can set them up with rsync access.
How about getting me rsync access to we can merge these in with the existing PH list. I'm sending you a public key privately.
How do you feel about the quality of the data.
David Hooton are you familiar with this effort? Got any feedback? :-)
Jeff C.
Or, instead of pulling them into PH (in multi), we could just mention to people to use them as fraud.rhs.mailpolice.com, as Bill Landry did in his examples.
This is also along the lines of what Patrik suggests in having a diversity of lists used as SURBLs, like there are for RBLs.
On the other hand, there is some convenience in having them in one place, and phishing is something good to stop as widely as possible.
Jeff C.
Can you clarify, are your lists intended to be sender domain lists or message body URI lists:
What is rhs.mailpolice.com?
MailPoliceTM maintains a domain-based list of domains which have been (ab)used to send spam to our customers. There are currently several domain-based lists: one which lists bulk mail senders and unsolicited advertisers; pornographic e-mailers and websites; reverse DNS hostnames of dynamic Internet connections; websites and IP's hosting fraudulant or phishing content; legitimate e-mail marketers and opt-in advertisers; and domains used by webmail providers.
What is the point of a domain-based list? what's wrong with an ip-rbl?
Judging e-mail based on the MAIL-FROM or hostname of the connecting mail server or websites advertised within an e-mail, is effective. Many unsolicited e-mailers regularly buy domains for the sole purpose of spam. No matter where the spam is sent from, it can be blocked based on the senders' domain name, or the domain name used in advertising URLs in the body of the e-mail.
Blocking based on IP address is effective only as long as the spammer continues to send from these IP addresses, it does not take into consideration that spammers can quickly move to another set of IP addresses, or use unlisted proxies.
Using a combination of domain-based and IP-based blacklists is an effective weapon against spam.
It sounds from the description that your RHS lists are sender domains as opposed to message body URI domains as we use with SURBLs.
That said, I can see how Bill may have found some overlap with message body URIs.
Jeff C.
----- Original Message ----- From: "Jeff Chan" jeffc@surbl.org
Can you clarify, are your lists intended to be sender domain lists or message body URI lists:
[SNIP]
It sounds from the description that your RHS lists are sender domains as opposed to message body URI domains as we use with SURBLs.
That said, I can see how Bill may have found some overlap with message body URIs.
Text from the link I posted with my previous message (http://rhs.mailpolice.com/#rhsfraud): =================== fraud.rhs.mailpolice.com
Domains and IPs involved in fraudulant activity, commonly referred to as "phishing". These sites appear in e-mail disguised as important notices from financial institutions (PayPal, EBay, banks), requesting credit card numbers or logon information. Using this list is highly encouraged when matching URLs inside an e-mail message. ===================
See the last sentence above.
Bill
On Friday, September 17, 2004, 4:32:41 PM, Bill Landry wrote:
----- Original Message ----- From: "Jeff Chan" jeffc@surbl.org
Can you clarify, are your lists intended to be sender domain lists or message body URI lists:
[SNIP]
It sounds from the description that your RHS lists are sender domains as opposed to message body URI domains as we use with SURBLs.
That said, I can see how Bill may have found some overlap with message body URIs.
Text from the link I posted with my previous message (http://rhs.mailpolice.com/#rhsfraud): =================== fraud.rhs.mailpolice.com
Domains and IPs involved in fraudulant activity, commonly referred to as "phishing". These sites appear in e-mail disguised as important notices from financial institutions (PayPal, EBay, banks), requesting credit card numbers or logon information. Using this list is highly encouraged when matching URLs inside an e-mail message. ===================
See the last sentence above.
Bill
Aha, maybe the other lists are more sender oriented than "fraud"?
Jeff C.
----- Original Message ----- From: "Jeff Chan" jeffc@surbl.org To: "SURBL Discuss" discuss@lists.surbl.org Sent: Friday, September 17, 2004 4:39 PM Subject: Re: [SURBL-Discuss] Additional phish/fraud list
On Friday, September 17, 2004, 4:32:41 PM, Bill Landry wrote:
----- Original Message ----- From: "Jeff Chan" jeffc@surbl.org
Can you clarify, are your lists intended to be sender domain lists or message body URI lists:
[SNIP]
It sounds from the description that your RHS lists are sender domains as opposed to message body URI domains as we use with SURBLs.
That said, I can see how Bill may have found some overlap with message body URIs.
Text from the link I posted with my previous message (http://rhs.mailpolice.com/#rhsfraud): =================== fraud.rhs.mailpolice.com
Domains and IPs involved in fraudulant activity, commonly referred to as "phishing". These sites appear in e-mail disguised as important notices
from
financial institutions (PayPal, EBay, banks), requesting credit card
numbers
or logon information. Using this list is highly encouraged when matching URLs inside an e-mail message. ===================
See the last sentence above.
Bill
Aha, maybe the other lists are more sender oriented than "fraud"?
All of the other lists are strictly sender oriented. They are all RHSBLs, and I have been using the "block" and "dynamic" lists with SA for over a year. The "block" list has a hit rate that's as high or higher than the spamcop ip4r list, and I have found the list to be pretty darn accurate, as well.
Bill
On Friday, September 17, 2004, 5:00:23 PM, Bill Landry wrote:
From: "Jeff Chan" jeffc@surbl.org
On Friday, September 17, 2004, 4:32:41 PM, Bill Landry wrote:
(http://rhs.mailpolice.com/#rhsfraud):
fraud.rhs.mailpolice.com
Domains and IPs involved in fraudulant activity, commonly referred to as "phishing". These sites appear in e-mail disguised as important notices
from
financial institutions (PayPal, EBay, banks), requesting credit card
numbers
or logon information. Using this list is highly encouraged when matching URLs inside an e-mail message. ===================
See the last sentence above.
Bill
Aha, maybe the other lists are more sender oriented than "fraud"?
All of the other lists are strictly sender oriented. They are all RHSBLs, and I have been using the "block" and "dynamic" lists with SA for over a year. The "block" list has a hit rate that's as high or higher than the spamcop ip4r list, and I have found the list to be pretty darn accurate, as well.
Bill
All good to know. Thanks for finally sharing. ;-)
Sounds like it's just the fraud list that we're interested in for SURBLs then.
Jeff C.
----- Original Message ----- From: "Jeff Chan" jeffc@surbl.org
All good to know. Thanks for finally sharing. ;-)
Sounds like it's just the fraud list that we're interested in for SURBLs then.
Well, maybe not. According to Jay's last post, possibly all of the lists could be queried via SURBL, which I was totally unaware of.
Bill
On Friday, September 17, 2004 7:20 PM, Jeff Chan wrote:
Can you clarify, are your lists intended to be sender domain lists or message body URI lists: http://rhs.mailpolice.com/ It sounds from the description that your RHS lists are sender domains as opposed to message body URI domains as we use with SURBLs.
For all the lists, it's both sender domain and URI's in the mail. Any domain found in the mail source that can be easily [as in automatically] linked to a spammer is listed. I wrote my own URI parser for email more than a year ago, and that's where all the data has come from.
I think I've tuned it enough so that false positives are basically eliminated, possibly at the expense of missing a few URIs. But that's why people should be using multple RHSBL's. :)
-- Jay Swackhamer jswack@nebularis.com MailPolice Spam&Virus Elimination http://www.mailpolice.com Nebularis Inc http://www.nebularis.com
----- Original Message ----- From: "Jay Swackhamer" jswack-lists@nebularis.com
For all the lists, it's both sender domain and URI's in the mail. Any domain found in the mail source that can be easily [as in automatically] linked to a spammer is listed. I wrote my own URI parser for email more than a year ago, and that's where all the data has come from.
I think I've tuned it enough so that false positives are basically eliminated, possibly at the expense of missing a few URIs. But that's why people should be using multple RHSBL's. :)
This is great news, Jay. I'll try using the block list with SURBL (since it includes the bulk, porn, and fraud lists) and see how it goes.
Thanks,
Bill
On Fri, 17 Sep 2004 16:00:45 -0700, Jeff Chan jeffc@surbl.org wrote:
How about getting me rsync access to we can merge these in with the existing PH list. I'm sending you a public key privately.
How do you feel about the quality of the data.
David Hooton are you familiar with this effort? Got any feedback? :-)
I think it would be great to have the additional data merged into PH if we can. I'm running some tests on the data over the weekend but so far can't see any reason why the 2 shouldn't be merged.
Collecting phishing data is something that requires the biggest possible catchment area, the more the merrier as far as I'm concerned - it's also very hard to mistake what a phishing email is so additional FP's really aren't much of an issue.
On Friday, September 17, 2004, 7:43:19 PM, David Hooton wrote:
On Fri, 17 Sep 2004 16:00:45 -0700, Jeff Chan jeffc@surbl.org wrote:
How about getting me rsync access to we can merge these in with the existing PH list. I'm sending you a public key privately.
How do you feel about the quality of the data.
David Hooton are you familiar with this effort? Got any feedback? :-)
I think it would be great to have the additional data merged into PH if we can. I'm running some tests on the data over the weekend but so far can't see any reason why the 2 shouldn't be merged.
Collecting phishing data is something that requires the biggest possible catchment area, the more the merrier as far as I'm concerned
- it's also very hard to mistake what a phishing email is so
additional FP's really aren't much of an issue.
Thanks for your feedback, David!
I agree FPs shouldn't happen too often with Phishes.
Is there much overlap between the MailSecurity and MailPolice phishing data?
Jeff C.
On Fri, 17 Sep 2004 19:49:07 -0700, Jeff Chan jeffc@surbl.org wrote:
Thanks for your feedback, David!
I agree FPs shouldn't happen too often with Phishes.
Is there much overlap between the MailSecurity and MailPolice phishing data?
I'm still investigating this now, but even if there is an overlap I'd say it would be minimal, we've found that geography seems to dictate the general profile of phishing attacks. Businesses and users from differing countries and even states seem to recieve quite different versions of the same old story.
Some phishers are also using the trojan that they send the message from as the redirector for the attack, so in theory every email could have a unique IP or URL in them.
I guess what I'm saying is that there is an awful lot of phishes happening and I don't think that Both MailSecurity and MailPolice are seeing the same slice of the pie :)
On Friday, September 17, 2004, 3:10:48 PM, Jay Swackhamer wrote:
Raymond Dijkxhoorn wrote:
Are those zones available for rsync (rbldnsd format) ? Can test it on my own cluster also then right now.
Nice to see more lists starting off.
The fraud list has been operating publically since around March.
OK taking a look at the fraud.rhs.mailpolice.com data, there's not too much overlap with the MailSecurity phishing data which we're currently using in PH in muli.surbl.org.
The former has about 260 records, and the latter has about 400 records, and the overlap is around 25 records. So adding in the mailpolice fraud data would grow PH by about 240 new records.
Most of the data looks pretty regular, but one difference is that the mailpolice data has some records like these:
1380781-usd10.e-gold.com accountassistant.z6.com.br cgi4-awconfirmisapidll-38u3428.cjb.net citibank.com.userset.net dfko49b.mail333.com halifax-online.co.uk.userset.net homelink.form.accepted.cc homelink.form.accepted.pula.cc paypalzzzz.tripod.com pcp09296036pcs.arlngt01.va.comcast.net proba21.netfirms.com rranostand.home.ro xyxca.home.ro your-tradetool.com zyxell9.clawz.com [not a complete list of these longer domains]
which we would typically try to reduce to their base (registrar) domains. Reducing would cause some obvious false positives, for example comcast.net, if we did not happen to whitelist it.
Some of these also don't make sense. e-gold.com is legitimate, and www.e-gold.com and 1380781-usd10.e-gold.com resolve to the same IP address. Why would e-gold phish themselves or allow a phisher to be hosted on their main web server?
One solution would be to not reduce. Another would be to discard these longer domains, but it's not too easy to detect which ones to discard. Neither solution is really great, but they're both better than reducing, because of the FPs that would create.
The un-reduced longer domains basically won't be matched by most code using SURBLs, because the client-side code usually tries to reduce to base domains. So if we leave the longer domains in the data, aside from making the data a little larger, it doesn't have too much downside. On the other hand since multi.surbl.org is a logical "or" of all domains, any extra records in any list going into multi.surbl.org makes multi unnecessarily longer. But the number of these longer domains is probably minor in the larger picture: a dozen or two.
Also Jay: example.tld is on the list. That doesn't resolve and probably isn't useful for fraud or phishing so you may want to consider removing it. ;-)
It would be nice to figure out these issues before adding the mailpolice fraud data into PH.
Comments?
Jeff C.
On Sat, 18 Sep 2004 00:33:59 -0700, Jeff Chan jeffc@surbl.org wrote:
OK taking a look at the fraud.rhs.mailpolice.com data, there's not too much overlap with the MailSecurity phishing data which we're currently using in PH in muli.surbl.org.
The former has about 260 records, and the latter has about 400 records, and the overlap is around 25 records. So adding in the mailpolice fraud data would grow PH by about 240 new records.
Most of the data looks pretty regular, but one difference is that the mailpolice data has some records like these:
<snip>
which we would typically try to reduce to their base (registrar) domains. Reducing would cause some obvious false positives, for example comcast.net, if we did not happen to whitelist it.
Hmm, this is not great.
One solution would be to not reduce. Another would be to discard these longer domains, but it's not too easy to detect which ones to discard. Neither solution is really great, but they're both better than reducing, because of the FPs that would create.
This is probably the best approach.
Also Jay: example.tld is on the list. That doesn't resolve and probably isn't useful for fraud or phishing so you may want to consider removing it. ;-)
It would be nice to figure out these issues before adding the mailpolice fraud data into PH.
Agreed on all counts.
On Saturday, September 18, 2004, 2:38:29 AM, David Hooton wrote:
On Sat, 18 Sep 2004 00:33:59 -0700, Jeff Chan jeffc@surbl.org wrote:
Most of the data looks pretty regular, but one difference is that the mailpolice data has some records like these:
<snip> > which we would typically try to reduce to their base (registrar) > domains. Reducing would cause some obvious false positives, for > example comcast.net, if we did not happen to whitelist it.
Hmm, this is not great.
One solution would be to not reduce. Another would be to discard these longer domains, but it's not too easy to detect which ones to discard. Neither solution is really great, but they're both better than reducing, because of the FPs that would create.
This is probably the best approach.
Thanks for the feedback! :-)
BTW for anyone who wants to check them out, the slightly processed list, which would go into PH is at:
http://spamcheck.freeapp.net/mailpolice-fraud.srt
The changes are my standard ones:
1. force to lower case 2. discard records that have other than [a-z0-9.-] (original style domain name restrictions)
Unusually in this case don't try to reduce gtlds to two levels.
Jeff C.
On Saturday, September 18, 2004 5:38 AM, David Hooton wrote:
Also Jay: example.tld is on the list. That doesn't resolve and probably isn't useful for fraud or phishing so you may want to consider removing it. ;-)
It would be nice to figure out these issues before adding the mailpolice fraud data into PH.
Agreed on all counts.
Yes, example.tld was always in there for testing purposes. It's a never-used domain name, so it's safe for inclusion, and good for verification, IMHO. Same could be said for example.com.
-- Jay Swackhamer jswack@nebularis.com Nebularis Inc http://www.nebularis.com Tel: 1-613-843-9358 Fax: 1-613-825-5960
On Saturday, September 18, 2004, 5:14:24 PM, Jay Swackhamer wrote:
On Saturday, September 18, 2004 5:38 AM, David Hooton wrote:
Also Jay: example.tld is on the list. That doesn't resolve and probably isn't useful for fraud or phishing so you may want to consider removing it. ;-)
It would be nice to figure out these issues before adding the mailpolice fraud data into PH.
Agreed on all counts.
Yes, example.tld was always in there for testing purposes. It's a never-used domain name, so it's safe for inclusion, and good for verification, IMHO. Same could be said for example.com.
Fair enough. We added our own testpoints, but chose different ones.
http://www.surbl.org/faq.html#testpoints
We whitelist example.tld, example.com, etc. to keep them off our lists anyway.
http://spamcheck.freeapp.net/whitelists/placeholder-domains.sort
Jeff C.
Question for Jay: can you make us a cut of the fraud data that contains only URI domains and IP addresses, not any sender domains or IPs?
Jeff C.
On Saturday, September 18, 2004 3:33 AM, Jeff Chan wrote:
Most of the data looks pretty regular, but one difference is that the mailpolice data has some records like these: 1380781-usd10.e-gold.com [ ... ] Some of these also don't make sense. e-gold.com is legitimate, and www.e-gold.com and 1380781-usd10.e-gold.com resolve to the same IP address. Why would e-gold phish themselves or allow a phisher to be hosted on their main web server?
There was a phishing attempt a couple months ago using a legitimate e-gold.com account for donations to the Red Cross. E-gold expresses their accounts as subdomains to the e-gold.com domain. After contacting e-gold, they did disable the account, but there still were emails with that subdomain being circulated AND the page still did resolve.
The same for other domains that allow signups using subdomains, like "paypal-cgi-bin.tripod.com" etc.
I do lookups on the entire URI, without shortening it. And then I use wildcards in the DNS zone (which should be shortened as much as possible down to the second or third subdomain) so they resolve. That's worked very well in my experience for the past year. Most of the fraud data is reviewed and added manually because of the high subdomain abuse.
-- Jay Swackhamer jswack@nebularis.com Nebularis Inc http://www.nebularis.com MailPolice Spam&Virus Elimination http://www.mailpolice.com Tel: 1-613-843-9358 Fax: 1-613-825-5960
On Saturday, September 18, 2004, 5:26:13 PM, Jay Swackhamer wrote:
On Saturday, September 18, 2004 3:33 AM, Jeff Chan wrote:
Most of the data looks pretty regular, but one difference is that the mailpolice data has some records like these: 1380781-usd10.e-gold.com [ ... ] Some of these also don't make sense. e-gold.com is legitimate, and www.e-gold.com and 1380781-usd10.e-gold.com resolve to the same IP address. Why would e-gold phish themselves or allow a phisher to be hosted on their main web server?
There was a phishing attempt a couple months ago using a legitimate e-gold.com account for donations to the Red Cross. E-gold expresses their accounts as subdomains to the e-gold.com domain. After contacting e-gold, they did disable the account, but there still were emails with that subdomain being circulated AND the page still did resolve.
The same for other domains that allow signups using subdomains, like "paypal-cgi-bin.tripod.com" etc.
I do lookups on the entire URI, without shortening it. And then I use wildcards in the DNS zone (which should be shortened as much as possible down to the second or third subdomain) so they resolve. That's worked very well in my experience for the past year. Most of the fraud data is reviewed and added manually because of the high subdomain abuse.
Thanks for clarifying that point. I guessed from the data that yours was working with the whole URI instead of trying to reduce to a base domain like we do. It's a different design decision.
The two strategies can be compatible in a somewhat kludgey way if we chose to not reduce the whole URI data, causing them to not match the domains extracted by SURBL code from messages found in the wild.
I'd still be interested to hear if you may be able to provide a version of the fraud data without sender domains or sender IPs. (On the other hand, the fraud list is probably too short to be including those, so is it already the case that senders are not in fraud?)
Jeff C.
On Saturday, September 18, 2004 9:06 PM, Jeff Chan wrote:
The two strategies can be compatible in a somewhat kludgey way if we chose to not reduce the whole URI data, causing them to not match the domains extracted by SURBL code from messages found in the wild.
Yeah, that could possibly be an argument in the eval function... something like "check_uridnsbl('URIBL',1)" where the 1 does a match against the whole URI, but otherwise defaults to the URI reduction.
I'd still be interested to hear if you may be able to provide a version of the fraud data without sender domains or sender IPs.
In the case of the fraud list, I recall that all the data is from URIs, and doesn't contain any sender IP or reverse DNS info.
-- Jay Swackhamer jswack@nebularis.com Nebularis Inc http://www.nebularis.com MailPolice Spam&Virus Elimination http://www.mailpolice.com Tel: 1-613-843-9358 Fax: 1-613-825-5960
On Saturday, September 18, 2004, 10:35:35 PM, Jay Swackhamer wrote:
On Saturday, September 18, 2004 9:06 PM, Jeff Chan wrote:
The two strategies can be compatible in a somewhat kludgey way if we chose to not reduce the whole URI data, causing them to not match the domains extracted by SURBL code from messages found in the wild.
Yeah, that could possibly be an argument in the eval function... something like "check_uridnsbl('URIBL',1)" where the 1 does a match against the whole URI, but otherwise defaults to the URI reduction.
That would allow the function to use both types of data. Getting them mixed up could create problems though.
I'd still be interested to hear if you may be able to provide a version of the fraud data without sender domains or sender IPs.
In the case of the fraud list, I recall that all the data is from URIs, and doesn't contain any sender IP or reverse DNS info.
That sounds right, looking at the data.
Jeff C.
Hi!
I'd still be interested to hear if you may be able to provide a version of the fraud data without sender domains or sender IPs.
In the case of the fraud list, I recall that all the data is from URIs, and doesn't contain any sender IP or reverse DNS info.
Sounds great.
Thanks for explaining.
Bye, Raymond.
On Friday, September 17, 2004, 2:47:57 PM, Bill Landry wrote:
This is a list that MailPolice hosts and I have been running it for a few hours and it has already flagged some phish and fraud e-mails. Here is some info about the list: http://rhs.mailpolice.com/#rhsfraud
This is my configuration for SA 2.64 with the SpamCopURI plug-in:
uri MP_URI_RBL eval:check_spamcop_uri_rbl('fraud.rhs.mailpolice.com','127.0.0.2') describe MP_URI_RBL URI's domain appears in MailPolice fraud list tflags MP_URI_RBL net score MP_URI_RBL 2.0
And for SA 3.0 with the URIDNSBL plug-in:
urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A header URIBL_MP eval:check_uridnsbl('URIBL_MP') describe URIBL_MP URI's domain appears in MailPolice fraud list tflags URIBL_MP net score URIBL_MP 2.0
Bill
Let's ask more people to test the mailpolice fraud list in their SURBL installations as Bill, David and others are doing.
If the results of additional testing are good we may merge this data into our phishing list, PH in multi.
In particular we'd like to know if anyone gets any false positives. We're not expecting any FPs, but it's good to do some testing before we include this data officially.
As noted earlier, unlike SURBLs the mailpolice lists take the entire URI including subdomains, host names, etc., but since the SURBL client code tries to reduce URIs to base domains before checking them against the list, these should not causes matches resulting in FPs.
So please give it a try, and share what you find.
Thanks,
Jeff C.
----- Original Message ----- From: "Jeff Chan" jeffc@surbl.org
Let's ask more people to test the mailpolice fraud list in their SURBL installations as Bill, David and others are doing.
If the results of additional testing are good we may merge this data into our phishing list, PH in multi.
In particular we'd like to know if anyone gets any false positives. We're not expecting any FPs, but it's good to do some testing before we include this data officially.
As noted earlier, unlike SURBLs the mailpolice lists take the entire URI including subdomains, host names, etc., but since the SURBL client code tries to reduce URIs to base domains before checking them against the list, these should not causes matches resulting in FPs.
So please give it a try, and share what you find.
I've switched from the single MP "fraud" list to combined "block" list, which includes bulk, porn, and fraud. So far I am very please with the results. However, it is the weekend when spam to ham ratios are much greater than during the week. So, the true test will come next week. After I get back into town on Wednesday, I will post some result stats.
Bill
Bill
-
Bill Landry -
David Hooton -
Jay Swackhamer -
Jeff Chan -
Raymond Dijkxhoorn