thanks to thinking people.

[Alexandre Chapellon <al...@mana.pf>]

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 <al...@mana.pf>
Mana SAS

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

Great!

1 down, 19,587,294,872,875 more admins to go!   ;-)

Ted

On 7/15/2010 5: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!
>

Re: thanks to thinking people.

[Toni Mueller <su...@oeko.net>]

Hi,

On Mon, 19.07.2010 at 09:43:20 -0600, Brian Godette <bg...@idcomm.com> wrote:
> 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.

this is true, BUT

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

this measure makes it much easier to track down the spammers in your
userbase, because the sent emails usually contain a header like
"X-Authenticated: joe-sixpack-with-his-can-of-worms".

Then you only have to verify that the spam report is legit, and then
can simply block this user's account until they have cleaned their PC.

Running SA on outbound is still a necessity, though.


Kind regards,
--Toni++

Re: thanks to thinking people.

[Alexandre Chapellon <al...@mana.pf>]

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.chapellon@mana.pf
> >>>>>>>> <ma...@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 <al...@mana.pf>
Mana SAS

Re: thanks to thinking people.

[Brian Godette <bg...@idcomm.com>]

  On 7/20/2010 1:01 PM, Ted Mittelstaedt wrote:
>
> 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
>
  You need to actually read what I'm writing instead of skimming. The 
subjects being discussed are outbound mail from your own MTA, not 
joe-user's IP address, your own mail server's IP address. How internal 
and/or authenticated users with an infection can cause your MTA to end 
up on blacklists (especially trap fed) regardless of your rate based 
tripwires/log scanning. And how dumb-bots nearly never send outbound (to 
the rest of the world) through your MTA, only the smarter ones that can 
use SMTP-AUTH usually do that. That all leads to needing something a bit 
more than log scanning and rate limiting.

Again, blocking outbound 25 from everything but your own MTA is all well 
and good for containing internal outbreaks from causing everyone else 
grief, but it has little impact on keeping your own MTA clean.

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

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.chapellon@mana.pf
>>>>>>>> <ma...@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
>>>>
>>>
>
>

Re: thanks to thinking people.

[Alexandre Chapellon <al...@mana.pf>]

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.chapellon@mana.pf
> >>>>>> <ma...@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 <al...@mana.pf>
Mana SAS

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

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.chapellon@mana.pf
>>>>>> <ma...@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
>>
>

Re: thanks to thinking people.

[Brian Godette <bg...@idcomm.com>]

  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.chapellon@mana.pf
>>>>> <ma...@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
>

Re: thanks to thinking people.

[Brian Godette <bg...@idcomm.com>]

  On 7/22/2010 2:23 PM, Ted Mittelstaedt wrote:
>
>
> On 7/22/2010 11:29 AM, Benny Pedersen wrote:
>> On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote
>>> A forged sender looks no different than a legitimate sender. Postfix
>>> would have no way to be 'smart' about this (except for some instances
>>> of SPF fail, but then why 'bounce'? Why not reject?).
>>
>> and why not show logs ?
>>
>> bounces is newer external since postfix change sender to mailer-daemon
>> with will end in some mailbox local if it was sent from local ip, if it
>> sent remotely its just a reject that makes the remote mta do the bounce,
>> but it will be the same that happend remotely when it bounces
>>
>> if bounces go external then the mta is not configured correct, and it
>> can be other reasons it does bounce then just not used a reject
>>
>
> Nonsense.
>
> You have internal users.
>
> They are using auth-smtp.
>
> One of those "internal" users is running a laptop
>
> He takes laptop to starflucks and joins the wireless
>
> He sends mail through your server.
>
> How exactly does Postfix "know" that he is an "internal"
> user.
>
> Spammer in the wild sees a mail from your user with a
> senders address of "ilovecats@example.com" originating
> from your smtp-auth system
>
> Spammer in the wild guesses user is using a UID of
> "ilovecats" and a password of "pussy"
>
> Spammer in wild authenticates into your auth-smtp
> server and spams the world with a forged senders
> address.
>
> How exactly does Postfix "know" the difference between
> Spammer and the internal user on the laptop at Starflucks?
>
> The notion of "bouncing mail to inside users" is a joke.
>
> Ted
>

