[ExchangeList] Re: I NEED TO GRIPE!

  • From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
  • To: <exchangelist@xxxxxxxxxxxxx>
  • Date: Mon, 23 Oct 2006 14:47:10 -0500

You're right about that. When you deal with unaccountable entities with
questionable motivations and methods, it's better to avoid them all and
use more sophisticated and trustworthy methodologies to stem the spam
tide. Why put a company at risk using these "do-gooders" when you can
benefit from vendors who take responsibility for their products?
 
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/> 
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> 
MVP -- Microsoft Firewalls (ISA)

 


________________________________

        From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
        Sent: Monday, October 23, 2006 12:21 PM
        To: exchangelist@xxxxxxxxxxxxx
        Subject: [ExchangeList] Re: I NEED TO GRIPE!
        
        

        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: