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

Mailman List Mirror (Read Only)
1

Bellsouth basically told me they were blocking Pair Networks because
the percentage of spam vs non-spam is around 75 - 80%. They say
they are communicating with them on this. Supposedly there was a
conference telephone call this past Thursday 09-22-2005. BS says
they must reduce this spam amount for the block to be removed.

Pair seems to think it is mostly domain customers forwarding their
mailboxes to their BS dot Net email accounts.

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.

I imagine that at some time in the future, forwarding e-mail might become
impractical, if receiving systems insist on parsing it as originated or
relayed Spam.

This the first I've heard of BS having a 50/5 threshold limit.

Bellsouth has given us no statistics, no logs, no headers, not even a
timeframe for their vague claims. We can clearly see from our side that we
are not generating nor relaying Spam. But our customers can no longer
choose to forward their e-mail to Bellsouth. It seems that Bellsouth is
restricting its customers.

Kevin

2

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.

At my $employer I have similar problems with AOL. We occasionally get blocked because of bone-headed AOL users thinking that report spam is the same as delete, or thinking that report spam on forwarded mail is helpful, when it's not. It happens atleast once a month that one or more, or all of our outbound MXers get blocked over at AOL with 4xx or 5xx errors that result in me having to call postmaster to get them to remove it. Also just one hacked webform usually results in the same problem (we have thousands of web hosting customers). It's in our projects list to find 'some way' to rate limit individual senders but it's not a high priority right now.

I imagine that at some time in the future, forwarding e-mail might become
impractical, if receiving systems insist on parsing it as originated or
relayed Spam.

I've certainly brought up the idea of not allowing offsite forwarding to AOL. We already implemented no offsite catch-alls and I'd like to have removed any possibility of doing catch-alls but management veto-ed me on that one because of the high amount of customer complaints we'd get.

Sometimes, the 'cure' is definitely worse than the 'disease.'

3

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)

4

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.

I imagine that at some time in the future, forwarding e-mail might become
impractical, if receiving systems insist on parsing it as originated or
relayed Spam.

No, what will happen more and more is that parties who forward email will have to make a "best effort" to ensure that it is not spam.

Meaning a policy "unfiltered email does not get fowarded to external parties"

Its pretty simple. Its garbage and its coming from you. Block.

Happens to be it is not trivial (currently probably rarely possible) to guarantee that email is forwarded, rather than simply originated with forged headers.

Hopefully this will generate/increase a positive network effect for aggressive spam filtering, from blocklists, graylists, content filtering and so on.

Unfortunately the network effect is likely not to be a pleasant experience for many providers, as you have recently found out.

Customers may be entitled to request complete unfiltered access of their email account to the world, but they are not entitled in this day and age to expect that to carry over into a privelege for provider A to dump crap into provider B without a prior arrangement/understanding between provider A and B.

This the first I've heard of BS having a 50/5 threshold limit.

Bellsouth has given us no statistics, no logs, no headers, not even a
timeframe for their vague claims. We can clearly see from our side that we
are not generating nor relaying Spam. But our customers can no longer
choose to forward their e-mail to Bellsouth. It seems that Bellsouth is
restricting its customers.

Kevin

This is a problem. Headers would go a long way to disabling the forwarding instances and/or mandating strict filtering for those customers.

That being said, assuming you have told bellsouth you were working on eliminating raw forwarding they should have worked immediately to lift the block and give you the benefit of the doubt.

In the absence of retained technical evidence, a "easy out" blocklist and an "easy in" whitelist should be the norm.

Joe

5

One hacked webform can pump out as much spam in a few hours as the
rest of your users would send email to AOL in a week.

-srs

6

I realise this, but that's usually not the case. Almost without fail we notice and shut it down long before aol starts blocking, and clear out the queues of anything pending from the spammer. then hours or a day later AOL blocks us for something that's been dealt with. :confused:

7

AOL's (and our) feedback loops do help in that situation

srs

8

I implemented rate limiting for Exim to address this problem. The feature
is available in version 4.52 and later.
ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/ChangeLogs/NewStuff-4.52

We have a few thousand users who forward email off-site, and it gets the
same anti-spam filtering as locally-delivered email. This seems to be
sufficient to avoid trouble with AOL etc.

Tony.