>From what you described about GOOD rules (which was helpful), I'd suggest
adding something like this to the GUI
BLOCK rules cause specific file types to be blocked (but does not block the
others)
GOOD rules block all file types except for those specified in the rule
I don't see anything in the GUI that is that clear. Nowhere does it say
that GOOD overtly rejects everything else, that understanding is critical
to writing rules correctly.
I understand boolean logic just fine, what I don't know is how you intend
to use this logic and overrides, yes there's that word again, when
inheritance is introduced. Once you introduce inheritance, which I
obviously think would be a wonderful thing, we need to insure that
inheritance rules are clear.
I'll try this again, hopefully doing a better job of explaining my
thoughts.
If we have a very simple policy
~GeneralRule => block => exe\-bin|doc|.....and 50 other types
That would block all detected executable content, .doc files, and the 50
other types in the very long string.
*=> GeneralRule
would make this rule be enforced for all users
Now if we have a user allowdocu...@domain.com who we want to be able to
receive .doc files but still have everything else in GeneralRule blocked,
the question is how you want to make this happen?
We wouldn't want to use a GOOD rule for .doc, because then nothing else
would be allowed through (I understand that now, thank you).
So how do you plan to code it to allow us to remove .doc from the very long
GeneralRule definition for this one user?
Sure we could create a second policy like GeneralRuleButAllowDoc definition
that doesn't include doc, but then we're back to maintaining that long
definition in multiple places.
I'm hoping for some sort of setup where we could use a minus (-) syntax
with inheritance to remove or overide types from existing definitions:
allowdocu...@domain.com => block => -doc
that would inherit GeneralRule but remove .doc from it
We could also do
(-i)allowdocu...@domain.com => block => GeneralRule|-doc
which ignores inheritance, but has the GeneralRule referenced for the same
effect as the above rule.
See what I mean? I can't say how hard that would be for you to code, but
it would be a dream for us admins. Have a long general rule but for some
case need to remove ONE of those file types? Just use minus syntax and it's
like it never existed!
On Tue, Aug 22, 2017 at 1:57 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:
> >Yes, but it's unclear if good means that's all that is allowed or if
> it's an override of block.
>
> Did you read anywhere in this section the word 'overwrite'?
> Is it too hard to think a boolean OR? - or reverse, a boolean AND?
>
> block if
> the mail and flow direction matches a defined block rule
> OR
> the mail and flow direction NOT matches a defined good rule
>
> the same is
>
> pass if
> the mail and flow direction NOT matches a defined block rule
> AND
> the mail and flow direction matches a defined good rule
>
>
>
> >And then what happens with inheritance if an inherited policy has a
> block only, line that inherits that has a good, etc.
>
> What a question ?? It happens the resulting rule, what else!?
>
>
>
>
>
> Von: K Post <nntp.p...@gmail.com>
> An: ASSP development mailing list <assp-test@lists.sourceforge.net>
> Datum: 21.08.2017 19:25
> Betreff: Re: [Assp-test] More PDF Javascript catches
> ------------------------------
>
>
>
>
>
> On Mon, Aug 21, 2017 at 12:56 PM, Thomas Eckardt <
> *thomas.ecka...@thockar.com* <thomas.ecka...@thockar.com>> wrote:
>
> >I'm wondering if you should pose your question as a new thread so that
> others who typically ignore threads that they're not originally a part of
> could chime in.
>
> This is the development test list - I expect, that every thread is read by
> everyone.
> But you know they don't. Your call, just a suggestion.
>
>
> >I definitely don't understand the good and blocked syntax of the current
>
> address can be sender and/or recipient (both local and/or foreign)
> block = block-in + block-out
> block-in - for incoming mails
> block-out for outgoing mails
> same for good
>
> rule:
>
> block if
> the mail and flow direction matches a defined block rule
> or
> the mail and flow direction NOT matches a defined good rule
>
>
> just simple - isn't it?
>
> from the GUI
> ..At least one of the above option must be defined in a line - a maximum
> of all (six) could be defined, if this makes sense.....
>
> This should and it is confusing (means read again) .... 'all six' makes
> never sense!!!!
> Yes, but it's unclear if good means that's all that is allowed or if it's
> an override of block.
> And then what happens with inheritance if an inherited policy has a block
> only, line that inherits that has a good, etc.
> And that's why I suggested the - negation syntax, to clear this up. it's
> simple for you, but despite reading the gui many times over and over on
> this section it's not crystal clear as to what happens now. So, as long as
> you're reworking this section, I'm suggesting the simplication.
>
>
> >URL blocking
> I'm sorry, this was an absolutely terrible choice of *file extension* on
> my part. We're blocking the .url extension. Same questions below but this
> time with the .doc extension for clarity:
>
> Good / Block and inheritance
>
> ~policyname => block => exe\-bin|doc|bla
>
> I definitely don't understand the good and blocked syntax of the current
> UserAttach implementation. I think that could use some clarification in
> the gui. If you're reworking the UserAttach concept, maybe we could change
> this?
>
> If policy1 is defined as above, and we want to remove URL blocking for a
> user, how would we do that?
> * => policy1
> *allowwordfileu...@domain.com* <allowwordfileu...@domain.com> => good =>
> doc
> Would that add of doc to good, thereby negating the block inherited from
> policy1?
> Does adding good to the user make it so that doc is the ONLY type that
> person can receive?
> * => policy1
> (-i)*allowwordfileu...@domain.com* <allowwordfileu...@domain.com> =>
> block => policy1|-doc
> in this above example, that user has inheritance turned off, gets policy1
> and -doc removed from that list
> or
> * => policy1
> *allowwordfileu...@domain.com* <allowwordfileu...@domain.com> => block
> => -doc
> Inheritance is on above, and doc is removed from that inherited list (I
> think I like this syntax the best)
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> 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!
> *******************************************************
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Assp-test mailing list
> Assp-test@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