You don't BOUNCE you SMTP REJECT. No DSNs, no backscatter, and any FP 
from a legit user ends up with a support call to the correct party. If 
the outbound message does not exceed your SMTP REJECT level you let it 
go out WITHOUT MODIFICATION, no markup, no nothing.

Re: thanks to thinking people.

[Alexandre Chapellon <al...@mana.pf>]

Thanks Ted for that example i could not have wrote in english myself.

Le jeudi 22 juillet 2010 à 13:23 -0700, Ted Mittelstaedt a écrit :

> 
> On 7/22/2010 11:29 AM, Benny Pedersen wrote:
> > On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote
> >> A forged sender looks no different than a legitimate sender. Postfix
> >> would have no way to be 'smart' about this (except for some instances
> >> of SPF fail, but then why 'bounce'? Why not reject?).
> >
> > and why not show logs ?
> >
> > bounces is newer external since postfix change sender to mailer-daemon
> > with will end in some mailbox local if it was sent from local ip, if it
> > sent remotely its just a reject that makes the remote mta do the bounce,
> > but it will be the same that happend remotely when it bounces
> >
> > if bounces go external then the mta is not configured correct, and it
> > can be other reasons it does bounce then just not used a reject
> >
> 
> Nonsense.
> 
> You have internal users.
> 
> They are using auth-smtp.
> 
> One of those "internal" users is running a laptop
> 
> He takes laptop to starflucks and joins the wireless
> 
> He sends mail through your server.
> 
> How exactly does Postfix "know" that he is an "internal"
> user.
> 
> Spammer in the wild sees a mail from your user with a
> senders address of "ilovecats@example.com" originating
> from your smtp-auth system
> 
> Spammer in the wild guesses user is using a UID of
> "ilovecats" and a password of "pussy"
> 
> Spammer in wild authenticates into your auth-smtp
> server and spams the world with a forged senders
> address.
> 
> How exactly does Postfix "know" the difference between
> Spammer and the internal user on the laptop at Starflucks?
> 
> The notion of "bouncing mail to inside users" is a joke.
> 
> Ted


-- 
Alexandre Chapellon <al...@mana.pf>
Mana SAS

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

On 7/22/2010 11:29 AM, Benny Pedersen wrote:
> On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote
>> A forged sender looks no different than a legitimate sender. Postfix
>> would have no way to be 'smart' about this (except for some instances
>> of SPF fail, but then why 'bounce'? Why not reject?).
>
> and why not show logs ?
>
> bounces is newer external since postfix change sender to mailer-daemon
> with will end in some mailbox local if it was sent from local ip, if it
> sent remotely its just a reject that makes the remote mta do the bounce,
> but it will be the same that happend remotely when it bounces
>
> if bounces go external then the mta is not configured correct, and it
> can be other reasons it does bounce then just not used a reject
>

Nonsense.

You have internal users.

They are using auth-smtp.

One of those "internal" users is running a laptop

He takes laptop to starflucks and joins the wireless

He sends mail through your server.

How exactly does Postfix "know" that he is an "internal"
user.

Spammer in the wild sees a mail from your user with a
senders address of "ilovecats@example.com" originating
from your smtp-auth system

Spammer in the wild guesses user is using a UID of
"ilovecats" and a password of "pussy"

Spammer in wild authenticates into your auth-smtp
server and spams the world with a forged senders
address.

How exactly does Postfix "know" the difference between
Spammer and the internal user on the laptop at Starflucks?

The notion of "bouncing mail to inside users" is a joke.

Ted

Re: [sa] Re: thanks to thinking people.

[Charles Gregory <cg...@hwcn.org>]

On Thu, 22 Jul 2010, Benny Pedersen wrote:
> On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote
>> A forged sender looks no different than a legitimate sender. Postfix would 
>> have no way to be 'smart' about this (except for some instances of SPF 
>> fail, but then why 'bounce'? Why not reject?).
>
> and why not show logs ?

Sorry. Not OP. Just noting that the opinion that postfix should be smart 
enough to rewrite a forged sender just doesn't make sense.

