Discuss

discuss@lists.surbl.org

1876 discussions

[SURBL-Discuss] Re: Fwd: Re: Fwd: Re: Announcing SURBL support in SA 2.63 and 3.0 plugins - bug ?
by Jeff Chan 16 Apr '04

16 Apr '04

Simon Byrnand, Eric Kolve and I were having a discussion of what characters are legal in domain names, due to junk showing up around URIs and apparently confusing some of the SpamAssassin URI parsing code. Wanted to share some research and ask if anyone has any other authoritative information on what characters are currently legal for domain names. This is relevant for anyone trying to work with domain names. Also Eric, please share bugs you find in the SA URI parsing code, preferably by opening a bugzilla, especially if you can isolate the module, etc.: http://bugzilla.spamassassin.org/enter_bug.cgi Here's a little research on the subject: The original domain name RFC had names only with letters, numbers and hyphen: http://www.ietf.org/rfc/rfc1035.txt <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9 Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. But RFC 2181 leaves things wide open with respect to names: http://www.ietf.org/rfc/rfc2181.txt 11. Name syntax Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose. The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default. Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address. Clients of the DNS can impose whatever restrictions are appropriate to their circumstances on the values they use as keys for DNS lookup requests, and on the values returned by the DNS. If the client has such restrictions, it is solely responsible for validating the data from the DNS to ensure that it conforms before it makes any use of that data. After scanning the RFC descriptions that were linked from RFC 1035: > RFC 1035 Domain names - implementation and specification. > > Authors: P.V. Mockapetris. > Date: Nov-01-1987 > Formats: txt pdf > Obsoletes: RFC 0973, RFC 0882, RFC 0883 > Updated by: RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, > RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC > 2308, RFC 2535, RFC 2845, RFC 3425, RFC 3658 > Also: STD 0013 it appears that these may be the only two authoritative statements on what characters can be in domain names: RFC 1035: letters, numbers, hyphen RFC 2181: implementations should support anything Does anyone have any more info on what characters are legal in domain names? Jeff C.

2 1

Hello to everybody!
by Markus Zingg 15 Apr '04

15 Apr '04

Hi all I found out about the surbl project some days ago and was all excited, but then a bit frustrated not to find contact information. Well, it seems like I did not looked carefull enough but then got the pointer to join this list from Wayne and well, here I am. I don't know the culture of this list yet, but still take the "risk" to introduce myself instead of pasively reading a couple of days first. I hope not to offend people by doing so. My name is Markus Zingg and I live in Switzerland - Europ. English is not my native language, I hope you bear with me if I sound odd or plain wrong :-). I'm developping all kind of software mostly useing 'C' for the last 20+ years. I'm currently working on a project where we have developped an embedded email server. This is a 4x4x1" sized box which apart from being an SMTP, POP3 and WebMail server also contains a spam filter that in short and apart of some other methods works by extracting URI's from e-mails and matching them against a blacklist database. I'm happy to post the URL to a site describing the box in detail if you want me to. The box - which does not have the luxury of having a superfast Pentium processor - must do the filtering in a very efficient fashion and therefore all of the firmware is implemented in 'C' with some parts even being (some risc processor) assembler. In order to parse the e-mails and split them up MIME wise etc. I wrote a special parser which does all what's needed in one single pass (MIME parsing, content transfer decoding, decoding of hex and decimal encoded HTML areas etc. etc.) and parses the textual parts skiping attachements etc. The parser of course takes into acount wether it works on a html text or a plain text part and can't be fooled by the tricks the spammers used so far. It works extremly efficient and hence I thought it might be of intersted to the surbl project. As a side effect it can also detect dangerous attachements by looking at the filename extension and if configured to do so rename them on the fly. I figure though that this later part might does not go together well with SpamAssassin. Since it was written for this embedded hardware there is some effort needed to make it of general use but I partially did that already in order to test the filter more efficiently with thousands of spam samples I collected over the years and of course also spam that currently is coming in. I must admit that I don't know how SpamAssassin works in detail nor do I curently have a Linux based e-mail server setup. I do have however some PC's standing around that I could set up this way and I also used to work with Unix and Linux for several years in the past. Apart from the fact that doing whatever possible to get the spam problem somewhat under control my interest would be to get as much spamvertised domains as possible. I understand that I could read live surbl data already and even add such functionality to the firmware but did not wanted to do this withouth first asking and also without offering help. I also have some aditional ideas on how to get more spamvertised domains and other issues, but I think this posting got a little long already :-) I honestly have no idea if what I can offer is of any interest here. If not, please accept my apologies of having disturbed you. Markus

2 1

RE: [SURBL-Discuss] No install Problems with 0.10
by Paul Barbeau 14 Apr '04

14 Apr '04

Yep > -----Original Message----- > From: Charles Solomon [mailto:csolomon@aldridge-borden.com] > Sent: April 14, 2004 2:54 PM > To: Paul(a)hypernet.ca; discuss(a)lists.surbl.org > Subject: RE: [SURBL-Discuss] No install Problems with 0.10 > > > Do you get a clean bill of health when you --lint?

