You argue about the fficiency of blicking network flow like we do But beyond argue they are simples facts:
Before I introduce port 25 blocking I had more than 200 feedback loop complaints daily from differents MSP (Yahoo, AOL, abusix and others). Since blocking is enabled it I have have less than 50. Half of which are from user that are not blocked already, and 30 others percents are from my users who don't know to manage subscription list (let's say my very own spammers). I know it doesn't mean I do not spam at all right now.... But what I know it means is that now I have much more control on what's going out of my network. Scanning outgoing mails throug ANY content scanning is dangerous because of FP (except viral analysis maybe which produce very few FP). Further more if you compare the amount of ressources spent with the amount of spams stopped, networks ACL are much more efficicent than ANY spam filter configured to avoid FP! Anyway, everyone here knows you can't fight spam with one single weapon (there's no Hiroshima in this war). You need to protect your people, and SA is good at it but you also need to make sure you're not yourself part of the dark side... If everyone cares, we get a cleaner network. Le mardi 20 juillet 2010 à 10:52 -0700, Ted Mittelstaedt a écrit : > > On 7/19/2010 3:55 PM, Brian Godette wrote: > > On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote: > >> > >> > >> On 7/19/2010 12:56 PM, Brian Godette wrote: > >>> On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: > >>>> > >>>> > >>>> On 7/19/2010 8:43 AM, Brian Godette wrote: > >>>>> On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> Few months ago I asked this list if using SA on outgoing smtp was a > >>>>>> good idea (Thread: SA on outgoing SMTP). > >>>>>> This thread quickly moved to "Block direct port 25 for non-mta users! > >>>>>> I was really afraid of doing so and didn't really wanted to go this > >>>>>> way. > >>>>>> now about 6 months later I have to say: I was a fool! Today. > >>>>>> After spending some time trying to find a more user-friendly way to > >>>>>> clean up the mess around here, I came to the conclusion that port 25 > >>>>>> blocking on the bound of my network was inevitable. > >>>>>> Today it's done, and I have followed few others advices given on > >>>>>> list. > >>>>>> I wanted to testify the benfits of good designed network for thoose > >>>>>> who like me are afrais of annying customer with security (even more > >>>>>> blocking port 25 on the limits of the network is not really annoying > >>>>>> for most of customers). > >>>>>> > >>>>>> Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your > >>>>>> help dudes, all I have to care about now is my mailservers > >>>>>> configuration! > >>>>>> > >>>>>> -- > >>>>>> Alexandre Chapellon <alexandre.chapel...@mana.pf > >>>>>> <mailto:alexandre.chapel...@mana.pf>> > >>>>>> Mana SAS > >>>>>> > >>>>> > >>>>> I hope you realize you still need to deal with the issues of users > >>>>> with > >>>>> weak/guessable passwords and phishing of account info as well as the > >>>>> newer bots that recover account info from Outlook/Outlook > >>>>> Express/Thunderbird. > >>>>> > >>>>> Blocking outbound 25 from the rest of your network, and disallowing > >>>>> submission to your MX on 25 from your network, does very little for > >>>>> keeping your own MX from sending spam which is what SA on outgoing > >>>>> SMTP > >>>>> would be for. It's great from a policy standpoint and contains the > >>>>> "simple" bots, but for keeping your outbound from MX clean, not so > >>>>> much. > >>>>> > >>>> > >>>> That absolutely isn't true. Yes I agree that it's possible for a > >>>> spammer to write a virus that uses the submission port and > >>>> authenticated SMTP to send mail and runs on a user's PC. But if your > >>>> running even a simple log analysis script on your mailserver and you > >>>> READ the daily reports from it, then a user that sends many tens to > >>>> hundreds of thousands of e-mails will stick out like a sore thumb. > >>>> > >>>> We have NEVER had a spammer do this to one of our users. I don't know > >>>> why because it seems to me like it's an obvious way to relay spam. What > >>>> we HAVE had happen is spammers guess weak passwords and relay spam > >>>> through the webmail interface. My guess is that it's just a lot > >>>> easier to do this for them. Of course, when they do that their outgoing > >>>> spam is stamped with the username that was used to relay, and it's > >>>> very easy to detect and change the password. > >>>> > >>>> So far, all the spam viruses we have encountered on user systems are > >>>> of the variety where they infect the client and attempt to relay to > >>>> port 25. > >>>> > >>>> Ted > >>>> > >>> So basically you're agreeing with what I said. It stops the simple bots, > >>> but the other stuff, not so much. > >>> > >> > >> No, you said it "does very little" and I said it only "does very little" > >> in THEORY, but in actual practice (right now) it does a tremendous > >> amount. > > > > In actual practice it does very little for YOUR OWN MX, the simple bots > > simply do not target internal mail servers, they send direct. Which is > > why I said it's good from a policy standpoint but does nothing to > > actually prevent YOUR OWN MX from ending up on an RBL because all the > > bots that can do that don't care that you've got outbound 25 from your > > internal network blocked. > > > > Last I checked RBL's worked off IP addresses not MX's. If joe schmoe > on some other network has a bot that's sending with my MX forged then > I'm not going to end up in an RBL. If I have a customer with a bot on > it then that bot isn't going to be able to send since I block outbound > port 25 and virtually all bots only send via 25, not the submission > port (using auth) except for a few that will attack via a webmail > interface. > > >> > >> I won't rule out that the spammers won't become smarter but right now > >> they are stupid. I guess there's just too many wide-open servers still > >> out there for them to bother trying to get around one that's been > >> tightened down. > >> > >>> I've seen bots use smtp-auth from inside, whether it's by injecting into > >>> O/OE or recovered auth I can't say. I've seen bots use webmail as you > >>> have, I've also seen them use smtp-auth vs submission/ssl (587/495). But > >>> again, that's only after they've either guessed or phished the account > >>> info. In either case you're still left with having to scan outbound from > >>> your own MX, and/or rate limit, or accept being RBL'd for short periods > >>> of time being reactive to log analysis and spam reports. > >> > >> If you keep on top of the logs then you won't generally be RBLed. And > >> you can run a monitoring program like Big Sister and with a bit of > >> scripting you can be notifed when your server starts spamming. > >> Out-of-the-box the SMTP monitor in Big Sister will alarm if the > >> mailserver starts slowing down - which is customary when a spammer > >> commences a large spam run. But you can also write a script that runs > >> once an hour > >> and monitors your mailflow and alarms if it jumps. If your graphing > >> your mailflow then spam runs will create spikes that are very obvious. > > > > At which point it's already too late. > > > > Wrong. Reread my post. > > >> > >> It's been our experience that spam-scanning outbound mail causes a lot > >> more problems than setting up mailserver monitoring and being responsive > >> to it. Sooner or later one of your customers is going to call you and > >> bitch because their mail ended up in their coorespondents spam folder > >> due to them using HTML or including a bad URL and if it was your server > >> that tagged it spam, your going to be in a heap of trouble. But if it's > >> your customer's recipient's mailserver then that admin will be in the > >> hotseat. Sometimes even the spamassassin header addition, even if the > >> outbound mail ISN'T marked as spam, will trigger a spamfilter. There > >> are a LOT of very ignorantly-put-together content scanning spamfilters > >> out there. > >> > >> I've had lots of experience with the RBLs and I think that most people > >> simply don't understand just how much spam you have to send to earn a > >> spot on an RBL. Sending a few thousand pieces of spam won't do it. It > >> takes tens to hundreds of thousands of pieces for many hours to get RBLed > > > > Actually a few hundred will do it, at least for spamcop, PSBL, yahoo, > > comcast, roadrunner. > > once more, wrong. You can spout all you want but I can see the evidence > in my server logs. And in any case how is the bot going to relay in > the first place under a port 25 block unless it infects a machine and > snatches a password, in which case that customers' system is infected > and I'm going to change their password the moment I notice what's going > on and tell them to clean their system. > > What separates the men from the boys in this business is the men > have effective early warning systems, the children do not. And as I > said, there isn't any excuse for this as there's plenty of freely > available open source examples already out there on how to create > warning systems. > > The fact is that filtering outbound mail with SA > isn't going to block all outbound spam relayed through your mailserver > anyway. SA isn't 100% effective, no computerized scanning solution is, > and anyone who tells you different is selling snake oil. The only > real solutions that approach that are ones that insert a human into > the loop, and most people are not wealthy enough to pay a secretary > to read their e-mail for them. If RBL's worked the way you said then > outbound mail filtering with SA wouldn't prevent them from being triggered. > > To make any content filter really effective you have to accept a small > percentage of FP's. That's OK for end users on an individual mailbox > because they make the decision to ratchet up sensitivity of the content > filter, and accept a few FP's in exchange for the time saved by having > the computer put the spam in a folder. But as an admin of a shared > mailserver that has many people sending outbound mail through it you > cannot do that. None of your users made that tradeoff and is willing to > accept that -any- of the legitimate mail they send gets deleted as > a FP. They have no choice but to accept it if one of their recipients > filters FP's their mail, but they won't accept it if your SA install > FP's one of their mails. And there is no foolproof way to make SA > always exempt their legitimate outbound mail. > > We have an admin here who thinks like you. At least 2-3 times a week I > have to forward customer support mail requests to him that his > spamfilter has put into his spamfolder. Meanwhile he's blithely > oblivious that his hypersensitive spamfilter solution (that he > thinks is 100% effective) isn't working, and is convinced that it works > because someone else is picking up after his messes. He does good > work otherwise so I haven't pushed the issue with him, but I don't > let him work on the server-based filters because like you, he does > not really grasp the idea behind statistical analysis and content > filtering. > > Ted > > > It takes tens to hundreds and being unresponsive to > > end up on something like spamhaus. > > > >> and if that kind of a spam run isn't setting off the alarms in > >> your monitoring system, then all I can say is your monitoring system > >> sucks rocks. > >> > >> Ted > >> > > -- Alexandre Chapellon <alexandre.chapel...@mana.pf> Mana SAS
