Blocked Email Logging

[Denis1982]

Hi,

Im new to Spamcop and block lists in general. What I want to know is how do I know which emails have been blocked by spamcop. Is there a Log for this.

The only thing that I have done on the Exchange Server is add the bl.spamcop.net url under connection filtering.

There has been a noticeable decrease in the amount of spam but I am uncomfortable about not knowing which emails are being blocked. So again, is there any way to monitor the emails being rejected by Spamcop.

Thanks.

[Farelf]

...There has been a noticeable decrease in the amount of spam but I am uncomfortable about not knowing which emails are being blocked. So again, is there any way to monitor the emails being rejected by Spamcop.

Yes, it is *dangerous* to simply reject - SC recommends filtering (with subsequent access and recovery available) per http://www.spamcop.net/fom-serve/cache/291.html No filter is 100% false-positive free, no matter what some say, and the SCbl in particular blocks "bad" ISP addresses which may/often do include "good" senders. So it is more liable than some to have false positives in the general scheme of things - practical considerations are another matter.

Hopefully an Exchange user can give you any specific detail you need. What version are you using?

[Moved from Reporting Help - this forum includes help with the use of the SCbl]

[DavidT]

No filter is 100% false-positive free, no matter what some say, and the SCbl in particular blocks "bad" ISP addresses which may/often do include "good" senders.

I can testify personally to that, in that I've seen some false positives recently involving messages sent by customers of Cox cable....including me. The IPs getting listed are Cox mail servers, rather than the actual source IPs of individual compromised machines. Don't simply make messages disappear due to SCBL hits....make sure they get put someone that a human can review them.

DT

[StevenUnderwood]

Don't simply make messages disappear due to SCBL hits....make sure they get put someone that a human can review them.

I completely agree with this. However, that statement could be enforced by rejecting the message during transmission (not accept and bounce) where the sender becomes the human to review. At least the sender knows it did not get delivered. If it is redirected to some internal queue, there is no guarantee that anybody ever sees that message again.

I've seen it in several different business settings. A person is assigned to a task (monitor the queue). The first week (month, year, whatever) that person does their job but never sees anything of value (or even occaisionaly does) and then other duties are added to this person and they either do not have time or plan to do it less. Maybe that person is replaced, but this specific job function is not passed on. Suddenly the message queue has not been checked in months or years, problably because someone got angry at not getting a reply while others have simply walked away.

The SpamCop SCBL is aggressive, you seem to understand that some legit messages will be bounced. If you understand your processes, you should be able to make the decision how to handle the "marked" messages.

[Telarin]

I use the SCBL on my exchange server, and I reject messages. From a liability standpoint, it is MUCH better for a customer to get back a rejection telling them that we did not receive their message, and using some other message to contact us than it is to have a message lost in a spam box with 10,000 other spam messages that someone has to sort through.

[DavidT]

Except that in the case I mentioned above (Cox servers on the SCBL), we end-users, the senders of the messages, aren't necessarily receiving the bounces, which go into a black hole. I have never received such a bounce, despite some of my mail being routed through listed Cox IP addresses.

DT