On Wed, Jan 15, 2003 at 10:42:07PM -0000, Stephane wrote:
> Hello again,
>
> Amongst the answers to my previous post ("has a large company implemented SA") there
>was a very good idea on success stories with SA... It is true that most of the people
>on the net who would say they were happy with SA and that it worked well for them are
>using it for their private use, or run a server which does mailboxes storage as well
>(POP3/IMAP I would imagine). However I couldn't find any description of a successful
>implementation with a similar setup than ours -- I would guess at least a few other
>companies must follow the same model.
>
> Our infrastructure would look like:
> Internet-->[SA]-->[Mailsweeper]-->[SMTP/Lotus Notes gateway]-->Lotus Notes Mail
>reader on Client PC
> Each bracketed text is a separate server, so SA would be a dedicated relay, with no
>local mailboxes, just a passthrough.
>
> The goal for us is to tag emails (X-Spam-Flag) in a first step and let the Notes
>client put tagged msgs into a separate folder (only saves time, bandwidth and storage
>are still used).
> In a second step we would like to quarantine all detected spam at the SA server
>level (thus saving also bandwidth and storage).
>
this is almost exactly the setup we use with around 2000 mailboxes,
except substitute worldtalk for mailsweeper, and exchange for lotus
notes. we've done this as consultants several times now, and we
provide commercial remote support and manage blocking, whitelists, and
graylists for our clients.
> I received many replies to my previous post from people who work in companies having
>implemented SA, but none of them do the blocking at the gateway level, they give the
>choice to the users. With our infrastructure, we cannot do that, as the SA server
>will not know anything about the mailboxes, it would just be a relay, no local
>/var/spool/mail directory, no local /home/xxx directory for the users !
>
we block at the gateway level. the closer to the periphery you block
the more effective it is. (for spammers who don't take their bounces,
can have the option of not taking their mail in the first place.)
of course, it helps if you can have an /etc/aliases file with an entry
for each user, rather than just relaying everything. (we build these
several times per day using a script from an export of enterprise
address book.)
> I think most companies are afraid of implementing opensource software as a component
>for an important service such as email.
if this is true (and i don't think it is), it's because they're
uninformed about how much open source software they ALREADY depend on.
most of the internet is completely dependent on sendmail and bind,
even on proprietary platforms. (only relatively recently has
commercial sendmail and support for it been available.)
and google, yahoo, and hotmail run on bsd. ever seen them down?
and most of the TCP stack in windows was derived from berkeley unix.
>I think that generally even though people know email has not been designed to be a
>100% reliable protocol they still make business with it.
on the contrary, internet email is designed to be 100% reliable in that the
sender is supposed to be informed of nondelivery by a bounce. (this is
violated by a number of ISPs who silently dispose of suspected spam.)
the more time and care you spend on whitelists the likelier you won't
interfere with business-related mail.
>
> First of all, please let me highlight that the following thoughts are not my
>personal views but difficult barriers to face when you try to get opensource into a
>large manufacturing company (not an ISP, not a software company) like ours.
>
> The major fears are:
> - opensource software is often made by hobbyists and these people do not have the
>structure to provide software support/bugfixes, or quick response to a big problem
>incurring financial losses (no emails go through for example!)
this is what consultants and companies are for. providing services
and expertise to stablize open source software and provide you with
committed service levels, if you don't have inhouse expertise.
> - are upgrades straightfoward and not causing problems to the existing running
>system, are they well tested.
you're right that pieces of this software is not particularly mature,
so upgrades and version skew among the parts can be problematic.
as consultants, we add hysteresis to the process by installing on our
own machines and using new stuff for our own mail first, before we
install on our client machines, by doing performance testing, and by
installing on more adventurous clients before installing on
risk-averse ones.
> - what if the SA project is abandoned, what if the source is bought by a commercial
>vendor, in other words, what if SA as it exists today disappears ? With opensource
>you cannot have a contractual engagement to provide support or updates, nor can you
>really know the roadmap for a product and what is planned for future development
>
the benefits of open source are probably off-topic for this list,
but:
even if you are on your own with open source, the good thing is you
CAN be on your own. or you can hire someone else to maintain or
improve it. almost always you have a choice of several possibilities.
in the case of proprietary software, you're stuck with one vendor.
luckily, for email, the protocols are relatively stable, so there is
no forced reason to upgrade unless you need new features. (in the spam
arms-race, you probably want to upgrade from time to time).
one of the biggest technical problems with spam filtering is how you
can add your own rules. for example, one of my clients gets email from
a trading partner containing meeting and conference call announcements,
cc:ed to lots of people. of course i have to write special rules for
them for those things, but i can! with commercial software, i can't
even change the error messages and warnings to be usable without the
vendor's cooperation.
let me tell you a story:
10 years ago i installed multiple firewalls based on TIS firewall
toolkit at a UN agency. amazingly, they are *still* using that
software today, adding to and augmenting some aspects of it, adding
proxies alongside, etc. they have one competent network engineer
maintaining it, part time.
meanwhile, the commercial versions of the software (gauntlet) have
been through 6 versions, multiple forced platform changes, and two
corporate purchases (first, NAI, now Secure Computing). the software
has been closed source for half of its life, and as far as i can tell,
almost nobody understands it now, and nobody can debug it. it is
unclear how long it will live, since Secure Computing has a competing
product.
the situation is COMPLETELY TYPICAL in commercial software. a good
product succeeds, you buy it as a customer, and then the high quality
engineers vest and leave, the product or the company is sold, and
you're STUCK.
you install a proprietary MRP package which costs MILLIONS of dollars
and MILLIONS of dollars in consulting to install, and what are you
left with at the end? MILLIONS of dollars in required annual
maintenance payments which provide an annuity for the vendor and NO
SOURCE CODE. YOU ARE LOCKED IN.
since not only the code is closed but the interfaces are proprietary,
you can't switch databases, platforms or do anything without the
vendor's cooperation.
> Blocking spam-tagged emails at the gateway level as we intend to do requires a good
>trust in the chosen spam filter product !! And here is my point, this trust comes
>when you can point at other and say: they use it, they are happy with it, and all
>problems they encountered, they could fix them with the help of xxxx and if they get
>any more problems they can rely on xxxx to fix them quickly.
>
SA and amavisd have a number of features that if used correctly tend to
increase your users' trust in them as spam solutions.
- you can get a daily report of what sites were blocked and why at the
MTA level.
- the SA tests and their results are visible to the user in headers
and are logged.
- we log all spam so we can examine it later if necessary.
- anything we turn away is visible to the sender.
- we whitelist administration addresses so incorrectly blocked senders
can complain.
- we generate warnings (instead of errors) for a long time before turning
on possibly controversial features (such as blocking based on FQDN in
HELO).
and there are a number of ways to administer these that will increase
the enterprise trust in the solutions. it's hard for a newbie to know
about these ways without getting outside expertise.
> I am desperate to get SA implemented (I just love it!!) but we wouldn't like to
>reinvent the wheel if someone else did a similar implementation
>
> I appreciate this is a very long email (apologies), if this post has got nothing to
>do with this mailing list, I am more than happy to carry the discussion off it with
>anyone who feels they are in the same position as me, as my company.
>
> Best Regards,
> Stephane
>
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