> bounces is newer external since postfix change sender to mailer-daemon with 
> will end in some mailbox local if it was sent from local ip....

???? Postfix doesn't change the sender. Mailer Daemon is the 'sender' for 
all buonces. But it will be sent TO the original sender listed in the 
'From' header. If postfix has generated the From header based on 
transaction authentication, then a 'bounce' would indeed go back to the 
originating mail account. But if you are merely going by IP, then the 
'sender' that postfix tries to 'bounce' mail to will be the forged sender. 
And postfix has no way to know it is forged....

- C

Re: thanks to thinking people.

[Benny Pedersen <me...@junc.org>]

On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote
> A forged sender looks no different than a legitimate sender. Postfix  
> would have no way to be 'smart' about this (except for some  
> instances of SPF fail, but then why 'bounce'? Why not reject?).

and why not show logs ?

bounces is newer external since postfix change sender to mailer-daemon  
with will end in some mailbox local if it was sent from local ip, if  
it sent remotely its just a reject that makes the remote mta do the  
bounce, but it will be the same that happend remotely when it bounces

if bounces go external then the mta is not configured correct, and it  
can be other reasons it does bounce then just not used a reject

-- 
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

On 7/22/2010 11:03 AM, Charles Gregory wrote:
> On Thu, 22 Jul 2010, Benny Pedersen wrote:
>> On ons 21 jul 2010 19:09:55 CEST, Alexandre Chapellon wrote
>>> You can have forged return-path and /or stollen credentials... in both
>>> cases you look like a backscatter source.
>> i belive postfix is smart to change forged sender to something that is
>> not fqdn before it bounce :)
>
> A forged sender looks no different than a legitimate sender. Postfix
> would have no way to be 'smart' about this (except for some instances of
> SPF fail, but then why 'bounce'? Why not reject?).
>

Wash your mouth out!  Didn't you know Postfix is God's Gift to Mail 
Admins?  It can do ANYTHING.  Postfix is so smart that it can reach back 
through the SMTP connection to the spammer and blow his computer
up!!!


Or so the Postfix bigots would have you believe.

Ted

Re: thanks to thinking people.

[Charles Gregory <cg...@hwcn.org>]

On Thu, 22 Jul 2010, Benny Pedersen wrote:
> On ons 21 jul 2010 19:09:55 CEST, Alexandre Chapellon wrote
>> You can have forged return-path and /or stollen credentials... in both
>> cases you look like a backscatter source.
> i belive postfix is smart to change forged sender to something that is 
> not fqdn before it bounce :)

A forged sender looks no different than a legitimate sender. Postfix would 
have no way to be 'smart' about this (except for some instances of SPF 
fail, but then why 'bounce'? Why not reject?).

- C

Re: thanks to thinking people.

[Benny Pedersen <me...@junc.org>]

On ons 21 jul 2010 19:09:55 CEST, Alexandre Chapellon wrote
> You can have forged return-path and /or stollen credentials... in both
> cases you look like a backscatter source.

show logs

i belive postfix is smart to change forged sender to something that is  
not fqdn before it bounce :)

-- 
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: thanks to thinking people.

[Alexandre Chapellon <al...@mana.pf>]

Le mardi 20 juillet 2010 à 18:56 -0600, LuKreme a écrit :

> On Jul 20, 2010, at 18:07, Alexandre Chapellon <al...@mana.pf> wrote:
> 
> > Bouncing spam?????? What a good way to become a backscatter source (in addition to spam)!
> 
> We are talking about Checking OUTBOUND messages. It is perfectly ok to bounce internal messages. 

You can have forged return-path and /or stollen credentials... in both
cases you look like a backscatter source.

-- 
Alexandre Chapellon <al...@mana.pf>
Mana SAS

Re: [sa] Re: thanks to thinking people.

[Charles Gregory <cg...@hwcn.org>]

On Tue, 20 Jul 2010, LuKreme wrote:
> We are talking about Checking OUTBOUND messages. It is perfectly ok to 
> bounce internal messages.

Caveat: As long as proper care is taken to send the bounce to the 
authenticated sender of the mail and NOT just lamely use the 'From' 
header! Still prefer an SMTP reject over a bounce!

- C

Re: thanks to thinking people.

