Thank you! I really appreciate your help.
I'll check in a day or so to see if my traffic outbound to the Internet has
decreased.. I'm hoping it will! :)
-----Original Message-----
From: Raymond Dijkxhoorn [mailto:raymond@prolocation.net]
Sent: Wednesday, May 19, 2004 12:45 PM
To: SURBL Discussion list
Subject: RE: [SURBL-Discuss] DNS for dummies
Hi!
> I think I got it.. I added..
>
> chkconfig --level 2345 named on
> and
> I modified the resolv.conf to point to …
[View More]localhost first...
>
> I installed caching-nameserver..
>
> Do I need to do anything else? Does bind automatically know about
> 'caching-nameserver'?
And a 'service named start'
It will pickup things, the caching-nameserver is only a config and some
zones for bind...
Bye,
Raymond.
_______________________________________________
Discuss mailing list
Discuss(a)lists.surbl.org
http://lists.surbl.org/mailman/listinfo/discuss
[View Less]
I think I got it.. I added..
chkconfig --level 2345 named on
and
I modified the resolv.conf to point to localhost first...
I installed caching-nameserver..
Do I need to do anything else? Does bind automatically know about
'caching-nameserver'?
Thanks!
-----Original Message-----
From: Raymond Dijkxhoorn [mailto:raymond@prolocation.net]
Sent: Wednesday, May 19, 2004 10:29 AM
To: SURBL Discussion list
Subject: Re: [SURBL-Discuss] DNS for dummies
Hi!
> Hi all.. I'm a wanna be Linux …
[View More]guy who somehow, even with my own
ineptitude,
> managed to get SA 2.63 with Qmail up and running on Redhat 9.0! Recently
I
> got the SURBL's working and they have helped a LOT (I have a very weak box
> that is running SA.. so the lookups saved a lot of processing time!)..
> however..
What version of the URI are you using ?
> I have noticed my outgoing traffic on our T1 has shot through the roof. I
> currently have the Linux box using our ISP's DNS server for lookups.. I'm
> guessing it would be much more efficient if I had the linux box do it,
cache
> it.. I've even read about having it transfer the SURBL zones directly so
> that lookups remain local..
>
> Has anybody written a "HOWTO DNS" for dummies.. that could help walk me
> through setting this up on my Linux box?
Ohw on your local box its simple:
Install (via RPM) bind and caching-nameserver
Start bind, and edit your /etc/resolve.conf to look on localhost first.
Bye,
Raymond.
_______________________________________________
Discuss mailing list
Discuss(a)lists.surbl.org
http://lists.surbl.org/mailman/listinfo/discuss
[View Less]
I just saw this in a banner ad:
http://www.earthlink.net/earthlinktoolbar/download/
I don't have Windows. If someone else who does can reverse engineer it,
that might be useful.
--
Rich Graves <rcgraves(a)brandeis.edu>
UNet Systems Administrator
>-----Original Message-----
>From: Ted Deppner [mailto:tdeppner@surewest.net]
>Sent: Tuesday, May 18, 2004 4:53 PM
>To: discuss(a)lists.surbl.org
>Subject: Re: [SURBL-Discuss] mbox parser
>
>
>On Tue, May 18, 2004 at 10:58:15AM -0400, Chris Santerre wrote:
>> For what it is worth, I have abandoned all script
>extractions of URLs. It is
>> NOT reliable. The human eye is better, and almost as fast.
>Simply look at
>> the email source and search …
[View More]for every instance of HTTP.
>Then, using your
>> firing synapse and some of the jedi force powers, decide if
>what you are
>> looking at is a legit link. Then report it. :-)
>>
>> Then a team of squirrels on crack will take that submission
>and run it
>> through numerous test of validity. Then it will be listed.
>>
>> To go forwards, we had to go backwards.
>
>Ugh. You'll miss %xx encodings, Mime messages, and so forth.
I scan using outlook (don't ask!). So everything is decoded.
>No way you
>can analyze 45,000 messages in any reasonable amount of time.
Thanks to RBLs, and spammers realising they shouldn't send my company email
or they get listed to bigevil, my spam numbers are going down. Also I've
found that for every domain I add, there are 10 more spam with the same one
that can be deleted straight off. So it goes pretty fast, when I get my lazy
butt in gear to do it ;)
>
>We collect bounce messages and analyze those in aggregate. Very simple
>and high volume stuff floats to the top.
You are correct on that. I did have some great success with the scripts.
Mining the domains and working by hand might be ok, but I like to see the
whole email. So while time consuming, this is the best method for me to get
close to zero FPs.
Goes back to the old saying:
"Faster, better, and cheaper. Pick only 2."
--Chris
[View Less]
[moving announcement reply to discussion list]
Subject: RE: ANNOUNCE: Mail::SpamAsssassin::SpamCopURI 0.16
Date: Mon, 17 May 2004 13:18:07 +0200
From: <Rikhardur.EGILSSON(a)oecd.org>
To: <jeffc(a)surbl.org>, <announce(a)lists.surbl.org>
Cc: <spamassassin-users(a)incubator.apache.org>
For those of you who have to use a http_proxy, you should add this patch :
--- lib/Mail/SpamAssassin/SpamCopURI.pm.orig 2004-05-17 13:13:18.541107920
+0200
+++ lib/Mail/SpamAssassin/…
[View More]SpamCopURI.pm 2004-05-17 13:13:34.878624240 +0200
@@ -45,6 +45,7 @@
# do this since we never want the content
$ua->max_size(0);
$ua->timeout($LWP_TIMEOUT);
+ $ua->env_proxy;
dbg("redirect resolving: $url");
Or else, it won't work ..
- Ríkharður
-----Original Message-----
From: Jeff Chan [mailto:jeffc@surbl.org]
Sent: 15 May, 2004 11:54 AM
To: SURBL Announce
Cc: SpamAssassin Users
Subject: ANNOUNCE: Mail::SpamAsssassin::SpamCopURI 0.16
Eric Kolve has released SpamCopURI version 0.16 which fixes the handling of
the few URIs which use numeric IP addresses.
http://sourceforge.net/projects/spamcopuri
If you're using SpamCopURI, please upgrade to this new version.
[View Less]
For what it is worth, I have abandoned all script extractions of URLs. It is
NOT reliable. The human eye is better, and almost as fast. Simply look at
the email source and search for every instance of HTTP. Then, using your
firing synapse and some of the jedi force powers, decide if what you are
looking at is a legit link. Then report it. :-)
Then a team of squirrels on crack will take that submission and run it
through numerous test of validity. Then it will be listed.
To go forwards, we …
[View More]had to go backwards.
--Chris
>-----Original Message-----
>From: David Coulson [mailto:david@davidcoulson.net]
>Sent: Monday, May 17, 2004 8:08 PM
>To: discuss(a)lists.surbl.org
>Subject: [SURBL-Discuss] mbox parser
>
>
>I've got a decent mailbox containing a variety of spam e-mail.
>Is there
>a nice little Perl script out there which will spit out the URLs so I
>can submit them to Bill's list?
>
>David
>
>--
>David Coulson email:
>d(a)vidcoulson.com
>Linux Developer / web:
>http://davidcoulson.net/
>Network Engineer phone:
>(216) 533-6967
>
>_______________________________________________
>Discuss mailing list
>Discuss(a)lists.surbl.org
>http://lists.surbl.org/mailman/listinfo/discuss
>
[View Less]
I've got a decent mailbox containing a variety of spam e-mail. Is there
a nice little Perl script out there which will spit out the URLs so I
can submit them to Bill's list?
David
--
David Coulson email: d(a)vidcoulson.com
Linux Developer / web: http://davidcoulson.net/
Network Engineer phone: (216) 533-6967
Hello Rob,
I'm forwarding your message to the SURBL discussion and
SpamAssassin developers lists.
All,
Rob is looking for regular expressions to extract URIs form
message bodies. As we know this is a little more complex than it
may appear at first, given MIME decoding, weird cases, deliberate
obfuscation, etc.
Jeff C.
__
On Monday, May 17, 2004, 6:01:57 PM, Rob McEwen wrote:
> Jeff:
> Thanks for the resources you provided. At the least, these will give me a
> rough roadmap. The …
[View More]reason that these won't do much more for me than this is
> because I program using a different platform, different filtering software,
> a different mail server, and in an entirely different programming language
> (not perl or php). Some of this stuff does not translate very well and,
> frankly, some of it looks like "greek" to me.
> I program in Visual Basic.NET using the Microsoft .NET platform. Given that
> I'm also decent at C# programming, I think I could have done better if these
> examples were written in Java, for example.
> Nevertheless, my original question... the search for a really good regular
> expression for extracting URIs... is a VERY platform-independent issue.
> Finding the best regular expression for this could assist a variety of
> people using a variety of programming platforms and programming languages
> who might also attempt to write software to work with SURBL.
> Therefore, please consider posting this question on your website in the
> hopes that someone will provide a solution. I wouldn't be surprised if
> someone has already discovered the best Regular Expression for extracting
> URIs. Also, I believe that posting the answer on your site will be very
> helpful to others in my same predicament.
> (Note that it is easy to find Regular Expressions which extract the full URL
> where the URL is preceded by an "href". But this is obviously not enough.
> I'd like to find one which takes into account the country codes for
> determining whether two or three levels are needed and then only extracts
> what SURBL actually needs. Also, I fully admit that I'd have this one solved
> if Regular Expressions were my specialty. They are not!)
> Thanks for your consideration. Feel free to quote some or all of this e-mail
> at will.
> Rob McEwen
> PowerView Systems
> rob(a)PowerViewSystems.com
> (478) 475-9032
> -----Original Message-----
> From: Jeff Chan [mailto:jeffc@surbl.org]
> Sent: Monday, May 17, 2004 5:45 PM
> To: Rob McEwen
> Cc: jeffc(a)surbl.org; webmaster(a)PowerViewSystems.com
> Subject: Re: finding RegEx for extracting URIs
> On Monday, May 17, 2004, 5:22:50 AM, Rob McEwen wrote:
>> I'm trying to find a good regular expression for extracting URIs from the
>> raw text of an e-mail message. This would help tremendously for
> programming
>> a SURBL based filter. Do you know of any such regular expression? The ones
>> I've found on the internet so far are not very good, for numerous reasons.
> Hi Rob,
> I think your best best would be to copy the code from urirhsbl in
> SpamAssassin URIDNSBL or SpamCopURI's code:
> http://spamassassin.org/full/3.0.x/dist/lib/Mail/SpamAssassin/Plugin/URIDNSB
> L.pm
> http://sourceforge.net/projects/spamcopuri/
> Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
[View Less]
On Monday, May 17, 2004, 4:10:51 PM, John Fawcett wrote:
> From: "jdow"
>> From: "John Hardin" <johnh(a)aproposretail.com>
>>
>> > On Sun, 2004-05-16 at 01:46, John Fawcett wrote:
>> >
>> >
>> > > In order to obtain the 302 code the browser sees
>> > > 2 things are necessary:
>> > > 1. Add a / before the * (That is the correct format for
>> > > yahoo redirection)
>> > > 2. Change the …
[View More]hTtP:\\ to hTtP:// (The mixed case is not a problem)
>> >
>> > I think fixing all backslashes to forward slashes in the URL before
>> > processing by SURBL would deal with both cases.
>> >
>> > Are (unescaped or unencoded) backslashes even *valid* in URLs?
>>
>> Um, who cares? If the email programs parse them the way the spammers
>> want then we need to catch them parsed the way the spammers want. Of
>> course we COULD simply dump emails containing illegitimate back slashes
>> if nothing Microsoftish produces legitimate emails with backslashes.
>> I do not want to bet on that.
>>
>> {^_^}
>>
> In this case there is an additional consideration: SpamCopURI has logic to
> get the spammer domain out of a redirection url, by actually doing an http
> retrieval and reading the 302 response header.
> This retrieval fails if done on the url as written by the spammer.
> So the options are:
> - use unescaped \ as a spam indicator
> - mimic the broken browsers/email clients which are apparently rewriting
> malformed urls by mapping \ to /, thus allowing SpamCopURI to
> successfully retrieve the spammer domain for testing against surbl.
I would vote for the latter: map \ to /
(Although treating \ used as a separator as a --clue
indicator could also be useful, likewise using / for command
line flags. ;-)
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
[View Less]
NEW OPEN REDIRECTER
I just noticed a new (for me) yahoo redirecter in spam received
eur.rd.yahoo.com
On a hunch, I also tried things like:
uk.rd.yahoo.comit.rd.yahoo.comde.rd.yahoo.com
which are all open redirecters. There are sure to be more of
these using other country code prefixes.
So for those using SpamCopURI you probably need this
in your spamcop_uri.cf:
open_redirect_list_spamcop_uri rd.yahoo.com *.rd.yahoo.com
I'd recommend Eric to add this to the default SpamCopURI
…
[View More]configuration on the next release, along with others like
open_redirect_list_spamcop_uri drs.yahoo.com
open_redirect_list_spamcop_uri ads.msn.comg.msn.com
which aren't currently in the defaults.
NEW SPAMMER TRICK FOR URLS
Having added the new redirection service, I found that
SpamCopURI 0.16 didn't pick up the url shown at the end
of this message. The reason is that resolving the URL
through the SpamCopURI gives a HTTP/1.1 403 Forbidden.
As the response code does not begin with a 3 (= redirection),
the URL is assumed to be the final one. The domain which
is subjected to lookup in sc.surbl.org is (after normalizing
to the register level) is yahoo.com. So this one gets
past SpamCopURI.
Howver, in a commonly used browser, the url
redirects to the spamvertized site without difficulty.
I cannot help thinking that this url has been carefully
crafted to avoid processing by SpamCopURI but
still be acceptable to a browser. (That's a terrifying
thought).
In order to obtain the 302 code the browser sees
2 things are necessary:
1. Add a / before the * (That is the correct format for
yahoo redirection)
2. Change the hTtP:\\ to hTtP:// (The mixed case is not a problem)
While the second one is a general case (other redirection services
could be abused in the same way by browser loopholes) the first
one is a very specific browser loophole that applies only to
yahoo redirection.
Here's the URL. I didn't even munge it, since it should get
past the filters.
<a
href="http://eur.rd.yahoo.com/electric\croydon\laity\otherworldly\phonetic\e
xplicit\mountaineer\integrable\isadore\wangle\zounds\contumacy\embedded\sang
uine\arrangeable\duane\malarial\bremsstrahlung\freshmen\windup\spoon\accompa
ny\soldier\throb\boil\harrisburg\quartz\throne\giddap\waistcoat\guzzle\whoop
\abreast\corral\latrobe\ct\castor\gallup\click\cretinous\alcoa\lysine\wheelc
hair\levy\embedded\faint\floodlight\elmer\fiesta\pistachio\pulp\suppress\fle
awort\flick\topcoat\brain\prom\bill\knife\serene\*hTtP:\\7Wv2eg82o19X.zbxra1
.com/gp/iNdeX.ASP?id=BW"
target="_blank"><b>hit this</b></a>
John
[View Less]
Up to now I have been looking watching out for types of url which are not
parsed by SpamCopURI.
Today I have found one which is parsable by SpamCopURI, but which risks not
being blocked for a different reason.
When I went to Spamcop to report the spam, the URL was not parsed out by
spamcop reporting engine. This domain is therefore not going to enter into
the data (at least from this spam run) and so won't be blocked.
BTW the domain is: agrinho.com.
I suppose I should tell spamcop about this.…
[View More]..but I thought I'd mention it
here to fellow surblers because anything which stops spamvertized domains
going into spamcop will have an affect on blocking. In reality we need the
parsing mechanisms of clients (like SpamCopURI or URIDNSBL) *AND* of Spamcop
itself kept up to date with new obfuscation methods. Alternatively, we need
some way of submitting to one of the surbl lists, but that's a big step to
take...
John
[View Less]
I just got this in response to my posting. Shouldn't these
messages be going back to the list admin for
appropriate action?
I had posted the message to two lists, but I *think*
its a member of this list that has the autoresponder
setup incorrectly - I'll soon find out :-) as a result
of this post.
Thanks,
John
----- Original Message -----
From: "Michael McIsaac" <Michael.McIsaac(a)mpljasper.com>
To: <johnml(a)michaweb.net>
Sent: Sunday, May 16, 2004 10:48 AM
Subject: Re: Heads …
[View More]up: new open redirecters and new spammer trick forurls (I
am away from the office)
Thank-you for your email, however I will be out of the office until May 24.
I will answer your email personally when I return. If you need immediate
assistance please email our Accountant at Angela.VanDeBogart(a)mpljasper.com.
Thank-you
[View Less]
It's time to return to the question of a combined SURBL list
again mainly because David Hooton's anti-phishing list is now
ready. The list is too small to be a separate list at a little
over a hundred entries, but it will probably grow. So I'd like
to make it part of a combined list.
1. We had discussed two strategies for a combined list A records before:
I. Separate A records:
spammer.com IN A 127.0.0.1
IN A 127.0.0.2
Where the two addresses indicate it …
[View More]being on two lists.
II. Bitmasked address:
spammer.com IN A 127.0.0.3
where .3 means it's on the two lists corresponding to the .1 and
.2 bits, and similarly for other lists in other bit positions.
In the first case resolution on spammer.com.combined-list-name-here.surbl.org
would give two separate Addresses 127.0.0.1 and 127.0.0.2 and in
the second case it would give one result 127.0.0.3. The querying
program would need to act accordingly. For the bitmasked case
some SA code would need to be written or reused. As mentioned
earlier, various other RBLs combine lists using either of these
two strategies. Here's an example cited earlier of the bitmask
style:
http://opm.blitzed.org/info
> Using the DNSBL
> In opm.blitzed.org, the A record has an IP address of 127.1.0.x
> where x is a bitmask of the types of proxy that have been
> reported to be running on the host. The values of the bitmask
> are as follows:
>
> WinGate 1
> SOCKS 2
> HTTP CONNECT 4
> Router 8
> HTTP POST 16
So the code using a combined list could be made to detect
specific results, i.e., the specific list which triggered
a matching A record could be determined, and not just that it
matched "all" or any from the original list. On the other hand,
the fact that matches from any list occurred may be good enough
for some users. Personally I prefer more a detailed explanation
that would come from being able to distinguish the source list,
but that's a question of the program implementation and not the
combined list itself. The combined list itself would always
encode the source list, whether the querying program knew or
cared how to decode that or not.
2. Another question would be the name of the combined list. Since
there would be three or more lists, someone had suggested a name
of "all" before. That sounds good to me unless there are other
suggestions.
3. I'm assuming TXT records are no longer really feasible in a
combined list and that descriptive messages will need to be
signalled by the list (127. address) matched. I suppose it would
be possible to create custom TXT records for every entry, but a
generic TXT (or perhaps none) might be more likely. Is a generic
TXT better than none? Even in a BIND file, where it incurs some
use of space?
4. TTLs: If an entry has matches on more than one list, should
it get a unique TTL? If so, should such a custom TTL on the
multiply-matching entry be the longest TTL or the shortest TTL?
I lean towards the inheriting the shortest TTL from the matching
source list, plus setting a default TTL for the combined zone
file to be near the longest.
Am I right in thinking that TTLs are largely irrelevant for
rbldnsd, since it reloads zone info whenever the files change?
In other words, does the rbldnsd cache clear for a given zone
when the zone reloads, or do the cached entries with TTLs longer
than the last reload interval remain in the cache? (I'm kind of
hoping for the simpler, case of rbldnsd clearing whenever
reloading.)
5. We will likely want to combine the ws and be lists into a
single entry in a combined list, probably using the .1 bit for
both of them, since both lists contain the enumerated
(non-wildcarded) domains from SA regular expressions. Also,
things are moving towards combining the non-wildcarded domains
sa-blacklist and BigEvil/MidEvil, so this would somewhat
short-circuit that process and future-proof things.
Comments?
Jeff C.
[View Less]
I just got the following in a spam message which was
not identified by spamcopuri even though the numeric
domain it is in sc.surbl.org
<a href=3D"http://69.63.161.232/?rid=3D1528">
The debug output shows that the uri is found
by the SA modules but that SpamCopURI
queries for the wrong hostname.
It should be querying 232.161.63.69.sc.surbl.org
> debug: uri tests: Done uriRE
> debug: checking url: http://69.63.161.232/?rid%1528
> debug: querying for 63.161..sc.surbl.org
&…
[View More]gt; debug: Query failed for 63.161..sc.surbl.org
It looks like there are two problem is in SpamCopURI
(v 0.15) in the routine _spamcop_uri
(1)
# strip any non alpha characters off of the end
# this is to fix a bug where url parsing in core SA
# leaves parens and other junk on the URL that URI
# parses to the host
This causes the domain to become 69.63.161.
(including a trailing dot)
(2) The domain is stripped back to a two level domain
even though it is/should be an ip address.
It becomes 63.161. (including a trailing dot)
This domain then does not match an ip address format
so it is not reversed and the lookup is done for
63.161. added on to .sc.surbl.org, i.e.:
63.161..sc.surbl.org
Eric, can you help?
John
[View Less]
>-----Original Message-----
>From: Jeff Chan [mailto:jeffc@surbl.org]
>Sent: Thursday, May 13, 2004 5:07 PM
>To: SURBL Discuss
>Subject: Re: [SURBL-Discuss] RFC: Combined SURBL list details, phishing
>list ready
>
>
>On Thursday, May 13, 2004, 7:21:35 AM, Chris Santerre wrote:
>>>From: Jeff Chan [mailto:jeffc@surbl.org]
>
>>>Actually I was getting tricky and proposing to collapse ws and be
>>>into a single response within a combined list. …
[View More] This was mainly
>>>to prevent needing to remove separate be entries later since it will
>>>probably be merged into ws eventually. I was proposing short
>>>circuiting that process in the combined list.
>
>> I would say consider BE to be WS as of now. Just work with
>WS, because BE is
>> definetly going to be pulled in. How we do that on the
>backend won't matter
>> to the clients. For all intensive purposes, I won't be
>updating BE, I will
>> be updating WS directly thru the magic of Paul. (He's just
>swamped at the
>> moment.)
>
>> So again, consider BE non exhistant for future upgrades. It
>will save one
>> lookup ;)
>
>Sounds like you're saying we should not fold be in with ws for a
>combined list. Could we fold be in transparently into ws for the
>combined list, then remove it later (all invisibly to the users
>of the combined list)? Or are you guys already merging them
>behind the scenes? Want to try to get all the domains.... :-)
>
>Jeff C.
Yeah we will just transfer. Actually WS is so more up to date, the amount of
unique hits keeps getting smaller. Partly because I used to be the only game
in town, I felt the preasure to to keep updated. Now I don't thanks to you
guys :) So I'm trying to work on a bunch of things and not updating as
often. My ninja regex skills were getting rusty ;)
--Chris
[View Less]
So what do we do with candidates for whitelists? Also, what do we do with
things that should NOT be whitelisted, but NOT reported as spam? Examples
are cacheing services. Which are often used by spammers for images, but
legit as well.
I think images.exactis.com is one. And of course we have all the akamai.net
servers.
I'm just kind of thinking out loud. *man I'm hungry right now*
:-)
Chris Santerre
System Admin and SARE Ninja
http://www.rulesemporium.com
'It is not the strongest of the …
[View More]species that survives,
not the most intelligent, but the one most responsive to change.'
Charles Darwin
[View Less]
>-----Original Message-----
>From: Jeff Chan [mailto:jeffc@surbl.org]
>Sent: Wednesday, May 12, 2004 7:27 PM
>To: SURBL Discuss
>Subject: Re: [SURBL-Discuss] RFC: Combined SURBL list details, phishing
>list ready
>
>
*snip*
>
>Actually I was getting tricky and proposing to collapse ws and be
>into a single response within a combined list. This was mainly
>to prevent needing to remove separate be entries later since it will
>probably be merged into ws …
[View More]eventually. I was proposing short
>circuiting that process in the combined list.
>
I would say consider BE to be WS as of now. Just work with WS, because BE is
definetly going to be pulled in. How we do that on the backend won't matter
to the clients. For all intensive purposes, I won't be updating BE, I will
be updating WS directly thru the magic of Paul. (He's just swamped at the
moment.)
So again, consider BE non exhistant for future upgrades. It will save one
lookup ;)
--Chris
[View Less]
>-----Original Message-----
>From: Simon Byrnand [mailto:simon@igrin.co.nz]
>Sent: Wednesday, May 12, 2004 7:12 PM
>To: Jeff Chan; SURBL Discussion list
>Subject: Re: [SURBL-Discuss] RFC: Combined SURBL list details, phishing
>list ready
>
>
>At 11:02 13/05/2004, you wrote:
>
>>5. We will likely want to combine the ws and be lists into a
>>single entry in a combined list, probably using the .1 bit for
>>both of them, since both lists contain the …
[View More]enumerated
>>(non-wildcarded) domains from SA regular expressions. Also,
>>things are moving towards combining the non-wildcarded domains
>>sa-blacklist and BigEvil/MidEvil, so this would somewhat
>>short-circuit that process and future-proof things.
>
>Is it necessarily a good idea to combine lists like ws and be
>into a single
>entity when the sources of information are different ? (One comes from
>Bill, one comes from Chris) What policies of inclusion and
>removal do they
>each have ?
Well this is Paul's magic project. Bill, Paul, and I have pretty much the
same policies. We check everything. When in doubt we throw it out. Don't
want ANY FPs. Removal is pretty easy. But this process is going to be
somewhat better. They will be checked by groups of people instead of 3 :-)
>
>Say that a legitimate domain were somehow blocked, how would
>an end user
>know if it was Bill's data or Chris's that actually had it
>listed, to try
>and get it removed ? Etc...
Paul's magic again. Posted to a list. A group of trusted reviewers see it.
Make a decision. Poof!
>
>So from a technical point of view, fine no problem, but I wonder a bit
>about compatibility of listing policies etc..
Thats the beauty of what Paul is working on. I'm hoping he can find some
time to elaborate more.
--Chris
[View Less]
> > On Wed, 12 May 2004 16:02:33 -0700, Jeff Chan wrote:
> > > 2. Another question would be the name of the combined
> list. Since
> > > there would be three or more lists, someone had suggested a name
> > > of "all" before. That sounds good to me unless there are other
> > > suggestions.
> >
> > This could potentially lead to confusion if you
> subsequently add another
> > list not included in the "all" for some reason. …
[View More]That may
> seem unlikely
> > now, but who knows? How about "multi"?
>
> How about surbl.surbl.org? Being the primary rbl, this kinda
> makes sense :)
>
> Also on the other points about how to respond - I suggest the
> different IP
> per list as being smartest the octet based response is too
> non-specific.
> This only leaves the question on how do we handle multiple listings :)
>
> Cheers!!
>
> Dave
Hi all,
I'll put my hand up for the bit masked approach:
-it would require less traffic, yeah? If so, then that's gotta be good for everyone. Possibly less load on the DNS servers.
-I'm not sure what Dave means by too 'non specific', both methods achieve the desired results, which is all we really care about. The smarts lie in the code, it doesn't really matter if it is humanly 'harder' to read. You write a rule...it works...you forget whether you entered '2' or 127.0.0.2 as the value for the BigEvil list match some 5 minutes later - I don't need to remember it for an exam, and I hardly ever do manual lookups of URI's myself - the coding is much more efficient :)
-The SA programmers would spit out the new code required whilst blindfolded I would imagine...it sounds like they are just waiting to see what is required
As for the name, something like 'multi' seems good to me.
Keep up the good work as the existing lists are working very well.
Cheers
Scott
[View Less]
Jeff Chan <jeffc(a)surbl.org> writes:
> 1. We had discussed two strategies for a combined list A records before:
We still don't really care as long as you don't it right. :-)
If you think you might end up supporting more than 32 return codes
(seems like a very remote possibility), separate A records is much
easier. Maybe that helps make up your mind.
> So the code using a combined list could be made to detect
> specific results, i.e., the specific list which triggered
&…
[View More]gt; a matching A record could be determined, and not just that it
> matched "all" or any from the original list. On the other hand,
> the fact that matches from any list occurred may be good enough
> for some users. Personally I prefer more a detailed explanation
A more detailed explanation is merely the job of the client. If a
client can't handle multi-DNSBLs, then it's really behind the times.
Given that these clients are going to need to parse URIs and that is
non-trivial, I think you can just require multi-DNSBL support for newer
lists at some point if you want.
> 2. Another question would be the name of the combined list. Since
> there would be three or more lists, someone had suggested a name
> of "all" before. That sounds good to me unless there are other
> suggestions.
"query" and "bl" are two somewhat more common names for a single
combined blacklist.
> 3. I'm assuming TXT records are no longer really feasible in a
> combined list and that descriptive messages will need to be
> signalled by the list (127. address) matched. I suppose it would
> be possible to create custom TXT records for every entry, but a
> generic TXT (or perhaps none) might be more likely. Is a generic
> TXT better than none? Even in a BIND file, where it incurs some
> use of space?
You could return a single URL that if loaded contains information about
exactly which lists hit. You can also return multiple TXT records that
can be matched as SpamAssassin rules (yes!), but unless you promise to
keep the format very very stable, then we'll just use the A records.
My suggestion: start with the A and worry about the rest later.
> 4. TTLs: If an entry has matches on more than one list, should
> it get a unique TTL? If so, should such a custom TTL on the
> multiply-matching entry be the longest TTL or the shortest TTL?
> I lean towards the inheriting the shortest TTL from the matching
> source list, plus setting a default TTL for the combined zone
> file to be near the longest.
> [...]
Sounds fine to me.
> 5. We will likely want to combine the ws and be lists into a
> single entry in a combined list, probably using the .1 bit for
> both of them, since both lists contain the enumerated
> (non-wildcarded) domains from SA regular expressions. Also,
> things are moving towards combining the non-wildcarded domains
> sa-blacklist and BigEvil/MidEvil, so this would somewhat
> short-circuit that process and future-proof things.
As long as they have similar S/O ratios, I'm okay with it. If they are
maintained separately, it might shift the decision towards keeping them
separate, but if they're getting merged, then that makes more sense.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
[View Less]
>-----Original Message-----
>From: Matt Linzbach [mailto:MLinzbach@Merchant-Gould.com]
>Sent: Wednesday, May 12, 2004 2:57 PM
>To: Spamassassin-Talk (E-mail)
>Cc: SURBL Discussion list (E-mail)
>Subject: RE: X posting due to importance
>
>
>> -----Original Message-----
>> From: Chris Santerre [mailto:csanterre@MerchantsOverseas.com]
>> Sent: Wednesday, May 12, 2004 10:24 AM
>> To: Spamassassin-Talk (E-mail)
>> Cc: SURBL Discussion list (E-…
[View More]mail)
>> Subject: X posting due to importance
>>
>>
>> This was posted to Spam-L list. Very interesting. We should all watch
>> closely. Consider how we would defend our projects if we had to. :-)
>>
>> A Northern California District Court judge issued a temporary
>> restraining
>> order to prevent SpamCop, an antispam operation, from
>> interfering with
>> messages sent by alleged junk e-mailer OptInRealBig.com.
>>
>> http://news.com.com/2100-1024_3-5210518.html?tag=nefd.top
>
>
>/. has an active discussion on this today.
>
>http://yro.slashdot.org/yro/04/05/12/1226222.shtml?tid=111&tid=
123&tid=126&t
id=95&tid=99
And just like that, it is over :-)
http://biz.yahoo.com/prnews/040512/sfw083_1.html
Perhaps I should setup a BigEvil Drinking fund? I mean Legal defense fund.
Yeah thats what I meant!
--Chris
[View Less]
> -----Original Message-----
> From: Chris Santerre [mailto:csanterre@MerchantsOverseas.com]
> Sent: Wednesday, May 12, 2004 10:24 AM
> To: Spamassassin-Talk (E-mail)
> Cc: SURBL Discussion list (E-mail)
> Subject: X posting due to importance
>
>
> This was posted to Spam-L list. Very interesting. We should all watch
> closely. Consider how we would defend our projects if we had to. :-)
>
> A Northern California District Court judge issued a temporary
…
[View More]> restraining
> order to prevent SpamCop, an antispam operation, from
> interfering with
> messages sent by alleged junk e-mailer OptInRealBig.com.
>
> http://news.com.com/2100-1024_3-5210518.html?tag=nefd.top
/. has an active discussion on this today.
http://yro.slashdot.org/yro/04/05/12/1226222.shtml?tid=111&tid=123&tid=126&t
id=95&tid=99
[View Less]
This was posted to Spam-L list. Very interesting. We should all watch
closely. Consider how we would defend our projects if we had to. :-)
A Northern California District Court judge issued a temporary restraining
order to prevent SpamCop, an antispam operation, from interfering with
messages sent by alleged junk e-mailer OptInRealBig.com.
http://news.com.com/2100-1024_3-5210518.html?tag=nefd.top
Chris Santerre
System Admin and SARE Ninja
http://www.rulesemporium.com
'It is not the …
[View More]strongest of the species that survives,
not the most intelligent, but the one most responsive to change.'
Charles Darwin
[View Less]
2
1
Stupid SPAM
by Jose-Marcio.Martins@ensmp.fr
11 May '04
11 May '04
Hello,
Take a look at this SPAM :
http://www.ensmp.fr/~martins/Prozac
Mainly, check the source.
The problem is that it comes with many, many URLs. At the beginning,
there are URLs needed by the SPAM itself. After, it puts many URLs with
font size equals to 1. Most of these last domains aren't spam... 8-)
Jose-Marcio
--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41
Ecole des Mines de Paris …
[View More]http://j-chkmail.ensmp.fr
60, bd Saint Michel http://www.ensmp.fr/~martins
75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@ensmp.fr
[View Less]
Hi,
I've created binary and source rpms which can be found here:
http://www.elvis.demon.co.uk/SpamCopURI/
I will look at improving these and better integration with SpamAssassin rpms
over the next few weeks, but in the mean time your feedback is welcome.
Note it is likely you will have to --force the install so that the common files
with SpamAssassin are replaced. It is _strongly recommended_ that you build from
the source rpm on your system as the binaries are built on RedHat 7.3 and …
[View More]may
not suit your systems.
rpm --rebuild perl-Mail-SpamAssassin-SpamCopURI-0.15-1.src.rpm
It likely I will also share some related rpms in the near future. If anyone has
a better place to host the rpms let me know.
Regards,
Rob
--
Robert Brooks, Network Manager, Cable & Wireless UK
<robb(a)hyperlink-interactive.co.uk> http://hyperlink-interactive.co.uk/
Tel: +44 (0)20 7240 8121 Fax: +44 (0)20 7240 8098
- Help Microsoft stamp out piracy. Give Linux to a friend today! -
[View Less]