Re: [Assp-test] More PDF Javascript catches

[K Post]

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 

Re: [Assp-test] More PDF Javascript catches

[Thomas Eckardt]

>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 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> 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 ou

Re: [Assp-test] More PDF Javascript catches

[K Post]

>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
&

Re: [Assp-test] More PDF Javascript catches

[Thomas Eckardt]

>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> 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 =>  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 =>  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 =>  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

Re: [Assp-test] More PDF Javascript catches

[K Post]

On Mon, Aug 21, 2017 at 12:56 PM, Thomas Eckardt  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 =>  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 =>  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 =>  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

Re: [Assp-test] More PDF Javascript catches

[Thomas Eckardt]

Thank you for the "input" and suggestions.

>Would it be possible to specify sender and recipient pairs?

I'll think about this.

>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.


>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


>URL blocking

? to prevent misunderstandings - this discussion is about attachment 
blocking

to block URL's use URIBL or spamBombs


Thomas




Von:K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum:  21.08.2017 18:17
Betreff:Re: [Assp-test] More PDF Javascript catches



Wow wee!!!  This is terrific news!!
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.

I like the idea of inheritance being turned on by default and using the 
(-i) switch to turn it off for a given rule.  I would ask that as rules 
get further down the inheritance chain that they take precedence.

So if
policy1 is 
 ~policyname => block => exe\-bin|url|ade|adp|asx|

and
* => policy1 
userexecpt...@domain.com =>  block => exe\-bin|:MSOM

then userexcept...@domain.com would have url, ade, adp, asx blocked along 
with exe's blocked EXCEPT for ms office macros even though policy1 is 
inherited (which blocks office macros)

I'm not sure that I have a use for the whitelisted / no processing flags, 
but that might become useful.  I'd also ask here that if you implement 
this, to be sure to make it clear that it's an OR of the type of matches, 
vs a sender needing to be whitelisted and no processing in your (-i wl np) 
example.

Other thoughts:

Would it be possible to specify sender and recipient pairs?

That way we could let one user get a certain type of attachment from one 
other outside user
(from: u...@outside-domain.com)ouru...@domain.com=> exe\-bin|:MSOM

Good / Block and inheritance
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 
allowurlu...@domain.com =>  good => URL
Would that add URL to good, thereby negating the block inherited from 
policy1
Does adding good to the user make it so that URL is the ONLY type that 
person can receive?
* => policy1 
(-i)allowurlu...@domain.com =>  block => policy1|-URL
in this above example, that user has inheritance turned off, gets policy1 
and -URL removed from that list
or
* => policy1 
allowurlu...@domain.com =>  block => -URL
Inheritance is on above, and URL is removed from that inherited list  (I 
think I like this syntax the best)

We'd also need to consider the special case of zip's and encrypted zips.
This functionality works well now.  We'd just need to figure out a clean 
way to keep the syntax clean.
Super excited to see where you take this.  Happy to add input as needed.

THANK YOU


On Sat, Aug 19, 2017 at 4:25 AM, Thomas Eckardt <
thomas.ecka...@thockar.com> wrote:
Hello everyone, 

the attachment level definitions are subject to be obsolet (removed) in a 
future release. Only 'UserAttach' will be available. 

I know, 'UserAttach' can currently be hard to manage - for example in 
large environments. 
What are my plans for this? 

- named policies (templates) can be defined - like: ~policyname => block 
=> bla|blaa , ... 
- policies can be used any where - like : zip:a...@domain.com => 
%policyname% 
- policies can be joined - like: :a...@domain.com => %policy1%|%policy2% 

Where I'm not sure - is it useable to implement a configurable inheritance 
functionality. 

* => policy1 
*@domain.com => policy2|policy3 
us...@domain.com => policy4
(-i)us...@domain.com => policy4
(-i)*@otherdomain.com => policy2|policy5 
us...@otherdomain.com => policy6 

If per default inheritance is enabled. The resulting configurations for 
each of the above lines would be: 

* => policy1 
*@d

Re: [Assp-test] More PDF Javascript catches