[LuKreme <kr...@kreme.com>]

On Jul 20, 2010, at 18:07, Alexandre Chapellon <al...@mana.pf> wrote:

> Bouncing spam?????? What a good way to become a backscatter source (in addition to spam)!

We are talking about Checking OUTBOUND messages. It is perfectly ok to bounce internal messages. 

Re: thanks to thinking people.

[John Hardin <jh...@impsec.org>]

On Tue, 20 Jul 2010, Alexandre Chapellon wrote:

> Le mardi 20 juillet 2010 à 14:40 -0600, LuKreme a écrit :
>
>> On Jul 20, 2010, at 12:16, Ted Mittelstaedt <te...@ipinc.net> wrote:
>>
>>> Exactly, meaning that if you run SA on outbound mail then there's no 
>>> point at all unless you configure it to DELETE the outbound mail it 
>>> thinks is spam - and if you do that your going to get shot by your 
>>> users over the FPs.
>>
>> Well, no. If you do filter outbound and trigger on a spammy message, 
>> you bounce it, not delete it.
>
> Bouncing spam?????? What a good way to become a backscatter source (in
> addition to spam)!
>
> Definately not to be done!

Bounce _internally_, on _outbound_ email.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
  Today: the 41st anniversary of Apollo 11 landing on the Moon

Re: thanks to thinking people.

[Alexandre Chapellon <al...@mana.pf>]

Le mardi 20 juillet 2010 à 14:40 -0600, LuKreme a écrit :

> On Jul 20, 2010, at 12:16, Ted Mittelstaedt <te...@ipinc.net> wrote:
> 
> > Exactly, meaning that if you run SA on outbound mail then there's no
> > point at all unless you configure it to DELETE the outbound mail it
> > thinks is spam - and if you do that your going to get shot by your users
> > over the FPs.
> 
> Well, no. If you do filter outbound and trigger on a spammy message, you bounce it, not delete it. 
> 

Bouncing spam?????? What a good way to become a backscatter source (in
addition to spam)!

Definately not to be done!
-- 
Alexandre Chapellon <al...@mana.pf>
Mana SAS

Re: thanks to thinking people.

[LuKreme <kr...@kreme.com>]

On Jul 20, 2010, at 12:16, Ted Mittelstaedt <te...@ipinc.net> wrote:

> Exactly, meaning that if you run SA on outbound mail then there's no
> point at all unless you configure it to DELETE the outbound mail it
> thinks is spam - and if you do that your going to get shot by your users
> over the FPs.

Well, no. If you do filter outbound and trigger on a spammy message, you bounce it, not delete it. 

Re: thanks to thinking people.

[Matus UHLAR - fantomas <uh...@fantomas.sk>]

>> On 20.07.10 00:48, RW wrote:
>>> I was asking what's the point of adding headers or markup  that *is*
>>> seen by the recipient.

> On 7/20/2010 4:55 AM, Matus UHLAR - fantomas wrote:
>> I think Brian understood youre question as disagreement :)
>>
>> I think there's no logical point. In case of FP you are only telling the
>> recipient your spam filter sucks :)

On 20.07.10 11:16, Ted Mittelstaedt wrote:
> Exactly, meaning that if you run SA on outbound mail then there's no
> point at all unless you configure it to DELETE the outbound mail it
> thinks is spam - and if you do that your going to get shot by your users
> over the FPs.

I think that at this level by "outgoing email" we mean "email coming from
authenticated users". Such e-mail we can reject at smtp time so the users
will get proper error message.

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol. 

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

On 7/20/2010 4:55 AM, Matus UHLAR - fantomas wrote:
>>>> On Mon, 19 Jul 2010 13:25:26 -0700
>>>> Ted Mittelstaedt<te...@ipinc.net>   wrote:
>>>>> 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,
>
>>>    On 7/19/2010 4:01 PM, RW wrote:
>>>> What's the point of adding spam-filtering headers or markup to
>>>> outgoing mail?
>
>> On Mon, 19 Jul 2010 16:58:49 -0600
>> Brian Godette<bg...@idcomm.com>  wrote:
>>> Indeed, the point would be to score and SMTP reject outbound over
>>> some score, anything under would be sent unmodified.
>
> On 20.07.10 00:48, RW wrote:
>> I was asking what's the point of adding headers or markup  that *is*
>> seen by the recipient.
>
> I think Brian understood youre question as disagreement :)
>
> I think there's no logical point. In case of FP you are only telling the
> recipient your spam filter sucks :)
>

