SMTP Blocked By SORBS?

[rufus]

OK, so I just tried to send an email out from my Jaguar account, and it was bounced as a blacklisted spam server. The message (on SORBS DB) returned is:

--
Address: 69.73.149.27
Record Created: Thu Oct 21 05:14:36 2004 GMT
Record Updated: Thu Oct 21 05:14:36 2004 GMT
Additional Information: Received: from dragon.nocdirect.com (dragon.nocdirect.com [69.73.149.27]) by stealth.sorbs.net (Postfix) with ESMTP id 8E1A8DF98E for <[email]>; Thu[email] 21 Oct 2004 14:53:04 +1000 (EST)
Currently active and flagged to be published in DNS

--

Anybody else finding themselves blacklisted like this? Is Jaguar spam central? Tune in to find out! And yes, I will be opening a support ticket about this...

Regards,
-Toby

[Connie]

This is an off and on problem. JPC does not harbor spammers. Ocassionally one slips in. The staff at JPC works very quickly to resolve these issues once they become aware of them. These Spam list block every one who is in a block of IP adresses. If you as an innocent person happens to be in a block of IP adresses that a spammer has sent from you are blacklisted too.

This problem is not a JPC problem. It could happen with any host on the web.

[Ron]

It's not even necessarily a question of harboring SPAMmers. Your machine can get listed because you bounce an email back to a SORBS honeypot. It will last only a couple of days (which is bad enough) -- unless you keep bouncing to the same addy. Lately I've seen lots of spam hitting me with the same return addies, that's not a good development if we're bounding spams back to the sender.

Seems like JAG and/or CPanel has figured out how to get :fail: and :discard: working in forwarders as intended... :fail: bounces the email, :discard: drops it on the floor. At least that's what my testing this morning indicates.

[Ron]

Seems like JAG and/or CPanel has figured out how to get :fail: and :discard: working in forwarders as intended... :fail: bounces the email, :discard: drops it on the floor. At least that's what my testing this morning indicates.

I spoke too soon; I just got a bounce back from a :discard: account; it's been retrying delivery.

The darn system ought to silently drop :discard:s on the floor not refuse the connection or whatever else it is doing to cause the sending system to keep retrying.

I know Masood has argued that by accepting the mail and delivering it into a bit-bucket it is a waste of CPU, disk writes and bandwidth. That argument didn't hold water then as CPU and disk requirements were minimal, and certainly doesn't hold true now as I find that systems are retrying based on whatever error code is being returned.

What's so hard about obeying the site owner's wishes and discarding mails that are set to :discard:??? We already have a :fail: option!!!