[K Post]

Wow wee!!!  This is terrific news!!
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.

I like the idea of inheritance being turned on by default and using the
(-i) switch to turn it off for a given rule.  I would ask that as rules get
further down the inheritance chain that they take precedence.

So if
policy1 is
 ~policyname => block => exe\-bin|url|ade|adp|asx|

and
* => policy1
userexecpt...@domain.com =>  block => exe\-bin|:MSOM

then userexcept...@domain.com would have url, ade, adp, asx blocked along
with exe's blocked EXCEPT for ms office macros even though policy1 is
inherited (which blocks office macros)

I'm not sure that I have a use for the whitelisted / no processing flags,
but that might become useful.  I'd also ask here that if you implement
this, to be sure to make it clear that it's an OR of the type of matches,
vs a sender needing to be whitelisted and no processing in your (-i wl np)
example.

Other thoughts:


   - Would it be possible to specify sender and recipient pairs?

   That way we could let one user get a certain type of attachment from one
   other outside user
   (from: u...@outside-domain.com)ouru...@domain.com=> exe\-bin|:MSOM



   - Good / Block and inheritance
   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
   allowurlu...@domain.com =>  good => URL
   Would that add URL to good, thereby negating the block inherited from
   policy1
   Does adding good to the user make it so that URL is the ONLY type that
   person can receive?
   * => policy1
   (-i)allowurlu...@domain.com =>  block => policy1|-URL
   in this above example, that user has inheritance turned off, gets
   policy1 and -URL removed from that list
   or
   * => policy1
   allowurlu...@domain.com =>  block => -URL
   Inheritance is on above, and URL is removed from that inherited list  (I
   think I like this syntax the best)

   - We'd also need to consider the special case of zip's and encrypted
   zips.
   This functionality works well now.  We'd just need to figure out a clean
   way to keep the syntax clean.

Super excited to see where you take this.  Happy to add input as needed.

THANK YOU


On Sat, Aug 19, 2017 at 4:25 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:

> Hello everyone,
>
> the attachment level definitions are subject to be obsolet (removed) in a
> future release. Only 'UserAttach' will be available.
>
> I know, 'UserAttach' can currently be hard to manage - for example in
> large environments.
> What are my plans for this?
>
> - named policies (templates) can be defined - like: ~policyname => block
> => bla|blaa , ...
> - policies can be used any where - like : zip:a...@domain.com =>
> %policyname%
> - policies can be joined - like: :a...@domain.com => %policy1%|%policy2%
>
> Where I'm not sure - is it useable to implement a configurable inheritance
> functionality.
>
> * => policy1
> *@domain.com => policy2|policy3
> us...@domain.com => policy4
> (-i)us...@domain.com => policy4
> (-i)*@otherdomain.com => policy2|policy5
> us...@otherdomain.com => policy6
>
> If per default inheritance is enabled. The resulting configurations for
> each of the above lines would be:
>
> * => policy1
> *@domain.com => policy1|policy2|policy3
> us...@domain.com =>  policy1|policy2|policy3|policy4
> us...@domain.com => policy4
> *@otherdomain.com => policy2|policy5
> us...@otherdomain.com =>  policy2|policy5|policy6
>
> Or is it more practicable to have the inheritance switched off per default
> and it must be enabled for each line in question (i) ? (I prever the first
> variant - inheritance on per default)
>
> * => policy1
> (i)*@domain.com => policy2|policy3
> (i)us...@domain.com => policy4
> us...@domain.com => policy4
> *@otherdomain.com => policy2|policy5
> (i)us...@otherdomain.com => policy6
>
>
> And the last question - should it be possible to define dependencies for
> the different assp mail flags (whitelisted and noprocessing). like:
>
> (-i wl np)*@otherdomain.com => policy2|policy5
>
> where (-i wl np) will be interpreted as : inheritance OFF, applies to
> whitelisted and noprocessing senders only
>
> Any suggestion on this?
>
> Thomas
>
>
> Von:K Post <nntp.p...@gmail.com>
> An:ASSP development mailing list <assp-test@lists.sourcefo

