Re: content filtering



On 24 Nov 2008 20:01:49 GMT, Stephen Ward
<stephen.usenet.ward@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

With respect to you, what you have has no basis in fact.

Then continue to use RBLs to refuse connections from IP addresses
regardless of the message contents.

W/R/T your statement that what I said has no basis in fact, I can tell
you that at an earlier time I was an advocate of DNSBL's. But when the
set of white listed IP addresses grew beyond 6,000 I realized that
this was not a sustainable mode of operation. Perhaps you base your
opinion on experience that's limited to dealing with domestic US
senders? Mine differs from that. I work for a multi-national company
that receives mail from quite a few (thousands, actually) IP addresses
that DNSBLs routinely list.

RBL's are an
effective way of dealing with known hostile sending IP's. Most of the
RBL's are very well respected.

Sure. And if that's the only thing they did they would actually be
useful. But who makes the determination as to what's "hostile" and
what's not? Why do the IP addresses get listed, and how do they get
delisted?

Here is how it is. If you end up getting your IP listed on the likes of
the CBL (which then feeds lists like those offered by Spamhaus,
Barracuda, Spamcop etc) then your IP has, without any doubt, been seen to
send spam - and I would add PLENTY OF IT. Methods for removal are easy to
access and work without any flaw - unless of course you are a 'spammer',
'bulk emailer' or 'online marketing person'.

The "without a doubt" part of that is not believable. I have plenty of
doubts.

An IP may not have been deliberately sending spam. Why? Well by and large
you can thank Microsoft for their poor security model that allows people
with limited IT skills to download applications and become part of large
BotNets.

I'm pretty sure that if Apple's (or Linux, or FreeBSD's) market share
were as large as Microsoft's that you'd be saying the same thing about
them.

Even better are a number of lesser skilled 'certified' idiots
who set up Exchange Servers with poor security that then go on to become
relays for the .tw bunch of med & watch peddlers. Comes down to the idiot
that runs the bot or sets it up.

Considering that the large majority of spam originates from the US,
that's a pretty inaccurate generalization.

SMTP is broken.

That's something that most of have known for some time. But it's not
SMTP, it's the anonymity, that's the problem.

Over 90% of the traffic is *UNWANTED*. I'd go as far to
say the onus for mail delivery should be on the sender, not the
recipient.

Okay. Now all you need is some method of identifying the sender. Then
don't accept email except from those you trust. But who determines the
level of trust? Are some more trustworthy than others? Yes, they are.
But a DNSBL doesn't convey that information. They say only that you
should accept or reject a message based on its origin, not on the
sender or on the message contents. Binary decisions rarely work well
when dealing with conditions that have many variables. There's a very
large landscape of trust between "yes" and "no".

If a server is set up properly and message bounced with a SMTP
550 code would come to the attention of the mail server admin who could
then (1) secure his mail server & network (2) request removal (3) contact
the recipient (there are *other* methods of communication including
telephone, fax and letter).

You'd think so, but if you got a rejection with the text in, say,
Mandarin, would you take the time to translate it? If not, why would
you expect the rest of the world to pay attention to your English
language texts? Would you be inclined to call (or even to find their
phone number) a company in Singapore (or Mexico, Brazil, or Australia)
that rejected your email?

It's easy to put this at the feet of
Microsoft users,

It is if you don't understand the problem and like watching propaganda
disguised as advertising on TV.

but these certified baffoons who don't secure servers
need to be horsewhipped.

Most 'bot nets are composed of machines that aren't servers, so I'm
not sure where you're going with this. Most mail servers aren't the
source of spam. Of course, the IP networks they use may be the same as
the ones used by the compromised machines -- which brings us back to
the unreliability of DNSBLs when dealing with spam.
---
Rich Matheisen
MCSE+I, Exchange MVP
.



Relevant Pages

  • Re: Outlook Express Undeliverable
    ... If your client is not getting an NDR message back from ... his mail server (which means his sending mail server got rejected during the ... Maybe you have server-side spam filtering enabled and his mails ... sender is infected so his mails could also be infected. ...
    (microsoft.public.internet.mail)
  • Re: Bounce or discard?
    ... In the one case your mail server simply returns an error code telling ... the sending server that the mail was not accepted, ... in response to inform the sender of the bounce. ... One of the main differences is that in the case of spam with a forged ...
    (uk.net)
  • Re: Returning an email to its sender. Is that possible?
    ... How do you know the sender used their own e-mail address? ... will notice the sending mail server DURING the mail session. ... Fake bounces are tantamount to vigilantism. ...
    (microsoft.public.outlook.general)
  • Re: anti spam sw?
    ... It only tags suspect mail as spam. ... Bayesian filtering should ALWAYS be the *last* mechanism used to detect spam since it is a guessing scheme based on word weigthing over a historical sample set experienced by just one particular user. ... I also use the MXblocking plug-in because I don't want mails sent from dynamically IP addressed hosts. ... If someone wants to operate their own mail server then let them get a static IP address. ...
    (alt.computer.security)
  • Re: Beware of ISP spam filtering
    ... They receive the mail and tell the sender that they've got it correctly. ... Then they open a new connection to the destination server to pass the ... OTOH, if the destination server says no, maybe because the spam or virus ... it can send a bounce to let the supposed sender ...
    (uk.telecom.broadband)