For the second time in a month, I find out a server is listed in spamcop.

Ok that's not very groundshaking, it happens sometimes, but this is the second time in a month a server got listed WITH NO WARNING WHATSOEVER.

No emails from GNAX no emails from SPAMCOP no emails no contact from ANYONE so here I am unaware, until a user, a customer, a PAYING customer, complains that his email is being blocked by someone using spamcop! I check and sure enough, the server is listed at spamcop.

http://www.spamcop.net/w3m?action=checkblock&ip=65.254.42.68

I've gotten no email from spamcop or gnax or anyone about this, we handle spam problems within minutes of getting them, we NEVER ignore a problem or let it persist, once we know something's up we block/suspend/delete/scream at the user and put a hearty stop to it immediately.

I've removed spamcop from my RBL lists, obviously they're no longer useful to me as an antispam source, if my servers are listed with no warning I'm sure others are too.

Bye bye spamcop, it's been real but unfortunately you've gone the way of spews, too many listings and no warnings, a sad day.

Maybe it's because you scream at the user? :P I think you should contact SpamCop though.

Oh believe me I contacted Spamcop, again, but it's not like it's gonna stop them from silently and without warning blocking another server on down the road.

Are you sure someone on that ip/server wasn't sending out spam from your network? If they were then they have every right to list your server without notice. You should implement an outgoing filter so you can see where the spam is coming from.

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)
* SpamCop users have reported system as a source of spam less than 10 times in the past week

Possible reason is phish emails with return addresses to SpamCop traps.

Are you sure someone on that ip/server wasn't sending out spam from your network? If they were then they have every right to list your server without notice. You should implement an outgoing filter so you can see where the spam is coming from.

I have plenty of filters, the problem is I am not likely to parse through several 100 megs of logs UNLESS I KNOW SOMETHING IS GOING ON. Yes someone did send a little spam, it was an insecure formmail script as it usually is, and I put a stop to it, AFTER THE SERVER WAS LISTED WITH NO WARNING.

In one DAY's time my 100 or so servers will generate several GIGS of email logs, so are you suggesting I sit there watching those logs for a possible problem? If I get a report, I investigate, I find where it comes from, I put a stop to it, NO PROBLEM, NO HESITATION, but if I get NO WARNINGS no emails, no complaints, no NOTHING then what? Spend all day watching every mail server to see if someone is spamming but I am not getting any complaints?

Sure you go right ahead with that plan I prefer the anti spammers SEND ME COMPLAINTS so I can act on them, how hard IS THAT ANYWAY? Maybe if I had only 1 or 2 servers I could sit there all day watching mail logs with nothing better to do....

I'm not saying manually go through logs you should implement an outgoing filter to do the work it's quite simple actually. You could also require smtp authentication this would prevent most insecure scripts from being abused. I run a dnsbl service and it has just over 2 million ip’s listed are you suggesting that every one of those listed should be contacted to see why they sent spam to three or more of my companies spam traps just to tell me that they didn’t send the spam?

I'm not saying manually go through logs you should implement an outgoing filter to do the work it's quite simple actually. You could also require smtp authentication this would prevent most insecure scripts from being abused. I run a dnsbl service and it has just over 2 million ip’s listed are you suggesting that every one of those listed should be contacted to see why they sent spam to three or more of my companies spam traps just to tell me that they didn’t send the spam?

I am absolutely saying you should contact the abuse address for an IP before you list it, or AS you list it, ABSOLUTELY am saying that you should. It should be automated "ip to block, full header of email(s) that caused block, short automated note to abuse@wherever, save". I wouldn't tell you we didnt' send it, I'd tell you what did send it, and I'd put a STOP to it.

If you don't do this then your rbl is VERY irresponsible, care to share the name of it so I make sure not to use it?

Oh yeah filter outgoing email? Oh yeah that's real smart just imagine the crap storm when I block <insert some kinda important email here> and get served with a lawsuit because someone lost a big deal because of my blockage? Haha no thanks man I got enough problems. We implement some limits and stuff that make sense but still spam can slip through mostly formmailers and insecure scripts are the big problems.

Spamcop is getting lamer and lamer. We have a server get listed every few weeks and typically, we get no notification or we'll get one or two spam reports. Spamcop provides very little details as to why the server was listed, as well. They often list gmail servers too.

What do I do when they list us? I just change the outgoing IP of our mailserver and be done with it.

I am absolutely saying you should contact the abuse address for an IP before you list it, or AS you list it, ABSOLUTELY am saying that you should. It should be automated "ip to block, full header of email(s) that caused block, short automated note to abuse@wherever, save". I wouldn't tell you we didnt' send it, I'd tell you what did send it, and I'd put a STOP to it.

If you don't do this then your rbl is VERY irresponsible, care to share the name of it so I make sure not to use it?

Oh yeah filter outgoing email? Oh yeah that's real smart just imagine the crap storm when I block <insert some kinda important email here> and get served with a lawsuit because someone lost a big deal because of my blockage? Haha no thanks man I got enough problems. We implement some limits and stuff that make sense but still spam can slip through mostly formmailers and insecure scripts are the big problems.
unfortunatly it's not that easy...

