Hi All,

I'm aware this site doesn't directly have involvement with Senderbase, but according to Google, this is the only place anyone knows anything at all about it, so I thought I'd try my luck.

I'm not so much expecting to see anyone that can remove me, as much as hoping to find anyone that can provide information on how to this reputation improved.

On the 15th we started seeing bounces to users of Ironport devices, due to our poor Senderbase reputation. I sent an email to support[at]senderbase.org on the 16th. We went through all this first:
We confirmed our DNS. Specifically, our IP had an rDNS, which would resolve to a name, which would resolve back to that IP, which was the name in use in our HELO messages.
We were not listed on any RBL found on http://www.robtex.com/rbl/
We had a good reputation with Barracuda, Neutral with Trusted Source, "Insufficient email seen" from Sender Score, and not poor with anyone else.

It wasn't until the 21st we got a reply, with these key notes:
-SenderBase is not a listing organization

If the spam problem is fixed as you believe it to be, then there should be no further complaints received. Once all issues have been addressed (fixed), reputation recovery can take anywhere from a few hours to just over one week to improve

The most recent complaint we have on file is dated Sunday, March 15,

Well I'm not sure how they are not a listing organization. They maintain a list, we are on it, and we can't get any email out because of it.
On the 23rd, we became "neutral" with senderbase for half an hour, before becoming suddenly "Poor" again.

It's now nine days we've been unable to get email to Ironport users. Contrary to recommendation on the Senderbase site, Australia's largest ISP seems to outright reject (554 Error on connection) any email from us at all.

The main suggestion I have had regarding the relisting is the sudden "spike" reported in our traffic. Of course we have a spike. We had 0 emails going out because we were blacklisted. When we became available, everyone in the business rushed to resend their legitimate emails.

The second recommendation I see is regarding the fact senderbase.org lists us as having "unverified forward/reverse DNS", which is confusing because the it looks fine to me. Looking at www.robotex.com in the "reverse DNS" section shows an A -> PTR loop between the name and IP.

The third is just about improving our ham/spam ratio. We've had this IP without incident for years. We can't get any email out at all in order to improve our ratio, because we are in this catch 22 of being blacklisted.

The fourth is that we don't place ourselves on the bonded sender list. Sorry, but paying to apply for a whitelisting (which is unrefundable, yet unlikely to be accepted given our current listing) is just something I can't accept as a requirement for a company that produces nothing in the way of email lists.

It's not a shared IP. It's a dedicated mail server for our network only and this address is not used for Internet transit, so for a trojan to be an issue, it would have to smart host.

I sent an email back to Senderbase on 21st, requesting any sort of clarification or advice, but have not received any reply.

I'm all for blocking spam by every means possible. I agree with the methodology used by most blacklists out there, and I agree you usually get listed because you deserve it.

But this listing provides no information which is useful ("you have a bad reputation" is not useful) regarding how it lists. Looking at the senderbase information for IPs in my ISP's netblock, I can see addresses with no rDNS, and addresses listed in Spamcop or multiple RBLs currently, which have "Good" reputations with Senderbase. Clearly something unfair is going on for this to occur.

I've contacted the ISP in question, their view on the matter (which affects at least half a dozen domains we are sending to) is that they don't run the blacklist, but we wouldn't be there if we weren't evil, so no whitelisting will happen. Yes that's their problem, but I'm not getting anywhere with it.

It is now nine days since our original listing. The IP in question is 61.14.113.190. I'd love someone to prove me wrong about the rDNS or similar. I'm more interested in dealing with the issue than being right. I'm just completely at my wits end regarding what could ever be behind this situation.

All magic to me - but could it be something to do with your MX being set as mail.cocaus.org (61.14.118.130) and you are (from what you say) sending from smtp.cocaus.org (61.14.118.190)? Sounds fine to me, but there has to be some explanation, somewhere.

The behaviour you discuss is the current behaviour. To my knowledge there's nothing non-compliant about it. As I said, it's a "non-transit IP", specifically for the purpose of ensuring nothing comes out that IP but legit email.

I'm open to look into changing this configuration if anyone can point at a specific requirement, but it's standards compliant behaviour as far as I'm aware.

Far to many inconsistencies in the story line for me. Perhaps somewhat biased a bit, after spending 30-40 minutes doing research on the only data available at the time of our inital post, which was your 'posting' IP Address ... then coming back to make a Reply, only to find that you had edited your post and actually provided an IP Address to work with .. which of course didn't match what I'd been researching (although, some of the data and situations strangely similar??)

There is a bit of a problem trying to put those sentences together. Are you actually stating that each and every out-going e-mail was somehow magically sent to an IronPort configured e-mail system and that every one of these systems was also configured pretty much the same way, all somehow managing to use the same database information at the same time? That seems to be quite a reach of timing, coincidence, targeting, among the many other things avaiable for factoring into the mix.

I've ysed several tools to do various look-ups on the Domain name that is apparently involved ... cocaus.org .. most seem to have the same 'issue' .. for example;

http://www.senderbase.org/senderbase_queri...g=61.14.113.190
Report on IP address: 61.14.113.190
Hostname: smtp.cocaus.org
Information from whois
No information found for 61.14.113.190

ns1.christianit.net reports the following MX records for 'cocaus.org':
Preference Host Name IP Address TTL
10 mail.cocaus.org 61.14.118.130
http://www.mxtoolbox.com/diagnostic.aspx?H...mail.cocaus.org
Connect Time: 0 seconds - Good
Transaction Time: 5.859 seconds - Warning

Although your description may be truthful, it's a bit hard to substantiate, especially in dealing with the current e-mail situation.
http://www.senderbase.org/senderbase_queri...g=61.14.113.190 says:
Date of first message seen from this address 2008-03-04 ... one year+
http://www.senderbase.org/senderbase_queri...ring=cocaus.org says;
Date of first message seen from this domain 2009-03-22 ... after your problem started
WHOIS data says: Created/Registered Dates of 24-Feb-2009 / 3-Mar-2009 ... still shiny new .. ????

As above, this remark seems a bit over-the-top .... zero outgoing e-mail??? This would seem to suggest that your up-stream would be blocking all of your traffic, but it seems like that would be readily apparent in your own server logs, which you don't mention at all.

Perhaps semantics, perhaps some strange definitions involved, but .. I really don't grok your statement. If it's sending out e-mail, it surely does "transit the internet" .... Not sure why you would describe an "e-mail server for our network" as 'not' being a smart host, but I suppose 'smart host' could be defined in several different ways.

Once again, I'm lost in comparing this remark to the "zero e-mails going out" descriptions.

On one hand, thanks for acually providing the IP Address in question .... saved me from making yet another 'abusive' post about spending ten minutes reading your story and finding that you offered only an invitation to PM a request for this data 'if interested' ....

For the only data I can try to throw in at this point, I see a question involving the 'newness' of the IP Address, Domain name, and Registration data as probably lending some weight to the Reputation scoring. Yet, I am left a bit baffled by trying to match this data to your "have had this IP for years" description. No idea how to tie those totally different factoids together.

OK, perhaps this should clarify. The domain was renamed recently. The IP itself, had its rDNS change in accordance with this.
As far as the IP we have been sending from, it is still accurate it has been used for years without any such issues thus far to my knowledge.

OK, another clarification. 0 email according to the magnitude on senderbase. 0 email going to Ironport customers, as the one big ISP we are emailing that we aware of using it, does an "instant reject".

As above, I meant this in relation to Ironport users.

As above, we have had the IP for years. We have three domains used by the one business, and we changed the one referenced in rDNS. We were already blacklisted at this point. We had been for days, and were grasping at straws regarding how to get a delisting (which we still are).

Unfortunately, this means anything related to the "newness" of the domain or IP aren't valid.

Thanks for the input, it's more than we've received from anyone else thus far.

You say "years" ... previous post showed that SenderBase says;

http://www.senderbase.org/senderbase_queri...g=61.14.113.190 says:
Date of first message seen from this address 2008-03-04 ... one year+ a few days

Domain change makes sense, but this part doesn't.

Interesting that this is the second instance today of a "multiple Domains using the same e-mail server" scenario .... and both are having some severe issues with that configuration .. hmmmm

As I can't get SenderBase folks to answer my questions either, I offered that guess as a possible/probable part of the weighting score in the Reputation points algorithm.

OK further research has me wondering about a fair share of other things possibly going on .... some of them I really don't like .... (Some URLs have been 'broken' for display purposes here)

Slow traceroute cocaus.org
Trace cocaus.org (61.14.118.130) ...
202.148.230.211 RTT: 249ms TTL:170 (202.148.230.211.securetel.com.au probable bogus rDNS: No DNS)
* * * failed
* * * failed
* * * failed

Fetching http://cocaus.org/ ...
GET / HTTP/1.1
Host: cocaus.org
HTTP/1.1 403 Forbidden
<title>HTML Redirection to https: secure site</title>
CONTENT="1; URL=https://mail.cocaus.org/owa"
This page is attempting to redirect you to <a href="ht tps://webmail.livingcare.org.au/">htt ps://mail.cocaus.org</a>

Fetching http://cocaus.org/https://webmail.livingcare.org.au/ ...
GET /https://webmail.livingcare.org.au/ HTTP/1.1
Host: cocaus.org
HTTP/1.1 403 Forbidden
This page is attempting to redirect you to <a href="ht tps://webmail.livingcare.org.au/">ht tps://mail.cocaus.org</a>

Letting an actual browser loose on the attempt endsup with the URL;
htt ps://mail.cocaus.org/owa/auth/logon.aspx?replaceCurrent=1&url=ht tps%3a%2f%2fmail.cocaus.org%2fowa%2f

My recollection of the last time an OWA server came up, there was a boatliad of other stuff running on the same system/server, which had some other ramifications .... at the moment, all the redirction, URL replacement (and apparently tried to make it invisible) code that redirects to a URL that also redirects leaves me wondering what's really (been) going on. Perhaps off-topic, but ...????

...IIUC, technion addressed this (right, technion?):

I'm not sure of the answer ... 'owning' an IP address is one thing, using it for outgoing e-mail traffic is something else. That's the difference I'm not sure how to reconcile with existing data.

On the other hand, something in my head about another SenderBase record that seemed to change some of that data .... somewhere within the last few months ... I believe there was some speculation that perhaps after some timeframe of zero traffic, the "first date seen" database entry got nulled ????

It would appear that, with the rename, I updated the META redirect, but left the manual "click here" link. Now fixed.

Not sure where that URL came from. The webmail site was webmail.livingcare.org.au, now it's mail.cocaus.org.

We're still talking about one company. It's not like it's an ISP's email relay or anything.

Typical Exchange webmail. Try direct if you like -> mail.cocaus.org/owa and you land on a similar looking URL.

In a dedicated Exchange server environment, most people follow this guide, leading to the behaviour you describe:
ht tp://technet.microsoft.com/en-us/library/aa998359.aspx

True, there's a frustrating amount of lack of information about how the service runs.

I'm happy to grasp at straws at this point.

I consider Telerin the in-house expet on Windows Exchange servers, but suspecting he may not monitor this Forum section. Am kicking out a PM to see if he might have any input on things, perhaps just to help clear up some of my misgivings about data seen ...???

Hmm, I'm not seeing that this is really an exchange related issue. The page in question looks like a standard OWA page for an Exchange Server to me. Without information from Senderbase as to WHY they are ranking your IPs with a poor reputation, I'm not sure what could be done. I'll be happy to do a bit more research to see if I can come up with anything, but at this point I doubt I can find anything that hasn't already been mentioned here.

I'm quite convinced we've been sending email from that IP consistently some time prior to that date.
Maybe I'm wrong. In either case, it's still a lot of history to be blacklisted for now ten days over what, according to Senderbase support, is a single incident.

Thanks for that. I wasn't seeing anything wrong either, but with the current frustration I'm grateful for a second opinion on anything at this point.

Updating on current situation:
htt p://www.robtex.com/ip/61.14.113.190.html <-- not listed anywhere
htt ps://www.trustedsource.org/query/61.14.113.190 <-- sender reputation "trusted"
h tp://www.barracudacentral.org/lookups <-- "Not listed as poor"

It's a real struggle to see so many great services consider us an acceptable email server, with one service blacklisting us for ten days thus far.
There's an IP in our ISP's same address space with no rDNS, listed on three RBLs (of the five senderbase check), yet has a "good" reputation.

Interesting update now.
As of five minutes ago, I became "good" (even better than neutral!). I was about to post here in excitement, but decided to refresh the senderbase page to be sure.

Now, it's telling me "poor" again.
Only now, it's telling me that the hostname associated with that IP, is the old one, prior to the change several days ago.

I've done a "dig" from several different machines around the place (using different DNS servers) and they are all giving me the current rDNS name.

My monthly magnitude went from 2.2, to "unknown", to 0, to 3.0, over the course over about ten minutes.

Something's clearly not right in Senderbase.

I'm seeing "neutral" - with the rider "no email was detected from 61.14.118.0/24". So it shouldn't be changing from neutral very quickly. I guess strange things happen in the brief time the algorithm takes to recalculate and promulgate the ratings based on observed traffic (or none). If some sort of regression of your history is involved I can imagine things become quite volatile as it approaches the end. It seems anyway/somehow that your 'history' has been reset. Maybe that's routine, maybe that's their way of saying "sorry" (or "go, and sin no more" - yeah, I know, what sin?)

Can you get through to BigPond customers again?

Geeze .... I know we've been 'here' before. I wish I could get an answer from thos folks ... Initial page load of http://www.senderbase.org/senderbase_queri...g=61.14.113.190

Report on IP address: 61.14.113.190
Hostname: mail.livingcare.org.au
SenderBase reputation score Poor
Domain livingcare.org.au
Date of first message seen from this address 2008-03-04
Volume Statistics for this IP
Magnitude Vol Change vs. Last Month
Last day ...... 0.0 .. N/A
Last month .. 2.2

The last time this came up, a simple Refresh managed to bring up a page with different data. Not tis time. A dozen Refreshes on an IE7/WinXP-Home machine brings up the same page/data. Slid over to another IE7/WinXP-Pro machine, same page/data. Iceweasel/Debian machine, same page/data. So can only assume that this time, from this location, the Akamai configuration is working all too well ...

dns www.senderbase.org
Canonical name: a579.g.akamai.net
Aliases:
www.senderbase.org
www.senderbase.org.edgesuite.net
Addresses:
8.18.91.74
8.18.91.120

Trace www.senderbase.org (8.18.91.120) ...

Perhaps some documentation of just what servers/addresses (with data) others are getting might lead to a more specific question for the SenderBase folks this time ...????

I end up looking at this server:

[root[at]ceilingcat ~]# dig +short www.senderbase.org
www.senderbase.org.edgesuite.net.
a579.g.akamai.net.
210.9.88.51
210.9.88.58

Which takes *forever* to load. You'd swear it was running off a dialup modem.
As of right now, I'm getting the correct rDNS address again, "unverified forward/rev DNS match", my network owner is "Unknown", as is the "date first email seen from this address", and my score is unfortunately still "poor".

Aaagh, now I'm seeing the poor reputation again (yes, it is very slow to load from the west coast too):

Report on IP address: 61.14.113.190
Hostname: mail.livingcare.org.au

Domain livingcare.org.au
Date of first message seen from this address 2008-03-04

Volume Statistics for this IP

Magnitude Vol Change vs. Last Month
Last day 2.0 -37%
Last month 2.2

Server probably a72-246-53-9.deploy.akamaitechnologies.com [72.246.53.9]

based on tracert, nslookup

Non-authoritative answer:
Name: senderbase.org
Addresses: 72.246.53.26, 72.246.53.9

Someone, somehow, has to tell them their 'lottery' approach to DNS, traffic counts and reputation scoring is not a valid vehicle for spam control.

It was put to me elsewhere that this was probably my fault for having inconsistent DNS servers managing that IP range. Before anyone else suggests it, I struggle to see this being the case:

[root[at]ceilingcat ~]# dig +short ns 113.14.61.in-addr.arpa
ns3.brennanit.net.au.
ns2.brennanit.net.au.
ns1.brennanit.net.au.
[root[at]ceilingcat ~]# dig +short -x 61.14.113.190 @ns3.brennanit.net.au
smtp.cocaus.org.
[root[at]ceilingcat ~]# dig +short -x 61.14.113.190 @ns2.brennanit.net.au
smtp.cocaus.org.
[root[at]ceilingcat ~]# dig +short -x 61.14.113.190 @ns1.brennanit.net.au
smtp.cocaus.org.

Yeah good point, but brief checks are not conclusive. Before they started charging for their reports I found DNSstuff gave the most comprehensive analyses. There are some free DNS reports out there from other providers but last I looked none covered the whole range in one report as DNSstuff did. And DNSstuff have a free trial, from what I can see. I think getting a DNSstuff domain report would be worth doing, just to put that aspect to bed, once and for all. Or it might actually show a critical problem, which would be the best possible result (maybe missing 'glue' or whatever).

I had already been through thednsreport.com, which provides the exact service dnsstuff.com did before it became a paid service.
It warns me about glue at the parent nameserver, but that's only because the DNS servers are on a different TLD. I've got hundreds of domains I've been involved with run the same way, and the expected issue (an extra few seconds in lookup time) is all I seem to get.

There is a "fail" surrounding the two DNS servers being on the same network. I know exactly how many pipes to the Internet that network has and aren't too worried about that. I'd really hope things like this don't cause "suspicious threat activity".

All sounds good, seems you've considered everything that should or could count. I was sort of thinking of the DNSstuff member forums (and the quality of their documentation of issues found in the report) but you're far from a newbie in this stuff so probably none of that would advance the understanding of this perplexing case (though it may be time to look at the improbable too, as Sherlock would have it). Alternatively, SenderBase surliness remains inexplicable - unless SB cares to break with tradition and explicate. They really have to do that, haven't they? All very well for them to say they're not responsible (in depth) for the way users implement the service but at the same time they have a reputation for sensitivity, accuracy and relevance to maintain lest those self-same users gain the notion they might better put their trust elsewhere.

Well something did work. That something being to send them an email from a completely different domain. (no, my original emails weren't blocked by filters, they were from a different domain again to the one experiencing the issue. But they'd appeared to have had enough of me after the first email).

The reply was pretty much a cut and paste of the first, that being that they had a single complaint on the 15th (now 11 days ago) and a story about how when you have a bad credit rating, it takes a while to get it back, and I would have to "earn" back my neutral Senderbase reputation.

They never addressed anything relating to the DNS situation.

OK, that's not an issue and you're stuck in the 'Catch 22' of having to earn a reputation (which remains "Poor" at this time) by sending 'good' mail to SB users who are using your lowered reputation to block all mail from you. On the basis of a single complaint. Which should never have been made (presumably you are a charity or not-for-profit and exempt from the provisions of the Australian Ѕpam Act, and only sending to Australian addresses hence the exemption applies).

Seems no progress can be made with SB. Can you approach ACMA about this? Australian Registered Body registration detail would help establish your status and ACMA may be able to intercede with BigPond and others on the basis that an extra-legal restriction has been placed on your activity. Which is a monumental grey area - providers' servers, their rules - but, just maybe? It is, of course, in the interests of both the State (for Incorporated Association registration matters) and Commonwealth (Telecommunications matters) authorities to assist you so as to minimise State and Federal funding of whatever services you provide. SenderBase might lose Australian clients if the matter were advanced rapidly and robustly by ACMA but alternatively they might yet be able to adapt to suit applicable law in the local jurisdiction (which is their obligation, after all).

Just a layman's thoughts on the thing - there are few other courses of action, it seems to me.

Thanks for that. I'm also not aware how such things affect us, but will consider looking into it.

I did hear on another forum that, yet again, this was probably my fault for having a domain which was not registered at abuse.net.

This sounded overly stupid to me - I've certainly never heard of any requirement to do so. It's certainly not RFC mandated. But it WAS pointed out to me that senderbase's whitelisting service will only consider domains registered there.

Well I did so, and less than an hour later, turned around "neutral" on senderbase.

I waited an hour before posting this in case we were back in one of those flap states, but it doesn't appear to be.

I've severly rate limited our email through to Ironport users to ensure we don't get some massive traffic spike, I guess we'll see what happens over the next few hours/days.

Just curious, but what forum?

I know SpamCop uses abuse.net registration for its reporting addresses, but that makes sense because that is what abuse.net is there for. Like you, I would never expect it to affect a reputation score.

Microsoft's internal Partner Community (Exchange Miscellaneous).

Probably the last group of people I'd expect to be cluey on this, but then, Exchange configuration issues were suggested on this forum, so I took it there.

Presented them with full dumps of all Exchange config data, but when noone could see anything wrong, they started looking for less obvious issues in the same way we all have been.

Update: Still neutral four hours on.

I never would have thought of that, should have - more accustomed to thinking in terms of rfc-ignorant.org listings maybe. So much for 'considering the improbable', eh? SenderBase could be a lot more helpful, especially in personal messages (which would save having eventual solutions 'broadcast' in open bulletins ).

Thanks for the update to the 'knowledge base' and for the good news. Reputation still neutral at time of this post - SB response delay seems to be permanent now - probably deliberate (in which case one could almost grow fond of captcha as an alternative).

It could still be completely coincedental. For all we know we got punished for 15 days because of one reported incident.

Most of the options are requite depressing here. Whether it's abuse.net, loooong delisting periods, the fact a long established rDNS name for changed, or something else entirely, it's all stupid when you don't tell the person.

Open relays only get closed when they are told it gets them off an RBL in a matter of hours. This reputation guesswork is rubbish, and it does nothing to encourage people to improve their networks.

I'd also like the bigger Australian ISPs, all of whom seemed to be using this garbage filter system, who'd like to consider this. Multiple tech support agents would only give me the same thing about a "zero tolerance approach to spammers" and couldn't comprehend at all that this reputation system doesn't necessarily make guarantees about a certain IP belonging to a known spammer.

Agree, trouble is, it is extremely effective against the majority problem - spam from botnet senders (more than 50% of the traffic hitting every network, often 90% +) pushing fast-flux hosted spamsites (or Chinese/Romanian, whatever 'bulletproof' hosts, virtually untouchable). My provider, iiNet, uses it (switchable for inwards mail within user accounts) and I was able to infer ~99.7% effectiveness in stopping spam, judging by a 30 day trial with inwards filtering switched 'off'. Around 3,500 spam received in that time, compared to the default of having it switched 'on' when around 12 would be expected over the same timeframe. Which ain't bad for a commercial solution. No evidence of false positives seen but that can be hard to know - and your case demonstrates it will occasionally happen - though not a false positive in SB terms. Seems SB are quite prepared to live with low incidence false positives/injustices, in preference to making some very minor concessions in terms of 'policy' disclosure, as long as their clients are happy too (can't expect things to be otherwise). The end-users mostly live in a permanent state of numinous incomprehension so little/no pressure on providers from them. 'Such is life,' as Ned said. As proposed, ACMA might be able to make a difference - as an outside chance and while Conroy is boosting them above their former situation of obscurity.

Noting from http://www.senderbase.org/senderbase_queri...g=61.14.113.190 "SenderBase reputation score Good" - despite 0 Last day magnitude. And showing "Hostname: mail.livingcare.org.au". The object of "trying to make sense of it" is not working out well but nice to see that green.

It's telling me "neutral" at the moment, but I'll take grey over red any day.

I'm sure no closer to making sense of it, but I thank all the comments the same. It was helpful to at least keep busy with something throughout this process.

Hello,

Like another poster (technion), I'm aware that this isn't a senderbase forum, but I don't know where else to turn. I sent emails to support[at]senderbase.org on Mar 21 and Mar 22, and (in desperation) to dns-admin[at]ironport.com and hostmaster[at]ironport.com on Mar 23, but I've so far received no response.

My (primary) email server at 98.124.190.3 is listed at senderbase as "Poor", but I can find no reason for that other than my IP addresses recently changed. I run a small web hosting business (www.westryn.net). Around March 16 we moved our servers (web, email, dns, etc) to a new co-location facility, and of course we received new IP addresses. I assume that the new-to-us IP addresses were not previously in use, so when they were assigned to us their usage went from zero to a few hundred emails per day. We handle the email for our own business, plus emails generated by the websites that we host. Those emails are mainly order confirmation emails etc for e-commerce sites. We don't run any mailing lists.

I believe our rating has been "Poor" since the moment that the mail server was turned on in the new facility on the new IP address, as some MTAs refused to talk to our mail server right away.

We were not blocked by anyone when we were on the old IP addresses (the old mail server IP was 66.228.55.4, and you can see at senderbase that the current daily magnitude is now zero).

