cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3319
Views
0
Helpful
20
Replies

Outgoing Spam on ISP Network

Vinesh_ironport
Level 1
Level 1

Hello,

I manage an ISP network with several C-Series appliances and as you might be aware, there are much infected hosts on ISP networks and therefore they send out spam.

This results in getting the outgoing IronPort IPs blacklisted.

I'm having some difficult blocking these spam/virus because if i turn antispam ON for outgoing mails, about 2/3 of outgoing mails are false positives. I don't know why IPAS classify these mails as spam.
I did put some rate-limiting,but this doesn't always help.

Does anyone of you have any recommendations on how i can minimize this problem?

Thanks,
Vinesh

20 Replies 20

meyd45_ironport
Level 1
Level 1

As seveneyes says, you need to turn off fetching SBRS on the listener.

In my experience SBRS less than -3 could cause a perfectly legitimate message to be marked spam +ve.

There is a bug/FR to be able to tell IPAS not to use SBRS even if it is available.

Vinesh_ironport
Level 1
Level 1

Thanks to all,

I should be getting a C350 for this client by next week and i shall configure an outbound listener and disable the senderbase profiling and see how it works.

I'll keep you updated on the outcome.

Rgds,
Vinesh

recipient control

Did you check this feature. This limits recipient per hour by your customer end's IP.

This isn't exactly a perfect solution, but I think this is better than no control.

We do block our subscriber's port25 and it did not solve the problem.
The real thing should be SMTP AUTH.

Btw, currently we fall back to sendmail for rate/connection control.

I bought up this thread a while ago, but seems ironport did not really consider to put similar measure into the AsynOS.

https://www.ironportnation.com/forums/viewtopic.php?t=375&start=0&postdays=0&postorder=asc&highlight=

Well, I'd hate to be a partypooper but I wouldnt say smtp auth solves the entire problem.

We do port25 blocking for our customers so they have to use the a pair of
ironport x1000 configured with rate limiting and spamfiltering as outbound servers,
and eventhough this makes it easier to find the bad customers it doesnt stop misconfigured
mailservers that the customers have.

Say that a customer has a mailserver (misconfigured as an open relay)at home and
it relays through us using smtp auth. Without rate limiting we would get flooded with spam
from the customer in question. We usually find a few of those every month...

The last few weeks I've also been pestered with mail coming from networks outside
of our own customer networks using hacked mailaccounts using smtp auth to send spam
through our machines. So it would seem that the spammers have moved on as well...

But I'd have to agree that smtp auth slows down quite a few zombie machines :)

bfayne_ironport
Level 1
Level 1

Hello,

We do have these mails going through a relayed policy and we turned Senderbase control to OFF.
We even configured a relaylist for corporate and another for all others(where we applied more strict rules.
I'll definitely contact support so that they look into it.




Make sure that you disabled Senderbase in the listener. Just turning it off in a Sender Group is not enough.

In the GUI, select Network/Listeners/Advanced and look for this option "Use SenderBase IP Profiling".

If you uncheck that box, Senderbase will not even be queried. Otherwise the ESA will always query SBRS and give that info to IPAS.

That solved a major false positive issue for me.

Vinesh_ironport
Level 1
Level 1

Hello,

I did get a C350 and routed only outgoing mails for the entire ISP network on it with the SenderBase IP Profiling turned OFF on the listener and i noticed that it effectively reduced the number of false positives.

I should note that we do have some false positives and i'm still trying to find the correct IPAS threshold. But i have to admit that it's much better than previously and we are catching quite a lot of outgoing spam per day(coming from ADSL IPs and even corporate networks !! )

Thanks,
Vinesh