I know this is going to sound worse than the spirit in which I offer it but... Step one might be to adjust the attitude from "Deal with these people" to something along the lines of "how might we best resolve the issue".
No matter who you deal with, you will get much further with a good humble attitude rather than blame.
It is my experience that if they list more than a very specific range of IP addresses on your network, you have a real problem. If you have a spammer at the top and bottom of a CIDR block then they may list the range, but I have had them lost two small ranges in the same /24 before... so I know they have very good specificity.
I am sorry I can not offer you any specific steps or contact information to help you expedite the resolution, but I hope you will find some value in this advice.
Perhaps, if your network is small and you control all your mail servers and you really are clean, you can configure thrm to relay through a smart host or SendGrid or etc.
Good luck,Mike
Well,
I wouldnt have such a disheartened attitude if they would have been
specific or given time to comply.
I find listing an entire /17 without cause or a report to back it up an
unjust action.
I have contacted them through multiple mediums and have found no response.
So if someone has had better luck I want to know if I am doing something
wrong. I have also been absolutely pleasant with them. My frustration grows
as I am ignored.
Every network deals with bad apples I dont understand why our good standing
customers must also suffer these consequences.
Thanks
Have you tried the widely known services they provide?
http://www.spamhaus.org/lookup/
May I direct your reluctant attention to this, just under the first "lookup" box?
"If your IP address is listed on one of our IP blocklists; SBL, XBL or PBL (collectively known as the 'Zen' blocklist), this lookup tool will tell you which one and will give you a link to information on what to do."
May I focus your unwilling attention on "this lookup tool will tell you which one and will give you a link to information on what to do."?
Hello,
Yes I have followed all of the procedures. I will continue to wait to see
if there is any change.
Thanks
Would you please send me the address range in question--I would like to see what they told you to do.
I suspect that http://www.spamhaus.org/query/ip/199.87.233.245 may be part
of it (although it indicates a /21 blocked, not a /17).
- Matt
Yes that is part of it.
There are other blocks they listed as well.
And the removal instructions for that range (SBL) seems crystal clear to me, but long experience teaches that what is crystal clear to me is often to clear at all to spammers.
What is it about Colorado?
I am surprised that I have not been banned again for talking about spam here, so I'll leave you with this (from the information Matt provided):
http://www.spamhaus.org/sbl/query/SBL263089
Has these notations:
SBL263068 104.224.252.0/27 esited.com 2015-07-25 Spamming for fake products
SBL260293 104.224.197.94 whdot.com 2015-06-25 Spam source @104.224.197.94
SBL257796 104.224.205.144/28 whdot.com 2015-05-27 brand-fraud websites hosted on hacked subdomain
SBL253760 104.201.2.88 zeroddos.com 2015-04-16 Blackhat SEO spammer hosting @104.201.2.88
SBL249474 104.232.128.0/19 esited.com 2015-03-09 snowshoe range - CLOUDDDOS TECHNOLOGY CO.,LIMITED (AS22552)
SBL244070 104.221.128.0/17 esited.com 2015-01-05 snowshoe range - eSited Solutions
SBL244052 104.195.0.0/18 esited.com 2015-01-05 snowshoe range - eSited Solutions (NL-1)
SBL241541 104.201.0.0/18 esited.com 2014-12-02 Kuang Ren snowshoe range - ZERO DDOS LLC
SBL241495 69.87.192.0/20 d esited.com 2014-12-01 Kuang Ren snowshoe range - eSited Solutions (NL-1)
SBL241492 23.249.176.0/20 esited.com 2014-12-01 Kuang Ren snowshoe range - GCHAO LLC
SBL241491 66.254.160.0/19 esited.com 2014-12-01 Kuang Ren snowshoe range
SBL241489 162.247.232.0/21 esited.com 2014-12-01 Kuang Ren snowshoe range
SBL234439 104.167.64.0/19 esited.com 2014-09-14 spam emitters - ZERO DDOS LLC
SBL226660 199.87.239.226/31 esited.com 2014-06-27 DNS for spam domains
SBL223484 167.88.192.0/20 esited.com 2014-05-26 spam emitters - ZERO DDOS LLC
SBL207432 199.87.233.92 esited.com 2013-12-12 spam site - 78high.ss99g.com
SBL207431 199.87.239.226 esited.com 2013-12-12 spam redirector at zjjj58.com / s9gg.com
Removal Procedure
To have record SBL263089 (199.87.232.0/21) removed from the SBL, the Abuse/Security representative of esited.com (or the Internet Service Provider responsible for supplying connectivity to 199.87.232.0/21) needs to contact the SBL Team by email (use this link) to explain how the abuse problem has been terminated (we need to know exactly how the issue has been dealt with and that this abuse problem is fully terminated). If the abuse problem that caused this listing has been terminated we will normally remove the listing from the SBL without delay.
It is essential that emails to the SBL Team about this SBL listing include this exact ticket information in the email Subject:
If you are a representative of esited.com, you also need to see: Current Live esited.com SBL Listings
Yes Larry,
I have followed those instructions without a response.
So I was curious what to do when no response is given. I will wait longer
and see. Sorry if anything I have done has upset you.
Thanks
Well, http://www.spamhaus.org/sbl/query/SBL263089 has a fair amount of shady
stuff going on, and http://www.spamhaus.org/sbl/listings/esited.com gives a
pretty decent history of what Spamhaus has been doing. Note the
"(escalation)" entries in there, which indicates a lack of interest on
esited.com's part in fixing any of the problems.
- Matt
Hi Brian,
eSited has 37 unresolved spam listings with Spamhaus, all documented
and some going as far back as 2013. You got a problem boss.
In your position, I would start with "This list of customers has been
terminated for spamming. The hacks on these customers' servers have
been resolved. The following blocks are each used by multiple
customers. Can you help me get a better idea which one is spamming so
I can end it?"
Next, consider blocking outbound tcp port 25 by default and adding
exceptions upon customer request. Like a swimming pool, SMTP is an
attractive nuisance. You really have to take active steps to avoid
trouble.
If you have the tools, consider also capturing a day's email outbound
from your network and examine one random message for each origin.
Regards,
Bill Herrin
Would be nice to have an RBL service that attended NANOG meetings.
Would make for a more trusted RBL we can tell customers to make use.
Spamhaus ever attend a NANOG meetings ?
Thank You
Bob Evans
CTO
<delurk>
They come to M3AAWG on a regular basis and there’s the M3AAWG hosting SIG that you might want to participate in.
NANOG doesn’t always have a mail abuse (and not very many network abuse) session on the agenda, plus just how many people doing routing or DNS seem to even care what their colleagues down the hall in the abuse team are doing or which conferences they attend?
I remember a time (under the previous list management) when discussing spam here was deemed OT and non operational - off list warnings, suspensions and such. Ancient history I guess, but still ..
</delurk>
—srs
<m3aawg technical committee co-chair hat>
I agree with Suresh here -- NANOG used to almost be somewhat hostile
to anyone who started discussions regarding anti-abuse and/or security
issues which didn't involve routing backbone engineers.
A lot of us old-timers took the hint and basically started lurking,
not participating in meetings, or simply checked out of NANOG altogether
.
A lot of time has passed sine those days, so perhaps attitudes have
changed a bit with regards to operational anti-abuse issues?
- - ferg
</m3aawg technical committee co-chair hat>
<m3aawg technical committee co-chair hat>
I agree with Suresh here -- NANOG used to almost be somewhat hostile
to anyone who started discussions regarding anti-abuse and/or security
issues which didn't involve routing backbone engineers.
A lot of us old-timers took the hint and basically started lurking,
not participating in meetings, or simply checked out of NANOG altogether
.
A lot of time has passed since those days, so perhaps attitudes have
changed a bit with regards to operational anti-abuse issues?
- - ferg
</m3aawg technical committee co-chair hat>
I see that point - however, spamhaus has become a haus-hold word these
days and everyone runs into these issues....its not malware or bots we
block from a network level blackhole. Yet it is basic network operations
these days to have to deal with someone complaining about their hacked
mail server is now fixed yet they cant get mail. We usually tell them the
quickest way is to address spamhaus to get it removed and in parallel also
move the mail server to a new IP and change the dns and rDNS to the new
one. It gets us out of having to help with these RBL issues.
When an RBL sends a notice we jump on it and get it to the
customer...however, they usually dont send us or the customer anything.
Thank You
Bob Evans
CTO
Er - a couple of ways
1. If you run a farm of mail servers, something like splunk for your logs is kind of necessary. How difficult is it going to be to trigger a splunk alert on whatever looks like an administrative block? Either by a large provider, or by a DNS block list.
2. You can rsync spamhaus and grep for mentions of your ASN, get ISP feedback loops etc.
On a larger topic - NANOG and M3AAWG (also RIPE and M3AAWG’s summer meeting in Europe) really ought to collocate or at least be back to back in the same city somewhere down the line - maybe with a day’s worth of joint sessions on topics of mutual interest (malware detection and mitigation, DDoS filtering .. there’s a lot going on in M3AAWG that’s not plain old mail or even messaging)
It still won’t solve the larger problem that a lot of routing and DNS folks won’t find it of interest, but well, over the decade ++ I’ve been around M3AAWG I see an ever increasing number of (security focused, mainly) *nog regulars turn up there.
—srs
How do you know they don't? Most of them keep a low profile due to things like
http://www.bizjournals.com/southflorida/stories/2003/05/12/story1.html?page=all
I see that point - however, spamhaus has become a haus-hold word these
days and everyone runs into these issues....its not malware or bots we
block from a network level blackhole. Yet it is basic network operations
these days to have to deal with someone complaining about their hacked
mail server is now fixed yet they cant get mail.
If their mail server was SBL'd due to being compromised by spammers, they likely can't send mail / get remote mail delivered. They should still be able to "get mail", i.e. receive mail.
We usually tell them the quickest way is to address spamhaus to get it removed and in parallel also move the mail server to a new IP and change the dns and rDNS to the new one. It gets us out of having to help with these RBL issues.
That (moving them to another IP) should really be a last resort if the DNSBL(s) they're on are not responsive to being told the issue has been resolved. Moving them without having resolved the issue would be even worse, as it'll make it look like you're complicit with the spammer who compromised the server (since you're helping them get around the DNSBLs).
I did that once that I can remember, when one of $work's main SMTP servers was blocked by AOL, and when we reached out to AOL to ask why, their response was basically "Someone from our postmaster group will let you know why we're blocking you. It'll be at least a week before they can get to your ticket."