1 0

RE: [SURBL-Discuss] No install Problems with 0.10
by ITReading ITReading 14 Apr '04

14 Apr '04

Do you get a clean bill of health when you --lint? >>> Paul Barbeau <Paul(a)hypernet.ca> 04/14/2004 12:11:43 PM >>> > Did you remember to copy the .cf file to your spamassassin > rules folder? (I only mention this b/c I tend to forget to > do the most obvious of steps). Yep i put it in both places > > If you run spamassassin -D -t on a test message, do you see > it attempting to perform the queries? Nope it does not look line it

1 0

RE: [SURBL-Discuss] No install Problems with 0.10
by Charles Solomon 14 Apr '04

14 Apr '04

1 0

RE: [SURBL-Discuss] No install Problems with 0.10
by Paul Barbeau 14 Apr '04

14 Apr '04

> Did you remember to copy the .cf file to your spamassassin > rules folder? (I only mention this b/c I tend to forget to > do the most obvious of steps). Yep i put it in both places > > If you run spamassassin -D -t on a test message, do you see > it attempting to perform the queries? Nope it does not look line it

1 0

RE: [SURBL-Discuss] No install Problems with 0.10
by Paul Barbeau 14 Apr '04

14 Apr '04

ok then what am i missing could it be as i am running in CHROOT (OpenBDS) > -----Original Message----- > From: David Coulson [mailto:david@davidcoulson.net] > Sent: April 14, 2004 8:59 AM > To: Paul Barbeau > Cc: ''discuss(a)lists.surbl.org' ' > Subject: Re: [SURBL-Discuss] No install Problems with 0.10 > > > Paul Barbeau wrote: > > I guess i spoke to soon.. The "make test" works and it > looks like the "make > > install" works however when i send an email through with > > "http://nothere/" in it nothing gets tagged. Is that the > correct URL > > to use to confirm it is working? > > It filtered it out here :-) > > 3.0 WS_URI_RBL URI's domain appears in spamcop > database at > ws.surbl.org > [test.surbl.org is blacklisted > in SpamCop > RBL at] > [ws.surbl.org] > 4.0 SC_URI_RBL URI's domain appears in spamcop > database at > sc.surbl.org > [test.surbl.org is blacklisted > in SpamCop > RBL at] > [sc.surbl.org] > > David > > -- > David Coulson email: > d(a)vidcoulson.com > Linux Developer / web: > http://davidcoulson.net/ > Network Engineer phone: > (216) 533-6967 >

1 0

RE: [SURBL-Discuss] No install Problems with 0.10
by Paul Barbeau 14 Apr '04

14 Apr '04

I guess i spoke to soon.. The "make test" works and it looks like the "make install" works however when i send an email through with "http://test.surbl.org/" in it nothing gets tagged. Is that the correct URL to use to confirm it is working? Any ideas? Paul

2 1

RE: [SURBL-Discuss] 0.10 install difficulties
by Steve Wakelin 14 Apr '04

14 Apr '04

Raymond, It was Net::DNS that was not uo to the latest revision. Installed this from CPAN and all is now OK. Many thanks Regards /Steve -----Original Message----- From: Raymond Dijkxhoorn [mailto:raymond@prolocation.net] Sent: 14 April 2004 02:12 To: Steve Wakelin Subject: Re: [SURBL-Discuss] 0.10 install difficulties Hi! > Logged out > # make clean > # perl Makefile.PL > # make > # make test > > Same error > Has anyone got it to work on FC1? I can try at work tomorrow to compile in on FC1, i currently are running the URI checks on 2 RH9 boxes. Bye, Raymond.

2 1

[SURBL-Discuss] Fix for the "syntax error at /etc/pamassassin/spamcop_uri.cf" errors
by Daniel Patterson 14 Apr '04

14 Apr '04

Hello all, This is a quick note to those who are getting the following errors under 2.63: Failed to compile URI SpamAssassin tests, skipping: ^I(syntax error at /etc/spamassassin/spamcop_uri.cf, rule SPAMCOP_URI_RBL, line 1, near "eval:" syntax error at /usr/share/spamassassin/20_uri_tests.cf, rule URI_OFFERS, line 175, near "; }" ) The cause of this error is the perl module loader path being set such that your new, shiny SpamCopURI classes are not replacing their original counterparts in the original SA distribution. I'm running Debian, and I noticed, in /usr/bin/spamassassin and /usr/sbin/spamd the following line: use lib '/usr/share/perl5'; The actual content of this line will vary depending on your system, but if you're experiencing the above error, this is the source of your troubles. To fix it, I add the following immedietly after the previous "use lib" line: use lib '/usr/share/perl5'; use lib '/usr/local/share/perl/5.8.3'; This prepends /usr/local/share/perl/5.8.3 to the module search path, which will make the newly installed Spamassassin modules be loaded in preference to those found elsewhere on your system. You could possibly also remove the "use lib" line altogether, but I haven't tried that. daniel

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss