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
