Discuss

discuss@lists.surbl.org

1867 discussions

Start a nNew thread

Новое сообщение
by Vovan 13 Dec '10

13 Dec '10

http://samec.org.ua/

1 0

historical data
by Likarish, Peter F 01 Dec '10

01 Dec '10

Hello all, I'm a member of a university research team looking at identifying malicious content online. We're interested in acquiring a list of all malicious URIs seen in the last 6-8 months. Does SURBL maintain historical data? Is there any way to get access to this data? Please let me know if I need to direct my query elsewhere or if anyone has suggestions. Thanks much, Peter Likarish

1 0

RFC: Changing zone files to wildcarded data format
by SURBL Role 25 Nov '10

25 Nov '10

The proposed change: In order to more effectively blacklist abused subdomains, we would like to get feedback on changing the SURBL zone file data format to use wildcards. Currently the records look like this canonically: domain.com (actual result codes not shown) For wildcarding under rbldnsd, the record would look like this: .domain.com For wildcarding under BIND, the record would expand to two: *.domain.com domain.com The above would be the case if both domain.com and all of its subdomains were to be listed, which is the equivalent functional case now. For the BIND version of the zone file, it would generally mean a doubling of file size. In the highly unusual, exceptional case that only an unqualified domain were to be listed, the future record would look like for both rbldnsd and BIND: domain.com In the new case that a subdomain would be listed, the record would look like this for both rbldnsd and BIND: subdomain1.domain.com subdomain2.domain.com subdomain3.domain.com Impact on list data: This change would allow SURBL to list more compromized subdomains of otherwise legitimate sites without impacting the unqualified domain. As a result, this could lead to more complete coverage of cracked domains and abused hosts and facilitate better detection of unsolicited messages that mention such sites. Currently SURBL does list some abused subdomains, but only for a relatively limited number of major hosts such as sites at Microsoft, Google, Yahoo, etc. This change would potentially allow any subdomain to be listed. Application support of subdomain handling: To support the checking of subdomains, applications using SURBL data would need to be modified to send the fully qualified domain to the DNS resolver, assuming the typical DNS query method of lookup were used. Due to the wildcarding of domains generally, the change in applications to support subdomains could be a simple as not reducing domains down to their registered (unqualified) level, i.e., just sending all fully-qualified domains and letting the wildcard in the DNS zone match them. In a sense this makes the design of the SURBL applications simpler since they would no longer need to reduce domains. For example the two- and three-level-tld lookup tables would no longer need to be used, simplifying operations somewhat. Impact on existing nameservers: The last time this subject was raised, the recalled conclusion was that caching in nameservers would not be adversely affected since wildcarded responses are treated correctly in cache for both rbldnsd and BIND. It would be good to get a confirmation of this, otherwise there could be performance or resource impacts in nameservers. Another potential impact is that BIND zone files would be approximately twice as large as they are presently since BIND doesn't support a singular, combined record type for a wildcarded subdomain and its parent domain, unlike rbldnsd. (See the examples above.) This could increase zone file transfer or rsync times for example. This could also increase BIND resource utilization. Most nameservers use rbldnsd, however. rbldnsd systems may be less affected. The impact on rbldnsd zone file size is much less than the doubling in BIND, for example. Other impacts: One less obvious issue is that a change in zone file format could adversely impact applications that use the zone file not in a nameserver. For example reading the data into a database may require that some filtering be added in order to remove the leading dot, or to identify the records differently in the database. They may also need to handle subdomains more generally or in a different way than they currently do. Applications in general may need to be updated to take advantage of the proposed subdomain data. On the other hand, this change should be backward compatible in that wildcarded domains would continue to match queries reduced under the original (current) paradigm. In other words unmodified applications should continue to work as before, with the downside that they would not detect subdomains handled the new way. What other impacts could there be? What other changes would be needed? Would the added subdomain listing capability justify the various impacts, particularly on application design? Request for comments: Given the potential impacts, it seems prudent to ask for comments on the proposed change. Feedback is welcomed. Additional examples: For a full domain owned by the bad guy the listing would be: .badguy.com (rbldnsd) *.badguy.com (BIND) badguy.com (BIND) For a cracked subdomain, the listing would be: cracked.legitimate.com legitimate.com would not be listed. domain.com would almost never be listed in the rbldnsd file, but almost always in BIND. domain.com would usually not be listed for a cracked file, except in the very unusual case that these were bad: domain.com (unqualified) subdomain1.domain.com subdomain2.domain.com but this was good: NOTLISTED.domain.com (which would not be listed)

5 7

Phishtank Data and SURBL?
by Johnson, Ken 21 Oct '10

21 Oct '10