example:
=========
Received: from adsl196-125-84-217-196.adsl196-11.iam.net.ma [196.217.84.125] by ***
(SMTPD-9.10) id A3380CB4; Thu, 19 Oct 2006 16:50:48 -0500
Received: from 196.217.83.177 ([196.217.83.177]) by adsl196-125-84-217-196.adsl196-11.iam.net.ma with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Oct 2006 21:44:22 +0500
Message-ID: <4537AAD0.1000704@coachingpsychologyforum.org.uk>
Date: Thu, 19 Oct 2006 21:41:52 +0500
From: Marion Mercer <szxtmn@coachingpsychologyforum.org.uk>
User-Agent: Thunderbird 0.7 (Windows/20040616)
MIME-Version: 1.0
To: ***
Subject: linguist
Content-Type: multipart/related;
boundary="------------030307090105060105000706"
X-IMAIL-SPAM-SPF: (f336041a00008f4a) SPFNone
X-IMAIL-SPAM-DNSBL: (sorbs.dnsbl.net.au,f336041a00008f4a,127.0.0.2)
X-IMAIL-SPAM-DNSBL: (t1.dnsbl.net.au,f336041a00008f4a,127.0.0.2)
X-IMAIL-SPAM-DNSBL: (dnsbl.sorbs.net,f336041a00008f4a,127.0.0.10)
X-RCPT-TO: <***>
Status:
X-UIDL: 461205763
X-IMail-ThreadID: ***
========

Classic spam header here, where does the abuse email go to and in what language? If you have an automated system that can do this and handle around 5000 ip's a day without triggering dns overflows let me know.

Those of you that aren't getting *any* SpamCop notifications - were your IP addresses allocated to you by a RIR such as ARIN or APNIC, or were they assigned to you by an upstream network provider?

We have ours allocated by APNIC, and we do receive SpamCop notifications where a user has reported a message as spam. Each report contains a link to SpamCop's issue tracking system where we can report what action was taken against the originating host.

What we don't get though (and this is why I despise SpamCop) are the notifications when we're blocked for allegedly sending a message to one of their spam traps. The unfortunate thing is - all it takes is a bounce message or an auto response to a forged originating address that happens to be a spam trap and you're blocked and don't know until customers complain.

-Shaun

unfortunatly it's not that easy...

example:
=========
Received: from adsl196-125-84-217-196.adsl196-11.iam.net.ma [196.217.84.125] by ***
========

Classic spam header here, where does the abuse email go to and in what language? If you have an automated system that can do this and handle around 5000 ip's a day without triggering dns overflows let me know.

That's all that matters, the ip that sent the spam into your system I assume the *** is your mail server?

The email address is useless, the other lines before the line(s) added by your mail server are useless because you can't trust them either.

So in this case you bitch at abusepoc@afrinic.net:

NetRange: 196.0.0.0 - 196.255.255.255
CIDR: 196.0.0.0/8
NetName: NET196
NetHandle: NET-196-0-0-0-0
Parent:
NetType: Allocated to AfriNIC
NameServer: NS1.AFRINIC.NET
NameServer: NS-SEC.RIPE.NET
NameServer: NS.LACNIC.NET
NameServer: TINNIE.ARIN.NET
NameServer: SEC1.APNIC.NET
NameServer: SEC3.APNIC.NET
Comment:
RegDate: 1993-05-01
Updated: 2006-04-27

OrgAbuseHandle: GENER11-ARIN
OrgAbuseName: Generic POC
OrgAbusePhone: +230 4666616
OrgAbuseEmail: abusepoc@afrinic.net

OrgTechHandle: GENER11-ARIN
OrgTechName: Generic POC
OrgTechPhone: +230 4666616
OrgTechEmail: abusepoc@afrinic.net

$ip = <ip of the server that sent it to me>
whois $ip | <parse out the abuse handle>
<mail full email to abuse handle along with a note>
<block ip>

This really ain't rocket science ya know. You only use the parts of the header you can trust 100% and that is the lines that YOUR mail server adds to the header, everything else you simply consider as faked or forged because it likely is. And you bitch at whoever that last hop is, you let THEM worry about how it got into their system by parsing the header for those parts THEY trust if any.

If they ignore you, block them.

extract ip of sending server into your system
extract abuse handle for that ip
email abuse the email that caused this
block that ip for a while

You can enhance this with things like "has ip ever been blocked? if so how many times?" and adjust accordingly.

What language? English is the language of the internet of course, if they can't deal with it, that's not your problem. (yes flame away about the English comment I expect it).

If you're parsing 'submitted' spam you can probably use the last "recieved" line and run with it.

Seriously if you're not skilled enough to properly handle the task of parsing headers intelligently and taking proper actions rather than just blocking ips willy nilly then you're a pretty irresponsible "anti spam warrior" ya know?

Seriously if you're not skilled enough to properly handle the task of parsing headers intelligently and taking proper actions rather than just blocking ips willy nilly then you're a pretty irresponsible "anti spam warrior" ya know?


Exactly. The biggest offenders: AOL, Comcast and ATT (or whatever RBLs they use).

Hint: Spam that is forwarded from ourcustomer@customer-domain.com to ourcustomer@their-Comcast-account.com is NOT spam that is originating from our network!!! :angry:

--Tina

I won't argue that rbls should or shouldn't be notifying for all blocks, or say how they should notify. The simple fact is the state of e-mail (well, SMTP) is bad and people go to great lengths to improve it.

That being said, you really should not be relying on your customers to find out you're blacklisted. Even if an rbl does not send you a notification, it is trivial to implement this as part of your monitoring solution. RBL lookups are a simple DNS query.

It can easily be monitored hourly to check all of your hosts without bogging down your network, and you can do it for all of the popular RBLs.

In addition, whether you actually filter outgoing smtp or not, it is definitely a good idea to try to record as much information about mail being sent from your servers as possible in a format that makes it easy to look up the information later (plain text logs probably don't meet this goal!).