On Wed, 1 Mar 2006 13:36:27 +0000 (GMT), Paul Jakma <paul at clubi.ie> wrote:
> 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
>> mail from a DNSBL.
>> That depends on the DNSBL. You need to understand:
>> a) What the DNSBl is about
> b) Whether what the DNSBL is about suits your goals.
> a) DNSBLs that I use to reject email (using sendmail's built-in
>> 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
>> 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.
Very nice. I'm sure this setup works very well.
>> 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.
Very true, but then again I didn't in any way suggest that you should
use Spamcop as a source. I was merely talking about DNSBL's in general,
and as a concept. As you discussed in length above it really depends on
their classifications and if your goals agree with the results they
provide to your query.
> 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).
I may not have spent that much time looking at the output of Spamcop's
spam-parser. But then again I mentioned that I DON'T actually USE Spamcop.
>> 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"
I am now making the assumption that you wrote this in CAPS to warn any
potential readers of this thread. I am also making the assumption that
you didn't misunderstand me when I was talking about the results of
rejecting at smtp level to reduce back-scatter.
After reading this again I can see that I was less than clear.
I did meant to say that I reject some mail at smtp level to reduce back-
scatter, and if the sending "end" is configured correctly my server
should inform them that the mail has been rejected, and what other way
they have to contact me if this is an important message. As we all know
spam often originates from trojaned Windows boxes that use smtp engines
that don't actually respect RFC's.
Apologies for the confusion I may have caused.
You really should lay off the CAPS key though. No need for that.
> 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).
Fine. But I still wasn't advocating using Spamcops DNSBL to reject mail.
I was merely replying to this statement:
"> Anybody uses a DNSBL to reject mail is clueless"
And I was arguing the point that using a DNSBL to reject mail isn't
necessarily stupid. You do have to consider the source though, because
you sign over the control of your incoming email to them as soon as you
reject mail based on their list. That is a different argument (Where
incidentally it seems you made the assumtion I was in favour of using
Spamcop for rejecting mail).
> Paul Jakma paul at clubi.iepaul at jakma.org Key ID: 64A2FF6A
> "Only a brain-damaged operating system would support task switching and
> make the simple next step of supporting multitasking."
> -- George McFry
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!