Exactly, meaning that if you run SA on outbound mail then there's no
point at all unless you configure it to DELETE the outbound mail it
thinks is spam - and if you do that your going to get shot by your users
over the FPs.

Ted

Re: thanks to thinking people.

[Matus UHLAR - fantomas <uh...@fantomas.sk>]

> > > On Mon, 19 Jul 2010 13:25:26 -0700
> > > Ted Mittelstaedt<te...@ipinc.net>  wrote:
> > >> 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,

> >   On 7/19/2010 4:01 PM, RW wrote:
> > > What's the point of adding spam-filtering headers or markup to
> > > outgoing mail?

> On Mon, 19 Jul 2010 16:58:49 -0600
> Brian Godette <bg...@idcomm.com> wrote:
> > Indeed, the point would be to score and SMTP reject outbound over
> > some score, anything under would be sent unmodified.

On 20.07.10 00:48, RW wrote:
> I was asking what's the point of adding headers or markup  that *is*
> seen by the recipient.

I think Brian understood youre question as disagreement :)

I think there's no logical point. In case of FP you are only telling the
recipient your spam filter sucks :)

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines. 

Re: thanks to thinking people.

[RW <rw...@googlemail.com>]

On Mon, 19 Jul 2010 16:58:49 -0600
Brian Godette <bg...@idcomm.com> wrote:

>   On 7/19/2010 4:01 PM, RW wrote:
> > On Mon, 19 Jul 2010 13:25:26 -0700
> > Ted Mittelstaedt<te...@ipinc.net>  wrote:
> >
> >
> >> 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,
> > What's the point of adding spam-filtering headers or markup to
> > outgoing mail?
> Indeed, the point would be to score and SMTP reject outbound over
> some score, anything under would be sent unmodified.


I was asking what's the point of adding headers or markup  that *is*
seen by the recipient.

Re: thanks to thinking people.

[Brian Godette <bg...@idcomm.com>]

  On 7/19/2010 4:01 PM, RW wrote:
> On Mon, 19 Jul 2010 13:25:26 -0700
> Ted Mittelstaedt<te...@ipinc.net>  wrote:
>
>
>> 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,
> What's the point of adding spam-filtering headers or markup to outgoing
> mail?
Indeed, the point would be to score and SMTP reject outbound over some score, anything under would be sent unmodified. If it's a FP your own user contacts you.

Re: thanks to thinking people.

[RW <rw...@googlemail.com>]

On Mon, 19 Jul 2010 13:25:26 -0700
Ted Mittelstaedt <te...@ipinc.net> wrote:


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

What's the point of adding spam-filtering headers or markup to outgoing
mail?

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

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.chapellon@mana.pf
>>>> <ma...@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.

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.

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

Re: thanks to thinking people.

[Brian Godette <bg...@idcomm.com>]

  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.chapellon@mana.pf
>>> <ma...@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.

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.

Re: thanks to thinking people.

[Ted Mittelstaedt <te...@ipinc.net>]

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.chapellon@mana.pf
>> <ma...@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

Re: thanks to thinking people.

[Matt <lm...@gmail.com>]

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


In Exim you can ratelimit SMTP connections like so:

http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECTratelimiting

# Slow down fast senders; note the need to truncate $sender_rate
# at the decimal point.
warn ratelimit = 100 / 1h / per_rcpt / strict
    delay     = ${eval: ${sg{$sender_rate}{[.].*}{}} - \
                  $sender_rate_limit }s

Sure there are ways of doing this with other MTA's as well.

Since spam depends on many thousands of messages this effectively
limits the usefulness of your MTA for sending spam.  Must also limit
the number of connections per IP.  I also think this examples 100
recipients per hour is to low.

Matt

Re: thanks to thinking people.

[Brian Godette <bg...@idcomm.com>]

  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.chapellon@mana.pf 
> <ma...@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.