|
Michael, I respectfully disagree. My typical client
spends about 45 installing and configuring my solution. No infrastructure
changes required. My typical client then spends about 1 hour enrolling their
users to be protected by the solution – the solution is not an opt-in,
meaning that you consciously add in the mailboxes you want protected. My typical
client then pops champagne and celebrates. The only time he/she visits the
console of the product again is when he wants to add a new user or remove
someone. No administration, no baby-sitting. As
long as your Exchange is talking to your AD and you mail is flowing and your
data center is not burning down – all dependencies outside the control of
my product – you do not need to train or teach my product or download any
signature or dictionary. The SPAM does not sit in your server UNLESS you want
it to sit there. They do not clog your users mailboxes either. I will see your solution and raise you a
six-pack J Anti-SPAM != rocket science. It needs not
be advertised or implemented as such. Deji From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael B. Smith I'm an anti-spam solution provider as well
(as well as a hosted Exchange provider). I can tell you that I spend more time
maintaining my anti-spam services (only two servers) than I do my Exchange
farm. It's a high-touch, high-support business. Nobody guarantees anything. It's a
"best effort" business. (That's really what the contracts
say...) I think that my "best effort" is probably better than a From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al You could add FUD to that list for many
orgs. There was also a time where MBA/MGMT wanted to outsource for best
in class focus (think Brightmail). Those days are behind us with the concept
of black-box implementations and such, but that doesn't change the mindset. FWIW, I don't buy the lowered bandwidth
concept that comes across unless they can guarantee that I won't lose VALID
mail. Not having a tech involved would be
intriguing; I'd want to see the level of service they actually get vs. what
they perceive that they get. Al From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francis Ouellet Hi Deji, I've been on both sides of the fence in
the past year. Ultimatly the main reason for this was the
time required by the admins to implement this solution which was minimal. They (the powers that be) found that
outsourcing the tech was way cheaper than paying for an appliance etc... They thought that they could save some
bandwith this way and put some stress out of our mail servers So, cost and administration overhead were
probably the major factors behind this. Francis From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Something tells me I shouldn’t be
asking this, but the phrase “outsource Anti-SPAM” – and the
recent news about MCDonald “OUTSOURCE” drive-through order
processing – just make the question irresistible. Why would anyone outsource Anti-SPAM? If
your mail service is outsourced, too, that would be somewhat understandable,
although not justifiable, IMO. If you host and manage your mail infrastructure,
what is the logic behind outsourcing Anti-SPAM? I realize that you guys may not
be responsible for making the calls on this, but I am also interested in
knowing the reasoning that drove the final decision maker into making that
decision. Is it the administration overhead? Is it the cost? Is it the
effectiveness? For the record, I am an Anti-SPAM solution
provider, and it bothers me that people would give control of their
mail-infrastructure out to an external party for such simple task as SPAM
protection. Could this be because most of the solutions out there suck in one
form or another? What is it? Deji [getting off his soap-box now] From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter While we haven't outsourced our anti-spam
stuff, we're in the same boat with the AD address validation. We're likely
going to spin up an ADAM instance and have the queries run against that, so
that 1) we can control what information the anti-spam software has access to
and 2) it's not directly touching our DCs/GCs. It also lets you keep your DCs
out of the DMZ. Something you may want to consider... Hunter From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francis Ouellet Thanks for the reply Joe! The url provided
was extremely helpful. The reason I'm asking all of this is because the
management has decided to outsource anti-spam technology to a 3rd party that
uses our AD to validate e-mail addresses. Unfortunately their "security
through obscurity" methods are scaring the crap out of me. They won't
disclose the type of bind they are doing agains't one of our GC in the DMZ. I
guess I could sniff the incomming traffic and figure out what type of bind they
are doing? Thanks, Francis From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Depends on the auth options chosen. By
default, ldp will use kerberos as will my adfind. The auth option
is called LDAP_AUTH_NEGOTIATE which is a generic security services (GSS -
SPNEGO) provider and will try different mechanisms starting out with kerberos
but NTLM is also an option there. You can force it to bind with a simple bind
though which is clear text passwords. See http://msdn.microsoft.com/library/default.asp?url=""> and
look in the remarks section. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francis Ouellet Thanks for the reply joe, however one last
questions remains: Is the process of binding to the GC (in
the case I'm connecting to port 3268) different from say: A user authentication
to AD when logging on to a workstation? Does it use the same kerberos ticket
system? Thanks!! Francis From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe You have two major functions in this area 1. Connect. This is where you specify the
server, port, and network protocol you want to use. If you select
connectionless you are using UDP, otherwise you are using TCP. For most folks,
UDP is useless, so you may not want to play with it too much. You can also
specify an SSL connection. Until you work out the basics, don't worry about it. 2. Bind. This is where you specify the ID
you want to connect to AD with and the authentication mechanism you want to
use. The calls are all going against the server/port that you specified in
1. Note that you can't authenticate a UDP connection (just one reason why you
don't generally want to play with UDP). Some apps combine that all together in the
background so you don't see it such as my adfind command line tool. You simply
specify what you want and off it goes and handles the binding and connecting
and everything else for you. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francis Ouellet Hi, I'm trying to understand the process of binding to an ldap
server. I'm toying with ldp.exe and I'd like to know a little bit more about
the different bind options... If you decide to connect to port 3268 to query the GC and
then decide to bind do you bind on port 389 or continue to authenticate to the
GC? You see, I'm just a wee bit confused as to what happens in the background
:) Thanks, Francis Ouellet |
