>that there would be benefit to basically a complete
re-write of ASSP in a modular form, where instead of a single monolithic
program there are multiple programs that are each dedicated
single-purpose units (like a DNSBL processor, URIBL processor, etc.)
>From a human view assp V2 seems to be a monolit - but it is'nt. Looking in
to the folder 'sl-cache' you can see that assp is 'self splitting' in to
hundreds (879 more or less) small modules (subs).
Each of this parts is only loaded and compiled by a thread, if it needs to
run this code.
>From the still ~ 55.000 lines of assp.pl are ~ 10% common (startup) code -
90% of the code are loaded on request.
V2 has also some mechanism to remove still loaded coded parts from the
Perl namespace - for example parts that are only required at startup.
The 'monolit' is only used one time. If perl compiles assp for syntax and
dependcy check (perl -c assp.pl) , it uses the monolit. If called to run,
assp switches to the 'self splitting' and 'self loading' modus.
For assp to work this (the recommended) way, the 'lib/AsspSelfLoader.pm'
must be installed!
Thomas
Von: "Daniel L. Miller" <dmil...@amfes.com>
An: assp-test@lists.sourceforge.net,
Datum: 26.07.2012 06:38
Betreff: Re: [Assp-test] Feature Request - Content-Filter-Only
mode, with all of the per u
On 7/25/2012 9:38 AM, Charles Marcus wrote:
> On 2012-07-25 11:23 AM, Fritz Borgstedt <f...@iworld.de> wrote:
>> ASSP 1.9 is rocksolid and can be used pre/post.
> Understood, and thanks, but I would need full/solid SSL/TLS support, so
> v1 is no longer an option for me.
>
>> ASSP 2 is rocksolid and can be used pre/post.
> Well, I know a lot of mail admins who are perfectly happy with postfix's
> pre-queue anti-spam measures but don't like Spamassassin or other
> post-queue content filters... that is the main reason I'm asking.
>
> That said - and again, *please* do not take offense - but complaints
> about new versions of v2 locking up/freezing/etc abound on the assp-test
> list, going back for as long as I can remember. If it was only a rare
> occurrence, I wouldn't worry as much, but I have been seeing these
> reports all the time...
>
> Could you at least comment on the possibility/viability of splitting
> ASSP's functionality into pre and post processing 'modes' or 'modules'
> (for lack of a better term), so that we would have the option of only
> implementing the content-filter functionality (again, with full per user
> Block Reporting/Training functionality intact)?
>
> As always, thanks very much for your efforts, and again, I certainly
> don't intend any offense against your or Thomas' hard work!
>
I once thought the same - and while I still think (probably
inaccurately) that there would be benefit to basically a complete
re-write of ASSP in a modular form, where instead of a single monolithic
program there are multiple programs that are each dedicated
single-purpose units (like a DNSBL processor, URIBL processor, etc.) -
that's probably going to come from somewhere else. I don't see Fritz or
Thomas going to such an architecture - and there's a reason.
While ASSP has a host of features, there are two big ones that stand out
for me. One - the ability to "open a hole" in your anti-spam system
simply by sending an email to your desired sender. With the exception
of virus checks - that one step (per my own configuration) cuts through
every DNSBL, regex, IP, HELO, you-name-it check. Training required for
end-users - zero. Administrative overhead for me - zero. The ability
to auto-whitelist is simply invaluable to me. I had asked about
implementing such a thing in a pure Postfix manner - my previous
inquiries met with resistance. If it's available now - great - but I'm
not aware of it.
Second - the admin interface. Just about every other anti-spam solution
is configured via text files (at least the ones in my limited
knowledge). Some people like that sort of thing. ASSP provides a
complete GUI - for changing settings on-the-fly, a live log viewer, a
live status view - and quite a bit more. The fact that it provides a
config change history - self-generated - which allows you to try a
setting and then if it breaks - you know what you did to make it happen
- is another critical tool for me.
While I'm sure it's possible, having such a level of integration between
GUI, auto-whitelist, and every test by using independent executables is
probably quite a challenge.
If you're absolutely paranoid about what you expose to the internet -
and I commend you for it - you actually can (because I've done it!)
configure an external and an internal Postfix instance that pipe through
ASSP. So the internet talks to Postfix, and your authorized clients
talk to Postfix - and Postfix talks to ASSP in between for processing.
Perfectly doable, legal, and mostly non-fattening.
As with anything - when you increase the level of complexity you
increase the potential for breakage. ASSP has a LOT of things that you
CAN turn on - including quite a few optional modules - that may not be
as "mainstream" as others and as a result receive less testing. If
you're conservative about which options you enable you have quite a bit
of control.
When it comes to fighting spam - it's a constantly changing arena. As a
result, the filters need to keep up. That's one reason I love the
active development coming from Fritz & Thomas. There have been teething
troubles with certain versions - but that can happen with anything.
Nobody says you have to enable the auto-updates, or run with the most
bleeding edge versions (and sometimes these guys are cranking out new
versions faster than my system can download them). And while not all
the problems have been out of ASSP's control - like Perl versions,
modules, SQL servers, Windows/Linux/Mac specific quirks, etc. - most of
them are. If you setup a clean install with the recommended minimums I
think you'll be quite happy.
--
Daniel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
