Okay then if we have a rule with 50 extensions, but we want one user to
only have 49 of those blocked,we'd disable inheritance and have another
rule with the 49 blocks? That would still be WAY better than what we have
now. I look forward to cleaning up our UserAttach exceptions with
simplified rules. Thanks for all of this.
On Mon, Aug 28, 2017 at 1:23 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:
> >*allowdocu...@domain.com* <allowdocu...@domain.com> => block => -doc
> >that would inherit GeneralRule but remove .doc from it
>
> (-extension) will be NOT available
>
> >If we have a very simple policy
> >~GeneralRule => block => exe\-bin|doc|.....and 50 other types
>
> this will be NOT available
>
> policy (block=>.... , good=> ....) will inherit and will be combined
> (-i) in front of a policy to skip inheritance will work
>
> ~Templates can only contain extension sets (exe\-bin|doc|.....and 50
> other types) NOT policy sets
>
> This is the only way to get clear rules and processing. Otherwise it would
> be (for example) possible to define policy set loops.
>
>
>
> Thomas
>
>
>
>
>
>
> Von: K Post <nntp.p...@gmail.com>
> An: ASSP development mailing list <assp-test@lists.sourceforge.net>
> Datum: 28.08.2017 02:00
> Betreff: Re: [Assp-test] More PDF Javascript catches
> ------------------------------
>
>
>
>
> 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* <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* <allowdocu...@domain.com> => block => -doc
> that would inherit GeneralRule but remove .doc from it
>
> We could also do
> (-i)*allowdocu...@domain.com* <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* <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* <nntp.p...@gmail.com>>
> An: ASSP development mailing list <
> *assp-test@lists.sourceforge.net* <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*
> <http://sdm.link/slashdot>_______________________________________________
> Assp-test mailing list
> *Assp-test@lists.sourceforge.net* <Assp-test@lists.sourceforge.net>
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <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*
> <http://sdm.link/slashdot>
> _______________________________________________
> Assp-test mailing list
> *Assp-test@lists.sourceforge.net* <Assp-test@lists.sourceforge.net>
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <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
>
>
>
>
> 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
