[ExchangeList] Re: I NEED TO GRIPE!
- From: "William Holmes" <wtholmes@xxxxxxxxxxxxxx>
- To: <exchangelist@xxxxxxxxxxxxx>
- Date: Mon, 23 Oct 2006 13:21:07 -0400
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam system
has a cost benefit ratio, when that ratio drops below an acceptable ratio its
time to move on. There are more effective ways to handle spam that your
organization can have direct control over.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a toll for
causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
Any one wanting to read or chime in, please feel free! I know all of you are
e-mail admins, and you may have some thoughts on the subject as well.
I am extremely disappointed with SpamCop.net - one of the few blacklist sites
that have - rather, HAD a good reputation...
Is any one else being affected by their actions of Blacklisting domains
because they follow RFC822 and send NDR's when a mail is not successfully
delivered?
Okay, here's the overall story - SpamCop sets up these 'HoneyPot' email
addresses (whatever@xxxxxxx). SpamCop then sends e-mails out to many domains
(illegitimate e-mail addresses - basically acting as spammer's themselves)
and wait to see which domains send an NDR back to the 'HoneyPot' email
address. If your domain follows RFC822 and sends the NDR, they blacklist the
IP address of the server that sends the NDR.
Their website ( http://www.spamcop.net/fom-serve/cache/329.html#bounces
<http://www.spamcop.net/fom-serve/cache/329.html#bounces> ) even details
their stance on the issue. I have copied it below:
'Q: Why not allow bounces? They are required by RFC822!
A: Originally, SpamCop made attempts to forgive misdirected bounce messages -
to reject them as evidence of spam. However, there are two factors conspiring
to force us to rescind this policy. First of course, is that these
misdirected messages *are* spam as we define it (Unsolicited Bulk Mail). They
are objectionable to recipients and can even cause denial of service to
innocent third parties. Users of our blocking service want us to stop them.'
I understand what they are trying to accomplish - to prevent NDR's from being
sent to you when spammers 'spoof' your personal e-mail address. However,
SpamCop is punishing domains that abide by all security standards for e-mail
except for their 'rogue' approach to NDR delivery. Total BS in my opinion.
Now of course, any domain could enable LDAP authentication on incoming e-mail
and block NDR's being sent when an e-mail address is sent to a non-existent
e-mail address in your domain - BUT, even excluding RFC822 rules requiring
NDR's on e-mails that are not successfully delivered, most organizations want
to keep NDR's enabled so that senders are aware if a message is not
successfully sent. I mean, if a customer sends an e-mail to our domain and
misspells the SMTP address of one of our sales people - You want an NDR to go
back to them so hopefully they realize their mistake.
Spamcop.net even says to use SPF for checking the e-mail origin... Well, I
use SPF. But only block e-mails where the sending domain provides an SPF
record and the authentication fails. I am not going to block emails coming
into our domain just because a sending domain may not have SPF setup for
their domain... I mean, I cant force them to provide and SPF record, even
though it is recommended.
SpamCop.net users should either stop relying on their services or either use
SpamCop.net in a 'weighted' approach for determining SPAM.
Any way - I had to gripe about this poor decision on SpamCop's behalf and
would like to get your opinions...
Regards,
Chris Wall - MCSE + Messaging
NAM Exchange Administrator
Chris.Wall@xxxxxxxxxxxxxxxxxxx
T (919) 460.3236
F (919) 468.4889
Global Knowledge
LEARNING. To Make a Difference.
http://www.globalknowledge.com
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
Other related posts:
