[ILUG] Address change

[Paul Jakma]

On Wed, 1 Mar 2006, Tor Bendiksen wrote:

> Would you care to elaborate on this?
>
> Depending on the circumstances I think it's perfectly legitimate to reject
> mail from a DNSBL.

That depends on the DNSBL. You need to understand:

a) What the DNSBl is about
  - its general goal, which could be:
 	- List a specific type of open-relay
 	  (originally SMTP relays, but these days
 	   proxies of varying kinds too, and more)
 	- List a class of address
 	  (e.g. ISP dialup,DSL,countries,etc address ranges)
 	- punish persistent spam-friendly ISPs/hosters
 	  by blacklisting growing swathes of their address space
 	  (idea is their customers will rebel and either get the
 	   company to change its ways or leave)
 	- Provide a near real-time list of /possible/ spam-sources,
           based on heuristic analysis of very recent spam
           submissions. (note that 'possible' implies a lack of
 	  precision)
  - The exact listing criteria
 	- how exactly do things get listed?
 		- manually?
 		- automated?
 	- how long do things stay listed
 	- how are mistakes rectified, if at all?

b) Whether what the DNSBL is about suits your goals.
 	- your goal is probably 'get less spam', obviously
 	- however most people still wish to receive email
 	  you have to think about acceptable false-positive rates.
 	  (if SpamAssassin or Thunderbird bayes makes a
 	   false-positive, you just have to retrieve the mail from
 	   your spam folder. If a DNSBL does, and you reject email
 	   with DNSBL, you never see the email)

FWIW, I have two sets of DNSBLs I Use:

a) DNSBLs that I use to reject email (using sendmail's built-in
    support)

b) DNSBLs that I use to tag email with (using rbl-milter. It also
    uses set a, because it can check previous relays in the header
    files)

The 'tags' from B are fed to my Bayes filter, and I let my bayes 
filter decide statistically how important those various DNSBLs are.

SpamCop is most definitely a 'b' candidate DNSBL - never an 'a'. If 
you don't understand why, you shouldn't be using SpamCop.

> Another important thing of course is to choose your source 
> carefully. I have absolutely no problem with rejecting mail coming 
> from a source I deem to be potentially untrustworthy.

Whether I agree depends on the definition of "potentially 
untrustworthy". SpamCop for example are *NOT* a valid indicator of 
"potentially untrustworthy", they do not claim to be either.

It is 'normal' for quite trustworthy hosts to be listed by SpamCops 
DNSBL. If you don't understand why, you havn't spent enough time 
looking at the output of SpamCop's spam-parser (if you refuse to take 
SpamCop's OWN ADVICE to NOT USE SPAMCOP TO REJECT EMAIL in their FAQ 
and their help pages on trust).

> mail gets rejected. If their MTA and MUA isn't set up properly they 
> will of course never see the reason for being rejected, but that is 
> their problem IMHO.

As the subject is SpamCop, I have to point out:

SPAMCOP LISTING A HOST DOES **NOT** MEAN THEY'RE POORLY SETUP OR "BAD"

It just means spamcop got a lot of submissions that mentioned that 
host, and SpamCop's heuristics weren't able to /discount/ that host 
(this involves parsing the chain of the Received headers btw - an 
unreliable process. E.g. crossing to/from IPv6 to/from IPv4 means 
SpamCop can't follow the chain and the host gets considered a 
potential spamsource).

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
"Only a brain-damaged operating system would support task switching and not
make the simple next step of supporting multitasking."
-- George McFry