RE: Relaying Problem question - still fighting it!

  • From: "John Tolmachoff \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
  • To: "'[ExchangeList]'" <exchangelist@xxxxxxxxxxxxx>
  • Date: Tue, 30 Sep 2003 12:12:11 -0700

Simmer down there. No one is flaming you. You stated a way to do it
matter-of-factly, when it was more of your experience and what you do.

 

Fighting spam is a war that far too many people take far too lightly looking
for quick fixes so they can get on with other things. Fighting spam is a
major job, one that must be taken seriously. 

 

I did offer assistance to the original poster. Like I said, a review of the
logs is needed to determine HOW this occurred. When some thing breaks, you
do not just find a way to avoid it. You find out what happened and take
appropriate action to prevent a reoccurrence.

 

Simply adding some known IP ranges to block does nothing in the war on spam,
as spammers are by far smarter and have more time on their hands they all of
us do combined. 

 

John Tolmachoff MCSE CSSA

Engineer/Consultant

eServices For You

www.eservicesforyou.com

 

-----Original Message-----
From: Allen, Chris [mailto:CAllen@xxxxxxxxxxxxxxxx] 
Sent: Tuesday, September 30, 2003 11:50 AM
To: [ExchangeList]
Subject: [exchangelist] RE: Relaying Problem question - still fighting it!

 

http://www.MSExchange.org/

Well, then lock it down to specific IPs, such as the servers the apps are
running from, but until the kb articles on the ways of stopping relay
actually works, then there HAS to be a workaround. In my opinion, allowing
authenticated users to relay even though they fall outside of your internal
IP range is an open invite to attack and abuse. No matter how good your
policy is, there is always someone out there who can break it, unless you
are using access keys. As for Kaaza and apps of that nature, it is a simple
matter of not opening those ports in the firewall. Strict password policy is
a good rule of thumb, and should be in place, but it is not answer to this
user's problem. And stating that a work around is not the answer when there
is no other answer, well that is just ludicrous. If it weren't for work
arounds, you would not get ISA to pass certificates in through a server
publishing rule. Most Microsoft products and kb articles list work arounds
for known issues. When a valid fix comes out, great, I will apply it then,
but for now I am content in the fact that the spam gang has been silenced
through my network. I am not saying this is the answer to everyone's
problems, but it worked for me and I am simply offering an option. If you
want to flame me for that, go right ahead. But if more people would offer
solutions rather than criticisms then maybe we can get something done the
"proper" way.

 

-----Original Message-----
From: John Tolmachoff (Lists) [mailto:johnlist@xxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, September 30, 2003 2:36 PM
To: [ExchangeList]
Subject: [exchangelist] RE: Relaying Problem question - still fighting it!

 

http://www.MSExchange.org/

Now, the important part, Uncheck the "Allow all computers which successfully
authenticate to relay, regardless of the list above." What this will do is
confine relaying to the internal IPs, No longer will an external user be
able to relay using an authenticated user's information.  

 

While that may have worked for you, it will not work if you have users
connecting outside of the local LAN. Also, your setup will allow some one
from an internal IP to relay freely. This could happen in a number of ways,
including an internal user with Kaaza installed, an internal user that is
using software to send out bulk e-mail and so forth.

 

The point is Microsoft, or any one else, has no need to create any KB
article about how to configure a certain way, as each situation is different
and demands different configurations.

 

For me or any of my clients, I will never allow free relay from the internal
IP range. You must authenticate. Disallowing authenticated users to relay IS
NOT AN ANSWER TO A WEAK PASSWORD POLICY!

 

While there can be many right ways of doing things, coming up with a work
around is not one of them.

 

John Tolmachoff MCSE CSSA

Engineer/Consultant

eServices For You

www.eservicesforyou.com

 

------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist
Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp
Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
Leading Network Software Directory: http://www.serverfiles.com
No.1 ISA Server Resource Site: http://www.isaserver.org
Windows Security Resource Site: http://www.windowsecurity.com/
Network Security Library: http://www.secinf.net/
Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this MSExchange.org Discussion List as:
callen@xxxxxxxxxxxxxxxx
To unsubscribe send a blank email to
$subst('Email.Unsub') 

------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist
Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp
Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
Leading Network Software Directory: http://www.serverfiles.com
No.1 ISA Server Resource Site: http://www.isaserver.org
Windows Security Resource Site: http://www.windowsecurity.com/
Network Security Library: http://www.secinf.net/
Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this MSExchange.org Discussion List as:
johnlist@xxxxxxxxxxxxxxxxxxx
To unsubscribe send a blank email to
$subst('Email.Unsub') 

Other related posts: