Senderbase listing, trying to make sense of it

[technion]

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.

[Farelf]

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.

[technion]

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.

[Wazoo]

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??)

It's now nine days we've been unable to get email to Ironport users. ........... 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.

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.

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.

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

The third is just about improving our ham/spam ratio. We've had this IP without incident for years.

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 .. ????

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.

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.

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.

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.

I've contacted the ISP in question, their view on the matter (which affects at least half a dozen domains we are sending to)

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

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.

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.

[technion]

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 .. ????

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.

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.

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".

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.

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

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.

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.

[Wazoo]

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.

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.

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).

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

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

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 ...????

[turetzsr]

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

<snip>

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

<snip>

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.

<snip>

[Wazoo]

...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 ????

[technion]

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>

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

Fetching http://cocaus.org/https://webmail.livingcare.org.au/ ...

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

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

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

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

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

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.

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

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.

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

Perhaps off-topic, but ...????

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

[Wazoo]

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 ...???

[Telarin]

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.

[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 ????

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.

[technion]

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.

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.

[technion]

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.

[Farelf]

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?

[Wazoo]

I'm seeing "neutral" - with the rider "no email was detected from 61.14.118.0/24".

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 ...????

[technion]

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".

[Farelf]

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.

[technion]

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 [at]ns3.brennanit.net.au

smtp.cocaus.org.

[root[at]ceilingcat ~]# dig +short -x 61.14.113.190 [at]ns2.brennanit.net.au

smtp.cocaus.org.

[root[at]ceilingcat ~]# dig +short -x 61.14.113.190 [at]ns1.brennanit.net.au

smtp.cocaus.org.

[Farelf]

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:...

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).

[technion]

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".

[Farelf]

...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.

[technion]

Alternatively, SenderBase surliness remains inexplicable - unless SB cares to break with tradition and explicate.

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.

[Farelf]

...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.

[technion]

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.