[84801] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: 209.68.1.140 (209.68.1.0 /24) blocked by bellsouth.net for SMTP

daemon@ATHENA.MIT.EDU (Suresh Ramasubramanian)
Sun Sep 25 22:22:55 2005

Date: Sun, 25 Sep 2005 10:54:06 +0530
From: Suresh Ramasubramanian <ops.lists@gmail.com>
Reply-To: Suresh Ramasubramanian <ops.lists@gmail.com>
To: "sigma@smx.pair.com" <sigma@smx.pair.com>
Cc: nanog@nanog.org
In-Reply-To: <20050925022024.28928.qmail@smx.pair.com>
Errors-To: owner-nanog@merit.edu


On 25/09/05, sigma@smx.pair.com <sigma@smx.pair.com> wrote:
> Yes, this is quite clearly the case; there are dozens of mutual customers
> who have forwarding rules setup.  We are not generating Spam to send to
> Bellsouth; it's coming from somewhere else and then being forwarded.

Kevin

When we face this situation with a site that has lots of forwarding
users pointing their accounts to mailbox on our service, what we
generally suggest is that you route email for forwarding users out
through a dedicated server, and let us know its a forwarder

So we dont count numbers from that IP in our filtering metrics, or at
least take into account that its a forwarder.  We also have feedback
loops setup so that if you get a loop from us you can stomp on either
spam origination (like a compromised script on a pair webserver) or
forwarded spam [whatever's leaking past your filters in large amounts
- you can catch that and block it at your end].  note:  If you know
its spam, if you detect it as spam (for example using spamassassin)
dont tag it and forward it on - 550 it, as a hard and fast rule.

[same case with aol i believe - not speaking for aol here]

I would suggest you do it that way - at least suggest this to bellsouth.

--srs (postmaster@outblaze.com)

--
Suresh Ramasubramanian (ops.lists@gmail.com)

home help back first fref pref prev next nref lref last post