[ExchangeList] I NEED TO GRIPE!

  • From: "Chris Wall" <Chris.Wall@xxxxxxxxxxxxxxxxxxx>
  • To: <exchangelist@xxxxxxxxxxxxx>
  • Date: Wed, 18 Oct 2006 12:13:41 -0400

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


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)
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...




Chris Wall - MCSE + Messaging

NAM Exchange Administrator


T (919) 460.3236

F (919) 468.4889


Global Knowledge

LEARNING. To Make a Difference.




Other related posts: