I don't like to publicly shame[0] companies or services but today I have
found a need too. There is an anti-spam company called Spam Rats[1].
They provide an RBL service and today is the first time I've seen them.
So thank god they seem to not be used much.
I'm emailing this list to advise of their listing pratices. They have
listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of
PTRs in the /24 range. This is for co-lo customers. The range has a
netural score on senderbase.
This is the first RBL I have seen list a /24 for lack of PTRs. Not for
sending spam, but just PTRs alone. How do you explain this to your
customer?
Their removal process is also a joke. As we are "mass-listed" the normal
removal process does not apply. I've used their contact form but doubt
I'll get a response.
Please make 2013 the year you migrate away from Spam Rats if you choose
to use this service[2].
Who uses it? Or did you see your IP listed in one of those multiple dnsbl
query sites and contacted them on general principles even though you didn't
see any actual bounced email that could be traced to a spam rats listing?
That said, it is best practice to set ptr records even for your unassigned
ip space
Who uses it? Or did you see your IP listed in one of those multiple dnsbl
query sites and contacted them on general principles even though you didn't
see any actual bounced email that could be traced to a spam rats listing?
Customers use the range. They had a complaint to us that the IP was
listed by spamrats and thus the issue made it to my queue.
That said, it is best practice to set ptr records even for your unassigned
ip space
Mail servers do need to have PTRs, but it is my _choice_ if my hosts
that do not send mail have PTRs or not. I would not expect anyone to
block my /24 for lack of PTRs on non-mail-sending hosts.
We had issues and similar behavior from SORBS.net and TrendMicro ERS but
have never dealt with Spam Rats. It was our second direct allocation
from ARIN last year that was apart of a larger block that got split up.
Our block was listed in their DUL. It was a pain to remove. They wanted
our PTR records to say "static" and provide a longer TTL. Others on this
list have shared similar stories. This is crazy but it's their service
and seem to be a common practice amongst some RBLs.
I hope you get your issue fixed.
FYI - I have a PTR for all IPs. Just general practice.
Ask your customers what I asked you. Are they actually seeing email blocked
and bounced because of that spam rats listing.
Also it is your choice whether or not to follow best practices, it is spam
rats choice to block mail based on whatever they like, and it is the choice
of some random email Admin or the other to block mail based on spam rats..
Which is something I wouldn't recommend to people running a production mail
system, but we'll..
We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well.
I tried SpamRats a few years ago, but found them to have too many false positives. Then, they were trying to be early detectors of spam orginiating from static IP cable/DSL customers. Good idea, but poorly executed in operation.
Customers use the range. They had a complaint to us that the IP was
listed by spamrats and thus the issue made it to my queue.
That frequently just means they've subscribed to one of the monitoring services that notifies you if your IPs have turned up on any DNSBL the monitoring service has ever heard of, sometimes including ones that have been shut down, domain snatched up by speculators, and wildcard A record installed pointing at an ads landing page.
Mail servers do need to have PTRs, but it is my _choice_ if my hosts
that do not send mail have PTRs or not. I would not expect anyone to
block my /24 for lack of PTRs on non-mail-sending hosts.
If they're not mail servers, how is the DNSBL listing impacting them (assuming anyone even uses spamrats)?
Third, anyone may run any DNSBL with any policy they wish: listing
IP addresses whose octets are primes, domains with the letter "j"
in their names, etc. Provide they comply with RFC 6471, this isn't
a problem. What *might* be a problem is how they're used and by whom,
but one of the nice features of DNSLs in operational practice is that
those with suboptimal listing policies aren't used much.
Fourth, one of the hundreds of DNSBLs may be the least of your problems.
For roughly a decade now, it's been a very good idea to refuse/defer
all mail traffic from anything which doesn't have matching PTR and
A records. (The refuse/defer depends on whether the problem appears
to be a permanent misconfiguration or the temporary consequence of
a DNS oops.)
Personal experience is that I have had a large telco, which I won't name
since they immediately unblocked, blocked exactly such a range once, for
the exact same reason. RFCs and best practices often aren't a 100 % exact
match so sorry, I can't dig up a cite.
All IPs actually in use, or all possible IPs in a network? If the
latter, then it's not gunna fly for IPv6. Not at all. Not unless you
synthesise the responses - in which case there is no point to requiring
them anyway.
$GENERATE, as someone else pointed out, solves that problem for you?
(Does it scale for IPv6? I can't recall - but surely this could be
scripted too.)
I though the point of doing so was to establish with some degree of
accuracy that there were 'real people' behind the administration of said
IP, and that there was a somewhat increased level of accountability as a
result - which suggests there is infact a point.
>> FYI - I have a PTR for all IPs. Just general practice.
> All IPs actually in use, or all possible IPs in a network? If the
> latter, then it's not gunna fly for IPv6. Not at all. Not unless you
> synthesise the responses - in which case there is no point to requiring
> them anyway.
>
> Regards, K.
$GENERATE, as someone else pointed out, solves that problem for you?
(Does it scale for IPv6? I can't recall - but surely this could be
scripted too.)
No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you
had machines that supported zettabytes of data the zone would never
load in human lifetimes.
Any moron can run a DNSBL. Many morons do. But that doesn't mean
that anyone actually uses them.
They are yes. Emails are being blocked due to the listing on spamrats.
Please show us a copy of one of the failure messages. Feel free to
redact any private information, but please leave the IP addresses and
reject messages visible.
R's,
John
PS: In my experience, customers who think that their mail is being
rejected due to a DNSBL we never heard of are almost always mistaken.
A message bounces due to some random reason, they look up their IP on
one of those bazillion DNSBL lookup pages, find some obscure DNSBL
that lists them, and leap to the conclusion that's the problem.