Re: [Assp-test] More PDF Javascript catches

[Robert K Coffman Jr. -Info From Data Corp.]

> Where I'm not sure - is it useable to implement a configurable 
inheritance functionality.


>Or is it more practicable to have the inheritance switched off per 
default and it must be enabled for each line in question (i) ?


Either style would be OK for me.

> And the last question - should it be possible to define dependencies 
for the different assp mail flags?


I do not currently have a use case for this, so I currently don't need 
it.  Of course that could always change.


- Bob

On 8/19/2017 4:25 AM, Thomas Eckardt wrote:

Hello everyone,

the attachment level definitions are subject to be obsolet (removed) in 
a future release. Only 'UserAttach' will be available.


I know, 'UserAttach' can currently be hard to manage - for example in 
large environments.

What are my plans for this?

- named policies (templates) can be defined - like: ~policyname => block 
=> bla|blaa , ...
- policies can be used any where - like : zip:a...@domain.com => 
%policyname%

- policies can be joined - like: :a...@domain.com => %policy1%|%policy2%

Where I'm not sure - is it useable to implement a configurable 
inheritance functionality.


* => policy1
*@domain.com => policy2|policy3
us...@domain.com => policy4
(-i)us...@domain.com => policy4
(-i)*@otherdomain.com => policy2|policy5
us...@otherdomain.com => policy6

If per default inheritance is enabled. The resulting configurations for 
each of the above lines would be:


* => policy1
*@domain.com => policy1|policy2|policy3
us...@domain.com =>  policy1|policy2|policy3|policy4
us...@domain.com => policy4
*@otherdomain.com => policy2|policy5
us...@otherdomain.com =>  policy2|policy5|policy6

Or is it more practicable to have the inheritance switched off per 
default and it must be enabled for each line in question (i) ? (I prever 
the first variant - inheritance on per default)


* => policy1
(i)*@domain.com => policy2|policy3
(i)us...@domain.com => policy4
us...@domain.com => policy4
*@otherdomain.com => policy2|policy5
(i)us...@otherdomain.com => policy6


And the last question - should it be possible to define dependencies for 
the different assp mail flags (whitelisted and noprocessing). like:


(-i wl np)*@otherdomain.com => policy2|policy5

where (-i wl np) will be interpreted as : inheritance OFF, applies to 
whitelisted and noprocessing senders only


Any suggestion on this?

Thomas


Von: K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum: 14.08.2017 15:22
Betreff: Re: [Assp-test] More PDF Javascript catches




As always, I appreciate your input.  I feared this was going to be your 
response.  Most of these erroneously blocked mails come from big 
providers (like travel agency confirmation pdfs). I'm surprised that 
they have javascript, but they do.  We've been adding exceptions, which 
isn't fun, but is okay.


Do you think there's a way you could change UserAttach, or add another 
exception list, to let us use variables like %LEVEL2% to indicate all of 
the Level 2 defined types and then use + or - notation to add or remove 
types?  That would let us change Level2 in the GUI and not have to then 
go through all of the UserAttach exceptions and update them too.


So something like this:

Our Level 1 is 
exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm 

Our Level 2 is 
(exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm).zip 



This user needs to ALLOW office macros
ouru...@ourcharity.org => block => 
*exe\-bin|:MSOM|*url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|xlsm 



My proposal would be to instead have something like
ouru...@ourcharity.org => block => %Leve2%|+:MSOM   (add the :MSOM 
exception)



Just a thought.  Thanks

On Thu, Aug 10, 2017 at 3:16 AM, Thomas Eckardt 
<_Thomas.Eckardt@thockar.com_ <mailto:thomas.ecka...@thockar.com>> wrote:
One line of bad JS code is enough to completely destroy an IT 
environment (petabytes of data and thousands of machines in some minutes).
Such code can be encrypted, encoded and obviuscated in any not thinkable 
way.


It is simply not possible to classify JS code or to know how any of the 
hundreds PDF viewers will act on such code.