The senderbase query doesn't show us to be on any block lists at all. I do have reverse DNS in place, the forwards and reverses match, and I control the reverse DNS zone. I don't understand why the senderbase query results don't seem to see the reverse DNS.

I have abuse email addresses in place (and have had since the early 1990's), and I have registered them at abuse.net. Our hosting clients do not use us as a connectivity ISP, so they do not send their general email out through our mail server. We don't have anything except our servers on this block of IP addresses.

Because of the rating, many of my outbound emails are being blocked, with log messages like this (they vary depending on the particular destination):
554 Access to this email system has been rejected due to the sending MTA's (Hostname=mail3.westryn.net IP address=98.124.190.3) poor reputation score. Your current email server reputaion can be viewed at http://www.senderbase.org/
In fact, my server monitoring software can't even send txt messages about server problems to my cell phone because the txt service has blocked my emails (I am working with the txt service to try to get our mail server whitelisted with them).

I contacted AOL directly, and they have whitelisted us. But, it's obviously not practical for me to contact individually every ISP to which we or our hosting clients might send mail and ask them to whitelist us.

I have not received any reports of abuse to any of my (or my clients) abuse email addresses.

Can anyone please help me understand why my rating is Poor, so that I can fix the problem? Or, does anyone know of another way to contact senderbase, other than sending email to their support address?

Thanks in advance for any help!

Asking the same questions, telling pretty much the same tale .... This Topic will be mergd into that existing Discussion .....

While over on senderbase yesterday, I noticed an "IronPortNation" link which points to: http://www.ironportnation.com/forums/

I don't know what is being discussed in there, however. Anyone looked it over yet?

has anyone from the forum tried contacting senderbase? Now that there are two posters with the same problem, possibly an email from a third party might, at least, get someone thinking that their 99.98% rate (and now I don't remember whether it was for the amount of spam caught or for the number of positive positives). Anyway, it doesn't look good to be catching false positives. If they are like spamcop, there will be no answer, but things might change.

Miss Betsy

Unfortunately, if such a contact method existed, I would have done it.
At least AOL whitelisted you - none of the ISPs around here would do that.

Wazoo posted in my thread on Mar 24 2009, 07:31 AM that he was unable to get senderbase to ever respond to his emails either.

The major difference here is that Spamcop:
a) Post enough information on their website that if you are listed, you know exactly why, and how to get delisted
Have a forum right here with people who can get action

Senderbase has neither of those things. It's not the product that's frustrating, it's the ivory tower "don't talk to us just use our filters" approach that is their problem.

Since both posters have just gotten new IP addresses, it seems to be the sudden upsurge of email that is the cause of the poor reputation - a common sign of a spam run (according to several quotes on the senderbase site). IIRC, someone else had the same problem, but other forum members kind of suspected that the poster really was either a spammer or someone who was clueless about mailing lists.

Obviously, senderbase/Ironport/Cisco does not want to publish FAQ about how to improve one's reputation since spammers would immediately try to get a good reputation and then spam.

The two posters in this topic can feel special since they are 'one in a million' server admins! <g>

Quote from one of the links from senderbase.org: "A key benefit of using Cisco IronPort Hosted Email Security is anti-spam efficacy. Powered by the Cisco SenderBase® Network, which has real-time visibility into the threat landscape, Cisco IronPort Hosted Email Security delivers the industry’s highest spam catch rate (greater than 99 percent) with a less than one in one million false-positive rate."

Seriously, even if the chances are very low, it seems like Cisco IronPort should be interested in what is obviously a problem. Whoever was supposed to get email from the two networks probably aren't happy campers either.

It would seem to me that the solution would be for server admins to be proactive when they switch IP addresses by informing senderbase before they switch to show that they have a good reputation and that whoever they are getting the new IP addresses from also has a good reputation for their netblock. Like the deputies do at spamcop, the 'deputies' at senderbase could manually adjust the reputation for a certain period of time (however long it takes for the new IP address to get a good reputation based on its volume).

I doubt very much whether a spammer could find a way to abuse that system since there would have to be evidence that they were the owners of the old address and the new IP block owners would be alerted to a possible threat to their good reputation by a request from senderbase for verification that so-and-so would be moving their servers to this netblock. In fact, it might be a good thing for everyone concerned as a preventative measure and it could even be published on the website. If a server admin was checking his reputation on a regular basis, s/he would know about it and if s/he wasn't proactive then like the ones who come to spamcop because they were blocked because they were clueless (like the misdirected bounces), there is nothing to do but wait it out until their reputation improves. It also doesn't put an undue strain on senderbase because it is only one in a million instances.

IMHO, if this solution seems to be workable, it would be listened to by senderbase if it came from a server admin with a good reputation.

Miss Betsy

My long term ownership of the IP address in question was discussed already on this thread.

You have to consider what's a fair burden to place on network owners.

Setup a reverse DNS. Setup a forward DNS. Make sure your HELO matches it. Register at abuse.net. Setup a firewall that doesn't allow port 25 outbound except from the server. Deal with users who get grumpy that their POP/SMTP accounts on outside servers suddenly don't work. And no, they don't care that there's a port 587 they can still use.
Stop backscatter. Harder than it should be under Exchange 2007.
Setup SPF records.
Check the IP at any of the multi-dns RBL checks out there. Check yourself against Trusted Score. Check yourself against Barracuda.

Distribute an email use policy. Argue with marketing for days that purchased email lists are not appropriate.

It would be less of an issue if Senderbase published a standard DNS lookup that sites like www.robtex.com could plug into (just add one to the list). But they've made a business decision to go proprietry. Even the Perl Net::Sender module I tried working with (to save dealing with the website) tells you everything on the Senderbase database about an IP - except it's score. This is a well documented business decision to go another route. Instead, you load up this awful website that produces seemingly random results (still flapping between neutral and good, while doing constant refreshes) after sitting through 5-10 minutes of lag, hoping your browser doesn't time out on you. I'd really hate for regular repeating of this process to be added to the lists of tasks for a "responsible mail server admin".

There have been multiple replies from people stating senderbase contact has been a big black hole. I got the impression that at least one of these users were currently having no reputation issues.

When you do get a reply, it's automated, you're not talking to anyone in power, you're talking to a cut + paste guy who clearly doesn't have the authority to act on suggestions, and although I'd love to hear about something placed up the chain, I don't believe it will happen.

I found this some time back. It appears to be restricted to Ironport customers.
Ironport's implied view on these sorts of issues seemed to come down to "it's not our fault if Senderbase if incorrect, it's an independant third party, which we just happen to own".

That is a wonderfully succinct exposition. It should be tattooed (mirror image so they can read it) on many a forehead. Yes, quite a burden and a scandal IMO that SB adds more, like the strike of summer lightning, (rare), devastating, unannounced and unpredictable.

Robtex blacklistings seems to have gone sour at the moment BTW, it seems to me not to be picking up some listings.

OK, it wasn't an IP address change, it was a domain name change. Obviously, that would have to be included in the 'changes' Did that coincide with the reported incident on March 15th? Possibly some recipient didn't recognize the name change and reported an email from your network as spam?

I know that server admins are kind of between a rock and a hard place in trying to get end users to understand how email works. In spite of being a regular here, I still have a very vague idea of how it works.

However, senderbase would be part of what server admins need to check every once in a while. I don't know how server admins get to know things (like the change in allowable bounces), but they seem to know them. After a very short period when spamcop started allowing reporting of misdirected bounces, the only posters here were people that didn't seem to know very much about how to run an email server or didn't need to keep up with any advances in order to satisfy customers or bosses.

I don't expect any email to senderbase would be answered with anything but a cut and paste. However, I don't despair of someone actually reading it for content. And, even if senderbase didn't make any attempt to address this issue publicly, it still might work for other server admins who are going to make a change to notify senderbase before the fact of making a change.

I agree with your frustration about the lack of cooperation from senderbase on how to avoid a poor reputation. But it seems to be a fact of life now. The only approach that seems likely to work is to point out that within a week, two of the 'one in a million' false positives showed up with similar issues.

Miss Betsy

Again, discussed earlier. We changed the name after several days already on the blacklist to see if it would help a delisting. t did not.
I'll note that change is yet to be reflected on the senderbase page.

The domain change was my IPs rDNS domain. There were no changes to actual email addresses at any point.

Before you get too frustrated with me, remember I am an end user!

I was just trying to guess at what the 'report on March 15th' could have possibly been from?

Both of the reputation problems in this topic seem to have been connected with a change which altered the reputation score - for unknown reasons - but probably have to do with the change not being recognized as a change, but a new player with no reputation. However, you do have a 'report' to contend with.

From a consumer point of view, problems like this are solved by either convincing the store/organization/whatever that a new policy is warranted or by finding out how to avoid the problem in the future (often by trial and error without the cooperation of the entity). It is not always easy and sometimes it never works until consumers band together and have a confrontation.

I still think two 'one in a million' makes the 'one in a million' a little suspect so there are probably lots more out there. It might make some ISPs re-think using senderbase as 'the' authority. Just as most ISPs do investigate spamcop reports before shutting down a customer and the scbl is not always used to reject messages since it is so aggressive.

Miss Betsy

Definitely agreed. I did find a number of discussions around the place with similar issues. The major difficulty is someone needs to be fairly skilled to convince people that it's not their problem.

And when you say "I'm running a Netgear modem as my firewall", which realistically, many budgets don't have any opposing choice for, you acknowledge viruses can get through that modem. Whether that's what happened or not, there's doubt there, and it's hard to prove your innocence.

Tried to follow instructions to Register. Roadblock when forced to provide a Customer ID or Serial Number .... so went to the direct Forum Registration link. It appeared to work, but then did a redirect to the IronPort Support Portal Registration again. Apparently, there is linkage between the Forum and the Portal Suppot database. E-mail notification from the attempted Forum Registration has yet to occur, suspect it won't. Waiting for the clock to roll around to Pacific time to give someone a call.

Near as I can make out from the scanty details offered up in all the advertising hype, I'm going to liken the situation much as the 'problem' area of the spamcop.net parsing system when it comes across am unrecognized 'relay' .... the first few parses that see this 'new' relay, the parsing stops and ends up targetting this relay for a Report. Some parses later, this 'new' relay is recognized, and the parse then (usually) correctly then marches on to the more likely real source of the e-mail.

As far as SenderBase, I'm leaning towards the seemingly demonstrated decision process/results of .... new Domain/IP Address, a sudden ramp-up in traffic, bias is set to 'assume' that something bad has happened, the bias being set to match the advertised 'immediate reaction' to the 'assumed' bad traffic. What would seem to be missing in this scenario is the'adjustment' and/or decision that would normally be based on the ratio of 'seen' traffic and 'bad' traffic before making the rating decision .. or rather what seems to be happening, making the initial determination that the involved IP Address is a compromised system then letting time, traffic, and results 'adjust' the rating upwards. (Just noting that this is simply a bit of a guess .... trying to research e-mail reputation seems to keep sliding into web reputation, so many specific details left unsaid (other than the hype)

The marketplace definitely edges out the small guy - which is in direct opposition to the concept of the great World Wide Web.

I would like to help you but in another topic it has been demonstrated, it really takes someone who can 'talk the talk' and give them something to work with to get their attention. IMHO, the only solution is 'co-operatives' or associations, but when I researched it several years ago, the personality type of the server admin does not mesh well with that type of scenario. Server admins like, 'my server, my rules' and 'like or leave it' which doesn't compete well with bottom line capitalists - except in old western movies.

Miss Betsy

Talked for a bit with Abagail, who has opened up a ticket in reference to a possible waiver to the non-customer access to the IronPort Support Portal/Forum. Perhaps an answer tomorrow, certainly by Monday she says. We both agreed that my "volunteer status" may be an issue. She is a customer support contact for IronPort hardware, but admits to not being intimate with the details of either SpamCop or SenderBase. All I can do for now.

Good work, let's hope. Not as if you would be trying to 'bell the cat', and they can't ignore 'minor' effects (they're not so minor for those they affect - bad ethics, and it actually is dangerously deluded - "group think" - to allow self-congratulation to blind one to potential problems - bad business).

IronPort-SB should be jumping all over the chance to find out what is happening at the fringes of reliability. Scientists and engineers would all agree - that's where the interesting stuff happens. Like others, I'm not so sure about their fringe being 0.01%. That may be so for false negatives (and my own experience would strongly support that) but information on false positives is harder to get/estimate and, unlike false negatives, false positives even in low proportions are harmful, potentially extremely harmful.

Not sure if I'm getting this across with sufficient clarity but heck, if you build a thousand bridges and one of them falls down there is no way you can write it off as 'bad luck', 'within statistical expectation' etc. You have to find out *why* and incorporate that knowledge into prudent rectification if indicated.

OTOH, engineers build bridges for 30 year, 50 year, 100 year floods.

I am all for IP addresses getting blocked, even if they have legitimate customers, if there is a real problem. End users need to be as responsible about their connectivity as server admins and have a stronger say in correcting problems than outsiders.

It would be nice to have a list (the way that there is for mailing list managers) of the things, server admins need to do to be 'good' netizens - from closing relays to registering an abuse address. Some of them may be part of how a blocklist determines whether to list an IP address or not, but it doesn't compromise the parts which have to be kept private. It always helps in convincing someone to right a wrong to know a lot of details. A non-profit lobbyist told me a story about State Representative 'Lobby Day' - the lobbyists who went there with a passion and tried to persuade opposing Representatives to vote for legislation in support of their issue got nowhere. The Representatives would wait until they took a breath and ask them about Section 4, item 3. When the lobbyist couldn't answer, end of conversation. The savvy lobbyists cornered sympathetic Representatives and pointed to Section 4, item 3 and told them how it would work better if phrased differently. If a Netgear Modem is a known problem, but one admits it up front with all the measures one has taken to prevent viruses, one has better chance to convince another server admin that one is not a spammer, but falls in the fringes.

OTOH, there are always going to be glitches - from power outages to poor reputations because of being on the fringes. Some may have solutions - proactive planning about changes might work; others like power outages just have to be endured.

Miss Betsy

Yes, but I am talking about failure inside the design parameters.Yes, but how is that applicable here? I compared it to summer lightning ...The O/P's 'exposition' covers most of it succinctly and yes, it would be good if he could be credited with doing 'all the right things' and, at the end of the day, neither he nor his network has been shown to do anything 'wrong'. The single 'indictment' mentioned is very debatable, as I suggested earlier.All true but the problem is in getting a hearing at SB in the first place. Your exemplified 'Representatives' have shown no interest in either fact or fallacy.There are *always* solutions, expediency (or simple incomprehension) may dictate against their adoption. I have tried to argue it is shortsighted (and squandering opportunity) to ignore things on the fringes. I have supposed anyway that 'the fringe' might not be as well defined as might be thought.

Stone the crows Miss Betsy, fair crack of the whip