You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/04/03 01:27:13 UTC
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff Chan writes:
> On Friday, April 2, 2004, 2:11:39 AM, Jeff Chan wrote:
> > If it's the case that domains expire out of the SpamCop
> > URI data sooner than the particular spam domains remain
> > a problem, then I could definitely see a need for a longer
> > expiration. Being somewhat new to the game, I don't
> > have any data to support either argument.
>
> OK I can see one flaw in my argument would be that if message
> body domain blocking were already popular and successful then
> *reporting* about spam URIs would taper off as fewer spams
> reached victims, even if the spam-referenced domains stayed
> up. In that case we could simply increase our expiration
> time to make the blocking persist long after the reports
> tapered off. (But there still should be some mechanism for
> expiring domains off the block list, whatever time period
> is used. Or there should be some other method of removing
> domains from the list.)
>
> Does anyone have any data about the persistence of spam URI
> domains? I'll even settle for any data about spam web server
> IP addresses. :-)
I've seen the same domain being used for several months.
BTW I would suggest a TTL in the list of at least 1 month for reported
URIs. If you're worried about FPs hanging around for long, provide a very
easy removal method (e.g. web form or email). Don't bother trying to
assess the spamminess or otherwise of the requester, just remove the URL
ASAP (and log the action, of course).
Side issue: why use easy removal without questions? Spammers do not have
the bandwidth to remove themselves from every list. If they *do* go to
the bother, and a URL does get removed, then repeatedly crops up in spam
again, it should be raised as an alarm -- and possibly brought to the
notice of other people -- e.g. this list or others.
If it really is a spammy URL and the spammer just keeps removing it, I'd
imagine the URL would be noted as such and quickly find its way into
systems that *don't* offer easy removal. ;) If it isn't a spammy URL,
then you've saved yourself a lot of FPs and annoyed users, without
requiring much legwork on your part.
Basically the philosophy is to make it easy for anyone to remove an
URL from the list.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFAbfbRQTcbUG5Y7woRAlB0AJoDZtBP7lqSmUDngr9kBASS2VvJpgCfSG6v
8JNhCJUWh2C5X7NDm86crEE=
=i2Ij
-----END PGP SIGNATURE-----
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Saturday, April 3, 2004, 12:52:23 PM, Daniel Quinlan wrote:
> Jeff Chan <je...@surbl.org> writes:
>> I agree with the content check, but will step on many toes here
>> by proclaiming that other blacklists (other than SBL), name
>> servers, registrars, ISP address blocks, and similar approaches
>> are overly broad and have too much potential for collateral
>> damage *for my sensibilities*.
> There are other blacklists just as accurate as SBL (and some more
> accurate). And bear in mind these are secondary checks to lower the
> threshold for a URI already reported to SpamCop so the accuracy should
> be really good (two 99% accurate features => more than 99% accurate
> together).
Understood. I never claimed SURBL was a 100% solution to all
spam, but I feel it can give some good results which could be
useful and probably should not be ignored. I absolutely agree
it should be used in conjunction with other RBLs and techniques.
>> I really, really hate blacklisting innocent victims. I consider that
>> a false accusation or even false punishment. Having policies which
>> allow blacklisting an entire ISP or even an entire web server IP
>> address have the potential to harm too many innocent bystanders, IMO.
>> Your mileage may and probably does vary. ;)
> You already have a repeated URL.
Not sure what you mean. If you mean a domain fell off the list
then came back on, I agree that's possible with the current
simple, initial tuning. If you mean there are multiple domains
on the list resolving to the same web server or using the same
name server, yes, that's definitely going to happen.
> Are you just railing about other
> blacklists or did you really consider my suggestion?
See above. I'm not comfortable with all RBLs or their
approaches, but I use some myself. I definitely agree
SURBL should be used with other RBLs to catch spams it
may miss. The more pre-emptive approach of SBL and others
like it seem justified in terms of catching known spam
gangs, spamhausen and the like.
> I think pre-seeding a whitelist would be a sensible precaution against
> joe jobs and the more sporadic (for any one domain, SpamCop has false
> positives probably every day) type of false positive.
Yes, we are pre-seeding our whitelist. Any whitelists
anyone wants to share with us or reference would be gratefully
accepted and also hand checked by me before any get added
to our whitelist.
> I only made these suggestions to
> potentially allow you to selectively lower or raise your threshold for
> specific URLs based on other data and therefore increase your accuracy
> and spam hit rate.
Yes and I appreciate your suggestions. I think we may be
agreeing more than disagreeing.
I will definitely let folks here know when we have a 3.0
plugin, modify URIDNSBL, can find some coding help, etc.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Daniel Quinlan <qu...@pathname.com>.
Jeff Chan <je...@surbl.org> writes:
> I agree with the content check, but will step on many toes here
> by proclaiming that other blacklists (other than SBL), name
> servers, registrars, ISP address blocks, and similar approaches
> are overly broad and have too much potential for collateral
> damage *for my sensibilities*.
There are other blacklists just as accurate as SBL (and some more
accurate). And bear in mind these are secondary checks to lower the
threshold for a URI already reported to SpamCop so the accuracy should
be really good (two 99% accurate features => more than 99% accurate
together).
OVERALL% SPAM% HAM% S/O RANK SCORE NAME
69948 37790 32158 0.540 0.00 0.00 (all messages)
100.000 54.0258 45.9742 0.540 0.00 0.00 (all messages as %)
1.016 1.8815 0.0000 1.000 0.93 8.60 RCVD_IN_OPM_SOCKS
2.918 5.3956 0.0062 0.999 0.94 0.62 RCVD_IN_NJABL_DIALUP
1.138 2.1037 0.0031 0.999 0.93 8.60 RCVD_IN_OPM_HTTP
1.107 2.0455 0.0031 0.998 0.93 8.60 RCVD_IN_OPM_HTTP_POST
7.769 14.3292 0.0591 0.996 0.94 1.27 RCVD_IN_SBL
2.698 4.9749 0.0218 0.996 0.93 0.53 RCVD_IN_RSL
19.630 36.1842 0.1772 0.995 0.97 2.55 RCVD_IN_SORBS_DUL
3.127 5.7581 0.0342 0.994 0.92 0.74 RCVD_IN_NJABL_SPAM
9.759 17.9360 0.1493 0.992 0.93 1.20 RCVD_IN_SORBS_MISC
5.067 9.3146 0.0746 0.992 0.92 0.01 T_RCVD_IN_AHBL_SPAM
0.815 1.4978 0.0124 0.992 0.91 1.20 RCVD_IN_SORBS_SMTP
32.202 59.1532 0.5317 0.991 0.99 1.10 RCVD_IN_DSBL
17.386 31.8735 0.3607 0.989 0.95 1.00 RCVD_IN_XBL
13.524 24.8002 0.2736 0.989 0.94 1.20 RCVD_IN_NJABL_PROXY
9.088 16.6711 0.1772 0.989 0.93 1.20 RCVD_IN_SORBS_HTTP
(some older mail being tested, so these numbers are going to be somewhat
off)
> I really, really hate blacklisting innocent victims. I consider that
> a false accusation or even false punishment. Having policies which
> allow blacklisting an entire ISP or even an entire web server IP
> address have the potential to harm too many innocent bystanders, IMO.
> Your mileage may and probably does vary. ;)
You already have a repeated URL. Are you just railing about other
blacklists or did you really consider my suggestion? SpamCop is no more
accurate than the above blacklists. People report ham all the time,
sometimes repeatedly.
> Our approach is to start with some likely good data in the
> SpamCop URIs. See comments below.
And these are ways to make the data more accurate.
> I agree in principle, however I feel that the SpamCop reported
> URIs tend to have relatively few FPs. They are domains that
> people took the time to report; in essence they are *voting with
> their time that these are spam domains*.
Again, SpamCop has false positives. It is no magic bullet. Some
mailing lists are very low volume so when an announcement or conference
notice goes out, people report it as spam even though they actually
subscribed. It happens all the time.
I think pre-seeding a whitelist would be a sensible precaution against
joe jobs and the more sporadic (for any one domain, SpamCop has false
positives probably every day) type of false positive.
> I hope I'm not taking too confrontational a tone here. I'm just
> trying to defend our approach, which I think can be valid.
Nobody is attacking your approach. I only made these suggestions to
potentially allow you to selectively lower or raise your threshold for
specific URLs based on other data and therefore increase your accuracy
and spam hit rate. I suspect your blacklist will work well once a
plug-in supports it, but until then it seems like further discussion is
a waste of my time.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Saturday, April 3, 2004, 1:29:44 AM, Jeff Chan wrote:
> On Saturday, April 3, 2004, 12:34:24 AM, Daniel Quinlan wrote:
>> domain name
>> check name servers in other blacklists
>> check registrar
>> check age of domain (SenderBase information)
>> check ISP / IP block owner (SenderBase, SBL, etc.)
> name
> servers, registrars, ISP address blocks, and similar approaches
> are overly broad
I should add that I fully understand that there are rogue
ISPs, rogue name servers, rogue netblocks, etc., all of
which deserve something much stronger than simply being
rejected, blocked or blackholed. But SBL aside, it can be
difficult to successfully identify the true bad guys using
the above without catching too many innocents in the same
net.
That said, I use several of these other RBLs myself. I'm
not necessarily opposed to them, but feel our approach with
SURBL *adds* something hopefully new and effective.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Saturday, April 3, 2004, 12:34:24 AM, Daniel Quinlan wrote:
> Jeff Chan <je...@surbl.org> writes:
>> Can you cite some examples of FP-prevention strategies?
> 1. Automated testing. We're testing URLs (web sites). That allows a
> large number of strategies which could be used from each aspect of
> the URL.
> A record
> check other blacklists
> check IP owner against SBL
> domain name
> check name servers in other blacklists
> check registrar
> check age of domain (SenderBase information)
> check ISP / IP block owner (SenderBase, SBL, etc.)
> web content
> check web site for common spam web site content (porn, drugs, credit
> card forms, empty top-level page, etc.)
> Any of those can also be used in concert with threshold tuning. For
> example, lower thresholds if a good blacklist hits and somewhat
> higher thresholds for older domains.
I agree with the content check, but will step on many toes here
by proclaiming that other blacklists (other than SBL), name
servers, registrars, ISP address blocks, and similar approaches
are overly broad and have too much potential for collateral
damage *for my sensibilities*. I really, really hate
blacklisting innocent victims. I consider that a false
accusation or even false punishment. Having policies which allow
blacklisting an entire ISP or even an entire web server IP
address have the potential to harm too many innocent bystanders,
IMO. Your mileage may and probably does vary. ;)
Our approach is to start with some likely good data in the
SpamCop URIs. See comments below.
> 2. Building up a long and accurate whitelist of good URLs over time
> would also help. Maybe work with places that vouch for domain's
> anti-spam policies (Habeas, BondedSender, IADB) to develop longer
> whitelists.
I agree in principle, however I feel that the SpamCop reported
URIs tend to have relatively few FPs. They are domains that
people took the time to report; in essence they are *voting with
their time that these are spam domains*.
That's one of the reasons our whitelist is quite small now (@ 35)
yet catches the few legitimate domains and subdomains that
survive the reporting and thresholding and are (mis-over-)reported
enough to get onto the list before I can notice and whitelist
them. That need has been small so far.
http://spamcheck.freeapp.net/whitelist-domains
> 3. Using a corpus to tune results and thresholds (also whitelist
> seeding).
Agreed. Currently we lack spam and ham corporea of our own and
have not had a chance to set some up yet. That may come later
though.
I hope I'm not taking too confrontational a tone here. I'm
just trying to defend our approach, which I think can be valid.
I also realize people have a lot of work invested in other
approaches, but I hope they will eventually give ours a try.
I feel it has value, even if I can't prove it conclusively
myself yet. LOL! :-)
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Daniel Quinlan <qu...@pathname.com>.
Jeff Chan <je...@surbl.org> writes:
> Can you cite some examples of FP-prevention strategies?
1. Automated testing. We're testing URLs (web sites). That allows a
large number of strategies which could be used from each aspect of
the URL.
A record
check other blacklists
check IP owner against SBL
domain name
check name servers in other blacklists
check registrar
check age of domain (SenderBase information)
check ISP / IP block owner (SenderBase, SBL, etc.)
web content
check web site for common spam web site content (porn, drugs, credit
card forms, empty top-level page, etc.)
Any of those can also be used in concert with threshold tuning. For
example, lower thresholds if a good blacklist hits and somewhat
higher thresholds for older domains.
2. Building up a long and accurate whitelist of good URLs over time
would also help. Maybe work with places that vouch for domain's
anti-spam policies (Habeas, BondedSender, IADB) to develop longer
whitelists.
3. Using a corpus to tune results and thresholds (also whitelist
seeding).
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Friday, April 2, 2004, 4:23:51 PM, Daniel Quinlan wrote:
> jm@jmason.org (Justin Mason) writes:
>> Side issue: why use easy removal without questions? Spammers do not have
>> the bandwidth to remove themselves from every list. If they *do* go to
>> the bother, and a URL does get removed, then repeatedly crops up in spam
>> again, it should be raised as an alarm -- and possibly brought to the
>> notice of other people -- e.g. this list or others.
> I'm not so sure easy removal is actually a good idea. I think it's
> better to have FP-prevention mechanisms that don't require attention of
> the email sender.
Can you cite some examples of FP-prevention strategies?
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Daniel Quinlan <qu...@pathname.com>.
jm@jmason.org (Justin Mason) writes:
> Side issue: why use easy removal without questions? Spammers do not have
> the bandwidth to remove themselves from every list. If they *do* go to
> the bother, and a URL does get removed, then repeatedly crops up in spam
> again, it should be raised as an alarm -- and possibly brought to the
> notice of other people -- e.g. this list or others.
I'm not so sure easy removal is actually a good idea. I think it's
better to have FP-prevention mechanisms that don't require attention of
the email sender.
Why? Because it's a mechanism biased towards savvy users, people who
use blacklists, SpamAssassin, etc. In addition, it's exactly the same
folks who are already overrepresented in our ham corpus. So, the
effective FP rate will be higher than it appears in our corpus *and*
non-savvy senders will be penalized.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Friday, April 2, 2004, 8:53:46 PM, Loren Wilton wrote:
>> On Friday, April 2, 2004, 3:27:13 PM, Justin Mason wrote:
>> > Jeff Chan writes:
>> >> Does anyone have any data about the persistence of spam URI
>> >> domains? I'll even settle for any data about spam web server
>> >> IP addresses. :-)
> Jeff, it seems to me that you are in a good place to start figuring this
> out. Simply make some sort of database by reported URL (or the part you
> keep) and log the dates you find it reported. Any persistant domain is
> going to be reported either persistantly, or at least repeatedly.
> You could even make an exception report that showed the domains that are
> being reported consistantly for more than say 7 days.
Hehe, you're right about who can answer this question.
One issue is that we've only been collecting data for
a little over a month so we don't have the historical
view of some of these issues yet. So the feedback from
folks is definitely helpful. :)
Somewhat oddly I just added logging of the new spam
domains as they reach the threshold and get added to
the rbl as a result, just before you wrote. So now
we will be able to see if any domains drop off the list
and come back on with the current expiration. The log
is visible at:
http://spamcheck.freeapp.net/top-sites-domains.new.log
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Loren Wilton <lw...@earthlink.net>.
> On Friday, April 2, 2004, 3:27:13 PM, Justin Mason wrote:
> > Jeff Chan writes:
> >> Does anyone have any data about the persistence of spam URI
> >> domains? I'll even settle for any data about spam web server
> >> IP addresses. :-)
Jeff, it seems to me that you are in a good place to start figuring this
out. Simply make some sort of database by reported URL (or the part you
keep) and log the dates you find it reported. Any persistant domain is
going to be reported either persistantly, or at least repeatedly.
You could even make an exception report that showed the domains that are
being reported consistantly for more than say 7 days.
Loren
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Friday, April 2, 2004, 4:42:34 PM, Jeff Chan wrote:
> Something like an inverse logarithmic function
> where the input is the spam count and the output is the
> number of days to keep it on the list
Correction that should be a log function.
A linear function like reports/10 + 1 could also work. With such
a linear function 10 reports would get a domain on the list for 2
days, and 600 reports would get a domain on the list for 61 days.
(That's roughly the range of counts we're seeing now.) The data
itself already has a normal-looking curve to the counts.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Friday, April 2, 2004, 9:02:59 PM, Loren Wilton wrote:
> Jeff, I had a look at your list at some random time a few days ago. I
> noticed that the top 90% or so of the reports looked pretty solid. At the
> instant I looked, the bottom 10% of the reports were most all highly
> suspect. This is where the yahoo and geocities and other whitelist stuff
> was showing up. Some other reports (and I can't remember what any of them
> were) also seemed somewhat suspect, even though they probably weren't on a
> whitelist.
> I concluded that only the top 90% of your reports should be used in the
> blocking test, and ignore the reports with less than 10% of the
> highest-scoring report. Now, perhaps this percentage fluxuates with time, I
> certainly haven't made multiple checks to see. And maybe after whitelist
> removal the rest of the bottom 10% really is spam.
> But I think it would be an interesting experiment to compare the relibility
> of the top 90% to the relibility of the entire collection.
Thanks for checking this over for us! It looks like you visited:
http://spamcheck.freeapp.net/top-sites.html
which does not have the whitelist entries removed from it and
which does not go all the way down to the threshold of 10 spams.
The full list which is about 11000 entries can be seen at:
http://spamcheck.freeapp.net/top-sites.txt
This is a basis for the thresholded 400 or so domains at:
http://spamcheck.freeapp.net/top-sites-domains
which doesn't show the counts used to threshold, but they
all got over 10 counts. It does however have some duplicates
like www.domain.com for domain.com eliminated and perhaps most
importantly *has had the whitelisted domains and two level ccTLDs
removed*. It is the basis for the RBL:
http://spamcheck.freeapp.net/surbl.bind
Due to the whitelisting and thresholding, the domains that make it
into SURBL are quite spammy, hopefully and probably more than the
90% you estimated on the unfiltered list.
Cheers,
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Loren Wilton <lw...@earthlink.net>.
Jeff, I had a look at your list at some random time a few days ago. I
noticed that the top 90% or so of the reports looked pretty solid. At the
instant I looked, the bottom 10% of the reports were most all highly
suspect. This is where the yahoo and geocities and other whitelist stuff
was showing up. Some other reports (and I can't remember what any of them
were) also seemed somewhat suspect, even though they probably weren't on a
whitelist.
I concluded that only the top 90% of your reports should be used in the
blocking test, and ignore the reports with less than 10% of the
highest-scoring report. Now, perhaps this percentage fluxuates with time, I
certainly haven't made multiple checks to see. And maybe after whitelist
removal the rest of the bottom 10% really is spam.
But I think it would be an interesting experiment to compare the relibility
of the top 90% to the relibility of the entire collection.
Loren
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Friday, April 2, 2004, 3:52:31 PM, Jeff Chan wrote:
> We have enough history built up that I should be able
> to see if they would have fallen off my lists at certain points
> due to our relatively short expiration. I might be able to use
> that information to tune the expirations better.
After I wrote this I remembered a strategy someone else may have
suggested here earlier (unfortunately can't remember where I
first saw it): make the expiration tied to the amount of
reporting. That could make SURBL somewhat self-tuning:
1. Domains with many reports over a short period of time
probably really are spam domains and would get a longer
expiration. I.e., with a longer expiration we keep watching
this domain for a longer period of time, making it easier
to catch repeat offenses and keep the domain on the list for
longer. Something like an inverse logarithmic function
where the input is the spam count and the output is the
number of days to keep it on the list might be nice.
2. Domains with fewer reports get a shorter expiration.
This lets FPs roll off the list sooner, all automatically.
In other words we don't let small things bother us for
very long, but big offenders get the big hairy eye on
them for a long time. How does this sound?
Something that should probably be clarified about our
expirations is that they are "refreshed" by fresh spam.
If a domain keeps getting more than 10 spam reports over
a 4 day sliding window (current values), it will *stay on
the list for longer than 4 days*. Domains stay on the list
for as long as a certain rate of reports keep coming in,
which could in principle be forever.
It's not like the domains automatically get off the list
after 4 days. If reports keep coming in, they stay on
the list.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/
Re: Announcing SpamCopURI 0.08 support of SURBL for spam URI domain tests
Posted by Jeff Chan <je...@surbl.org>.
On Friday, April 2, 2004, 3:27:13 PM, Justin Mason wrote:
> Jeff Chan writes:
>> Does anyone have any data about the persistence of spam URI
>> domains? I'll even settle for any data about spam web server
>> IP addresses. :-)
> I've seen the same domain being used for several months.
Thanks much for the feedback. Can you cite some persistent
spam domains?
I'd like to check their histories against my data from SpamCop
reporting. We have enough history built up that I should be able
to see if they would have fallen off my lists at certain points
due to our relatively short expiration. I might be able to use
that information to tune the expirations better.
> BTW I would suggest a TTL in the list of at least 1 month for reported
> URIs. If you're worried about FPs hanging around for long, provide a very
> easy removal method (e.g. web form or email). Don't bother trying to
> assess the spamminess or otherwise of the requester, just remove the URL
> ASAP (and log the action, of course).
> Side issue: why use easy removal without questions? Spammers do not have
> the bandwidth to remove themselves from every list. If they *do* go to
> the bother, and a URL does get removed, then repeatedly crops up in spam
> again, it should be raised as an alarm -- and possibly brought to the
> notice of other people -- e.g. this list or others.
> If it really is a spammy URL and the spammer just keeps removing it, I'd
> imagine the URL would be noted as such and quickly find its way into
> systems that *don't* offer easy removal. ;) If it isn't a spammy URL,
> then you've saved yourself a lot of FPs and annoyed users, without
> requiring much legwork on your part.
> Basically the philosophy is to make it easy for anyone to remove an
> URL from the list.
It's a useful approach to know about. I'm sure as I get more
experience I'll be better able to make judgements about what
can work best. It definitely helps to have input from the
"spam war veterans" so I appreciate it!
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org-nospam
http://www.surbl.org/