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.
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.
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. 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
