Sorry it was not directly for you, but more like a general post. Le mardi 20 juillet 2010 à 12:01 -0700, Ted Mittelstaedt a écrit :
> You are mistaken. I'm a proponent of port 25 blocks. What I > am saying is that port 25 blocks work far better than attempting to > spamfilter outbound mail. It is the other guy who is arguing that > spamfiltering outbound mail is better than port 25 blocks. > > Ted > > On 7/20/2010 11:46 AM, Alexandre Chapellon wrote: > > 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