We have been having an increase in the number of phishing messages that slip through our antispam solution. We currently use Can-IT which includes an instance of SpamAssasin which has active scanning on for SURBL. We recognize that no current solution is going to be 100% effective - however one of the most recent phishing messages that got through was for a link which appeared to already be in phishtank.com data (see http://www.phishtank.com/phish_detail.php?phish_id=1068849) We had been working to see if we could incorporate phishtank.com data in the Can-IT environment to add one more source of blocks for these messages to plug some more holes when we noticed per http://www.phishtank.com/friends.php that SURBL appeared to already be listed as using (in some way) phishtank data. We presumed that http://www.surbl.org/lists.html#ph probably used it - but tests seem to have test messages with that url receiving no points inbound. Further testing on the SURBL lookup returned that w3t.org wasn't listed (which makes sense as the underlying url above is a shortener so it's only the extended url that is listed in phishtank and worth flagging on - does SURBL only accept root domains for listing? Basically we're just trying to figure out if this is a config error on our part or a misunderstanding on our part of how SURBL uses phishtank.com data and/or classifies reported phishing sites and subdirectories in the first place. Thanks in advance for any insight! Ken Johnson Information Technology LeTourneau University

2 1

portion of my domain name is List
by David Fletcher (SAN) 14 Oct '10

14 Oct '10

Hello, My domain is Sandestin.com. We are having some issues of our emails being blocked as spam. The message is 552 tin.com found in SURBL: Blocked, tin.com on lists [ws], See: http://www.surbl.org/lists.html. My domain isn't on the lookup but tin.com. Where do you think this issue lies? Is it SURBL or the spam filtering that is using surbl? David Fletcher I.T. Dept

3 2

Rejected content by multi.surbl.org
by Shattuck, Will 19 Jul '10

19 Jul '10

Hi all, One of my users sent email someone and received a rejected notice. Here it is: host mx01.lastspam.com[64.15.150.3] said: 550-5.7.1 rejected content, black listed 2010.In by multi.surbl.org. #762 #895 (m6F1MY037314479000) The attachments being sent were a 38 KB Excel file, and 1 MB PowerPoint. I understand that SURBL checks for websites and URLs inside the email, but I can't seem to find anything about SURBL lists rejecting content. I'm inquiring as we need to make sure these attachments get to the recipient. Thanks, Will

5 8

Detail information for listing / Removal request
by 127.0.0.1＠gmx.de 13 Jul '10

13 Jul '10

Hello, is there any page i can verify the source mails or urls which has led to the listing of the domain "ncsrv.de" at SURBL? This domain is used as a alternative url for almost every server in our network (server1 ... server99999.ncsrv.de), so websites are available even no customer domain is routed on the certain server. We use this domain also as internal identifier, also included in the host name configuration. As you will understand a full control over every URL used in unsolicited messages is almost impossible because we have a lot of root systems, so we can not shut down every listed URLs immediately. Is there a possibility to check for new entries at SURBL automatically so we can respond to that issue? Thanks, Rafael -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

3 9

How to delist from the SURBL list?
by SnipURL Editor 30 Jun '10

30 Jun '10

Hi, I have tried to send an email from the Lookup page, but that email is bouncing. What am I missing? Whom can I contact to get my IP unlisted, given that it's now been a month since it's been wrongly put in the list? Thanks Shanx

5 8

www.jmhsa.ch
by Gilles Robert 04 Jun '10

04 Jun '10

Hello, Why do I have such message from my program antispam : 1 .5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist > * [URIs: jmhsa.ch] I did check, our site jmhsa.ch is not blacklisted by ws_surbl.... Can anyone help me ? Thanks and regards. Gilles Les Sociétés JMH Cassarde 4 2000 Neuchâtel Tél. ++41.32.729.00.20 Fax ++41.32.729.00.29 www.jmhsa.ch societes(a)jmhsa.ch

3 2

Re: [SURBL-Discuss] Email Rejected due to Multi.surbl.org (Duane Wolf)
by Wolf, Duane A. 28 Apr '10

28 Apr '10

Well luckily I'm the mail administrator on both sides of this issue! :) What I found was that my firewall on the receiving side has a feature that utilizes uribl. Disabling this feature stopped the email rejections. Upon further investigation into this (with the help of some others folks) it was determined that uribl might have changed the way they do their blacklist notifications now. It looks like their "whitelists" (i.e. those that should not be blocked) also return results now - which is probably why the uribl feature blocks the email. http://uribl.com/about.shtml >From what I can see, their whitelist is not included in the multi list or its not working. I maybe off base on this but wanted to post what I have found so far. I am currently catching up on all the suggestions and info presented so far. Thanks again for everybody's help. Duane ------------------------------ _______________________________________________ Discuss mailing list Discuss(a)lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss End of Discuss Digest, Vol 66, Issue 3 **************************************

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
187
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss