Hi there,

Like many others I was wondering if you could provide me some more information regarding racv.com.au being blacklisted by spamcop. The likely reason for this is misdirected bounces but I was wondering if you can supply any hints as to what actually triggers your traps so I can implement a change to rectify this. Happy to take any such changes to management for approval but hard to do that when we are not even sure what changes are required. Thanks in advance!

Here are the details :

168.186.253.10 listed in bl.spamcop.net (127.0.0.2)

If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 14 hours.

Causes of listing
System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop)
It appears this listing is caused by misdirected bounces. We have a FAQ which covers this topic: Why auto-responses are bad (Misdirected bounces). Please read this FAQ and heed the advice contained in it.
Automatic delisting
If you are the administrator of lsrex100.racv.com.au and you are sure it will not be the subject of any more reports of spam, you may cause the system to be delisted without waiting for us to review the issue.
You may only do this once per IP! So please be sure that the problem is really and truly resolved. If you delist your system and we get more spam reports about it, you will not be allowed to expedite delisting again. Delisting normally occurs 24 hours after spam reports have ceased.
--
Volume Statistics for this IP
Magnitude Vol Change vs. Average
Last day 4.1 -54%
Last 30 days 3.6 -83%
Average 4.4

Spamtrap details (anything giving a hint of the address) are not released, hopefully someone with access to any other UBE evidence will wander past and help (note we're just users here). The likely cause of the spamtraps triggering was one or more misdirected bounces to the trap(s). The volume stats you quoted are sourced from SenderBase (lookup on IP). The lookup on domain gives a more worrying picture, perhaps - though SenderBase still locates just the same IP - http://www.senderbase.org/search?showRBL=1...ing=racv.com.au

This would seem more meaningfull :

http://www.senderbase.org/search?showRBL=1...archString=RACV

Anyways, im not after any trap info and if I understand the idea of misdirected bounces, it would seem info on the reason for our blacklisting need not include any details about the trap itself. Hopefully I will get an answer at some point that might at least assist us. At the moment we are notifying the companies using spamcop of the situation but sadly they seem to have no ability to domain whitelist(dont know why?), its all we can do.

Have checked several lists of list of BL results ... not much found (though noting that http://www.moensted.dk/spam/?addr=168.186....p;Submit=Submit looks rather exciting at first glance)

There is absolutely no 'Report History' for that IP address, suggesting that the 'only' traffic issues for the SpamCopDNSBL is in fact spamtrap hits. Therefore, the only available data is whatever the Deputies may provide upon a direct request.

That is extremely frustrating to hear, basically its saying nothing really looks too wrong...yet I emailed the "deputies" on Friday via the website and again yesturday yet I have had absolutley no response. At the same time my company is severely hamstrung by this blacklisting. Any ETA on when I might recieve an email response? Id like to take the time to thank those who posted on this thread, its greatly appreciated.

Hopefully I get an answer soon...

I agree .... it's been quite a while since I've seen an IP address listed, yet so 'clean' ..... this actually has the appearance that a spammer has figured out how to specifically get this server to 'talk' to the spamtraps directly, usually in hopes of getting 'you' to join the anti-SpamCop/BL/etc. bandwagon. 'We' are just as stuck as you, not being able to see the evidence ....

On the other hand, http://spamcop.net/w3m?action=checkblock&a...=168.186.253.10 is now showing;
... will be delisted automatically in approximately 9 hours. .... so there hasn't been any 'new' traffic to cause the clock to be reset ....

Just some notes ... the "Deputies" are two people, augmented by Don, normally Admin affairs, but jumping in as time allows to the Deputy InBox ... they (try to) handle a self-admitted 800-1800 e-mails a day. In the case of spamtrap data requests, there is also a question as to just 'who' is asking for it. Some of the things involved would include how much data was provided, is it being requested by "someone in charge of the server" (i.e. a role account) .. and of course, attitude may come into play. Here in the U.S., Moday was a bit of an odd holiday, some businesses closed to provide the long week-end, others waiting until Thirsday for the 'real' holiday, others not paying any attention to it at all ... that may also factor into the delay in a response ...????

Not to argue too much, as I know it's a hassle, but .... you can send all the e-mail you want. It's only when that e-mail hits an ISP that has chosen to use the SpamCopDNSBL data in a blocking fashion .... first of all, that's even against SpamCop.net's own recommendations, ... second, this condition is far from a universal situation .....

There's no way for 'us' to know what type, quantity, etc. of your business conditions may be, but .... a temporary set-up to get over the (time) hurdle may or may not be a possible option??? For example, for your Incoming stuff, there are three servers identified;

warrane.connect.com.au reports the following MX records:
Preference Host Name IP Address
10 lsrex100.racv.com.au 168.186.253.10
100 yarrina.connect.com.au 192.189.54.17
120 warrane.connect.com.au 192.189.54.33

So backup for your incoming stuff is pretty much assured. Is there some sort of similar business/security plan in effect for your outgoing e-mail?

(Note, another list checked, only SpamCop.net identified at http://www.mxtoolbox.com/blacklists.aspx?IP=168.186.253.10 )

ANY message sent by your system automatically to the return address in a spam message is likely to be sent to a spamtrap. This would include non-delivery messages for incorrect address, out of office messages, over quota messages, etc. If they go to the reply address, they will cause a problem.

If your incoming mail is cleaned of spam before these processes happen, the likelyhood can be reduced, but never eliminated, as long as you are using them. In my company, we allow OOO responses, but the end user typically sees maybe one spam message every few weeks throug the filters. Other non-delivery reasons are handled during the SMTP process with 500 level error messages.



TEST:
220 APPNP002.ad.racv.com.au Trend Micro InterScan Messaging Security Suite, Version: 5.5 ready at Tue, 10 Oct 2006 20:49:04 +1000
ehlo underwood.spamcop.net
250-APPNP002.ad.racv.com.au supports the following ESMTP extensions:
250-SIZE 20971520
250-DSN
250-8bitmime
250 OK
mail from:<underwood[at]spamcop.net>
250 <underwood[at]spamcop.net>: Sender Ok
rcpt to:<12345tester67890[at]racv.com.au>
250 <12345tester67890[at]racv.com.au>: Recipient Ok
data
354 APPNP002.ad.racv.com.au: Send data now. Terminate with "."
This is a test mesages to what is assumed to be an invalid address. I should not see this message after I send it. I did not get a reject of the address.
.
250 APPNP002.ad.racv.com.au: Message accepted for delivery
quit
221 APPNP002.ad.racv.com.au closing connection. Goodbye!


Connection to host lost.

RESULT:
http://www.spamcop.net/sc?id=z1098277635za...ac274814ddc3f0z

Interesting when compared to the results of http://www.mxtoolbox.com/diagnostic.aspx?H...100.racv.com.au


So as previously suggested, implications are that the normal bad settings are showing as secured, but .... the the abuse of the "trusted" mode of the 'net' is what's being abused again, in all likelihood. I'm having a hard time talking myself out of the scenario that spammer intentionally got this server listed ...which, by the way ....

168.186.253.10 not listed in bl.spamcop.net

I have noticed we are no longer blacklisted...for the moment. I appreciate the efforts you guys have gone to thus far and I look forward to being contacted by a deputy so I can work out what triggered our reports so I can close the loophole. From my point of view I would never state that our messaging environment is perfect but I would have thought that it was secure enough to avoid making it on to these lists.

Thanks again.

You may have missed the critical item provided by StevenUnderwood. The e-mail server "accepted" an e-mail to an unknown user ... then generated a 'bounce/rejection/failure/whatever' message to notify the "alleged" sender of that e-mail .... this is what I have been suggesting .. a spammer/anti-anti-spammer may have intentionally been doing just this and using spamtrap addresses just to get this server listed on the SpamCopDNSBL. That the response went to a "forged From: address" is what all the fuss is about.