What is SBL62478?

This got bounced back, and it happens every time I email this person


SMTP error from remote mail server after RCPT
TO:<>:
host os-srvr-proxy01.kabeltex.nl [82.151.32.101]:
554 5.7.1 <[my address]>: Sender address rejected:
SBL62478

When I google on SBL62478 I get this as the #1 hit

http://www.spamhaus.org/sbl/query/SBL62478

and it says

Could it be a fake bounce, allowing the person to receive emails with
the sender thinking they are not getting through?

 

Any offers on this one?

 

Any reason you couldn't google SBL?

Your mail was rejected by the recipient mail server because the sending
IP address was in the Spamhaus block list due to your ISP having
previously ignored reports of abuse (spam) emanating from its network.

You need to take this up with your ISP:

so you're in Holland, but posting to a UK group expecting help?

Whinge at your ISP Kabeltex, they're the problem.

 

I did and it said there was no entry for that SBL.

This has happened before with that particular recipient. To me it
looked like the block has expired by the time I checked it, but that
seems wrong.

MY ISP is actually ZEN UK

So you think ZEN have been hosting a spammer?

I am in the UK.

 

I haven't had any problem sending, from a Zen account.
I suspect the particular block of IP addresses you are on may have
been blocked, perhaps due to a subscriber within that block of IPs
having a computer which has become infected with something which a
spammer is using to send.
The fault is only with the user in that they didn't secure their
computer properly.
It may also be that the receiving server is using stale cached SBL
data, if it seems to be a regular problem with just that addressee.

 

That implies the recipient's mail server doesn't like something about
either your sender address or the IP of the mail server that's relaying it.

I'm not surprised. The SBL list will only typically contain IP
addresses/ranges, not references like that contained in the rejection
message.

Doubt it. I'd guess at:

- The outbound server you're using to send email has wound up on the PBL
list (whose server are you using?).

- You're running your own SMTP server, and your WAN IP is either from a
dynamic pool or has suffered the same fate as above (either at the
negligence of yourself or a previous owner).

- The recipient mail server is interrogating all IP's in the received
mail headers, including your WAN IP (which if you're not relaying mail
directly is not a very clever thing for them to be doing).

 

N/A but I agree; used to do this years ago and the IP gets blocked all
the time because ISPs' dynamic IP blocks are known - even if my IP is
a "fixed" IP. I think most ISPs' "fixed" IPs actually come from a
dynamic IP block but they config their DHCP server to always dish out
the same IP.

 

Well, using what I believe to be Zen's SPF records, I can tell you that
none of the listed IP's are on Spamhaus' SBL:

 

En el artículo <>,

They're not now, but they were at the time the OP tried to send his
mail.

 

Is there a simple procedure I can use next time to track this sort of
thing down?

Any tips much appreciated.

This happened during a mailshot I was doing to about 1000 people (a
forum I run) which was mailed at a rate of one email every minute, to
minimise the chances of it being labelled as spam (I know most ISPs
now do profiling/signaturing across the incoming emails).

We tried a commercial mailing service but apart from other issues,
gmail dropped maybe 1/3 of it.

This 60-second delay works pretty well. A 10-sec delay works much less
well. I need to avoid including URLs or image attachments, as that is
dodgy (especially with gmail). And the sender domain (the bit to the
right of the @) has the SPF set up hopefully correctly to correspond
with ZEN's SMTP server.

But this one guy generated exactly the same bounce error on two
mailings about a month apart, which I thought was very odd.

 

If you know the IP's of the servers you're relaying through (which if
you're using SPF you will), then most online RBL checks will identify
issues with Spamhaus' lists in advance of a send:

http://www.anti-abuse.org/multi-rbl-check/