Discuss

discuss@lists.surbl.org

1 participants
1864 discussions

Re: [SURBL-Discuss] [SURBL-Announce] ANNOUNCE: Some two-level-tlds accented characters changed to IDN
by Michele Neylon :: Blacknight 11 Apr '11

11 Apr '11

Interesting issue Has SURBL got anything in place to deal with IDN ccTLDs? ie. where the actual extension is an IDN as well? Regards Michele On 4 Apr 2011, at 16:54, SURBL Announcement list [READONLY] wrote: > Anthony Howe noticed that gcc was complaining about ISO 8859-1 > accented characters used in the two-level-tlds file. With his kind > help, we converted those to equivalent IDN representation. Diffs are: > > 278c278 > < aéroport.ci > --- >> xn--aroport-bya.ci > 893c893 > < drøbak.no > --- >> xn--drbak-wua.no > 1955c1955 > < lea?gaviika.no > --- >> xn--leagaviika-52b.no > 2835c2835 > < osterøy.no > --- >> xn--ostery-fya.no > 3554c3554 > < tysvær.no > --- >> xn--tysvr-vra.no > 3587c3587 > < unjárga.no > --- >> xn--unjrga-rta.no > 3650c3650 > < vegårshei.no > --- >> xn--vegrshei-c0a.no > > As a practical matter this should have little operational impact since > those domains are obscure and unlikely to be abused. Nonetheless, we > thank Anthony for the correction. > > _______________________________________________ > Announce mailing list > Announce(a)lists.surbl.org > http://lists.surbl.org/mailman/listinfo/announce Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

3 2

removal does not work!?
by Dominic John Rack 15 Mar '11

15 Mar '11

hi, one of my customers has problems sending email to certain recipients. he found out, that his domain "seegerundkollegen.de" is listed on surbl which might be the reason for mails being rejected. i have thoroughly checked the server and cleaned up all problematic files. there definitely had been ftp-abuse so we altered all ftp-accounts also. the server is clean and secure now. we have requested removal from the surbl ph-list about ten days ago - no effect up to now! the domain is still listed L what can we do to solve this issue quickly? it is really important to free this domain! regards. dominic john rack ............................................ mediatects . media architecture and design

3 2

how to contact
by Jason DeGraf 15 Feb '11

15 Feb '11

your whitelist"surbl.org address does not work

1 0

multi.surbl.org.rbldnsd download
by Jeff Poling 31 Jan '11

31 Jan '11

I recently became responsible for our SURBL system. Last week or firewall changed and the SURBL system had issues with the rsync process. We corrected the firewall issues, but I am still seeing the following: You are connected to rsync40 receiving file list ... done multi.surbl.org.rbldnsd rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(231) rsync error: received SIGUSR1 or SIGINT (code 20) at main.c(965) I am kind of at a loss as to what is going on. . .any insight is greatly appreciated! Thanks, Jeff

2 1

SpamAssassin
by Eric Lamison 19 Jan '11

19 Jan '11

I'm using SpamAssassin to test for problems with our email and I'm getting warnings about being on SURBL blacklists. When I do a lookup though, it says the server is not listed. Any suggestions as to what the problem is? From SpamAssassin: 1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: logicalwebco.net] 4.5 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist [URIs: logicalwebco.net] 1.9 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: logicalwebco.net] 0.8 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist Thanks, Eric Lamison

2 1

Re: [SURBL-Discuss] please forwarding to the webmaster: many links are broken on surbl.org
by gilles＠jmhsa.ch 27 Dec '10

27 Dec '10

Bonjour. Je serai de retour au bureau après les fêtes, soit le 3 janvier. Merci de vous adresser en mon absence à societes(a)jmhsa.ch. Hallo, ich bin zurück im Büro nach den Festtagen am 3. Januar und bitte Sie, sich in der Zwischenzeit an societes(a)jmhsa.ch zu wenden.

1 0

please forwarding to the webmaster: many links are broken on surbl.org
by Martin Schiftan www.blocklist.de 27 Dec '10

27 Dec '10

Hello, on the Website there are a lot of Links broken: http://www.surbl.org/links -> http://www.surbl.org/nameservers-output.html -> http://www.surbl.org/datafeed/ http://www.surbl.org/contact -> Look-Up-Link in the second section refers to http://lookup/ and on all Sites: -> http://www.surbl.org/public-dns.html also i have stop to read, the website is to broken and not complete. Please forwarding this mail to the Webmaster to fix the links and redirects. Because webmaster(a)surbl.org or a other default address does not works. Thanks. Martin Schiftan http://www.blocklist.de/en/ Fail2Ban Reporting Service

2 1

Новое сообщение
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

← Newer
1
2
3
4
5
6
7
8
9
...
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