Accepting executable code from a sender is not a matter o

Re: [Assp-test] More PDF Javascript catches

[Thomas Eckardt]

Hello everyone,

the attachment level definitions are subject to be obsolet (removed) in a 
future release. Only 'UserAttach' will be available.

I know, 'UserAttach' can currently be hard to manage - for example in 
large environments.
What are my plans for this?

- named policies (templates) can be defined - like: ~policyname => block 
=> bla|blaa , ...
- policies can be used any where - like : zip:a...@domain.com => 
%policyname%
- policies can be joined - like: :a...@domain.com => %policy1%|%policy2%

Where I'm not sure - is it useable to implement a configurable inheritance 
functionality.

* => policy1
*@domain.com => policy2|policy3
us...@domain.com => policy4
(-i)us...@domain.com => policy4
(-i)*@otherdomain.com => policy2|policy5
us...@otherdomain.com => policy6

If per default inheritance is enabled. The resulting configurations for 
each of the above lines would be:

* => policy1
*@domain.com => policy1|policy2|policy3
us...@domain.com =>  policy1|policy2|policy3|policy4
us...@domain.com => policy4
*@otherdomain.com => policy2|policy5
us...@otherdomain.com =>  policy2|policy5|policy6

Or is it more practicable to have the inheritance switched off per default 
and it must be enabled for each line in question (i) ? (I prever the first 
variant - inheritance on per default)

* => policy1
(i)*@domain.com => policy2|policy3
(i)us...@domain.com => policy4
us...@domain.com => policy4
*@otherdomain.com => policy2|policy5
(i)us...@otherdomain.com => policy6


And the last question - should it be possible to define dependencies for 
the different assp mail flags (whitelisted and noprocessing). like:

(-i wl np)*@otherdomain.com => policy2|policy5

where (-i wl np) will be interpreted as : inheritance OFF, applies to 
whitelisted and noprocessing senders only

Any suggestion on this?

Thomas


Von:K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum:  14.08.2017 15:22
Betreff:Re: [Assp-test] More PDF Javascript catches



As always, I appreciate your input.  I feared this was going to be your 
response.  Most of these erroneously blocked mails come from big providers 
(like travel agency confirmation pdfs).  I'm surprised that they have 
javascript, but they do.  We've been adding exceptions, which isn't fun, 
but is okay.

Do you think there's a way you could change UserAttach, or add another 
exception list, to let us use variables like %LEVEL2% to indicate all of 
the Level 2 defined types and then use + or - notation to add or remove 
types?  That would let us change Level2 in the GUI and not have to then go 
through all of the UserAttach exceptions and update them too.  

So something like this:

Our Level 1 is 
exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm
Our Level 2 is 
(exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm).zip

This user needs to ALLOW office macros
ouru...@ourcharity.org => block => exe\-bin|:MSOM|
url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|xlsm

My proposal would be to instead have something like
ouru...@ourcharity.org => block => %Leve2%|+:MSOM   (add the :MSOM 
exception)


Just a thought.  Thanks

On Thu, Aug 10, 2017 at 3:16 AM, Thomas Eckardt <
thomas.ecka...@thockar.com> wrote:
One line of bad JS code is enough to completely destroy an IT environment 
(petabytes of data and thousands of machines in some minutes). 
Such code can be encrypted, encoded and obviuscated in any not thinkable 
way. 

It is simply not possible to classify JS code or to know how any of the 
hundreds PDF viewers will act on such code. 

Accepting executable code from a sender is not a matter of classification 
- it is a matter of TRUST ! (I trust no one without human code 
verification) 

Define ':CERTPDF' and request the sender to sign there PDF files. 

For now, assp only checks that there is a certificated. In a future 
release the certificates may be verified and/or compared to a provided 
CERT-list. 



Thomas





Von:K Post <nntp.p...@gmail.com> 
An:ASSP development mailing list <assp-test@lists.sourceforge.net> 

Datum:09.08.2017 15:54 
Betreff:[Assp-test] More PDF Javascript catches 





I really like the javascript detection in PDF files, but I've seen lots of 
false positives too.   

I 

Re: [Assp-test] More PDF Javascript catches

[K Post]

As always, I appreciate your input.  I feared this was going to be your
response.  Most of these erroneously blocked mails come from big providers
(like travel agency confirmation pdfs).  I'm surprised that they have
javascript, but they do.  We've been adding exceptions, which isn't fun,
but is okay.

Do you think there's a way you could change UserAttach, or add another
exception list, to let us use variables like %LEVEL2% to indicate all of
the Level 2 defined types and then use + or - notation to add or remove
types?  That would let us change Level2 in the GUI and not have to then go
through all of the UserAttach exceptions and update them too.

So something like this:

Our Level 1 is
exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm
Our Level 2 is
(exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm).zip

This user needs to ALLOW office macros
ouru...@ourcharity.org => block => *exe\-bin|:MSOM|*
url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|xlsm

My proposal would be to instead have something like
ouru...@ourcharity.org => block => %Leve2%|+:MSOM   (add the :MSOM
exception)


Just a thought.  Thanks

On Thu, Aug 10, 2017 at 3:16 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:

> One line of bad JS code is enough to completely destroy an IT environment
> (petabytes of data and thousands of machines in some minutes).
> Such code can be encrypted, encoded and obviuscated in any not thinkable
> way.
>
> It is simply not possible to classify JS code or to know how any of the
> hundreds PDF viewers will act on such code.
>
> Accepting executable code from a sender is not a matter of classification
> - it is a matter of TRUST ! (I trust no one without human code verification)
>
> Define ':CERTPDF' and request the sender to sign there PDF files.
>
> For now, assp only checks that there is a certificated. In a future
> release the certificates may be verified and/or compared to a provided
> CERT-list.
>
>
>
> Thomas
>
>
>
>
>
> Von:K Post <nntp.p...@gmail.com>
> An:ASSP development mailing list <assp-test@lists.sourceforge.net>
> Datum:09.08.2017 15:54
> Betreff:[Assp-test] More PDF Javascript catches
> --
>
>
>
>
> I really like the javascript detection in PDF files, but I've seen lots of
> false positives too.
>
> I keep meaning to report it.  One file that just got caught has only 2
> lines of javascript
>
> 6 0 obj
> <>
> endobj
>
>
> and
>
> 33 0 obj
> <>
> endobj
>
> Is there anything more that could be done to be less aggressive but still
> give us good protection?
>
> Thanks! 
> --
> 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

Re: [Assp-test] More PDF Javascript catches

[Thomas Eckardt]

One line of bad JS code is enough to completely destroy an IT environment 
(petabytes of data and thousands of machines in some minutes).
Such code can be encrypted, encoded and obviuscated in any not thinkable 
way.

It is simply not possible to classify JS code or to know how any of the 
hundreds PDF viewers will act on such code.

Accepting executable code from a sender is not a matter of classification 
- it is a matter of TRUST ! (I trust no one without human code 
verification)

Define ':CERTPDF' and request the sender to sign there PDF files.

For now, assp only checks that there is a certificated. In a future 
release the certificates may be verified and/or compared to a provided 
CERT-list.



Thomas





Von:K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum:  09.08.2017 15:54
Betreff:    [Assp-test] More PDF Javascript catches




I really like the javascript detection in PDF files, but I've seen lots of 
false positives too.  

I keep meaning to report it.  One file that just got caught has only 2 
lines of javascript

6 0 obj
<>
endobj


and

33 0 obj
<>
endobj

Is there anything more that could be done to be less aggressive but still 
give us good protection?

Thanks! 
--
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

[Assp-test] More PDF Javascript catches

[K Post]

I really like the javascript detection in PDF files, but I've seen lots of
false positives too.

I keep meaning to report it.  One file that just got caught has only 2
lines of javascript

6 0 obj
<>
endobj


and

33 0 obj
<>
endobj

Is there anything more that could be done to be less aggressive but still
give us good protection?

Thanks!
--
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